Красивый или рабочий код?

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

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

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

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

Но мы отвлеклись. Если (как любят говорить экономисты, да и не они одни) при прочих равных условиях выбор стоит между быстрым написанием кода и красивым, вдумчивым кодом, не просто желательно, а необходимо выбирать второй вариант.

Второй вариант подразумевает – понятное разделение сущностей классов, вменяемая (понятная ) архитектура классов, красивые методы (сюда входят правила оформления кода, правила по типу не более 50 строк на метод), вдумчивое комментирование и документация проекта.
Теперь пару слов о документации проекта. Если проект очень маленький, я склоняюсь к тому, что и кодер в комментариях может дать полное представление об оном. Если проект уже не мал, то проект без документации его – нет.. не провальный, но теряет свою «вкусность», ибо в дальнейшая разработка будет осложняться осмысливанием ранее написанного (документация упрощает данный этап)

Теперь перейдем к очень интересной теме – как же писать код применительно к определенному ЯП? Ведь некоторые языки предлагают «элегантные» решения тех или иных задач. Стоит или не стоит их использовать?
Известно, что сейчас различных ЯП хоть отбавляй. Давайте я приведу пример на C#.
Возьмем простейшую задачу – вводится массив элементов и необходимо сформировать массив, состоящий из элементов, которые больше (пусть) 5.
Давайте напишем алгоритм решения, взяв во внимание то, что мы не знаем, некоторых возможностях C#
К примеру, мы написали такой код:
  1. int[] SomeArray = new int[100];
  2.  
  3.       Random rnd = new Random();
  4.       for (int i = 0; i < 100; i++)
  5.         SomeArray[i] = rnd.Next(10);
  6.  
  7.       List<int> NewArray = new List<int>();
  8.       foreach (var x in SomeArray)
  9.         if (x > 5)
  10.           NewArray.Add(x);
  11.       foreach (var x in NewArray)
  12.         Console.Write(x + " ");
* This source code was highlighted with Source Code Highlighter.

Если же Вы знакомы с лямбда-выражениями, то лучше записать так
  1. int[] SomeArray = new int[100];
  2.  
  3.       Random rnd = new Random();
  4.       for (int i = 0; i < 100; i++)
  5.         SomeArray[i] = rnd.Next(10);
  6.  
  7.       int[] NewArray2 = SomeArray.Where(X => X > 5).ToArray();
  8.  
  9.       foreach (var x in NewArray2)
  10.         Console.Write(x + " ");
* This source code was highlighted with Source Code Highlighter.


Теперь перед нами стоит вопрос. Как писать лучше – как в первом или втором варианте?
Мой личное мнение по данной задачи таково – если вы понимаете, как работает второй вариант и знакомы с данными возможностями, то однозначно – второй вариант. Если же вы не знаете этого, и такие строки кода вызывают у Вас «непонятки», то напишете по примеру первого варианта. Никто не будет Вас убивать за это. А код останется понятным.

Что я хотел сказать данной заметкой? Если есть возможность, то пишите красивый код. Если такой возможности нет, то пишите «просто рабочий» код, но как возможность появится – проведите хотя бы рефакторинг проекта.
2012-09-18