Модель сверхэффективного программиста (3)

предыдущая часть

Вторая обязательная прокаченная микро-стратегия — это мастерство обеспечения быстрого фидбека. На этом построена вся культура agile-движения, а также немало методологий разработки наподобие Test Driven Development или Continuous Integration. Однако все эти мэйнстримовские понятия — по сути макро-стратегии. Мы же говорим именно о микрах — почему например один программист, отлично владеющий TDD, безбожно проигрывает другому программисту с точно такими же навыками TDD?

В нашем случае быстрый фидбек подразумевает организацию собственной работы в масштабе (с точностью до …) единичных минут, когда можно писать код и исследовать работу практически без потерь времени на всяческую вспомогательную деятельность. Например, предыдущая микра «обучение», как говорилось, подразумевает некую «игру» с новым кодом в процессе знакомства с ним. Эффективнее всего это делать в консоли, из шелла, когда с текстом программы мы взаимодействуем также исключительно в текстовом режиме. Точно так же лучше всего редактировать формируемый HTML-код непосредственно в самом браузере. Для опробовывания новых фич под рукой всегда желательно иметь тестовую платформу (инфраструктуру), где можно быстро протестировать новые изучаемые подходы или собрать работающий прототип. А в упомянутом TDD скорее всего ключевой микрой станет умение создавать и тестировать конкретные кусочки кода в максимальной изоляции от всего остального.

Вот какие в быстром фидбеке можно отметить анти-паттерны (которые невероятно замедляют процесс программирования):
— цикл «писать и отлаживать». Пишем полчаса некоторый класс, затем впихиваем его в действующую систему, запускаем, и… ждём когда всё развалится, и начинаем дебажить;
— случайная отладка. В поиске бага пытаемся случайно искать причину. Может быть, проблема вот в этой строке? Так, закомментим, проверим… Нет. А может, в этой? Или в этой?..
— метод проб и ошибок. Решаем локальную проблему в коде, возвращаемся к развитию системы, снова делаем «попытку» её улучшить на локальном уровне, и т. д. в цикле;
— использование отладчика в ежедневном кодировании;
— логи в отладке. Одна из наиболее зловредных концепций отладки, хотя и самая распространённая, особенно в крупных системах (чем крупнее продукт, тем логгирование популярнее, что свидетельствует о стратегической неправильности схемы разработки в целом). Вставляем вывод в файл/на консоль состояния различных элементов программы в самые разные части кода, и затем изучаем их, пытаясь понять причины возникших проблем.

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

Этому посвящена тема третьей микры.

Поделиться статьей ...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Share on VKPrint this page

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

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