Software Development puzzle

Cow and Hero

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

В общем результат побочного эффекта:

QA capacity

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

Дикий девелопер

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

Заменяемый солдат

Бойцы должны быть взаимозаменяемы, каждый должен быть способен взять меч товарища и разрубить в клочья космических засранцев. Программисты должны переходить в тестировщиков при необходимости, это сильно повышает гибкость команды и реально поможет выдавать больше (рубить больше космических засранцев). Взаимозаменяемость должна происходит не только вертикально, направлении Developer => QA но и горизонтально, Developer-1 => Developer-2. Те. нужно шарить знания, учится пользоваться оружием товарища. Всего этого можно достичь путем введений code review, парного программирования, месячной групповой медитацией и групповым 3 - х недельным запоем.

Опасайся "неведомой ебаной хуйни"

Внедрение языка или технологии в которой разбирается один член команды сильно уменьшает гибкость команды, все становится еще печальнее если остальные члены команды не заинтересованы в изучении внедряемой технологии/языка. Все это дело влечет за собой расслоение команды, депрессии, массовые самоубийства, поиски работы на стороне, в общем ничего хорошего. Если возникла мысль интегрировать в проект новый язык подумай 2 раза, потом еще 3. А потом еще.Так как это сильно увеличит сложность проекта в целом (тут можно посмотреть призентацию Rich Hickey Simple Made Easy), уменьшит гибкость команды, приведет к всяким плохим вещам и вообще будет полный пиздец. В общем опасайся неведомой ёбаной хуйни.
Тут должна быть картинка "неведомая ёбаная хуйня"

Penetrate gently

Рефакторить только тот код который покрыт тестами. Хочешь прорефакторить -> покрой тестами! Тут все просто.

ЗЛО

Использование сторонней тулзы для проведения функционального тестирования и автоматизации регрессионного тестирования - ЗЛО! Зло становится еще большим если система хранит конфиги тестов и тестовые данные в бинарном виде (например excel), это делает невозможным нормальное использование системы контроля версии (тут просто наболело). Суть зла заключается в том что тесты написанные в отдельной тулзе придется поддерживать, тесты не будут автоматически изменены после рефакторинга кода и это порождает огромные проблемы. В итоге время затраченное на поддержку сторонней тестовой инфраструктуры будет просто колоссальным. Этого можно избежать если функциональные тесты будут написаны в одном проекте с тестируемым кодом, на нормальном языке таким образом будет нормально работать рефакторинг что поможет сократить время на поддержку тестов.

Про отстой

Документация - полный отстой в плане хранилища сакральных знаний о проекте и предметной области, ее сложно поддерживать, она не актуальна. Комментарии к коду практически такой же отстой (тут про комментарии касательно бизнес требование а не тех которые про дикие моменты в коде и magic numbers). Например если вы решаете указывать версию документа по которой было реализовано требование вы скоро придете к тому что номер не соответствует реализации. Получается полная жопа. И единственное что может нам помочь это.... КОД! Наш любимый код, который мы так любим и ненавидим. Что приводит на к следующему абзацу.

Код должен быть само документируемым и максимально приближен к предметной области. В идеале все бизнес задачи должны быть описаны высокоуровневым API который оперирует бизнес объектами. А нирваны можно достичь путем написание DSL на котором реализуются бизнес требования, это сделает код максимально выразительным и приближенным к предметной области.

Written on December 15, 2012