Представете си, че трябва да добавите нова, сложна функционалност към вече съществуващ софтуер (който в общия случай не сте го писали вие).
Как бихте приоритизирали следните 7 добри практики?
Следва списък с практиките, подредени от най-приоритетната до тази с най-нисък приоритет. Разбира се, това е лично моето мнение и за тези от вас, които не са съгласни с мен, ще се радвам да попълните едно кратко Survey (<1 минута).
  1. Ще опитам да реша проблема по най-лесния възможен начин с най-малко код. Причината това да е на първо място в моя списък е много проста – кодът е най-големият враг на програмиста. Той е бъгав, много често недобре написан, грешен, раздут и какво ли още не. Когато кодът е в големи количества, става още по-труден за четене и разбиране от хора (да, компютърът няма проблеми с големи количества код, но хората имат). А най-важното качество на едно парче код е “дали е разбираемо от хора“, защото все още хората са тези, които ще го поддържат. Препоръчвам ви да прочете още по темата на блога на Jeff AtwoodThe  best code is no code at all.
  2. Ще опитам да напиша най-чистияспретнат и добре структуриран код. Както вече споменахме, кодът е създаден, за да бъде четен от хора. Тук ще цитирам Martin Fowler, който, може да се каже, е един от бащите на софтуерното инженерство – “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” ~Martin Fowler. А за да бъде лесно четим от хора едно парче код, той трябва да е чист, спретнат и добре структуриран. Това ще даде възможност на хората, които го четат, да го разберат по-лесно и най-вече по-бързо и да го променят, ако се налага.
  3. Ще опитам да напиша код, който да бъде максимално консистентен с останалата част от софтуера – конвенции за именуване, структура на кода, шаблони и т.н. Понякога просто се налага да пренебрегнем някои от личните си правила за писане на код и да спазим правилата, които са наложени вече в даден софтуер. Консистентността отново е много важна за четимостта на кода. Недопустимо е в цялото приложение променливите да се кръщават по определен начин, но понеже на нас не ни харесва, да си ги кръщаваме по друг. Това просто ще “боде” очите на другите хора, които ще поддържат кода. Стремете се да бъдете максимално консистентни с останалия код.
  4. Ще напиша максимално много тестове, покриващи максимално много сценарии. Разбира се, когато пишем софтуер, е хубаво да нямаме много бъгове. За тази цел трябва добре да си помислим за всички възможни сценарии и гранични случаи и да ги реализираме. В този ред на мисли, от голяма полза би ни било, ако следваме Test Driven Development (TDD) методологията. Когато пишем тестовете предварително, се хващат много повече гранични случаи, защото първо мислим как всъщност може да счупим функционалността. Но дори и да не следваме TDD, ако напишем достатъчно много тестове, това ще ни гарантира спокойствието, че с течение на времето, докато кодът се променя, старата функционалност ще работи. Дори и да пренапишем/рефакторираме дадената функционалност, ако тестовете минават, значи всичко е наред. Така ще избегнем регресия на софтуера.
  5. Ще опитам да намеря най-подходящия алгоритъм за решаването на дадения проблем. Изборът на алгоритъм е доста субективен въпрос. За едни даден алгоритъм за решаване на проблема може да е най-добър, за други – друг. Затова и приоритетът ми на този въпрос е по-нисък. По-важното за мен е алгоритъмът да е написан чисто и спретнато. Ако впоследствие се окаже, че алгоритъмът, който съм избрал, не е най-добрият, ще го подменя с по-добър. И тази подмяна ще бъде лесна, защото кодът на стария алгоритъм е кратък, разбираем и лесно четим. Същевременно имам тестове, които ще ми гарантират, че подмяната на алгоритъма няма да доведе до регресия.
  6. Ще опитам да проуча и имплементирам най-добрата архитектура и най-подходящия шаблон (design pattern), за да реша проблема. Шаблоните са една от тези “добри практики”, с които обаче трябва много да внимаваме, затова поставям избора на шаблон с по-нисък приоритет. Много често шаблоните внасят още едно ниво на абстракция, което усложнява кода, прави го по-трудно четим и по-трудно разбираем. Трябва да сме напълно убедени, че ни трябва да реализираме даден шаблон/архитектура, преди да се впуснем в неговата имплементация. Въпреки това шаблоните решават много проблеми по много добри и стандартизирани начини, така че все пак, ако се налага, можем много да спечелим от тяхната имплементация.
  7. Ще опитам да напиша най-бързодействащия код. Бързодействието на софтуера е абсолютно неоспоримо едно от най-важните му качества. И ние като програмисти трябва да се стараем максимално да създаваме софтуер, който е бърз и реагиращ на взаимодействията с потребителя. Но промяната на код с цел бързодействие трябва да се случи на една следваща стъпка. Тогава, когато сме сигурни (премерили сме), че точно определен сегмент от кода е виновен за забавянето на приложението, може да го променим (оправим). Като в същото време се стараем да запазим чистотата на кода. И отново, тъй като имаме тестове, това ще ни гарантира, че бързодействието няма да е за сметка на регресии.
Както вече споменах, вие също може да подредите тези седем практики тук. Резултатите от изследването ще бъдат публикувани периодично.