#Розробка

Безперечно, переписати проєкт наново приваблива пропозиція. Можна нарешті врахувати все розуміння, виправити всі помилки… Під час це звучить настільки привабливо, що всі інші покращення відкладаються “на після переписування”. От тільки зараз часу переписувати немає, але як руки дійдуть… Тоді все зробимо як треба.

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

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

Але про такі переписування довго не думають — їх роблять. А я кажу про інші. Ті, що робляться, гадаю, з нестачі розуміння… приблизно так само, як і переїзди на новий трекер задач. Тоді краще сісти та зʼясувати, що ж все ж таки не влаштовує в поточному проєкті та як це виправити послідовними змінами.

Наприклад, я нещодавно думав переписувати наново рушій для блогу. Бо… надто складний він зараз. Але нічого технологічно нового я не планував: той самий Hugo. Та от бачу, що краще поступово додавати функції та оновлювати дизайн на місці. (Цими днями додав посилання на Mastodon… а також замінив значки на обрізаний Nerd Fonts.) Бо переписувати буде нереально довго.

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

• Написання плану реалізації. Це коли перед початком роботи над задачею ми сідаємо та розписуємо покроково, що треба змінити — причому не навмання, а з максимумом конкретики. Головною перешкодою до виконання задач у людей з РДУГ є не відсутність мотивації, а неясність. Невизначена задача може висіти вічно, навіть коли вона дуже важлива. Тому свідома попередня підготовка з проговоренням всіх аспектів суттєво збільшує шанси на успіх.

• Парне програмування. Ще одна відома практика з РДУГ — двійник (body double). Якщо задача надто складна для подолання — наприклад, нудне прибирання — можна запросити друга, щоб просто посидів поруч. -Це покращує фокус та зменшує ризик відволікань. Та що ж виходить: парне програмування — це ж як раз в першу чергу людина-двійник!

• Щоденні стендапи. Робота з відкладеним результатом тяжко дається людям з РДУГ. Через викривлене сприйняття часу до останнього моменту здається, що залишилось ще довго — а потім доводиться або робити поспіхом та погано, або гарно та з вигорянням. (А якщо строків взагалі немає…) Щоб цьому запобігти, радять розбивати задачі на такі, що можна виконати в короткий термін — може, щодня — та якось відзначати перебіг — наприклад, звітувати. От вам і стендап!

Може все це й збіг (або хибна інтерпретація.) Але я тепер дивлюся на ці підходи з новою повагою: спеціально чи випадково, вони допомагають досягти успіху.

Чистий код та DRY - це гарні принципи, але з них я роблю один виняток: коли працюю з фічафлагом. (Чи це “всім відоме” поняття? Фічафлаг — це перемикач, яким можна наживо обрати між старою та новою поведінкою частини коду. Зазвичай не для всіх, а для конкретного користувача. Таким чином можна не показувати нові фічі всім відразу, але мати можливість їх випробувати.)

Фічафлаги завжди ускладнюють код, це очевидно. Зокрема, часто це не подобається лінтерам. Коли у функцію, яка вже підігнана під правило максимальної довжини, додають розгалуження за фічафлагом, то вона гарантовано порушить це правило.

Звично в таких випадках порефакторити код, щоб він знову став красивим, структурованим тощо. Я гадаю, це хибний крок. Тому що фічафлаг — конструкція тимчасова, та доля її та старого коду — бути видаленими. Тоді доведеться всі спрощення повертати назад.

Окремий випадок — то тести. В тестах рідко виходить красиво параметризувати поведінку коду під фічафлагом. Тому замість того, щоб намагатись вплести фічафлаг у тести, краще скопіювати тест чи цілий файл, та впровадити зміни такими, якими вони стануть остаточно. Якийсь час у вас буде зайвий тест, а потім старий видалите і все знову буде красиво.

Та й не тільки в тестах, а й будь-де в коді краще копіпастити весь той код, де гілки фічафлагу не є простими. А лінтер — сміливо вимикати; почекає.

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

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

