Как бороться с говнокодом в проекте

good-code

Введение

Эта небольшая классикация наводит порядок у меня в голове и раскладывает по полочкам тот скромный арсенал методов, которые может противопоставить хаосу и энтропии боец, стоящий перед фактом неотвратимого дедлайна и осознающий природную лень разработчиков софта.

По поводу оценок

  • Затраты личной энергии — сколько психической энергии должен потратить «Лично» автор фичи, чтобы просто это реализовать, при этом ни на кого не надеясь
  • Долгосрочный эффект — насколько уменьшится % ошибок, улучшится качество кода и возможно даже дизайн
  • Требования к уровню процессов в компании — сколько потребуется помощи от менеджмента компании, и при каком минимальном уровне процессов в компании это будет работать

Self-review

Затраты личной энергии:3 Stars
Долгосрочный эффект:2 Stars
Требования к уровню процессов в компании:0 Stars

Перед коммитом просматриваем каждое изменение в changelist по Ctrl+D в IDEA.

Эффект:

  • это дисциплинирует
  • отлавливается много мелких ошибок
  • позволяет взглянуть на коммит «целиком» незамыленным взглядом
  • позволяет написать комментарии и стереть todo там где это нужно
  • можно сразу обобщить какое-то решение если мы видим что оно применяется больше чем в 1-2х местах

Unit-tests

Затраты личной энергии:4 Stars
Долгосрочный эффект:4 Stars
Требования к уровню процессов в компании:1 Stars

Всегда пилим систему на модули\кубики.
Кубики должны быть развязаны по логике и отвечать за конкретные задачи.
Между кубиками желательны «чистые» интерфейсы без контекстов и зависмостей.

Далее каждый кубик мы покрываем unit-тестами или функциональными тестами (которые гоняются на каком-либо окружении)

По возможности используем mock-и , это очень мощный инструмент. Как пример отличной библиотеки — Mockito.

Эффект:

  • снижает стресс — надо меньше ограничений решения держать в голове, нажал F9 и убедился что функционал не сломан
  • всегда знаем, что система минимально «работает», так же новому человеку в команде легче понять что код «не сломан»
  • не боимся рефакторить код
  • держим сложность кода в рамках приличия
  • не боимся смотреть в глаза QA и PM, меньше «эхо» из багов после релиза

Сложности:

  • трудно дизайнить чтобы было testable
  • трудно найти баланс между легкостью теста и покрытием
  • надо хорошо понимать код
  • старый код может сильно сопротивляться (но есть моки!)
  • надо выделять на написание и поддержку тестов время, это окупается но сроки проекта должны позволять писать тесты, и менеджмент должен это понимать.
  • малоэфективно тестить определенные области: UI, сеть, то что завязано на производительность и многопоточность, то что завязано на конкретные настройки окружения
  • важно не путать unit-тесты и полноценные функциональные авто тесты, последние на порядок более серьезная задача

Авто-тесты/QA

Затраты личной энергии:1 Stars
Долгосрочный эффект:4 Stars
Требования к уровню процессов в компании:4 Stars

Если у нас есть опытные QA, которые способны гонять тесты на реальной системе  (эмулируя работу внешних систем), то это сильный шаг вперед в качестве. Часто когда мы пишем Java EE код, то толком протестироваться с помощью unit-тестов нельзя, код может быть жестко завязан на БД\внешнюю систему\ESB-шину, требовать тонну магических xml-конфигов итд. итп.

Эффект:

  • сдача проекта становится менее нервным мероприятием при наличии автоматизированного способа валидации функционала
  • можем гонять тесты при приемке компонентов, которые реализовывал субподрядчик
  • как и любые автотесты, их можно гонять перед каждым билдом

Сложности:

  • нужен отдельный выделенный QA, который умеет заниматься автоматизацией
  • любые изменения функционала ломают тесты, поэтому писать их имеет смысл только на заключительной стадии, когда 80-90% функционала написано и уже устоялось
  • если система не модульная, или нет хороших точек для «расширения» (протоколы, интерфейсы), то писать автотесты может быть трудновыполнимой задачей
  • UI плохо поддается такому тестированию или требует отдельных инструментов\навыков; крупные компании\долгоживущие проекты вполне могут себе это позволить, в остальных случаях ручное тестирование UI гораздо гибче и быстрее.

Автоматический code-review

Затраты личной энергии:1 Stars
Долгосрочный эффект:1 Stars
Требования к уровню процессов в компании:3 Stars

Доступны вот такие инструменты (в порядке убывания пользы)

  • IDEA Inspections — поиск ошибок в коде от JetBrains встроенный в IDE, для него можно сделать шаблон и раздать каждому в команде.
  • PMD  — поиск багов и кривое использование API
  • Findbugs  — поиск багов,
  • Checkstyle  — проверка code conventions,

здесь есть сравнение PMD/Findbugs между собой

плюсы

  • работает само
  • улучшается читаемость кода
  • исправляются очевидные ошибки
  • легко фиксить не вникая в код за «константное время»
  • легко внедряется

минусы

  • автоматизированный тул не находит сложные моменты, не понимает код
  • ложные срабатывания
  • крайне трудно натянуть на живой проект, если изначально он начинался без применения подобных инструментов; может быть написано много кода да и команда не обучена использованию подобного инструмента
  • слабый долгосрочный эффект

Парное программирование

Затраты личной энергии:5 Stars
Долгосрочный эффект:4 Stars
Требования к уровню процессов в компании:4 Stars

Сидим вместе за одним пк, один пишет код второй думает и проверяет.

Хорошо

  • в целом решения получаются несколько более взвешенными и продуманными т.к. коллективный разум легко отсеивает совсем плохие решения, может немного вырасти креативность
  • знание шарится между членами команды (collective code ownership), когда один увольняется у нас есть замена
  • люди обучают \ тянут друг друга

Плохо

  • «тормоза» тормозят остальных
  • не всем нравится, люди должны быть совместимы, тяжелая притирка
  • производительность ниже, чем при индивидуальной работе
  • голова устает от болтовни, надо понимать что за «писать код» и «болтать» отвечают разные зоны мозга и не все так могут
  • компания должна одобрять такой подход явно, а значит всё упирается в менеджмент

Ручной code review

Затраты личной энергии:3 Stars
Долгосрочный эффект:4 Stars
Требования к уровню процессов в компании:2 Stars

смотрим каждый коммит и стучим автору по голове.

Хорошо если процесс code-review поддерживает какой-то автоматизированный инструмент для комментирования кода, но можно и просто писать email или доносить результат лично.

Хорошо:

  • долгосрочный эффект в росте продуманности решений в проекте

Плохо:

  • наказывать и ругать всегда не так эффективно, лучше предотвращать говнокод на более ранних стадиях
  • возможны конфликты, если автор активно защищает свой говнокод  и ревьювер не обладает должным авторитетом\не наделен дубинкой :)
  • если решение «объемное» и уже реализовано в коде — глобально переделывать может быть слишком затратно

Другие записи...

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

* Please Enter the Output

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>