Наявність світла — тема, що актуальна вже другий рік. Багато розробників замислювалися над застосунками, які сповіщали б про те, чи є світло вдома в конкретний момент. У цій статті детально порівнюються коди двох таких проєктів.
У цій статті Олександр, фронтенд-розробник у компанії Uptech, розповідає, що таке legacy-код та як спростити собі та іншим роботу з ним. А також ділиться різними рекомендаціями, як можна знизити кількість помилок і підвищити загальну надійність застосунків.
Розберемось, як влаштований CR, як підготувати свій код, а також дати зворотний зв’язок, коли ви знаходитесь у ролі ревʼюера. Через те, що зазвичай одній людині доводиться одночасно виступати як автор коду та як ревʼюер для коду колег, то інформація у цій статті буде корисна для всіх, хто працює з кодом.
Team Lead і Java Coach Богдан Чупіка зібрав у цьому матеріалі досвід колег щодо проведення code review і розбирає на конкретному прикладі, як організувати цей процес якісно та корисно для проєкту.
Невеликий обсяг ще не гарантує, що ваш код буде чудовим та без багів, а кожен девелопер зможе його підтримувати. Зазвичай, це означає протилежне. Андрій Стаценко, керівник напряму NodeJS ділиться думкою про те, який підхід до написання нового коду є найкращим.
Михайло, фронтенд-розробник, зібрав правила, які допомагають швидко та легко проходити Code Review. Стаття буде корисна як новачкам, так і просунутим розробникам, оскільки розвиток будь-якого проєкту рано чи пізно вимагає вливання нового коду через рев’ю.
Коли пишеш читабельний код, то допомагаєш майбутньому собі. Бо зрозумілий код потрібен насамперед тому, хто буде його змінювати.
Олександр Бородін, COO в VT Labs, за 10 років досвіду в Software Development мав нагоду подивитися на код і як розробник, і як менеджер, і як замовник. У цій статті він розповідає, як різні практики та стандарти коду впливають на життя девелопера, його оточення та продукт.
Як проходить код-рев’ю у компанії, де працюють 25 команд розробки?
Інна Дитяшова, Software Developer в FIVERR, розповідає про підходи та інструменти, які вони використовують, а також про те, які проблеми виникають, коли над одним продуктом працює близько 150 програмістів — у статті.
Механізм code review достатньо простий: написали код — перевірили — внесли правки — протестували. Ніби нічого особливого, але вся суть у деталях, як завжди.
Євгеній Вінійчук, Senior Software Engineer та Team Lead в Youshido, поділився своїми заувагами, на які він зважає в роботі з review. Як треба і, головне, як не треба критикувати — читайте у його статті.
Максим Усатенко, .NET разработчик, делится 7 кейсами из личного опыта, которые не только уменьшат количество ошибок на проде, но и улучшат чистоту и качество вашего кода.
В статье упор делается на человеческий фактор и определенные взгляды на процесс разработки — то, что может пересмотреть каждый девелопер, не увеличивая бюджет проекта и не привязываясь к конкретным требованиям заказчика.
«Нет такого Code Review, который смог бы ускорить вашу разработку»
Code Review — король разногласий и недопониманий между разработчиками, катализатор отмирания нервных клеток и то, из-за чего ваш эстимейт может оказаться не таким уж и завышенным. Почему и зачем применять его однозначно нужно и что учитывать в процессе — читайте в статье Никиты Мазура, Front-End Developer в Django Stars.
Станислав Фелинский, Software Architect, делится опытом code review в контексте GameDev, его принципами и рабочими методами. Материал будет интересен как авторам и рецензентам кода, так и всем инженерам команды.
Со сложностью программ нужно бороться, считает Артём Побережный, NodeJS Developer. Ведь чем дольше наши приложения будут оставаться простыми для понимания, тем дольше мы сможем быстро и дешево их улучшать.
Чтобы упростить систему, надо избавляться от лишнего. От чего и как — читайте в статье.
Коментарі