Проблема, втім, у розумінні. Поза знайомою галуззю в тебе може взагалі не бути жодної гадки про те, як щось працює (згадую, як при переході з PHP на Ruby мені було дуже дивно, що окремі файли Ruby не є адресованими за HTTP.) Та й взагалі, що існує, які абстракції визначені, які процеси тощо.

Зокрема, ще складніше обʼєднувати декілька продуктів для розвʼязання власної задачі. Навіть коли по кожному є документація, рідко вона передбачає твою комбінацію. (От є бібліотека для JS, але чи працює вона в React Native?) До того ж проблеми можуть виникнути на різних шарах абстракції (А чому Metro не бачить типів тієї бібліотеки та що поміняти, щоб бачив?) Інтеграція не продається, її завжди доведеться збирати власноруч.

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

Критика мікроменеджменту (тобто стилю менеджменту з надмірною увагою до деталей, а також до контролю підлеглих) серед айтівців це як товкти воду в ступі: консенсус такий, що мікроменеджмент — погано та непрофесійно.

Мені щастить працювати в оточенні, де контролю навпаки, мінімум. Це значить, що виконання роботи згідно з домовленостями та в термін — особиста відповідальність кожного. Магії немає. Але в цьому оточенні звикаєш до того, що люди не потребують менеджменту, що зазвичай домовлене буде зроблено.

Та, нещодавній досвід ремонту змусив мене усвідомити, що так буває зовсім не завжди. Серед працівників ремонту “сказано-зроблено” є не нормою, а виключенням. Причому про якість роботи це нічого не каже: людина може давати бездоганні результати… якщо їй вчасно про це нагадати та проконтролювати ті самі деталі.

Деякий час мене бісило це нескінченне нагадування — поки не зрозумів, що інколи мікроменеджмент необхідний. Чи можна те ж саме сказати про айтівців? Про деяких айтівців? Чи працював би я краще з вправним мікроменеджером? Навряд чи дізнаюсь.

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

📚 Книга — недооцінений шлях прокачатися з початківсько-середнячкового рівня в чомусь до середнє-просунутого. Технічна книга, мається на увазі.

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

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

Звісно, ту книгу ще потрібно знайти. Бо хороша книга то рідкість. А потім за неї ще буде потрібно заплатити, часто немало. Та якщо вже пощастило натрапити на надійну книгу, не шкодуй грошей — вони окупляться. А до того ж в наші часи письменництво потрібно винагороджувати, бо інакше автори переведуться, а далі що?

Наведу пару прикладів. Колись мені дуже допоміг The DynamoDB Book - треба було зрозуміти, що ж воно таке то DynamoDB, та як на ньому збудувати архітектуру. Бо основи легко знайти в посібниках, але що з ними далі робити?

А з недавнього був Thinking in SwiftUI. Навіть після місяців практики, а також читання офіційної документації, форумів, та блог-постів, ця книга була справжнім одкровенням. Тільки з нею я нарешті зрозумів, збагнув, як SwiftUI працює в нюансах. Стало незрівнянно легше міркувати про свій код, коли в голові є моделі з книги.

Отже. Хочеш підвищити рівень — знайди почитати гарну фахову книгу.

Є велика мудрість в тому, щоб помітити, які важливі задачі можна зробити швидко. (Я думав про розробку, але насправді це будь-чого стосується.)

Так, є архетипова ситуація, де розробник каже на задачу - “ой, справ на пʼять хвилин” - а вона обертається цілим днем. Це не скасовує того, що, є й такі задачі, які дійсно можна зробити, покрити тестами, та оформити за лічені хвилини. Особливо коли це стосується прибирання (тобто видалення) коду, або дрібних змін в інтерфейсі.

Швидка задача — не обовʼязково неважлива. Зазвичай коли якийсь контекст закривають, залишаються недоробки, чи ще краще — їх виявляють з часом. А потім дивишся, а користувачі страждають через якусь дрібницю.

