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

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

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

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

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

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

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

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

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

19 жовтня React+ fwdays'24 - конфа про JS та React 🤩
✅ Онлайн та офлайн у Києві.
✅ Для підписників знижка 15% по промокоду JABA15 (є знижки для студентів/аспірантів та військових, знижки не сумуються).
✅ Був багато разів на івентах від fwdays й це завжди класний нетворкінг й цікаві спікери.

Які доповіді зацікавили?
Я би послухав би про мікрофронтенди 🤓*

До речі, відгадайте, з якої версії ми в WebbyLab почали використовувати React в продакшені?
РЕЄСТРАЦІЯ👉* https://bit.ly/3Y4gifA

Накидайте посилань на авторів/видання/підписки/блоги, які ви читаєте, щоб розвиватися як спеціаліст

За 10 хвилин починаємо:
- приєднатися, щоб поставити запитання на платформі GDG
- Подивитись онлайн на ютуб

Наступний вебінар Google Cloud service review: Cloud Run

?: 29 червня, 17:00-19:00

Программа:
– Що таке Cloud Run
– Cloud Run VS Cloud Function VS Firebase Function
– Cloud Run Service VS Cloud Run Job
– Integrations
– New Cloud Run features

Доповідачі:
– Віктор Турський, Senior Software Engineer, Google, веде @jabascript
– Нікіта Галкін, GDE, Cloud Architect, Independent Contractor, веде @node_recipes

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

До зустрічі!