О процессах разработки, или об чем все знают - записки КО, часть третья

В прошлых сериях выпусков “Записки Кэпа” были частично освещены такие моменты, как писание тестов на тесты тестов для тестов кода и почему всем должно быть похуй на Git.

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

Итак, тора гие читатели этого уютного дневничка, как вы знаете - если в любом софтострое собирается минимум двое программистов - то один из них сразу Архитектор. Если трое - то Директор или ЦТО, Старший Программист и джуниор-сбегайзаводкой. Лычки тут могут быть самые разные, но в целом это ситуацию не меняет. Чем больше народу - тем иерархичнее стая бабуинов, это обусловлено эволюцией, структурой интеллекта и мозга да и вообще теорией категорий в полный рост.

Следующая очевидная весчь - софт пишется не сразу, не прям из головы (прошли 90-е, эх, всплакнем о “select * from customer” по $1000 за строчку SQL запроса). Это долгий и мучительный процесс, в котором присутствует такая чуждая любому метаклассу вещь как коммуникация.

Вот об коммуникации в команде программистов и сейчас подробнее. Потому как все эти методологии вырастают именно из неё, если бы софт писался в одиночку - ничего бы этого не было никогда, за ненадобностью а на марсе росли бы яблони, группы свободного поиска бороздили просторы Саракша, ну и так далее, Туманность Андромеды вот это все.

Итак, чтобы писать какой-то софт, как правило нужно

  • собрать требования (будем писать скайнет или говносайт на похапе с тремя страницами)
  • проникнуться доменной областью, ну например понять зачем нужна двойная бухгалтерия или как правильно выписывать откаты с тендера
  • осознать границы своей некомпетентности и попробовать понять, чем их расширить (купить недостающий софт, прикрутить сбоку бантик етц)
  • расчленить систему на большие компоненты, про которые можно сказать а хуй его знает что оно там делает, но клева что оно как-то должно получать транзакции с маркета и передавать его соседу, чтобы он по ним разложил бабло на аккаунты. При этом про аккаунты и маркет все знают чуть меньше чем ничего.
  • углубить знания доменной области
  • расчленить систему на охватываемые границами восприятия компоненты, чтобы транзакции с маркета уже было например разобраны на типы документов (XML, JSON, CSV или какой-то FLS)
  • выделить из этого всего некие сучности, интефейсы, придумать контракты
  • написать код
  • протестировать
  • сдать проект
  • получить бабло

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

Мне реально впадлу писать про канбан и скрам, генерацию кода про UML и прочее, поэтому я остановлюсь на двух больших группах процессов - итеративном эджайле и водопаде.

Начну с водопада, как наиболее презираемого прогрессивной общественностью.

Водопад придумали тогда, когда компьютеры были большими, время работы компьютера стоило сильно дороже времени работы программиста, ресурсы этого самого компьютера стоили еще больше, чем если бы программиста продали на органы. Соответственно подход к штанге машине был своего рода Ритуалом, когда пачку из сотен перфокарт надо было ввести в 1-мегагерцовый процессор 4096 килобайт кода и данных, чтобы посчитать приземление Аполлона на космические декорации Луны в Голливуде, или там ядерный взрыв на Новой Земле. Я лично с водопадом столкнулся в школе, когда за 45 минут нужно было отладить ассемблерный код для TSR, написанный на бумажке в 4 столбика. Из этого можно еще развести большой срач на тему, почему людей не умеющих писать код на бумаге, нужно вон из профессии ссаными тряпками, но это в другой раз. К слову, у всех нас в той школе программы на ассемблере работали практически с первого ввода, и мы их могли чуть не по памяти записать (а многие прерывания MS DOS я до сих пор помню, равно как предназначение int 13h и недокументированные функции MS DOS 6.22 по int21h, ah=52h). Но тут я чуть увлекся своей неебической крутизнойвоспоминаниями молодости, потому вернемся к водопаду.

Из предпосылки “час работы компутера” »> “час работы программиста” следует, что программа должна хотя бы работать на момент введения в эксплуатацию. Чтобы этого добиться - ввели правила, по которым

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

исходя из этих правил, чувак со стопкой перфокарт на руках имеет практически 100% рабочее приложение, которое отладили в мозгах и доказали корректность (привет, Coq и AGDA)

Так было написано очень много банковского софта на коболе и прочих реликтах, и все было относительно неплохо, пока пацаны из IBM/Microsoft/AMD и прочих контор не начали сильно снижать цену железа и ресурсов, приведя индустрию в коллапс пиздеца “да хуле тут оптимизировать, докупим еще 100500 гиг памяти и купим кластер у амазона”, мелкософтофиса на четырех ДВД и т.д.

Цена часа работы программистов и часа работы железяки сначала сравнялась, а теперь ваще уже несопоставима. И умные чуваки, почесав репу, решили - водопад неэффективен, потому что соседняя контора Рога И Копыта клепает 10 говносайтов в минуту, а мы только 1 клевый проект в год. И тут понеслась.

