#думки_вголос
Що таке код-ревʼю і кому воно потрібне? Особливо сьогодні, в часи LLM, які прямо все-все можуть робити за нас.

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

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

В першу чергу це спосіб не пропустити сумнівні рішення не лише в кодову базу, а й у голову автора. Адже схваливши такі пул-ріквести, ми прямо кажемо — "молодець, нам норм". І якщо таке рішення проходить раз, другий, то на третій автор уже буде впевнений, що його підходи до коду — правильні.

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

Це, певно, одна з найперших порад, які я даю щодо покращення процесу ревʼю — вчіться один у одного. Код-ревʼю це чудова нагода для цього.

Щодо LLM в код-ревʼю. Це прекрасний інструмент для визначення механічних хиб — потенційних багів чи відхилень від конвенцій. В цьому плані використання LLM не відрізняється від того ж лінтера чи ще якого статичного аналізатора. Усе, що може бути автоматизоване — має бути автоматизоване.

Але й повністю віддати на плечі алгоритму весь процес ревʼю мені не видається можливим. Він може покрити більшість речей, які можна формалізувати, а от відкриті до дискусій питання будуть приречені на довічне лімбо "це вже майже ідеальний варіант, але…". З LLM дуже важко сперечатися, воно завжди знайде до чого доколупатися. Навіть у рішеннях, запропонованих ним же.

Насправді, на мою думку, головна причина неможливості повної автоматизації код-ревʼю LLM — це відповідальність. У LLM її немає. "Так, дійсно, я пропустив цей PR. Хочеш, більше не буду його пропускати?".

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

Хороше код-ревʼю має шукати відповідь на питання "Чому автор зробив саме так?". Не "чому тут let а не const", не "Boolean() vs ||", чи ще якесь технічне душнільство, яке має бути знайдено пайплайном. А саме "Чому автор обрав цей шлях?".

Хороше код-ревʼю заохочує. До дискусії, до обміну знаннями, до професійного росту.

Хороше код-ревʼю — спільна справа. Джуни мають ревʼювати техлідів, так само як і мідли — синьйорів. Одним словом — усі мають ревʼювати усіх.

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

Код-ревʼю — це точка росту не лише для одного розробника, а й для усієї команди, продукту.

P.S. Цієї середи, до речі, відбудеться онлайн-зйомка "Вайбкод-ревʼю для трейні". Деталі згодом ;)

#коштозбір
Товариство, збір на РЕБ для 115 ОМБр триває.

Зібрано: 43 105 грн
Мета: 300 000 грн

🔗Посилання на банку
https://send.monobank.ua/jar/46FX59UkXS

💳Номер картки банки
4874100026432743

Громадо! 2 квітня робимо чергову лампову, і вже знаємо, що буде гаряче.
Двоє спікерів, обидва з темами про ШІ — але не з тими, де “ой які ми всі молодці, живемо в майбутньому”. А з тими, де чесно і в лоб.

Мирослав Танцюра розкаже, чому ШІ пише фігню — і чому це не його провина (спойлер: це наша).

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

Формат як завжди — ніякого “сиди тихо і слухай”. Хочеш перебити — перебивай. Хочеш челенджити спікера — будь ласка, тільки будь готовий, що тобі теж прилетить. Без образ, але й без дипломатії.

І так — на цій зустрічі ми анонсуємо наступну лампу. Нова локація, новий формат, спонсори, подарунки, афтепаті на свіжому повітрі. Коротше, ми трохи підросли і хочемо показати, що з цього вийшло.

📅 2 квітня, двері о 18:00

📍 Львів, офіс Sigma Software

Приходь, якщо не боїшся думати вголос. Ну і якщо боїшся — тим більше приходь, ми тебе розговоримо.

Реєструйся ось тут за ціну менше смузі

#коштозбір
Товариство, збір на РЕБ для 115 ОМБр триває.

