Як код стає поганим🧑‍💻

Не буває такого, що ми з початку проекта такі зібрались з дев командою і вирішили - будемо писати фіговий код. Ну я сподіваюсь, що такого не буває😅 І тим не менш, через якісь проміжок часу код база стає все менш і менш читабельною, її все складніше і складніше підтримувати.

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

Дискдеймер: код (процеси, планінг, etc) ніколи не будуть ідеальними. Будь яка код база з часом стане легасі. Тому ми кажемо про покращення, а не про те, щоб зробити ідеально.

Тож які фактори впливають на погіршення коду:

1. Закладання поганої архітектури на початковому етапі розробки. Для цього може бути багато причин. Ми можемо бігти галопом для того, щоб показати mvp клієнту, або мати мету швидко релізнути стартап до закінчення бюджету. Можливо, ми розраховували на невеличкий проект з мінімум залежностей, а він вже переріс своє. Можливо, розробникам на етапі планування бракувало досвіду, щоб передбачити можливі проблеми та розширення. І тим не менш, маємо що маємо - архітектура не може підтримати проект. Як цього можна запобігти? Впроваджувати гарну архітектуру з перших днів проекту відповідно до вимог і бачення майбутнього. Тут важливо памʼятати про баланс. Overengineering може завдати шкоди продукту так само, як і underengineerin. Ми кажемо про мінімальну архітектуру, яку в подальшому можна буде рефакторити і екстендити.

2. Людина, на якій «тримався» проект, іде з компанії. Умовний Джеймс був єдиним носієм інформації про продуктові рішення, технічні деталі, блокери та костилі на проекті. Коли він іде, поточні та нові розробники просто не можуть тягнути, бо не мають технічного/продуктового розуміння. Через те, що в руках Джеймса концентрувалося так багато «власті», він частенько міг пушити нечитабельний код багфіксів, в нього могли бути magic numbers, і тд. Як цьому запобігти? Уникати концентрування інформації в руках однієї людини. Контролювати стан кодбази командою. Запроваджувати knowledge sharing сесій та підтримувати документацію.

3. Реалізація фічей в рамках дуже щільного дедлайну. На будь якому проекті був(буде) період, коли треба швиденько релізнутися під продуктовий бум (або через інші причини). Тоді ми не маємо час на гарний код, в нас основною метою є економія часу. Для запобігання погіршення коду в таких випадках ми завжди повинні закладати планінг для рефакторингу. Не просто обіцяти собі це зробити, а мати конкретні дедлайни і відповідальну особу.

4. Нові розробники пишуть код без розуміння особливостей архітектури. Тут запобіжними методами є knowledge sharing, гарні pr review, а також атмосфера в команді, де людина почуває себе захищеною для питання і визнання помилок.

Які ще фактори погіршення коду спадають вам на думку?