I am working on DeepRSS

Тайна, покрытая мраком...

Почему следует избегать специализации обобщений для базовых классов и интерфейсов в C#

За этой статьей стоит одна бессонная ночь, проведенная в холодном дебагере Вижуалстудии. Я совершил ошибку. Интересную ошибку, которой спешу поделиться.

Речь пойдет об обобщениях в C#, их конкретизации и о том, что иногда не стоит доверять ни компилятору, ни собственному интеллекту, а просто не наследовать от мухи слона, заводя огромное количество ненужных абстракций.

Длинная вводная

Для начала, давайте определимся с понятиями.

Под Обобщениями я подразумеваю общие (или параметризованные) типы в языке C#. В англоязычной литературе они называются Generics. Более подробно про обобщения можно прочитать тут: Обобщения (Глава из книги “Язык программирования C# 2005 (Си Шарп) и платформа .NET 2.0”)

Под специализацией обобщения, чтобы не начинать словоблудие, я понимаю вот это:

static void PrintAllItems<T>(T collection) where T:IEnumerable
{
 // foreach работает медленно, зато универсально
 foreach (var item in collection)
 {
     Console.WriteLine("IEnumerable: " + item.ToString());
 }
}

static void PrintAllItems(int[] intCollection)
{
 // for работает быстрее foreach
 for (int i = 0; i < intCollection.Length; i++ )
 {
     Console.WriteLine("int: " + intCollection[i]);
 }
}

Метод PrintAllItems(T collection) - это обобщенный метод.
Метод PrintAllItems(int[] intCollection) – это специализация обобщеного метода.

И теперь, метод PrintAllItems будет работать для всех IEnumerable – типов одинаково, кроме типа int[], для которого метод будет работать немного иначе (хотя, int[] точно также реализует IEnumerable как и double):

static void Main(string[] args)
{
  double[] doubleArray = { 1.1, 2.2, 3.3};
  int[] intArray = { 1, 2, 3 };

  PrintAllItems(doubleArray);
  PrintAllItems(intArray);
}

Результат:

IEnumerable: 1.1
IEnumerable: 2.2
IEnumerable: 3.3
int: 1
int: 2
int: 3

И наконец-то, почему же таки следует избегать конкретизации обобщений для базовых классов и интерфейсов
Чем проще писать программисту код, используя такие синтаксические сладости, как перегрузки методов и обобщения, тем сложнее компилятору разрешать эти самые перегрузки. Ведь практически каждый обобщенный метод может соответствовать любому типу. Может получиться так, что приложение будет работать очень странно. Тут все зависит от вашей осторожности… или неосторожности. Именно вы (и я в том числе), ответственны за создание методов, которые, не должны… должны создавать минимальное, замешательство для программиста, использующего ваш код и для вас самих.
Будьте осторожны. Ваши обобщенные методы могут быть более обобщение того, чего от них ожидают.
Да, ваши обобщенные методы могут быть неожиданно универсальны, и поверьте, что это не всегда хорошо.

Давайте рассмотрим следующий пример. А пока вы читаете код, постарайтесь угадать, что и в какой последовательности он выведет на экран.

using System;
namespace ConsoleApplication6
{
   public class MyAnimalBase
   {
   }
   public interface ISayableAnimal
   {
       void Say();
   }
   public class MyCatDerived : MyAnimalBase, ISayableAnimal
   {
       #region ISayableAnimal Members
       void ISayableAnimal.Say()
       {
           Console.WriteLine("Inside MyCatDerived.Say");
       }
       #endregion
   }
   public class AnotherCow : ISayableAnimal
   {
       #region ISayableAnimal Members
       public void Say()
       {
           Console.WriteLine("Inside AnotherCow.Say");
       }
       #endregion
   }
   class Program
   {
       static void WriteMessage(MyAnimalBase b)
       {
           Console.WriteLine("Inside Say(MyAnimalBase)");
       }
       static void WriteMessage<T>(T obj)
       {
           Console.Write("Inside Say<T>(T): ");
           Console.WriteLine(obj.ToString());
       }
       static void WriteMessage(ISayableAnimal obj)
       {
           Console.Write(
           "Inside Say(ISayableAnimal): ");
           obj.Say();
       }
       static void Main(string[] args)
       {
           MyCatDerived d = new MyCatDerived();
           Console.WriteLine("01 Calling Program.Say");
           WriteMessage(d);

           Console.WriteLine();
           Console.WriteLine(
               "02 Calling through ISayableAnimal interface");
           WriteMessage((ISayableAnimal)d);
          
           Console.WriteLine();
           Console.WriteLine("03 Cast to base object");
           WriteMessage((MyAnimalBase)d);
          
           Console.WriteLine();
           Console.WriteLine("04 Another Type test:");
           AnotherCow anObject = new AnotherCow();
           WriteMessage(anObject);
          
           Console.WriteLine();
           Console.WriteLine("05 Cast to ISayableAnimal:");
           WriteMessage((ISayableAnimal)anObject);
       }
   }
}

И вывод будет следующим:

01 Calling Program.Say
Inside Say(T): ConsoleApplication6.MyCatDerived

02 Calling through ISayableAnimal interface
Inside Say(ISayableAnimal): Inside MyCatDerived.Say

03 Cast to base object
Inside Say(MyAnimalBase)

04 Another Type test:
Inside Say(T): ConsoleApplication6.AnotherCow

05 Cast to ISayableAnimal:
Inside Say(ISayableAnimal): Inside AnotherCow.Say

По себе знаю, уважаемый читатель, что вы, скорее всего не бросились анализировать скучный код, сопоставляя его с результатом выполнения.
Давайте разберемся вместе, что же все-таки произошло.
Первый тест показывает, и это очень важно запомнить, то, что WriteMessage(T obj) лучше соответствует типу, чем WriteMessage(MyAnimalBase b), для объекта, который унаследован от MyAnimalBase. Это потому, что компилятор идет по пути наименьшего сопротивления, и создает метод, который абсолютно соответствует типу MyCatDerived, превращая T в MyCatDerived.
А вот метод WriteMessage(MyAnimalBase b) требует преобразования типа. Это сложнее для компилятора, а значит -- WriteMessage(T obj) лучше.

Но, давайте отойдем от абстрактных примеров с животными и используем пример с IQueryable, который, как вам известно наследуется IEnumerable. Как вы думаете, победит ли Say(IEnumerable enumerable) хотя бы раз?

