В предната статия обърнахме голямо внимание на грешките при писане на код. Сега ще наблегнем на по-общите части, които могат да свършат работа и за по-широк спектър от професии.
Гугълна ли го?
Всеки програмист е имал поне няколко случая, в които си е блъскал главата над даден проблем малко повече време, отколкото трябва, вместо да потърси информация в интернет още в самото начало. Голяма грешка е да се спира процесът на работа на някой колега, преди да са се предприели някакви предварителни опити за решаване на проблема самостоятелно.
Важна част е да обърнем внимание и на друго -новаците често копират и използват чужд код, без да знаят какво прави той. Това, естествено, е погрешно -никога не използвайте код, който не разбирате напълно. Вникването в материята е задължителна част.
„Ами ако…“
Мисълта за това какво може да се счупи и какви мерки да предприемем е ок. Но размишленията отвъд решението, от типа „ами ако“, макар и да изскачат като въпросителни, не трябва да диктуват планирането до такава степен, че да обхваща нереалистичен спектър от решения. Създаването на нови функции трябва да бъде с цел предотвратяване на реални проблеми, не на евентуални такива.
Писането на минимално количество код, което обслужва един проблем, е най-добрият вариант.
Щом работи, значи всичко е наред
„ It`s not a bug, It`s a feature! ”
Проверката и подсигуряването са ключов момент за решаването на дадена задача. Разбирането на кода, проследяването на логиката и повторението на задачата са стъпките, които се предприемат, за да се осмисли по-добре.
Тук включваме и като грешка да не се съмняваш в качеството на съществуващия код.
Всеки програмист се е сблъсквал с глупаво написан код – например, когато се налага да се пише CSS, защото WordPress темата се „чупи“ на мобилна версия. В случаите, в които се сблъскваме с „разхвърляна стая“, понякога не можем да подредим всичко. Но трябва да разберем и осъзнаем грешките, било то и създадени от специалисти, работещи в сферата. Затова, ако даден код предизвиква въпросителни, трябва да се подходи критично, не пораженчески, и да се вземе под съмнение качеството, а не да се приеме, че просто ние не разбираме и това е. От друга страна, за всеки странен на пръв поглед код, който обаче изпълнява особена функция, създателят му трябва да предупреди с коментар.
Възприемане на грешките по неправилния начин
Грешката е нещо хубаво. Грешката означава, че има прогрес.
Експертите програмисти са заинтригувани при появата на грешка. Новаците обикновено изпитват паника.
Ако малките червени точици предизвикват паник атаки на разработчика, трябва внимателно да обмисли поведението си! Грешката е помощник, защото ти показва пропуск, който може да бъде елиминиран.
Липса на почивки
Нека завършим темата с един универсален съвет.
Взимането на почивка е важна част от ежедневието.Това не само е полезно физически и психически, но и помага за един нов поглед върху написания код -което влияе на доброто представяне, а доброто представяне води след себе си и други подобрения, например увеличаване на заплатата. Затова ето един мотиватор – измисляйте си причини за кратки почивки, за да увеличите шансът от парични постъпления.