Трохи про говнокодерство (aka технічний борг)
🍄 Спостереження 1:
Інженери не хочуть працювати на проектах, які погано написані, а хочуть там, де все красиво.
👉 Висновок: інженери не хочуть працювати з чужим говнокодом.

🍄 Спостереження 2:
Даєш інженеру новий проект, бо він не хоче йти на той, де говнокод. Через якійсь час інженер уходить з нового проекта, бо тепер й на цьому проекті говнокод.
👉 Висновок: інженери не хочуть працювати зі своїм говнокодом теж.

🍄 Спостереження 3:
Інженер говнокодить й через якійсь момент перестає розуміти, що він пише говнокод. Говнокод стає нормою.
👉 Висновок: говнокод псує інженера, бо він втрачає нюх на поганий код.

🍄 Спостереження 4:
Виходить, що на проекті не має бути говнокоду? Насправді, технічний борг часто як брудний посуд на кухні. Ти не можеш приготувати блюдо й не вимазати посуд. Тут головне просто не забути помити його.
👉 Висновок: не забувай регулярно "мити посуд" й робити періодичне прибирання.

🍄 Спостереження 5:
Якщо є гарна структура/архітектура коду й просто писати й писати новий код й завжди слідувати цій структурі/архітектурі, то може здатися що все добре, але насправді все одно буде зʼявлятися технічний борг, оскільки базова структура/архітектура була розрахована під один масштаб, а коли ви все більше додаєте коду, то масштаб змінюється.
👉 Висновок: ти створюєш технічний борг, навіть якщо просто пишеш схожий код.

🍄 Спостереження 6:
Коли проект в продакшені, то доводиться оновлювати фреймворки та бібліотеки. Й якщо цього не робити, то з часом це зробити все складніше й код стає в результаті складніше підтримувати.
👉 Висновок: технічний борг зʼявляється, навіть якщо ти не пишеш код

🍄 Спостереження 7:
Говнокод часто є наслідком браку часу. Зазвичай економлять на реалізації та проектуванні абстракцій. Якщо погано спроектовані абстракції, то говнокод розповзається по всьому проекту. Якщо ж говнокод схований всередені абстракції, то він ізольований й його потім значно легше привести до ладу.
👉 Висновок: краще покласти говнокод в контейнер ніж все обмазати ним.

🍄 Спостереження 8:
З першого разу не вдається написати гарний код (навіть якщо попередньо витратив час на проектування), оскільки часто неможливо передбачити всі нюанси. Й після того, як код запрацював, може знадобитися декілька разів його переписати (навіть до того як було створено пул-реквест). З робочим кодом стають зрозумілі нові деталі й стає зрозумілішим, як краще його можна було спроектувати.
👉 Висновок: якісний код це результат ітеративної роботи й проектування коду не відірвати від процесу його написання.

Спостерігали таке? Діліться в коментарях й власними спостереженнями