Але як тільки така робота стає поза поточним контекстом, планувати її стає важко. Керування проєктами гарно працює з епіками на тижні та місяці роботи, а не на хвилини. Мені стає боляче слухати про “заплануймо це на після оцього”, коли йдеться про годину чи дві роботи.

Тому, я гадаю, чудово, коли розробник може сам помітити та виконати таку роботу прямо сьогодні, без відкладання на невідоме майбутнє. Звісно, для того треба вірно оцінити обсяг роботи, а також бути обізнаним про пріоритети та життя-буття користувачів.

Сьогодні така тема проскочила, що от є у вас база даних. І вона може застаріла. Але оновлювати її не хочеться — бо складно, ризиковано, доведеться вимикати сайт, і так далі.

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

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

А коли проєкт тільки-но починається, то може здаватися, що треба все тримати в порядку та чистоті. Бо ти ж закладаєш самий фундамент, а він мусить бути надійним. Але ні — як на мене, щоб досягти успіху, краще розвʼязати собі руки та залишити довершення на пізніше. (Це й оновлення залежностей стосується.)

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

LLM вражають своєю здатністю генерувати код. Багато коду. Та набагато швидше, ніж його може хоч надрукувати людина. Це дійсно приголомшує, особливо тому, що цей код не такий вже й поганий.

Тому важливо нагадати, що код не тільки не має цінності сам собою, а й створює майбутні витрати. Цінність може мати функціонал програми — це те, за що платитимуть клієнти, це економічний продукт. Але кожний рядок коду, який ми вклали в реалізацію цього функціоналу — це витрата.

Я гадаю, людям складно думати про код, бо це зовсім новий ресурс. З фізичними ресурсами практично завжди зрозуміло, що більше витрат — не краще. (Хіба якщо ви отримуєте відкати за цеглу. Що можна порівняти з оплатою за рядки коду.) Але код — це інформація, вона нічого не важить. Коли пишуть для людей, то всі знають, що треба писати стисло. Але код не читають, як книжку. До того ж як взагалі виміряти видачу програміста, окрім як кодом? “Реалізований функціонал” це щось зовсім уявне.

Тому й маємо абстракцію: кладемо в програміста гроші, отримуємо з іншого боку код. Але це нісенітниця: з програміста отримують робочу програму, а код — це тільки аспект реалізації.

Та це й навіть не головна складність. Також більша частина роботи програміста складається з редагування коду, що теж ні в яку аналогію не вкладається. А чим більше коду, тим складніше з ним працювати. Та це витрати категорично більші, ніж на первісне написання коду! Тому я завжди хочу., щоб коду було якнайменше… звісно, його завжди доводиться писати, але то так саме, як завжди доводиться витрачати клей чи цвяхи. А ще згадайте — в рідкісних випадках, коли видаляють великий шматок коду, вся команда радіє.

…Я, здається, придумав пояснення для тих, хто не програмує. Код — це уречевлена складність. Оце нехай думають, чи потрібно її більше.

Час від часу доводиться переносити великі шматки коду в нове місце. Від копіювання цілого підпроєкту в новий проєкт до перенесення класу в більш доцільне місце.

Неодмінно в такій ситуації бачиш технічний борг — який теж доведеться переносити. Та приходить ідея — навіщо переносити борг, якщо саме зараз можна його на корені переписати так, як краще? Оце ніколи так не треба робити!

Чому? Бо перенесення створює багато змін. На їхньому тлі не буде зрозуміло, що рефакторили, а що просто перенесли. Та коли в цьому коді виникнуть баги, історія версій мало допоможе в пошуку.

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

Отже, мій підхід такий: спочатку пересуваємо код з мінімальними змінами. Навіть можна, щоб він не працював відразу. Наступними комітами приводимо у притомність. А потім можна й рефакторити. Причому рефакторити краще взагалі після того, як пересування прийняте та перевірене, щоб знов-таки знати, чи відносяться баги до перенесення, чи до рефакторингу.

Таким чином в нас буде один коміт з пересуванням. Він буде величезний, але головне знати, що в ньому нема змін за змістом. А далі вже — маленькі, змістовні коміти. Чудова історія для майбутнього пошуку!