static void Say<T>(T obj)
{
    Console.WriteLine("Say<T> won!!!");
}

static void Say(IEnumerable enumerable)
{
    Console.WriteLine("IEnumerable won!!!");
}

static void Main(string[] args)
{
    int[] a = {1, 2, 3};

    IQueryable q = a.AsQueryable();

    Say(a);
    Say(q);
}

Нет. Не победит.

Say won!!!
Say won!!!

Именно это и было причиной моей бессонной ночи, о которой я упомянул вначале статьи. Но, вернемся к нашим барана…, то есть животным.

Следующие тесты показывают, что поведение компилятора можно все-таки контролировать путем явного приведение типа к интерфейсу или базовому классу.
Разрешение имен – это тема очень интересная. Только, к сожалению, бой между интеллектом программиста и компилятором всегда выиграет компилятор.

А победа на войне – за нами!

По мотивам книги «More Effective C# 50 Specific Ways to Improve Your C#»
Глава: Item 7. Do Not Create Generic Specialization on Base Classes or
Interfaces

31 день с Silverlight :: День #1: События мыши в Silverlight

Полный список англоязычный постов, вы можете найти тут: 31 Days of Silverlight Series = Awesome!


Оригинал англоязычного поста: Day #1: Mouse Events in Silverlight

В своем первом посте «31 день с Silverlight», мы сосредоточимся на обработчиках событий мыши. В случае интерактивных приложений, вы всегда желаете знать, когда пользователи работают с вашим приложением при помощи мыши. Это руководство расскажет о различных событиях мыши, и о том, как их использовать. Итак, давайте же сделаем первый шаг, на пути к освоению этой не сложной, но очень интересной темы

Событие MouseEnter

Я собираюсь продемонстрировать работу этого события на двух уровнях. Первым будет событие MouseEnter по всему Silverlight-контролу. Это событие будет возбуждено, когда курсор мыши входит в пространство, занимаемое Silverlight-контролом. Второе событие будет срабатывать при наведении мыши на круг, находящийся середине пользовательского контрола. Вот наш начальный XAML код.

<UserControl x:Class="SilverlightMouseEvents.MouseEnterDemo"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
  Width="400" Height="300">
  <Grid x:Name="LayoutRoot" Background="White">
    <Ellipse x:Name="myEllipse" Fill="Blue" Width="150" Height="150" />
  </Grid>
</UserControl>

Теперь я добавлю обработчики событий в XAML, и покажу вам, как сделать это в C# коде. Вот измененный XAML код вместе с добавленными обработчиками событий.

<UserControl x:Class="SilverlightMouseEvents.MouseEnterDemo"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
  Width="400" Height="300" MouseEnter="UserControl_MouseEnter">
  <Grid x:Name="LayoutRoot" Background="White">
    <Ellipse x:Name="myEllipse" Fill="Blue" Width="150" Height="150" MouseEnter="myEllipse_MouseEnter" />
  </Grid>
</UserControl>

Теперь нам необходимо перейти на code-behind файл кодом на C#, для реализации обработчика событий. Как только я создал обработчиков событий в XAML коде, студия автоматически создала для меня заготовки методов обработки событий в C# коде. Вот как выглядит первоначальное содержимое C# code-behind файла:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;

namespace SilverlightMouseEvents
{
  public partial class MouseEnterDemo : UserControl
  {
    public MouseEnterDemo()
    {
      InitializeComponent();
    }

    private void UserControl_MouseEnter(object sender, MouseEventArgs e)
    {

    }

    private void myEllipse_MouseEnter(object sender, MouseEventArgs e)
    {

    }
  }
}

Для того, чтобы сохранить разумной длину этого поста, я не буду делать ничего сложного в моих обработчиках событий, но я покажу вам, как изменить цвет эллипса. Я добавил одну строку кода в каждый метод, и каждый из них закрашивает эллипс другим цветом. Сейчас, когда мы перемещаем курсор мыши в области Silverlight приложения — круг будет залит зеленым цветом, а когда курсор мыши окажется внутри круга — фигура будет закрашена пурпурным.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;

namespace SilverlightMouseEvents
{
  public partial class MouseEnterDemo : UserControl
  {
    public MouseEnterDemo()
    {
      InitializeComponent();
    }

    private void UserControl_MouseEnter(object sender, MouseEventArgs e)
    {
      myEllipse.Fill = new SolidColorBrush(Colors.Green);
    }

    private void myEllipse_MouseEnter(object sender, MouseEventArgs e)
    {
      myEllipse.Fill = new SolidColorBrush(Colors.Purple);
    }
  }
}

Событие MouseLeave

Это событие работает практически точно также, как и событие MouseEnter. MouseLeave срабатывает тогда, когда курсор мыши ПОКИДАЕТ некую область. Что еще можно сюда добавить, а? На этот раз, однако, я вообще не делал изменений в моем XAML коде. Так вот, еще раз привожу начальный XAML код.

<UserControl x:Class="SilverlightMouseEvents.MouseLeaveDemo"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
  Width="400" Height="300">
  <Grid x:Name="LayoutRoot" Background="White">
    <Ellipse x:Name="myEllipse" Fill="Blue" Width="150" Height="150" />
  </Grid>
</UserControl>

На этот раз я сделаю все в C#-коде. Я добавлю обработчики событий в момент инициализации приложения. Вот мое окончательное решение на C#:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;

namespace SilverlightMouseEvents
{
  public partial class MouseLeaveDemo : UserControl
  {
    public MouseLeaveDemo()
    {
      InitializeComponent();
      this.MouseLeave += new MouseEventHandler(MouseLeaveDemo_MouseLeave);
      myEllipse.MouseLeave += new MouseEventHandler(myEllipse_MouseLeave);
    }

    void myEllipse_MouseLeave(object sender, MouseEventArgs e)
    {
      myEllipse.Fill = new SolidColorBrush(Colors.Purple);
    }

    void MouseLeaveDemo_MouseLeave(object sender, MouseEventArgs e)
    {
      myEllipse.Fill = new SolidColorBrush(Colors.Green);
    }
  }
}

Событие MouseLeftButtonDown

