Стендап Сьогодні
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
07.04.2026
15 хвилин про bike shedding
В мене, якщо не писати щодня, прокидається бажання писати серйозніше, але не зараз, а коли буде час. (Ніколи.) Тож спробую нову тактику: нехай пост займає не довше 15 хвилин; є що сказати — ділюся.
Bike Shedding - це відоме явище в плануванні, при якому певній неважливій частині приділяється неадекватно багато часу. Назва походить від байки, де під час планування електростанції комісія захопилася подробицями гаража для велосипедів. Чи щось таке.
Звісно, в програмуванні нас чекає особлива пастка. Часто наперед не зрозуміло, де в нас “електростанція”, а де “сарайчик”. Або погляди на це розходяться. Одним словом, в програмних проєктах (не)важливість аспекту не так легко побачити.
От, проєктуєте ви JSON API. І все з ним зрозуміло. Але. Чи повертати поля результату на верхньому рівні {"foo": "bar"}, а може, загорнути в {"data": {"foo": "bar"}}, чи response, чи entity, чи все ж за назвою сутності {"fooser": {"foo": "bar"}}?
На жаль, чіткої відповіді немає. Тому є шанс застрягнути на цьому питанні. (Це гарна ознака “сарайчика” - чим більше варіантів, тим менша важливість.) Кожен поділиться власною думкою. Може, навіть прийде ідея розшукати стандарти. Дослідження зробити…
Стандарти різні — є, та їх багато, але дотримуються їх бозна-хто та бозна-як. Якщо ви бачили багато різних API, то там завжди по-своєму. І за моїм досвідом, такий аспект API аж ніяк ні на що не впливає. Тож можна було й не починати весь цей процес, а відразу взяти будь-який підхід та піти далі.
А от що дійсно важливо — то дбати про узгодженість в межах власного API.