Стендап Сьогодні
📢 Канал в Telegram @stendap_sogodni
🦣 @stendap_sogodni@shevtsov.me в Федиверсі

🤖🚫 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

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

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

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

20.02.2025

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

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

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

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

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

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

22.02.2025

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

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

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

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

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

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

24.02.2025

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

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

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

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

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

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

28.03.2025

Почитай книгу

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

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

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

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

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

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

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

24.04.2025

Швидкі задачі

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

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

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

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

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

29.04.2025

Кращий час для виправлення технічного боргу може бути зараз

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

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

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

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

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