Зібрано: 44 155 грн (+1050грн)
Мета: 300 000 грн

🔗Посилання на банку
https://send.monobank.ua/jar/46FX59UkXS

💳Номер картки банки
4874100026432743

#анонс
Товаристо, сьогодні відбудеться онлайн-зйомка на ютуб.
Це буде вайбкод-ревʼю для трейні. Не те, щоб зовсім новий формат, але мій підхід буде сильно відрізнятися від того, що я вже робив на публічних співбесідах.

По-перше, фокус буде не на коді як такому, а радше на відповідальності за цей код. Чому? Бо головна умова — задачу має бути виконано вичключно за допомогою ШІ.

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

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

Ну й тривалість має бути меншою за звичні дві години, але хто зна, хто зна…

Планую почати зйомку о 19 годині, тож хто має час та натхнення долучитися, чекатиму вас у віртуальній студії:
https://riverside.com/studio/-s-studio-3uCyp

.

За кілька хвилин почнемо потихеньку запис "Вайбкод ревʼю для трейні", тож як маєте бажання, заходіть до студії.
https://riverside.com/studio/-s-studio-3uCyp

Маленький тизер на завтра )

Нове відео на каналі!

Товариство, запрошую до перегляду нашої розмови з Павлом Зубенко, Engineering Manager в Svitla Systems. Обговорили багато цікавого — що то за роль така, чи пише Павло код, що найважче в роботі і так далі. І ще трошки про джунів поговорили.

https://youtu.be/wUruDAKZj0E

ВПОДОБАЙКА Й КОМЕНТАР ПІД ВІДЕО ОБОВʼЯЗКОВІ

***
Відео вийшло за сприяння Svitla Systems, глобальної IT-компанії з більш ніж 20-річним досвідом, головний офіс якої знаходиться в Каліфорнії, а операційна діяльність поширюється на більш ніж 15 країн, зокрема США, Канаду, Мексику, Коста-Ріку, Аргентину, Україну і Польшу.

Svitla об'єднує понад 1000 спеціалістів з різних технологій. Серед клієнтів як інноваційні стартапи, так і компанії із Fortune 500.

Вакансії Svitla Systems

@babichdev

#розіграш
А ще маємо "Питання від партнера", товариство.

Svitla Systems розігрує бананку і крутяцьку парасольку (дивлюсь у вікно — актуально шо капєц) просто за те, що ви дасте відповідь на запитання у формі.

Цього разу, до речі, єдино правильної відповіді немає, тож участь в розіграші братимуть усі, хто заповнять формочку до 13 квітня.

https://forms.gle/rqHKzisACJxDsSCp9

І якщо ви ще досі з якихось причин не подивилися нове відео "Що робить Engineering Manager" — не зволікайте. Вийшло дуже цікаво.

#коштозбір
Товариство, збір на РЕБ для 115 ОМБр триває.

Зібрано: 47 210 грн (+3055грн)
Мета: 300 000 грн

🔗Посилання на банку
https://send.monobank.ua/jar/46FX59UkXS

💳Номер картки банки
4874100026432743

P.S. Я дуже хочу написати один допис про крутяцьку фічу CSS, але не маю достатньої мотивації. Мотивація може зʼявитися, якщо сьогодні до вечора зʼявиться щонайменше 20 донатів. Будь-яких, від 10 до 1000000000грн, аби вони зʼявилися )

Подивіться трохи смішного, може подобрієте і пару гривень закинете на наш збір.
https://www.youtube.com/watch?v=4IbYcY0-va0

Ще шість донатів не вистачає до нового допису. Маєте часу до вечора )

UPD: Вніс передоплату в 70000 грн.
Тепер маємо 40 днів на те, щоб зібрати залишок. Квитанція в коментарях

UPD2: Допис закінчив пізно, тому буде вже зранку )