Началась гонка на выживание - кто выкатит продукт бизнесу быстрее. Потому что бизнес не ждет, ему надо вчера, надо чтобы круче у конкурентов, потому что пипл хавает и так. И родилась культура “хуякхуяквпродакшн”, как следствие - разные скриптовые недоязыки типа Руби, ПХП или там Петона, на которых этот хуяквпродакшн делается левой задней пяткой не приходя в сознание после кокаинового прихода от смузи в коворкинге в лофте.

Другие умные чуваки (ну вы помните, кто не умеет работать - тот руководит, кто не умеет ни руководить, ни работать - то учит) на волне этого всего придумали модное словао эджайл, под которое подвели все свои пережитые детские травмы и унижения. Нелюбители митингов решили издеваться над чуваками и придумали скрамстендапы. Чуваки, не умеющие планировать свою и чужую работу, придумали принцип коллективной ответственности и общее владение кодом. Ну чтоб крайнего потом не найти. Также они придумали спринты и отмену спринта при изменении требований.

В общем, там, где водопад практиковал доскональное понимание “а что мы собственно делаем” и имел четко разделенные зоны ответственности, всякие распиздяи придумали себе целый список отмазок, чтобы всегда можно было прикрыть жопу.

Если внимательно прочитать все принципы этого самого эджайла, то они офигенно похожи на EULA мелкософта - мы ни за что не отвечаем, оно само.

И что самое смешное - это устраивает бизнес. Потому, что инфраструктура ойти в подавляющем большинстве случаев - вспомогательная, или вообще расходная часть. И если внедрение какой-то методологии позвляет реально (а чаще - на бумаге и в красивых отчетах) сэкономить бабло заказчика - то это будет клева, почетно. И масса всех этих эджайлкоучеров и евангелистов от хуяквпродакшн ширится и глубится, особенно в разных бодишопах (где 20-летние сеньорные архитекторы и Ведущие Разработчики продаются заказчикам за рейт в 50 в час, и это все еще выгодно, даже сейчас). Ну и в банках, особенно инвестиционных - там понты дороже денег.

Тем самым бизнес сам себя загоняет в еще больший ад пизды, чем было раньше, через опускание планки качества в угоду скорости и “гибкости” разработки.

В чем же гибкость? Об этом надо сказать особо, в сравнении с водопадом.

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

  • хорошо почитать
  • хорошо понять
  • хорошо сделать
  • хорошо сдать в эксплуатацию

приводится нечто типа

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

как утверждают апологеты итеративного эджайла, в среднем получится такой же хороший результат, как и в первом случае. Дополнительной плюшкой преподностися так называемый “ранний фидбек” от бизнеса (ну типа “не хотим стелс, хотим пассажирский боинг на гипердрайве”), который теоретически позволит сделать именно то, что надо бизнесу уже сегодня днем, а не было надо сегодня утром. Это в среднем весьма смахивает на среднюю температуру по больнице 36.6, ну там где кто-то умер, а у кого-то 40.1

В результате этой организационной модели появляются технологические новинки вроде TDD, BDD, ATDD, DDD и прочих Driven Development, которые часто превращаются в Костыль-DD, ВолшебныйПиздюль-DD и ФиксиБагСука-DD. А также большое количество разработчиков, которые виртуозно перекладывают ответственность, участвуют в митингах 146% рабочего времени, делают доклады на конференциях по переливанию из пустого в порожнее, и творят прочую чернь.

Есть теория, что по большому же счету, если например взять и сделать один и тот же проект по водопаду, и по итеративному эджайлу - то время, затраченное на проект, будет сопоставимо для обоих способов. Но для этого нужно чтобы в случае водопада требования были четко и ясно озвучены.

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

Далее, любой процесс разработки софта - это просто процесс. Он решает только коммуникационные задачи, будь то принуждение метакласса к хождению на митинги и общение с коллегой на понятном коллеге языке, или же приучение джуниора не ломать билд. Как следствие - если у вас есть классная команда - то ей вообще похуй на процесс, она все сделает хорошо хоть по водопаду, хоть по эджайлу, хоть если им всем приставят пистолеты к голове и взвод чирлидерш с ближайшей фермы будет делать им всякое. А если наоборот - у вас там R&D отдел (Raspizdyayi & Dolboeby) - то вам хоть скрам, хоть канбан, хоть Кена Швабера в тимлидеры - кина не будет.

Ну и напоследок - в самих процессах, как впрочем и в Git/Java/Scala/PHP/Python/Ruby - нет ничего плохого. Они совершенны и идеальны там, где им место. Это не очередная серебрянная пуля или там золотой молоток, которые работают всегда. Итеративный процесс не будет работать в операциях на сердце (в этой версии может скальпель может быть перепутан с пилой для вскрытия черепа, это known issue, мы работаем над хотфиксом) равно как водопад не будет работать в случае белорусского налогового кодекса.

Всем спасибо. Любое совпадение персонажей с реальными людьми совершенно случайно.