Те ж стосується й пересування в новий репозиторій — навіть важливіше — бо будемо знати, звідки взялася початкова версія коду.

Вміння ставити питання. Це абсолютно найважливіша навичка, яка розвʼязує купу складнощів. Прояснити задачу, а не залишатися безпорадним. Зрозуміти архітектуру проєкту. Знайти відповіді в інтернеті. Особливо коли ти тільки починаєш карʼєру, в тебе повинно бути багато запитань, та недосвідчена людина, яка не ставить питання — миттєвий тривожний дзвіночок.

Не треба багато піклуватися про знання. В наш час знань надто багато та вони надто мінливі. Та майже будь-яку відповідь можна знайти в інтернеті чи документації. З професійним ростом ти не набуваєш більше “знань” - тільки більше досвіду, знання навпаки забуваються та заміщаються іншими. А от об що люди спотикаються — це об невміння, нерозуміння можливості поставити питання. Це дійсно вганяє в тупик.

Інколи люди соромляться задавати “дурні питання”. Не треба цього боятися. Якщо в тебе залишається нерозвʼязане питання, навіть якщо воно наївне, в майбутньому це тільки створить більшу перешкоду. (Та, якщо так мислити, більше сорому.) Тому треба все питати. Єдине дурне питання — те, яке повторюється без змісту багато разів. Тож вміння ставити питання містить і вміння записувати відповіді.

Вміння розрізати задачу на підзадачі. Це, певно, головний показник професійного росту. Ми починаємо з маленьких задач, які за нас вже відокремили. Та поступово переходимо на складніші рівні — блоки, проєкти, і так до цілих систем. Зауважу, що тут не про “зробити” задачу, а тільки розрізати — знайти, з чого вона складається, розпланувати. Спочатку (та й завжди) - для себе. Прийде час, і ти сам будеш готувати задачі для інших.

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

Вміння доводити справи до кінця. Одна з найчастіших скарг — через не до кінця зроблену задачу. Від банального “було 5 пунктів, зробили тільки два” до менш тривіальних “не підчистили / не дорефакторили” чи “не продумали всі випадки”. Відповідальність на це лежить на виконавцеві — в програмуванні часто ніхто, окрім тебе, і не знає всі подробиці, а “хвости” вилазять тільки пізніше, коли вже і ти про них забув. Тому ми, виконавці, повинні оглянути роботу критичним оком та закрити всі недоробки. Або принаймні задокументувати на майбутнє, хоча це завжди ризикований вихід.

Як бонус — вміння побачити кінець та не йти далі. На цьому все.

От є перед вами задача, та й наче зрозуміло, що з нею робити, але знайдений підхід “не масштабується”, чи має ще якесь відоме обмеження. А хочеться справжнє, “постійне” рішення, щоб другий раз до нього не вертатись. Тільки, зазвичай, “постійне” рішення виглядає складнішим та дорожчим. Інколи — залежно від фантазії — набагато. Тож що робити?

Я ось що скажу. Будь-яке рішення є тимчасовим. Може, буквально відомий термін його дії. Може воно буде зупинене неочікуваними обставинами. Може, стане не потрібним. А потім, нарешті, будь-який продукт припинить своє існування.

Тож не треба боятися “тимчасових” рішень. Краще поставити питання — на який термін це рішення нам потрібно? (Та який взагалі “горизонт подій” ми здатні уявити?) Коли знаємо простий, хоч може й обмежений розвʼязок, який стільки “проживе” - то й чудово!

Є й інша проблема — рішення “назавжди” так само може виявитися не таким вічним, як нам хотілося. А поступатися зручністю та ускладнювати собі життя доведеться вже сьогодні. Зате якщо зробити просте рішення зараз, може через рік краще буде зрозуміло що ж його робити далі… на наступний “тимчасовий” термін. :)

От знаєте, чим більше досвіду набираєшся, тим більше до себе вимог щодо красоти рішень. І це наче має сенс. Тільки є проблема: красиві рішення не народжуються самі собою з голови. Скільки ти над ними не думай.

