Повідомлення telegram каналу - @from_a_to_qa

Логотип телеграм спільноти - From A to QA | Все про тестування 2024-07-14

From A to QA | Все про тестування

Кількість підписників:
4101
Фото:
76 
Відео:
40 
Посилання:
234 
Категорія:
Технології
Опис:
Привіт. Я Артур — Director of Engineering, Head of QA, кандидат наук та викладач в універі. Пишу про тестування, програмування, автоматизацію та айтішку. По питанням пишіть @ar2r_s

Канал From A to QA | Все про тестування - @from_a_to_qa - №426

Вчора слухав один вебінар і почув доволі цікаву думку.
Коли ви працюєте в айтішці -- у вас два шляхи -- ви або пишите гамнокод, або розбираєтесь та наводите порядок у чужому гамнокоді.
Чому так?
Якщо ви працюєте у стартапі (а це майже весь аутсорс, доречі) -- писати одразу хороший код - це не буде ефективно, так як ваша архітектура буде перероблюватись декілька разів і одразу споєктувати кінцевий варіант можно тільки якшо у вас етап проєктування буде по ватерфолу (чого зараз майже немає), і тому вибудовувати супер складне рішення по всім канонам та методологіям буде просто обкрадання замовника. Доречі саме тому більшість проєктів загибаються навіть не вийшовши на етап пошуку інвестицій -- через оверінжинірінг програмістів, які роблять резюме-дрівен-девелопмент. Так, звісно, це не значить, шо треба гамнякати як можно. Треба притримуватись загальних рекомендацій, шаблонів, архітектури, але писати НОРМАЛЬНИЙ код , якшо ви у стартапі.
Якщо ж ваш стартап здобув інвестиції та потрошки обростає фічами, інтеграціями, залежностями -- він починає перетворюватись у легасі. І додавання нових фічей становиться все складніше, і саме тут друга фаза - РОЗБИРАННЯ ТА ПРИВЕДЕННЯ В ПОРЯДОК чужого гамнокоду. Тут як раз саме місце для ваших знаннь з книжок по тіпу Фаулера чи Клепмана - для того, щоб адаптувати архітектуру під нові вимоги та бачення того, як розвиватиметься продукт. І тут як раз найскладніша, та, як на мене, найцікавіша робота, яка показує дійсно навички хорошого програміста.
Щодо мене, я дійсно бачив багато проєктів, де через провтики людей було затягнуто занадто складні архітектурні рішення бо "замовник так хотів" або "ми колись таке юзали і нам сподобалось" або "зараз доволі популярно". Через це проєкти потім занепадали, зривали бюджети і дедлайни. Також бачив багато успішних кейсів, коли не дивлячись, що там пів кодової бази було написано на колінці вчорашнім джуніором і мідлом в форматі "потім перепишемо" знаходили блискавичні інвестиції і переростали в величезні продукти.
А які ваші думки? Чи погоджуєтесь ви з тим що більшість стартапів - це гамнокод, а справжні тру-програмісти показують себе тільки в ковиряннях у легасі? 🤓

1700
24-10-29 07:34