В этом случае, я продолжаю использовать тот же самый XAML код. Единственным изменением является ссылка на наш новый класс MouseLeftButtonDownDemo из XAML кода нашего юзер-контрола. Я уже показал, как использовать обработчики событий как в XAML, так и в C# коде. Вы уже видели XAML, так что я просто покажу только C# код.

Событие MouseLeftButtonDown, как вы уже догадались, срабатывает при нажатии левой кнопки мыши Пожалуйста, обратите внимание, что код этого примера так же охватывает пример события MouseLeftButtonUp, которое рассматривается ниже, и то, что значительной разницы между ними нет. Это будет особенно очевидно, когда мы займемся реализацией Drag & Drop. Вот пример добавления события MouseLeftButtonDown в наш код.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;

namespace SilverlightMouseEvents
{
  public partial class MouseLeftButtonDownDemo : UserControl
  {
    public MouseLeftButtonDownDemo()
    {
      InitializeComponent();
      this.MouseLeftButtonDown += new MouseButtonEventHandler(MouseLeftButtonDownDemo_MouseLeftButtonDown);
      myEllipse.MouseLeftButtonDown += new MouseButtonEventHandler(myEllipse_MouseLeftButtonDown);
    }

    void myEllipse_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)
    {
      myEllipse.Fill = new SolidColorBrush(Colors.Green);
    }

    void MouseLeftButtonDownDemo_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)
    {
      LayoutRoot.Background = new SolidColorBrush(Colors.Purple);
    }
  }
}

Событие MouseLeftButtonUp

До сих пор мы создавали отдельные методы-обработчики событий для каждого отдельного события. Во множестве случаев, вы обязательно захотите, чтобы разные элементы управления вызывали один и тот же метод обработки событий, чтобы каждый раз не писать один и тот же код обработки событий. В следующем примере, я добавлю еще один круг внутрь StackPanel. Обе эти фигуры будут менять свой фон на оранжевый. Вот наш новый, дополненный, XAML код:

<UserControl x:Class="SilverlightMouseEvents.MouseLeftButtonUpDemo"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
  Width="400" Height="300">
  <StackPanel x:Name="LayoutRoot" Background="White" Orientation="Horizontal" HorizontalAlignment="Center" >
    <Ellipse x:Name="myEllipse" Fill="Blue" Width="150" Height="150" />
    <Ellipse x:Name="myEllipse2" Fill="Red" Width="150" Height="150" />
  </StackPanel>
</UserControl>

Теперь мы добавим обработчик события MouseLeftButtonUp в нашем C# коде:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;

namespace SilverlightMouseEvents
{
  public partial class MouseLeftButtonUpDemo : UserControl
  {
    public MouseLeftButtonUpDemo()
    {
      InitializeComponent();
      myEllipse.MouseLeftButtonUp += new MouseButtonEventHandler(Ellipse_MouseLeftButtonUp);
      myEllipse2.MouseLeftButtonUp += new MouseButtonEventHandler(Ellipse_MouseLeftButtonUp);
    }

    void Ellipse_MouseLeftButtonUp(object sender, MouseButtonEventArgs e)
    {
      Ellipse myCircle = sender as Ellipse;
      myCircle.Fill = new SolidColorBrush(Colors.Orange);
    }
  }
}

Как видите, в теперь наш обработчик состоит из двух строк кода. Теперь нам необходимо получить ссылку на эллипс, который на самом деле вызвал метод-обработчик. Параметр «sender» содержит эту информацию, так что, с его помощью мы и получаем ссылку на эллипс, и заполняем фигуру необходимым цветом.

Событие MouseMove

В этом последнем примере, мы используем событие MouseMove. Это событие срабатывает каждый раз, когда курсор мыши меняет свои координаты. Вы можете контролировать перемещение мыши как по всей площади приложения, так и для конкретного элемента. В любом случае, вы можете сделать довольно много полезных вещей при помощи этого события, в том числе и реализовать перетаскивания элементов (Drag and Drop). (Drag and Drop мы рассмотрим в будущем посте).

Мой XAML настоящее время состоит из двух TextBox'ов на странице. Первый я, ловко, назвал Xbox, а второй — Ybox. Мы будем отображать новые X и Y координаты мыши в этих полях, каждый раз, в момент перемещения пользователем курсора мыши.

<UserControl x:Class="SilverlightMouseEvents.MouseMoveDemo"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
  Width="400" Height="300" VerticalAlignment="Center">
  <StackPanel x:Name="LayoutRoot" Background="White">
    <TextBox x:Name="Xbox" Width="200" Height="35" Text="X" />
    <TextBox x:Name="Ybox" Width="200" Height="35" Text="Y"/>
  </StackPanel>
</UserControl>

Сейчас C# code behind файл выглядит не слишком сложными. В данном примере мы используем параметр MouseEventArgs, от которого мы получим текущие координаты мыши. После чего, просто запишем значения координат в текстовые поля.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;

namespace SilverlightMouseEvents
{
  public partial class MouseMoveDemo : UserControl
  {
    public MouseMoveDemo()
    {
      InitializeComponent();
      this.MouseMove += new MouseEventHandler(MouseMoveDemo_MouseMove);
    }

    void MouseMoveDemo_MouseMove(object sender, MouseEventArgs e)
    {
      Xbox.Text = e.GetPosition(null).X.ToString();
      Ybox.Text = e.GetPosition(null).Y.ToString();
    }
  }
}

Резюме

Это был краткий обзор событий мыши, которые доступны вам в Silverlight. Используя их вместе, можно создать очень интерактивный и динамичный интерфейс для пользователя. В завтрашнем посте, мы поговорим об интересных способах работы с экраном в Silverlight. И не только о возможности перехода с одного XAML файла на другой, но и о том, как реализовать PowerPoint-подобные переходы с одного экрана на другой.

< link > GlassDoor – сервис, на котором можно узнать про зарплаты в Google, Microsoft, Facebook, Yahoo

… И есть даже информация про Украинские компании, хотя, очень мало. Работа сайта базируется на анонимных анкетах пользователей. Можно оценить компанию, дать отзыв, рассказать о зарплате и.т.д. Такие анонимные анкеты, по моему субъективному мнению, могут быть довольно точными.

GlassDoor.com

Неофициальная история конструирования ПО

В начале, был один ярус, и это было хорошо . В бородатых восьмидесятых, был один мейнфрейм и тысячи «немых» терминалов пользователей, которые были подключения к одной и только одной Большой Железяке. Эти 3270 терминалов называли «немыми», потому что у них была только клавиатура и монитор. Без процессора. Это было просто устройство ввода / вывода.


