Да, давайте немного поговорим об agile и бразильском определении текущего состояния agile, сгенерированном под названием «eXtreme Go Horse».
Заблуждения
Прежде всего, нужно избавиться от распространенных заблуждений.
Agile идет быстро
К настоящему времени мы все (должны) знать, что Agile не означает быть быстрее. Речь идет о том, чтобы приносить пользу раньше и на постоянной основе, а также иметь возможность реагировать и менять курс раньше.
Спринт делает все во временном интервале
Итак… вы говорите, что Agile — это не только скорость, но и необходимость… спринтов?
Возможно, это был неудачный термин, используемый разработчиками Scrum, но он, конечно, не помогает людям думать, что «agile — это быть быстрым».
Однако спринты — это просто временной интервал для выполнения определенного объема работы.
Проблема
Руководители настаивают на гибкости и скраме, потому что они думают о том, чтобы быть быстрыми, спринтами!
Но самая большая проблема в том, что создание программного обеспечения — это не спринт, а марафон.
И если вы не человек, вы знаете, что не можете пробежать марафон. Это действительно плохая идея.
Ад! Большинство людей не могут даже пробежать короткую гонку. И я также говорю о программном обеспечении.
Люди в результате
Выгореть. Проще говоря, профессия теряет много хороших людей из-за выгорания.
Не путать с «выгоранием» (диаграммами), тоже из скрама, но каким-то образом это не вызывает путаницы у тех же людей, ожидающих от разработчиков все большего и большего.
В какой-то момент в компаниях было слишком много разработчиков, многие из которых занимались в основном раздутыми функциями и «не приносили достаточной пользы». Потом пошли массовые увольнения (или идут до сих пор), и теперь у вас еще больше перегружены разработчики.
Результат программного обеспечения
Поскольку людей заставляют работать быстро, а затем еще быстрее, качество падает, и «быстро и грязно» становится нормой.
Нет времени на тестирование, нет времени на качество кода или чистый код и передовой опыт, но всегда есть время и сверхурочные для исправления ошибок.
Поставлять программное обеспечение не быстро, но последовательно
Первое, что люди видят в новых фреймворках, — это то, как быстро они могут сделать «приложение todo»… но для большинства из нас это не так.
Быстро и грязно покататься на лошадях, чтобы приготовить большую миску грязной пасты, — это нормально для MVP, побочного проекта или одноразового проекта. Но в большинстве случаев вы будете работать над чем-то месяцами подряд.
Что важно: делать что-то быстро, а затем замедлять каждую новую функцию, пока вы не сбежите с корабля (аксиома XGH 8) или не решите переписать все целиком (см. аксиому XGH 10).
XGH: экстремальная лошадь
Пока я писал этот пост, я обратил внимание на то, что XGH широко известен только бразильским разработчикам, чего недостаточно во всем мире.
Это было сделано неизвестно когда, неизвестно кем, оно немного устарело в написании (я буду рефакторить по мере необходимости), но, как вы увидите… оно вне времени (см. аксиому 14) и имеет отношение к тому, что я говорил. .
Отказ от ответственности: это, по сути, список «не делать». Это забавно как мем, но, как я люблю говорить: если все, что вы делаете, — это вещи из мемов… тогда ваша жизнь — шутка.
Там были некоторые переводы, но я перевел их здесь, пытаясь обновить вещи, чтобы они имели больше смысла сегодня.
Наслаждайтесь, но не следуйте ему. (небольшое примечание: люди обычно просто читают XGH как «вперед»)
Экстремальный манифест «Go Horse»:
1. Если подумать, то это не XGH.
в XGH вы не думаете, вы делаете первое, что приходит в голову. Второго варианта нет, единственный вариант — самый быстрый.
2. Есть 3 способа решения задачи: правильный, неправильный и XGH, который как неправильный, но быстрее.
XGH работает быстрее, чем любая другая известная вам методология разработки программного обеспечения. (см. аксиому 14).
3. Чем больше XGH вы делаете, тем больше вам нужно делать.
На каждую задачу, решаемую с помощью XGH, будет создаваться еще около 7. Но все они будут решаться с помощью XGH. XGH стремится к бесконечности.
4. XGH полностью реакционноспособен.
Ошибки существуют только тогда, когда они всплывают на поверхность.
5. XGH принимает все.
Решил проблему? Скомпилировано? Совершить и все.
6. Всегда выполняйте коммит перед обновлением.
Если случится дерьмо, твоя часть всегда будет правильной… и твои коллеги могут пойти на хуй.
7. У XGH нет крайнего срока.
Сроки, установленные вашим клиентом, являются лишь деталями. Вы ВСЕГДА сможете реализовать ВСЕ в заданное время (даже если это связано с доступом к базе данных с помощью сомнительного сценария).
8. Будьте готовы покинуть корабль, когда он начнет тонуть… или обвинить кого-то или что-то еще.
Для тех, кто использует XGH, однажды корабль утонет. Чем больше времени проходит, тем больше система становится монстром. В тот день, когда дом рухнет, лучше обновить свой LinkedIn или обвинить кого-то.
9. Будьте подлинными, XGH не уважает стандарты.
Пишите код как хотите, если он решает проблему, коммит и все.
10. Рефакторинга нет, только доработка.
Если что-то случится, повторите быстрый XGH, который решит проблему. В тот день, когда переделка включает в себя переписывание всего приложения, прыгайте с корабля, лодка утонет (см. аксиому 8).
11. XGH совершенно анархичен.
Фигурка руководителя проекта полностью одноразовая. Хозяина нет, каждый делает что хочет, когда возникают проблемы и требования (см. аксиому 4).
12. Всегда обманывайте себя обещаниями улучшения.
Включение TODO в код как обещание улучшения помогает разработчику XGH не испытывать угрызений совести или вины за то дерьмо, которое они сделали. Конечно, рефакторинга никогда не будет сделано (см. аксиому 10).
13. XGH абсолютен, он не цепляется за относительные вещи.
Время и стоимость абсолютны, качество абсолютно относительно. Никогда не думайте о качестве, только о кратчайшем сроке реализации решения, по сути… не думайте, а делайте!
14. XGH вне времени.
Scrum, XP… все это просто прихоть. XGH не цепляется за причуды момента, это для слабаков. XGH всегда был и всегда будет использоваться теми, кто пренебрегает качеством.
15. XGH не всегда ориентирован на обходной путь программирования.
Многие программы, ориентированные на обходные пути, требуют очень высокого уровня мышления, но XGH не думает (см. аксиому 1).
Примечание переводчика: в оригинале используется Gambiarra Oriented Programming. Поскольку я понимаю, что некоторые люди знают, что такое gambiarra… это более широкий термин, чем просто «хак» или «обходной путь».
16. Не пытайтесь плыть против течения.
Если ваши коллеги используют XGH для программирования, а вы приверженец и любите делать все правильно, забудьте об этом! Для каждого шаблона проектирования, который вы используете правильно, ваши коллеги будут генерировать в 10 раз больше гнилого кода с использованием XGH.
17. XGH не опасен, пока не возникнет небольшой порядок.
Эта аксиома очень сложна, но предполагает, что проект, использующий XGH, находится в самом разгаре хаоса. Не пытайтесь внести порядок в XGH (см. аксиому 16), это бесполезно и вы можете потратить драгоценное время. Это заставит проект тонуть еще быстрее (см. аксиому 8). Не пытайтесь управлять XGH, он самодостаточен (см. аксиому 11), как и хаос.
18. XGH — ваш союзник, но он мстителен.
Пока вы хотите, XGH всегда будет на вашей стороне. Но будьте осторожны, не бросайте его. Если вы запускаете систему с использованием XGH и отказываетесь от нее, чтобы использовать модную методологию, вам пиздец. XGH не допускает рефакторинга (см. аксиому 10), и ваша новая система, полная наворотов, рухнет. И тогда вас может спасти только XGH.
19. Если работает, не трогай.
Никогда не меняйте, не говоря уже о вопросе, работающий код. Это пустая трата времени, тем более что рефакторинга не существует (см. аксиому 10). Время — это механизм, который движет XGH, а качество — незначительная деталь.
20. Тестирование — для слабаков.
Если вы взяли в руки систему XGH, вы лучше знаете, что делаете. А если вы знаете, что делаете, зачем тестировать? Тестирование — пустая трата времени, если код компилируется — этого достаточно.
21. Привыкайте к ощущению неминуемой неудачи.
Неудача и успех всегда идут рука об руку, и XGH ничем не отличается. Люди часто думают, что шансов на провал проекта с использованием XGH всегда больше, чем на успех. Но успех и неудача — это вопрос точки зрения. Проект пошел насмарку, но вы чему-то научились? Тогда это был успех для вас!
22. Проблема только в вас, когда ваше имя в git виноват.
Никогда не кладите руку на файл, автором которого не являетесь вы. Если член команды умрет или будет долго болеть, лодка утонет! В этом случае используйте аксиому 8.
23. Чем больше, тем лучше.
С XGH вы преуспеваете в дублировании кода — качество кода не имеет значения, и нет времени на абстракции, проверку кода или рефакторинг. Время имеет важное значение, поэтому копируйте и вставляйте быстро!
24. Код — это документация.
В XGH код является единственной необходимой документацией. Комментарии и дополнительная документация — пустая трата времени. Если кто-то не может понять, как работает код, он не должен над ним работать (см. аксиому 20).
25. Безопасность не имеет значения.
В XGH безопасность является второстепенной деталью. Внедрение надежной защиты — пустая трата времени (см. аксиомы 5 и 7). Доверьтесь удаче, отсутствию интереса со стороны хакеров и аксиоме 8.
