Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

Пости з тегом #Розробка

12.11.2024

У вас, певно, не буде часу на це переписування

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

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

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

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

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

16.01.2025

Скільки інженерних практик є прихованими механізмами подолання РДУГ?

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

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

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

20.02.2025

Фічафлаги та рефакторинг

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

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

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

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

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

22.02.2025

Проєкти зеленого поля

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

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

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

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

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

24.02.2025

Мікроменеджмент

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

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

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

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

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