Два яруса . Благодаря Биллу Гейтсу, компьютеры, в комплекте с их собственными процессорами, ушли в массы, а в конце 80-х и начале 90-х я был разработки клиент-серверных приложений с "толстым клиентом" — часть расчетов осуществлялась на локальной машине, а данные находились в базе данных на уделенном сервере. Жизнь была легкой и простой. И резюме разработчиков были точно такими же легкими и простыми. Вам было только необходимо знать SQL для работы с данными и какой-нибудь язык программирования. Вот, например C++… Ах, Вам тяжело его изучить? Используйте SQLWindows, PowerBuilder, Visual Basic или даже Delphi!
Основной темой для обсуждения была: где реализовывать бизнес-логику — на стороне клиента или в базе данных, как набор хранимых процедур? В последнем случае, вы были вынуждены мастерски владеть процедурными языками СУБД, например, такими как T-SQL или PL/SQL. Но, больше от Вас ничего не требовалось.
Архитектура приложений по-прежнему оставалась простой. При запуске, приложение не требовало от вас подключения к Интернету, и это было хорошо. Приложения запускались на локальном компьютере, и работало в локальной сети. Конечно же, если сервер баз данных падал или слишком многие пользователи одновременно хотели получить данные, то в работе Вашего локального приложения могли бы возникнуть проблемы и перебои. Но, это было единственное узкое место, да и случалось такое не каждый день.

Три яруса. В середине девяностых годов, создание веб-браузеров, открыло Интернет для общественности. Предприятия с нетерпением переделывали их проверенные и надежные клиент-серверные системы для того, чтобы просто сделать их доступными в Интернете. Зачем? Потому что они могли это сделать. Именно с этого момента все начало усложнятся. Тонкий HTML клиент взаимодействовал веб-сервером, либо мог предоставлять статический контент (тексты, изображения), не используя для этого к помощи стороннего ПО, а при необходимости, можно легко передать управление на другой сервер для более продуктивной работы. Интернет провайдеры предлагали пропускную способность для продажи. Сетевые соединения были медленными. Тонкие клиенты выглядели очень плохо по сравнению с толстыми клиентами на Visual Basic или PowerBuider.
Вопрос остался прежним: «Где размещать бизнес-логику?» Уж точно не на тонком клиенте. Теперь выбор был либо где-то веб-сервере или в СУБД. Одного только веб-сервера уже было недостаточно. Так как я сам из мира Java, то хочу объяснить Вам, что же там происходило.

Множество ярусов . Средний ярус превратился в несколько уровней. Веб сервер взаимодействовал со Сервлет-контейнером, который в свою очередь взаимодействовал с контейнером EJB, который либо работал с СУБД непосредственно либо просто помещает сообщение в очередь Message-Oriented Middleware. Чтобы сделать это еще более гибким, добавьте в коктейль несколько служб контроля доступа, так чтобы Java сначала посмотрела туда, перед тем как поместить сообщение в очередь. Давайте не будем забывать и о демилитаризованных зонах (DMZ), которые увеличивают общее число ярусов.
Вот когда появилось Новое Поколение Разработчиков. Эти люди, называющие себя Архитекторами программного обеспечения. Они требовали чтобы логические слои были специфичны и заточены под разрабатываемый проект. И они хотели их сейчас! Книга по шаблонам проектирования от «банды четырех» была легко доступна, — и шабаш начался.

Это было время расцвета фреймворков для создания ПО.

Если разработчик Java не знал Struts в начале этого века, то его шансы быть нанятым для разработки Enterprise проектов были близки к нулю. Сейчас все больше и больше людей понимают, что Struts был еще одним недопеределанным бесполезным MVC фреймворком, который усложнял архитектуру тысяч приложений. Но само существование таких фреймворков получило теплый прием и даже овации в легионах быдлокодеров (Code monkey), которые поняли, что они могут зарабатывать на жизнь, вставляя if и else в шаблоны, предоставленные местными архитекторами. Заканчивать ВУЗ для получения диплома по компьютерным наукам уже не нужно.
Первое десятилетие 21-го века подходит к концу, и мы все еще живем в очень хрупком мире программного обеспечения с дести ярусными архитектурами. Каждый дополнительный уровень (как движущуюся часть) делает архитектуру еще более хрупкой. Каждая подвижная часть покупается с дополнительными расходами — технической поддержкой. Но в мутной воде многоуровневых архитектур, команды поддержки довольно быстро начинают играть в игру перевода стрелок друг на друга.
Бюджет первоначально выделенных на проект, получает опустошается довольно быстро, владелец проекта начинает урезать функционал для экономии средств, что оставляет ему несколько кое-как работающих приложений. Это здорово, что наши офшорные партнеры готовы протянуть руку помощи! Мы в ней нуждается. Это как присланные деньги от родителей для студента, живущего в общежитии.

Два яруса . Вот уже прошло две недели, как началось второе десятилетие 21-го века. Я очень надеюсь, что мы вернемся назад к двухуровневой архитектуре. Как же так? Клиенты взаимодействуют облаком, это и создает всего два яруса. Вы можете утверждать, что облако само по себе содержит несколько уровней внутри, но это все немного по другому. Облако может поддерживаться одним поставщиком, а с точки зрения клиента это единая часть программного обеспечения.

Приложение клиента запускается локально, оно имеет локальное хранилище, что позволяет работать как в онлайн, так и в офлайн режиме. И данных и код находятся настолько близко к пользователю, насколько это возможно. Вы думаете, почему Microsoft Excel является наиболее популярным программным обеспечением среди бизнес-пользователей на предприятиях? Потому что Excel позволяет пользователю иметь свой маленький кусочек данных и любительский, но рабочие код (формулы) очень близко. Прямо на рабочем столе. Нет необходимости просить этих Всемогущих Админов о милости и помощи. Нет зависимости от сетевого подключения или каких-то таинственных серверов, которые могут работать медленно или падать. Наиболее продвинутые пользователи даже научиться работать с базами данных MS Access, чтобы уменьшить зависимость от отдела IT. Так держать!

