1. DRY: DON’T REPEAT YOURSELF
Повторението е майка на знанието и баща на затъпяването. Особено неприятно е ако пишете код предимно чрез копи/пейст и в един момент трябва да промените едно и също нещо на 12 места. Не го правете. Изнасяйте общата функционалност в абстрактни класове или някъде другаде.
2. CREATE LOTS OF UNIT TESTS. TESTS ARE AWESOME
Юнит тестове, интеграционни тестове, пърформанс тестове – най-сигурният начин да покажете, че нещо не работи. Програмирането е инкрементален процес – всичко се случва малко по малко, стъпка по стъпка. Лесно и бързо е ако имате код, който проверява стъпките ви автоматично, а не ръчно както би ви се наложило иначе.
3. REFACTOR OFTEN AND SOONER. DON’T BE LAZY
Първоначалният вариант на кода вероятно ще е нещо, което ще нарушава доста от точките изброени в тази статия. Това не е проблем стига да следвате №2. Веднъж, щом имате идея какво трябва да прави кодът и как да го прави по-оптимално просто пренаписвате части от имплементацията и с божията помощ и достатъчно тестове, които да проверят поведението й, вероятно всичко ще е наред.
4. CODE TO AN INTERFACE, NOT TO AN IMPLEMENTATION
Разделете програмата си на колкото се може повече логически модули. Тези модули комуникират помежду си чрез интерфейси. Това намалява сложността, защото един клас от 1000 реда се тества, поддържа, чете по-трудно отколкото два по 500 реда. Разделяй и владей.
5. WRITE SHORT METHODS. SHORT METHODS ARE AWESOME
Ако не можете да обясните нещо кратко и ясно, тогава не го разбирате достатъчно добре. Ако имате обемен и сложен метод, по-добре го разбийте на няколко по-малки. Никой не обича да чете дълги и сложни писания.
6. BRANCH ON NEW FEATURES AND BUGFIXES
Ако ползвате SVN вероятно тази точка няма да ви пасне толкова добре, колкото ако ползвате децентрализирана система за контрол на версиите на кода като Git или Mercurial. Целта е всяка обемна нова функционалност да си има собствен бранч, така че да можете да работите по нея когато и колкото си искате и всъщото време трънка да държи само стабилна версия на приложението ви.
7. PREMATURE OPTIMIZATION IS THE ROOT OF ALL EVIL
Преди години работих върху игра за мобилни телефони и реших да пиша супер оптимален код. Някъде една седмица след като написах по-голямата част от този “супер оптимален” код вече бях изгубил идея за логиката му. Загуба на време е. Ако се налага да се оптимизира нещо, го правете след като функционалността е завършена и има тестове за нея. Най-скъпият ресурс на един проект е времето за подръжка и разработка – не го раздувайте излишно за няколко процента по-бързо изпълнение.
Цитатът е на Доналд Кнут.
8. DRY: DON’T REPEAT YOURSELF
See #1 🙂
9. THROW EXCEPTIONS. EXCEPTIONS ARE AWESOME
Освен ако не пишете на С нямате сериозна причина да не използвате изключения. Ако се случи нещо непредвидено просто хвърлете изключение. Не случайно се казва изключение. Не връщайте -1 или булева стойност или някаква друга глупост. Не обременявайте дизайна на приложението си излишно. Просто хвърляйте изключения във всеки изключителен случай 😉
10. DON’T FORGET TO DOCUMENT YOUR CODE
Пишете самодокументиращ се код. Пишете документация към кода във формата на коментари, особено ако правите нещо сложно или извратено (като оптимизиране например :P). Пишете анотации към публичните методи поне. Не заради вас, а заради бъдещите несретници, които ще трябва да ви четат бакийте.
Тези правила може да не пасват на вас или вашият проект. Може би вече ги изпълнявате. Няма значение, все има нещо, което ви куца. Напишете го на лист хартия, сложете го до монитора и почнете да го следвате.
И блогнете за него 🙂
Follow me…
