Пользователь
0,0
рейтинг
26 декабря 2013 в 14:04

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

image

О переводе

Это перевод 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 с использованием только привычных вам инструментов.



Оцените, пожалуйста, качество перевода

Проголосовало 116 человек. Воздержалось 80 человек.

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

Перевод: Chad Fowler
Volodymyr Stelmakh @lavice
карма
16,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (9)

  • +3
    «Как будто девять женщин смогут родить ребенка за месяц!» — интересное сравнение. Надо запомнить и применять.
    • +1
      Да, самому нравится. Этого, правда, не было в оригинальной статье, но очень подходило по смыслу, не удержался :)
      P.S. Автор не я, но где увидел уже не помню.
      • +8
        Фредерик Брукс: «Мифический человеко-месяц, или Как создаются программные системы»
        • 0
          Точно, большое спасибо.
        • 0
          Даже если вы очень талантливы и прилагаете большие усилия, для некоторых результатов просто требуется время: вы не получите ребенка через месяц, даже если заставите забеременеть девять женщин. © Уоррен Баффет
    • 0
      Это довольно распространенное сравнение. Его часто используют на всяких agile курсах.
  • 0
    Возьмите любую повторяющуюся задачу и напишите для нее генератор кода

    А 2 умножить на 2 будет 4. Ваш КО.
    Наверное, толпы индусов про это не знают до сих пор (или сознательно уклоняются), но тут-то, надеюсь, не полные индусы собрались…
  • +3
    Спасибо, lavice, за качественный перевод. Приятно читать.

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

    Но тут: резкий скачек от “у нас ничего не автоматизировалось” до генерации кода на основе модели. Такой подход, конечно же существует, но я не скажу, что он настолько сильно распространен из-за сложности создания самой модели.
    Если брать пример из главы, то мне кажется, легче будет 20 сайтов с корзиной, путь даже на собственном движке, наклепать, чем одну модель все это время разрабатывать.

    Опять же, не ясна фраза с генерацией кода. Т.е., конечно же, во многих ситуациях, генерация части кода оправдана, как то создание UI интерфейсов или классы, декларирующие поля базы данных. Но, насколько я понял, автор хочет сгенерировать весь код приложения.

    В формуле с рейтами программиста, явно рассматриваются какие-то предельные ситуации: “очень хороший и дорогой”, “дешевый и плохой”.
    Будто-бы, посередине ничего нет. Я думаю, за рейт $45, можно вполне найти очень хорошего разработчика на просторах СНГ, так и в Индии (ведь, не все же там индокодят, просто тех, кто индокодит — большее число)
    • 0
      Спасибо.

      Мне вообще эта глава показалась какой-то незаконченной, что ли.
      Хотя, тут еще дело в общем стиле книги, у него нигде нет конкретики, только формулировка общих подходов. В данном случае — призыв автоматизировать рутинную работу с целью экономии ресурсов.

      Что касается разброса рейтов, мне кажется, это просто литературный прием, игра на контрасте. К тому же, в статье упоминается, что и формула, и значения взяты практически с потолка.

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