Рассмотрим пример автоматизации продаж. В настоящее время, наша компания работает над программным обеспечением, предназначенным для автоматизации работы страховых агентов. Я просто приведу один пример. Мы храним цифровые подписи клиентов в базе данных. Агент приходит в дом клиента, заполняет электронные формы и просит человека поставить подпись пальцем прямо по стеклу смартфона работающего под Android. Приложение на Adobe AIR сохраняет эту оцифрованную подпись в локальной базе данных смартфона. Как только агент сможет получить доступ к любой сети Wi-Fi, он сможет синхронизировать локальные данные с любым ПК или облаком. Разве это не в два яруса? Продавец может запустить и работать с приложением в независимости от наличия соединение с Интернетом. Когда соединение будет доступно, данные можно будет синхронизировать Уровнем 2. Вот и все. Клиент-Сервер вернулся.

Один ярус. Шансы довольно высоки, что через 10-15 лет мы снизим число уровней архитектуры обратно в один ярус превратить наши смартфоны в немые терминалы.
«Да, возможно я и мечтатель. Но я такой не один»
Джон Леннон

---

Оригинал: The Unofficial History of Software Engineering

Про эту замечательную статью я узнал из подкаста автора статьи Якова Файна (Будама). За что что ему спасибо. ;)

Если Вы хотите прослушать его комментарии к статье, то прошу Вас проследовать по ссылке ниже:
Америчка: #267 Неофициальная история конструирования ПО

Перевод статьи с английского на русский: Дмитрий Жарий

Вы хотите быть Специалистом или Генералистом?

Эта мысль, без сомнения, на том или ином этапе жизни посещает каждого из нас. В какой-то момент вы чувствуете, что подошли к перекрестку судьбы, и задаете себе вопрос: “Должен ли я углубить свои знания и навыки в моем любимом языке программирования или фреймворке и изучить в нем каждую мелочь?” Или я должен расширить свой кругозор и изучить смежные инструменты и технологии или даже изучить новые языки программирования и платформы? Этот вопрос может, действительно, ввести вас в заблуждения при поиске правильного пути. Есть слишком много аргументов за и против. Даже если вы обратитесь к кому-нибудь за советом, этого не сделает дорогу ясной для вас, и, более того, перед вами откроется ряд новых путей, которые усложнят выбор.

Давайте рассмотрим аргументы в поддержку этих альтернатив более детально.

Рассматривая возможность стать специалистом, вы, вероятно, думаете о превращении в какого-то гуру, который будет знать все о какой-либо технологии, фреймворке или продукте. Специалистов не много, так что вы могли бы, потенциально, найти высокооплачиваемую работу в компании, которая не может жить без вашего опыта. Правильно? Ну… теоретически да, логика здесь есть. Но, реальность, конечно же, сильно отличается от теории. Истинна заключается в том, что большинство компаний никогда не доводят свои проекты до такой степени сложности и размера, что присутствие гуру на проекте становиться жизненно необходимым. Чем более вы позиционируете себя как специалиста, тем более сужается выбор мест, куда вы потенциально можете идти. И, возможно, что в регионе, в котором вы живете, такой ниши может не оказаться вовсе.

Это не означает, что вы не должны изучать ваши инструменты в глубину, а должны знать их только поверхностно. Совсем наоборот, вы должны знать все, что вам необходимо сейчас, и даже за пределами своих сегодняшних потребностей. Это увеличит ваше понимание внутренней работы инструментов. Вы будете писать лучший код. Вы найдете ошибки более легко. Вы сможете найти выход из нестандартных ситуаций. Вы будете знать больше способов того, как забить гвоздь вашим молотком. Но в какой-то момент, вам придется прекратить копать и посмотреть вокруг. Ведь есть много других, интересных и не менее полезных вещей для изучения.

Есть еще одна очевидная опасность для специалиста. В сфере разработки ПО все меняется чрезвычайно быстро. Новые великолепные языки и фреймворки появляются из ниоткуда, вспыхивают как яркая звезда и, погружаются в небытие. Инструменты стареют, заменяются новыми версиями, которые, в свою очередь, стареют и, в итоге, выходят из употребления. Все движется вперед. Если вы делаете ставку не на ту лошадь, если вы вкладываете все время в обучение одной конкретной технологии, вы рискуете потерять ставку, если лошадь не победит.

Так что, генералистом быть лучше? Ответ обычный: все зависит от ситуации, от рынка, и от вас. Однако этот подход имеет свои сильные стороны.

Во-первых, подход генералиста расширит границы ваших знаний. Вас не загонит в тупик ситуация, когда конкретная технология начинает доставлять массу проблем. Знание различных технологий и инструментов дает возможность сравнить возможные решения, которые позволяет реализовать каждая из них, и выбрать ту технологию, которая наилучшим образом соответствует вашим задачам. Если мы говорим не о сопоставимых либо конкурирующих технологиях, а про различные навыки, которые находят свое применение в рамках одного проекта, это даст вам возможность увидеть проблему в различных слоях технологии и проанализировать ее на различных уровнях абстракции. Вы можете сравнить варианты реализаций, и сделать вывод: где и как необходимо решать конкретную проблему. Предположим, мы говорим о классическом многоуровневом приложении, где есть база данных, уровень бизнес-логики и слой пользовательского интерфейса. Если вы будете компетентны в разработке каждого их этих слоев – это позволит решить проблему намного быстрее и легче. Вместо оптимизации каждого байта приложения, вы можете посмотреть на проблему с другой точки зрения: просто собрать и настроить готовое приложения, которое просто выполняет свою задачу. Вам не всегда жизненно необходимо настраивать сверх оптимальное кеширование на стороне сервера? А как на счет тонкой настройки пользовательского интерфейса, чтобы избежать запуска сложных запросов несколько раз? Или это надуманная проблема, и, скорее всего, ваш пользователь совершенно не нуждается в этой фиче? Видите? Вы можете думать о различных условиях, в которых будет работать ваше приложение, и это дает вам определенную свободу духа, чтобы найти наиболее эффективное и элегантное решение.

