Best-Practices

Когда я впервые столкнулся с методологией Agile около десяти лет назад, это было похоже на открытие огня. Наконец-то у нас появилась система, которая обещала гибкость, быстрые итерации и свободу от бюрократических оков Waterfall. Мы собирались быть другими. Мы собирались быть быстрыми. Мы собирались носить худи и проводить стоячие встречи о стендапах. Затем произошло нечто забавное. Мы настолько увлеклись Agile, что забыли, зачем начали её использовать. Мы стали адептами Agile, и, как и в большинстве случаев фундаментализма, мы упустили из виду первоначальную цель....

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

Помните, что «эффективный код» — это как «хороший вкус»: у каждого своё мнение, но код большинства людей менее эффективен, чем они думают. Мы все бывали в такой ситуации: мы что-то пишем, это работает, не выдаёт ошибок сразу, и мы думаем: «Миссия выполнена». Но между кодом, который просто работает, и кодом, который работает хорошо, существует огромная разница. Именно в этой пропасти умирают мечты о производительности. Правда в том, что неэффективность не всегда очевидна....

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

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