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

А коли команда до десяти людей і проєкти невеличкі, ще й стартують частіше, ніж раз на пʼять років, то треба їх якось початково сетапити, нерідко власноруч. А якщо це не «повноцінні» проєкти, а прототипи — то критично важливо це ще й робити швидко, бо прототипи можуть писатися по декілька штук на місяць/тиждень/день (а потім іти у смітник 🥲).

І для себе я відокремив мінімальний набір найважливіших штук, які намагаюся налаштувати зі старту:
1. Білд однією командою.
2. Лоґування.
3. Конфігурація.
4. Тести.

З першим усе наче зрозуміло, бо я вже неодноразово писав у попередніх дописах.

Друге — це прям must have. Я зазвичай не користуюся зневаджувачем з низки причин. По-перше, у C++ з ними поганенько. По-друге, колись давно компонувальник просто не міг зібрати дебажний білд нашої програми для телефону, бо він був 32-бітний, а в нас там ліби по 800+ мегабайт (шаблони розгорнулися ггг). Тож я звик користуватися лоґами. І бажано, щоб це був не cout або print, а нормальне лоґування з часом тощо. А якщо ще й у файл пише, то взагалі збс. І щоб для користування не треба було навколо танцювати, а достатньо було додати один #include або import у будь-який файл.

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

Тести… Їх народ не любить писати. І я не любив і досі не люблю. Але згодом я збагнув, що не люблю цього робити не тому, що це якось складно, нецікаво або не дуже потрібно, а тому, що якогось хєра це завжди дуже марудно! Обовʼязково треба поприсідати, щось кудись прокинути, десь ввімкнути, прописати тощо. Отже: сетапимо все з самого початку, робимо порожній тест, який нічого не перевіряє, але він є — і вже люди зможуть далі робити за зразком. (Це як перлина: щоб вона сформувалася, треба якусь пилинку, навколо якої потім вже нашаровується перламутр). А далі замість того, щоб додавати в програму якесь тимчасове лоґування проміжних значень, запускати програму, дивитися, чи правильне там значення, чи ні — замість усього цього просто робимо тест, який робить те саме: перевіряє проміжні (чи які вам треба) значення! Зручно й швидко 🙂

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

Добре, коли сама мова тобі допомагає це робити. Наприклад, в тому ж Nim 👑, памʼятаю, тести дуже легко писати. Прямо в тому самому файлі навалюєш їх — і все працює. Або в Ruby ♦️ та Crystal 🔮 теж класно.

А днями дізнався про прикольну фішку мови Chapel: там є конфігураційні сталі та змінні! Буквально додаєш config перед оголошенням

config const steps = 42;

як отут 👆, і бем! — жодних додаткових рухів не треба. Тепер можна або ключем значення передавати: myapp --steps=100500 — або через конфіг-файл. Так, цукор, але люблю таке. (А от у сусідньому чаті, де я це побачив, чувак якийсь підгорів з того config і доводив, що це кепська фіча. Хз.)

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