Но, давайте пойдем дальше. Если вы являетесь специалистом по различным технологиям, то ваш набор знаний и навыков становиться все более отшлифованным. И это превращает вас в эффективную команду из одного человека. Вы самодостаточны, знакомы со всеми аспектами текущего проекта, вы способны завершить практически самостоятельно, без посторонней помощи со стороны специалистов и гуру. И это уже является минимальным требованием для веб-разработчиков: каждому необходимо иметь практические знания всех составных частей веб-проекта. Вы должны знать ваш фреймворк, быть знакомым с базами данных и иметь возможность создавать HTML разметку для пользовательского интерфейса. У нас есть данные, которые необходимо собирать и хранить? Вот, здесь я разработал модель данных, создал индексы, написал необходимые запросы и оптимизировал работу с базой данных для нашего конкретного сценария. Нам необходимо приложение для взаимодействия с базой данных? Подождите минутку, вот код, реализация ввода данных, их проверка, бизнес-правила и разграничение уровня доступа к данным – все готово. Чудесно. А где же наш яркий и сияющий пользовательский интерфейс? Всё тут же, это валидный HTML и CSS. Хотите еще Ajax? Дайте мне пять минут. Готово, проверяйте!

Узнали себя? Вы можете делать все это и многое другое, и вам это нравиться. Либо вы один и тех, кто посвятил большую часть своей жизнь тому, чтобы стать гуру базы данных? Или вы интерфейсный разработчик, владеющий HTML, CSS и семантической разметкой, но вы никогда не работали с базами данных. Что? Вы боитесь баз данных? Нет, это действительно не страшно, обязательно попробуйте, когда ни будь.

Поймите меня правильно. Я очень уважаю специалистов и профессионалов. Их глубокие знания технологий, могут оказаться очень полезными. Иногда они могут дать вам такое решение, к которому вы бы не пришли самостоятельно. Я всегда чувствую, небольшое, но в то же время просвещения после получения совета от них. И я бесконечно благодарен им за откровенность и затраченное на меня время.

Несмотря на это, я понимаю, что большая часть проектов может быть завершена без этих продвинутых знаний. И мы не приносим в жертву качество приложения или создаем уродливые хаки для исправления того, что мы не могли обойти нормальным путем. У нас все в порядке. У нас просто не было каких-либо серьезных проблем. Не в этом проекте. И не в прошлом. И серьезных проблем не было даже в том проекте, который мы завершили в прошлом году. И мы можем уверенно сказать, что мы не ожидаем серьезных проблем и в нашем следующем проекте.

Ладно, вы не можете быть настолько уверены в будущем. Но, знаете что? Вы всегда можете узнать все, что вам необходимо тогда, когда это вам потребуется. Зачем же раньше времени бить тревогу? Рядом со мной есть необходимая книга. Когда я чувствую, что мне не хватает знаний в некоторых конкретных областях – я прочитаю необходимые главы. Или просто найду ответ в Google. Сегодня, вы сможете найти почти все в Интернете. И это быстро. И очень часто вы найдете ответ быстрее, чем волосатый парень Боря, гуру, сидящий за столом в углу, допьет свою чашку кофе и соблаговолит подойти к вам.

Кроме того, в Сети храниться колоссальный объем знаний и опыта других разработчиков. С большой вероятностью, вы можете наткнуться на такое, уже готовое решение, которое вам не вычитать и в двух тысячах страниц умной книги. Да, гуру тоже появляются в Интернете. Последний раз я принимал участие в одной технической дискуссии, так один опытный парень из Microsoft появился из ниоткуда и принес нам неожиданное, но столь необходимое просветление.

И можете не беспокоиться по поводу путей развития вашей карьеры. Быть генералистом может быть действительно лучше. Есть много небольших и средних компаний, которым необходим человек, имеющий делать многое. И это не значит, что они просто хотят заменить целый отдел разработчиков на одного многофункционального разработчика для того, чтобы сократить расходы. Скорее всего, для их проектов вполне достаточно человека с широкими навыками, у которого руки растут из правильного места. Там нет настолько нетипичных ситуаций, необычных сценариев или граничных случаев, в которых может работать только гуру. По сути, эти компании не могут предоставить работу необходимой сложности для столь высококвалифицированных специалистов. И, если гуру попадет в такую компанию, без работы особой сложности, то, скорее всего первый месяц ему будет очень скучно, а со следующего – он просто уволиться. Вы – универсальный разработчик, и вы можете решить очень широкий круг задач. На самом деле, будучи универсальным разработчиком, вы свободно можете оставить свое сегодняшнее место и стать контрактером, фрилансером, или даже открыть свою собственную небольшую компанию по разработке ПО. Это не сложно теперь, когда вы ознакомились со всем аспектам разработки продукта.

Когда я вспоминаю свои первые годы в программировании, моим самым интересным и в то же время депрессивным периодом было именно начало. Я просто знал слишком мало. Я мог писать программы, которые работали, но, потом я застревал в чем-то таком, что я действительно не знал. Я хотел бы сохранить некоторые данные в базу данных, но у меня не было опыта работы с базами данных. Хорошо было бы хранить настройки в XML, но я никогда не работал с ним. Собственно, аппаратное ускорение может дать нам прорыв, но я еще не программировал 3D-графику. Создать свой собственный сетевой протокол? Это же настолько сложно, могу ли я это сделать? Создание веб-сайта? Я знаю только несколько HTML тегов. Да, мне было действительно сложно сделать что-либо.

Теперь, программирование приносит мне намного больше удовольствия, ведь я могу сделать много разных вещей. Что более важно, я могу начать и решить задачи без постоянной помощи на каждом шагу. Я могу играть свою игру. GDI работает слишком медленно? Я сделаю это через 3D. Да, с полигонами, освещением и текстурами, они все будут там. Необходимо сохранить и извлечь информацию, введенную пользователем? Я сделаю это по средствам базы данных. Вот, я разработал модель данных для этого. Создать новое нужное приложение? Конечно, прямо сейчас же возьмусь, со всеми теми слоями, ООП, и еще много чем. Создать пользовательский интерфейс? Вот, валидный HTML, CSS, безтабличная верстка и семантическая разметка. А вот тут необходимо сделать слишком много действий, это может отвлекать пользователей. И чтобы добраться до непроходимого места, они должны нажать эту кнопку для открытия диалога. Но все они, вероятно, будут пользоваться такой-то фичей довольно часто. Давайте поставим ее прямо на главной странице. Подумайте о юзабилити. Кто-то нарисовал ярко-красной кнопки рядом с голубой панелью инструментов с серым фоном вокруг? На не приятно смотреть, это не вписывается в нашу цветовую схему. Исправьте дизайн. Где мы находимся, если кто-то ищет эти конкретные ключевые слова в Google? Недостаточно высоко. Давайте подвинем эти слова ближе к началу страницы и удалим ненужные ключевые слова из названия страницы. Мы можем сделать немного поисковой оптимизации собственными силами.

