Страсть к программированию. Глава 18. Автоматизируй свою работу

О переводе

Это перевод 18 главы книги The Passionate Programmer: Creating a Remarkable Career in Software Development. Её автор — Chad Fowler — талантливый Ruby-разработчик, известный докладчик на конференциях, посвящённых Ruby и IT в целом. Бывший саксофонист, а сейчас — CTO 6Wunderkinder.

Краудсорсинговый перевод книги ведётся на github, присоединяйтесь.

Глава 18. Автоматизируй свою работу

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

Стоит ли упоминать, что мне редко удавалось хотя бы договорить до конца? Проблема моего положения не в том, что я ошибаюсь (еще бы!), но в том, что не существует простого способа доказать, что я прав. А с точки зрения бюджета, единственные данные, которыми мы располагаем, ведут к выводу, что более низкий почасовой рейт выгоден для компании.

Представьте эдакий сферический проект в вакууме. Сколько понадобится разработчиков, чтобы написать подобное програмное обеспечение за три месяца? Пять, вы говорите? Шесть? Хорошо, а что насчет двух месяцев? Как бы вы сократили срок?

Стандартным ответом менеджера будет добавить больше програмистов. (Как будто девять женщин смогут родить ребенка за месяц!) Это неправильно, но это то, во что они верят. А уж если, вдруг, у вас получится закончить отдельный проект быстрее, после увеличения количества разработчиков, менеджмент будет на 100% уверен, что, чем больше людей, тем выше продуктивность.

Но ведь любую задачу всегда можно решить несколькими способами. Если цель — усовершенствовать разработку в целом, вы можете:

• Найти людей, способных выполнить работу быстрее,
• добавить еще людей или
• автоматизировать работу

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

Это приводит нас к простой (и немного наивной) формуле, предполагающей, что в фиксированый промежуток времени:

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

Итак, вариант с «более быстрыми» программистами слишком труднодоказуем, и мы не хотим потворствовать использованию дешевой рабочей силы. Нам остается только автоматизировать.

Я помню панику вокруг сокращений в США в восьмидесятых. Тогда мы винили не только и не столько другие страны, как технологии и, особенно, компьютеры. Огромные роботы-манипуляторы устанавливались на заводах. Они настолько опережали людей по скорости и точности работы, что даже не было смысла сравнивать. Все были подавлены, кроме, естественно, производителей этих роботов.

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

Если мы подставим некоторые (достаточно произвольные) числа в формулу, приведенную выше, мы получим уравнения, показанные на рис. 1.

Автоматизация — основа нашей индустрии. Но, почему-то, до сих пор мы не пытаемся автоматизировать наши задачи как разработчиков ПО. Как производить доказуемо лучшее ПО быстрее и дешевле, чем ваши оффшорные конкуренты? Стройте роботов. Автоматизируйте себе работу.

Рис. 1

Действуйте!

1. Возьмите любую повторяющуюся задачу и напишите для нее генератор кода. Начните с простого. Не думайте о повторном использовании. Просто убедитесь, что генератор экономит ваше время. Подумайте, как можно повысить уровень абстракции того, что вы генерируете.
2. Изучите Model-driven architecture (MDA). Попробуйте какие-либо доступные инструменты. Поищите, как в вашей работе можно применить идеи MDA, если не весь подход целиком. Обдумайте возможность применения концепций MDA с использованием только привычных вам инструментов.

Автор: lavice

Источник