В письменників є правило: “напиши гидку першу чернетку”. Бо треба з чогось почати. Ніхто не пише ідеально з нуля. Та замість того, щоб чекати натхнення та уявляти твір в голові, швидше буде забути про стандарти, написати хоч щось. Тоді тобі буде від чого відштовхнутися, а це — виявляється — незрівнянно легше.

Така ситуація знайома мені з роботи: хочеться відразу зробити все правильно, красиво. А воно не виходить. А ти далі думаєш — а воно і далі не виходить. Поки…. не почнеш поступатися правилами та щось писати. І тоді потроху задача розплутується, і навіть згодом знаходиш ту саму красу, якої хотів.

І цікаво, що підхід TDD - він як раз і виконує цю саме ідею. Починаємо з примітивного розвʼязку. Потім поступово розвиваємо його. Не намагаємося зробити все відразу. Або навіть уявити всю картину. Тільки ти коли останній раз користувався TDD? Я — давно. А може, варто й почати.

Я, чесно скажу, не фанат читання загальних повчальних книжок з програмування. Спеціалізовану книгу - полюбляю. А загальну… Ну ось, знайшов три таких, які я дійсно часто згадую.

The Pragmatic Programmer - моя улюблена книга з “практики програмування”. Тут немає конкретної мови чи підходу — тільки принципи та поради. Мені, звісно, зараз багато в ній здається банально очевидним, але це тому, що я її читав. Запевняю, ця книга зробить з тебе кращого програміста.

Domain-Driven Design - ця книжка в принципі описує певний підхід до архітектури застосунків — від спілкування з замовниками до розбиття на класи. Я ніколи не користувався цим підходом. Але це й не потрібно, бо ідеї закладені в цій книжці достатньо загальні, щоб користуватися ними навколо. Зокрема ідея того, що код продукту повинен використовувати ті ж назви, що й опис його бізнес-логіки.

The War of Art - так, це не книга з програмування. Це маніфест творчої людини. Вона торкається знайомих кожному програмісту труднощів. Зокрема, головне тут — ідея “опору” (resistance) - уявної сили, що заважає нам творити. Книга напівпоетична, але має, може, найпрактичніші з порад про те, як подолати опір та творити. Я наполегливо рекомендую аудіоверсію від автора, бо він читає з великим почуттям.

А у вас є такі книги? Ну, щоб не Кнут чи Кормен-Лайзерсон-Рівест, а щось що ти дійсно читав та досі згадуєш?

Ще одна тема від пана Степана.

Програмісти — цікаві працівники. (Або це програмування — цікава задача.) Під час дай їм тиждень на задачу — зроблять за тиждень. Дай місяць — зроблять за місяць. Взагалі не давай ніяких обмежень — можуть й три місяці полірувати.

Це не тому, що вони ліниві, скоріше навпаки — в кожній задачі можуть знайти ще і ще роботи. Програмісти люблять свою роботу! Та люблять гарний результат. Настільки, що просто не знають, де й зупинитися.

Програмування на результат вимагає часових рамок. Без них жодна задача з програмування не має ніякого завершеного стану. Завжди залишається недописаний тест, непокритий крайовий випадок, не повністю впорядковані класи.

Якщо робиш проєкт як хобі — з цим простіше. Бо, або тобі взагалі байдуже, що з ним станеться, або ти все ж хочеш проєкт випустити та робиш в мінімальні терміни. Виходить парадокс: те, що на роботі зайняло б ітерацію, у своєму проєкті виходить за вечір. Так, десь воно буде поламане, тестів взагалі не буде, половину ми раніше — накопіювали б зі старих проєктів, а тепер — просто навайбкодимо. Але ж результат буде!

Мені, зокрема, дуже некомфортно працювати, коли мені не ставлять жодних рамок. Ну, як, “нам потрібно якісно, а ти вже працюй, скільки потрібно”. Але ж ми не космічні кораблі запускаємо! Тому робота й розтягується на довше, ніж її варто було б робити.