Работа доставляет огромное удовлетворение, когда вы можете многое сделать сами. Вы разрабатываете гибкую архитектуру и пишите качественный код. Когда вы открываете базу данных – для вас все известно и знакомо. Нет необходимости в эксперте по базам данных. Вы можете создать пользовательский интерфейс и без эксперта по фронт-энд разработке. Вы даже можете создать приятный дизайн и выбрать набор цветов и без тех дорогих веб-студий. Нет, ваш дизайн не получит премию «Дизайн года». Но это будет выглядеть красиво и будет достаточно хорошим. Вы можете организовать элементы управление и структуру меню так, чтобы интерфейс был простым и интуитивно понятным для пользователей. И да, вы можете сделать это сами, без тех юзабилити экспертов, которые будут стоить вам в половину бюджета.

Пока вы любите то, что вы делаете и стремитесь быть лучше – вы сможете реализовать любое ваше желание.

Я также верю, что хороший разработчик должен быть квалифицированным в различных техниках. Не существует веских причин для того, чтобы вы застревали в вопросах баз данных и игнорировали архитектуру приложения. Вы, конечно же, не знаете всего по вопросу производительности баз данных. Но, нет оправдания для системного программиста, если он смеется над front-end разработчиками. Конечный пользователь не увидит ваши фантастические методы распределения памяти. А разработчик интерфейсов не должен прибывать полной темноте, по отношению к тому, как действительно работает программное обеспечение, какие алгоритмы и структуры данных используются и каким образом мы могли бы повысить эффективность наших запросов. Или должен ли веб-программист выбрасывать из внимания аспекты SEO и маркетинга, как несущественные? Нет, конечно же! Это ваша задача: разрабатывать веб-приложение с учетом SEO. А насколько нормально для прикладного программиста создавать сумасшедший пользовательский, который будет отпугивать нормальных пользователей? Нет, спасибо тебе, пожалуйста, отложили свои диаграммы классов и шаблоны проектирования и какое-то время подумай о юзабилити, что и как нужно сделать либо переделать.

Я часто жалел тех разработчиков, которые закрылись своим футляром и не желают смотреть вокруг или признаться, что есть еще важные и интересные вещи.

Вы не можете делать все самое лучшее, пока вы не видите всю картину в целом. И если вы действительно не видите всего, то ваша работа и близко не будет настолько хорошей, как могла бы быть.

---

Оригинальный (англ) пост: Going specialist or generalist.
Этот текст перевел: Дмитрий Жарий

3 простых правила, которые сделают из вас Суперзвезданутого Программиста

Я верен, что вы уже читали пост Джоэля о том, что 1% разработчиков в 10 раз продуктивней всех остальных; про разработчиков-суперзвезд; тех, только которых и стоит нанимать. Вы знаете, что вы умеете программировать, что вы умный и талантливый, но – этого недостаточно. Вы хотите быть в 10 раз продуктивней, чем все остальные в вашей компании? Вы хотите быть гуру, к которому приходят все, когда у них возникает проблема; гуру, которому достаточно лишь мельком взглянуть на проблему и лишь взмахнуть пальцем, чтобы решить ее?

И вы можете! Следуйте следующим 3-м простым правилам, и в течение 12 месяцев все это и многое другое будет вашим.

Правило 1: Пишите много кода. Вам нужно исправить небольшую ошибку на участке кода, написанного кем-то другим? Не теряйте времени, пытаясь понять код или мотивацию человека, создавшего его. Просто перепишите большую его часть, и сделайте, чтобы код работал так, как это удобно вам. Назовите это рефакторингом, если, вдруг, кто-то спросит.

Правило 2: Пишите код быстро. Затроньте наибольшее количество файлов, и не забудьте включить каждый из них в ChangeLog. Не беспокойтесь о случайном создании трудно находимых ошибок; они помогут вам в будущем, потому что их, на самом деле, трудно найти. Избегайте создания тривиальных ошибок.

Правило 3: Не тратьте время для документирование кода, или добавления небольших комментариев, объясняющих потенциальные ловушки, связанные с изменением нечетких участков кода. Вам это не нужно – вы пишете код.

Усердно следуйте этим трем правилам – и вы станете суперзвездой вашей команды в течение 12 месяцев. Выпишете их и приклейте на видном месте. Только не в офисе! А где-нибудь в скрытом от посторонних глаз месте. И повторяйте их каждый день, перед началом работы. Они могут показаться вам спорными, но поверьте мне, все это имеет очень глубокий смысл.

Вы задаете вопрос: откуда я знаю, что это работает? – Потому что я сделал это сам, и потому, что я видел, как это делают другие. Конечно, я не понимал, что придерживался Трех правил – в то время, я был молодым и наивным и думал, что я просто пытаюсь сделать все возможное для проекта. И только теперь, спустя много лет, опираться на мудрость и опыт, я могу вот так просто поделиться ими с вами.

Система 3-х Великих Правил Программирования основана на Двух Фундаментальных Принципах: техническом и социальном.

Технический принцип: Вы работаете в 10 раз продуктивней над вашим кодом, по сравнению с тем кодом, который писали не вы.

Каждый понимает свой собственный код лучше. Это часть вашей памяти, часть ваших соглашений — весть этот код соответствует вашим убеждениям. Вы знаете, как работает функция, которая называется X и знаете все тонкости ее работы. Вы смотрите в класс Y, чтобы найти вашу функциональность и, конечно же, она там есть. Даже если вы находитесь в нижней части файла, вы прекрасно знаете какой код находиться сверху. Все эти мелкие детали понятны вам. Теперь вам не нужно так беспокоиться о случайных побочных эффектах, когда вы что-то изменили, потому что вы помните о тех местах, которые были немного рискованными и интуитивно знаете, где вы можете писать код небрежно, а где – нет.

Короче говоря: если вы написали код, у вас есть почти идеальная модель кода в вашей голове, потому что это то, что вы использовали, чтобы написать его.

Социальный принцип: то, насколько хороши вы в программировании, судят по тому, сколько строчек кода вы написали, насколько быстро вы можете завершить необходимые фичи и пофиксить критические баги, и насколько ваше понимание сути дела необходимо для решения проблем.

