Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni
🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!26.08.2023
Починай з простого
Хочу звернути увагу на одну професійну ваду, яку за собою помічаю. Коли переді мною стоїть великий проєкт, але більш-менш зрозуміло, що має вийти в кінці, то я починаю робити його, скажімо, від початку та до кінця. А мав би робити від простого до складного.
Проілюструю. Для розробки дерева задач для Obsidian потрібно з документів витягати задачі. Кожна задача має назву — це, власне, той текст, яким вона підписана. Поки все ясно.
Але… тексту може бути більше одного рядка. Або не бути зовсім. Або це не текст, а блок коду, чи заголовок, чи зображення. А також в тексті може бути форматування, посилання, ті ж самі зображення… Markdown все це дозволяє.
Підхід, який я вважаю вадою, це відразу намагатись покрити всі можливі комбінації синтаксису. Їх же ж вигадувати не треба — все відомо. От тільки вигадати код, який все покриває, непросто, та й взагалі, незрозуміло, як підступитись. Навіть маленький шматок (такий, як обхід дерева в пошуці задач) - складна задача, якщо вона має покривати всі можливі варіанти.
Краще, на мою думку, взяти найпростішу ситуацію: коли в документі є тільки список задач, та кожна задача має тільки один рядок опису з чистого тексту. Далі — потроху ускладнювати (наприклад, дозволити більше одного рядку тексту.)
Мені це здається контрінтуїтивним: якщо я знаю майбутні умови, навіщо мені свідомо ігнорувати їх та писати код, який гарантовано доведеться переписувати? Чи не зайва то робота? В тому й справа, що поступовий рефакторинг дає кращий код, ніж спроби відразу передбачити все.
Наступного разу пропоную планувати роботу від найпростішої реалізації до повної.
(Так, я розумію, що це приблизно те, що радить TDD.)