#css_in_action
Анімуючи небуття
Ми усі звикли до анімацій в CSS. Зокрема я зараз говоритиму про transition: воно змінює значення від початкового до кінцевого в залежності від часової функції на заданому часовому проміжку.

І тут важливо згадати про дві умови: анімація не може відбутися, якщо немає так званого before-change style — попереднього відрендереного стану, від якого анімація може стартувати, а також якщо значення, яке ми намагаємося "оживити", не може мати проміжних станів, тобто є дискретним.

В CSS обидві умови можна зламати, просто використавши display: none. Тривалий час задача "показати/сховати елемент і додати анімацію появи/зникнення" покладалась на JavaScript та його ненадійні таймери. Згодом зʼявилася дещо надійніші події на кшталт transitionend, але вони вирішували лише частину проблеми.

Але сьогодні ця задача більше не є проблемою. CSS надає нам дуже цікаві інструменти, що дозволяють дещо більше, ніж просто "анімувати `display:none`".

Мова про @starting-style та allow-discrete.

Коли елемент переходить від display: none до "видимого" значення, за замовчуванням усі кінцеві значення властивостей застосовуються одразу, навіть попри transition-duration. Чому? Бо у елемента немає *початкового стану*, на основі якого можна розрахувати перий кадр анімації. Чому? Бо він на момент початку переходу просто ніколи не був *відмальований*. Це якщо ми говоримо про видиму зміну стану.

Примітка
Елемент може не мати відмальованого стану з кількох причин. Наприклад, display: none означає, що елемент взагалі не бере участі в рендерингу, а от visibility: hidden значить, що елемент невидимий, але займає місце в макеті.

Так от, тут в нагоді нам стає @starting-style. Це @-правило дозволяє "допомогти" бравзеру створити той самий перший кадр, від якого він уже буде спроможний розрахувати анімацію. Тобто сама суть не в тому, що бравзер не може інтерполювати певні значення, а в тому, що він просто не розуміє, як має виглядати перший кадр.

element {
  transition: 1s;
  display: none;

  &.visible {
   display: block;
   opacity: 1;

   @starting-style {
     & { opacity: 0; }
    }
  }
}

Таким чином можна додати анімацію не лише до display: none -> block, а й при вставці нового елементу в DOM. Тож, якщо коротко: @starting-style це шпаргалка, яку ми надаємо бравзеру, аби він зміг зрозуміти, як намалювати перший кадр анімації для елементу, у якого не було відмальованого (rendered) стану до того.

Наступна проблема — анімація від видимого стану до "невідмальованого", і полягає вона в абсолютно іншому механізмі: оскільки дискретні значення анімувати неможливо, бравзер за замовчуванням просто "перемикає" їх на *початку переходу*. І саме тому намагаючись "анімувати" елемент в небуття від display: block до display: none ми не бачимо переходу, а лише миттєве зникнення.

Це можна було б вирішити, якби можна було "відкласти" перемикання на потрібний нам час замість миттєвої зміни. І от якраз це раніше можна було вирішити виключно за допомогою JavaScript: або ставити таймери, або слухати події завершення анімації, і вже тоді "клацати перемикач" вручну.

І, нарешті, цей механізм є і в CSS. Це значення allow-discrete для властивості transition-behavior. Він робить рівно те, що необхідно: дозволяє відкласти перемикання дискретної властивості на потрібний час.

element {
  transition:
    opacity 1s,
    display 1s allow-discrete;
  display: none;
  opacity: 0;
}
element.visible {
  display: block;
  opacity: 1;
}

Якщо ми приберемо .visible з елементу, то спочатку побачимо, як той поступово "зникає", і лише в кінці, коли opacity досягне нуля, display набуде значення none.

Якщо коротко, то allow-discrete дозволяє визначити для перемикання значення дискретної властивості певну точку на часовій шкалі анімації, але з купою виключень, звісно. Які я вам пропоную дослідити самим.

MDN: @starting-style
MDN: allow-discrete

***
@babichdev