Эти два принципа определяют пространство задачи – или, как мы называем это – Игру. Вы победите, если улучшите свою репутацию суперзвезды до уровня гуру. Чтобы улучшить свою репутацию, вам нужно увеличить скорость, с которой вы пишете код, исправляете ошибки и помогаете другим. Технический принцип говорит нам о том, как достичь этого — работайте в своем собственном коде как можно больше. Именно так, захватывайте как можно большую часть проекта своим собственным кодом.

Система 3-х правил – это безупречная стратегия для достижения этой цели.

Следуя правилу 1, вы быстро ознакомитесь с большим количеством кода. Самое главное, вы не будете тратить время, пытаясь понять чужой код, ведь это является сложным и трудоемким процессом.

Соблюдая правилам 2 и 3, вы увеличиваете вашу долю захвата, избегая наиболее трудоемких частей написания хорошего кода. Это жизненно важно, чтобы вы контролировали больше кода, чем остальные участники команды вместе взятые.

Кроме того, есть и социальные выгоды работы подобным образом:

Выгода 1: все увидят, как быстро вы пишите огромные куски кода и начнут уважать вас – особенно ваш босс, который не имеет другого критерия, чем оценивать вас по частоте и объему вносимых изменений.

Выгода 2: Хоть вы и вносите множество новых ошибок, все равно пройдут еще несколько месяцев, перед тем как они вылезут, а к тому времени вы уже приобретете репутацию программиста-эксперта. И даже сейчас Вы можете получить выгоду от всех этих багов во второй раз, ведь вы же можете исправить эти проблемы быстрее, чем кто-либо другой. Ваши коллеги будут затрачивать в 10 раз больше времени, по сравнению с вами, для отслеживания каждой из этих проблем. Все чаще они будут приходить к вам за советом или помощью, потому что именно вы написали этот кусок кода. Будьте дружелюбным, скромным, помогайте с удовольствием. Вы определите место ошибки очень быстро. Ваша репутация великого Гуру будет расти день ото дня.

Относитесь к этому процессу, как будто это игра в стратегию реального времени. Карта мира – это код вашего проекта. Участки кода, которыми владеете вы – это ваши ресурсы, а чужой код – производит ресурсы другим. Но, главный ваш ресурс – это ваша десятикратная эффективность, так как вы в 10 раз продуктивней при работе, как с вашим собственным кодом, так и с чужим. Ваша десятикратная продуктивность улучшает вашу репутацию, которая является валютой в Игре.

Очевидно, что если вы владеете очень небольшим участком кода, вам не удастся поднять большое количество репутации, поскольку большую часть времени вы будете работать с чужим кодом такими же темпами, как и любой другой. Пришло время изменить эту ситуацию.

Правило 1 – это основа вашей экономики. Вы станете суперзвездой, если захватите наибольший участок кода, больший, чем у кого-либо еще. Создавая новый код, или преобразуя чужой код в ваш собственный – вы инвестируете в экономику, ведь каждый участок вашего кода генерирует вам производительность и репутацию.

Правило 2 — это агрессивность. Захватывайте владения других людей и изменяйте их код так, чтобы он был понятен вам. Пусть люди видят, что вы затрагиваете много кода — это хорошо для вашей репутации. Однако вы должны быть осторожными при переходе в атаку. Переписывание кода влечет за собой возможное урезание репутации, но об этом позже.

Правило 3 — это защита. Затрудняйте другим людям работать с вашим кодом или исправить в нем ошибки. За каждый час, который они тратят на исправление ошибок вы инвестируете час на создание свежего кода или переписывания существующего чужого, тем самым расширяя границы вашего влияния.

Никогда не забывайте, что это все это делается ради получения репутации. Тут самое главное – не переусердствовать, иначе, вашей команде и менеджеру может показаться, что вы вредите проекту. Не менее важно сохранять хорошие отношения с вашими противниками – коллегами. Старайтесь всегда казаться вежливым, полезным и скромным. Ваша репутация определяет какое количество и какие части кода вы можете переписать под себя, не вызывая негативной реакции.

Для этого вы должны начать с малого, в самой ненавистной, уродливой области кода в проекте. Просто зайдите туда и перепишите там все, чтобы все стало понятным вам. Не беспокойтесь о всех тех ошибках, которые вы внесете. Люди будут благодарны за то, что вы такой смелый и достаточно дерзкий, чтобы бросить вызов старому коду проекта. Они согласятся с тем, что это необходимо сделать, и что исправление ошибок нового кода будет проще, чем поддержка старого.

Когда вы закончите – то обнаружите, что ваша репутация возросла. И вот теперь вы сможете переписать чуть менее отвратительные участки кода, без занудных вопросов о том, действительно ли это необходимо было сделать. В конечном итоге ваша репутация вырастит и станет настолько огромной, что вы сможете переписать любую часть основной функциональности приложений по своему усмотрению. К тому времени, вы будете знать гораздо больше об остальных частях системы, чем кто-либо другой, и будете допускать на удивление мало ошибок. Это обеспечит ваш статус Гуру.

Теперь вы – суперзвезда команды. Это завершение вашей игры.

Вы выиграли!

Постскриптум для наивных: Этот пост – легкая сатира на программирование в составе команды. Эти три правила – зло, хотя, несомненно, очень эффективны. Они принесут вред общему прогрессу проекта ради вашей собственной выгоды. Они не сделают вас лучшим программистом по сути, только по сравнению с остальной частью вашей команды. Вы, как я и многие другие, могли невинно делать нечто подобно этому в вашем прошлом, когда вы не знали, как делать это лучше. Теперь вы знаете.

Постскриптум для руководителей проектов: Если ваша обстановка соответствует Двум Фундаментальным Принципам, то ваши программисты будут играть в Игру, и ваш проект будет страдать. Меняйте правила. Убедитесь в том, что программисты признают и хорошо играют кодом друг с друга, для успешной работы небольших групп, которые решают большие проблемы. Переписывание кода, из-за появления ошибок приводят к появлению новых ошибок, из-за которых код будет опять переписан. И я не знаю хорошего способа избавиться от этого. И если вы знаете, то, пожалуйста, ради всех проектов во всем мире, оставьте комментарий!

---

Англ. оригинал:3 Simple Rules That Will Make You a ‘Superstar’ Developer
Автор оригинала: Mark O’Connor
Перевод: Дмитрий Жарий