Какова доля продуктивного труда современного разработчика

Коллеги, вопрос был навеян сегодняшней новостной публикацией, хотя «чесался в голове» достаточно давно.

Вопрос вот в чем:

Для того, чтобы какой-то полезный новый или измененный код попал в продуктивную среду, он должен быть написан. Код пишется в одной из сред разработки, потом код должен быть перенесен в среду тестирования. Среда тестирования должна быть создана, наполнена модельными данными и убита после тестирования (lean). Для тестирования кода должны быть разработаны покрывающие функциональные тесты. Могут быть разработаны и иные тесты (нагрузочные, интеграционные и любые иные по потребности). Ничего из этого (за исключением пользовательского тестирования) не должно осуществляться вручную, а следовательно это тоже код.

Вся наша разработка, модельные данные, сценарии, информация о средах хранится в системе управления версиями, т.к. она — код.

Вопрос тролля: сколько времени должен потратить разработчик (они не дешевы в 21 веке) на строки кода которые он должен написать «непродуктивно»  с тем, чтобы донести до пользователя код, который будет ему реально нужен?

Масла к хлебушку добавляет осознание того, что большинство такого кода все же придется писать, а не заимствовать, т.к. импорт обвязки и тестов невозможен, т.к. она была настроена на другую функциональность, среду, язык, глубину тестирования, принципы интеграции. Импорт не подходящей на 100% обвязки (а такой и нет никогда в наличии) требует её доработки, а значит тестирования, увеличивает импортированный технический долг.

Коллеги, работающие с боевой разработкой ПО, скажите, эти потери в реальном проекте не настолько велики, насколько кажутся? Какое-то время закрывать глаза на resilience?

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Practitioner — новый учебный курс 2016

Правильный следующий шаг после ITIL Foundation.
 

Узнайте больше!

Комментарии и мнения

  1. Александр

    По-моему надо разделить сферического коня в вакууме и реальную лошадь. Описанный случай это идеальный элемент идеального проекта, в жизни все не так красиво, меньше контролируется но и обходится дешевле. Надо относится к методологии как к ящику с инструментами, а не единообразной автоматизированной линии. Если вам в гараже нужно просверлить пару отверстий вы не покупаете сверлильный станок, вы возьмете дрель. Тут та же система. Если дешевле после неудачного изменения откатиться на старую версию вручную — то может так и сделать? Если дешевле сделать ряд тестов вручную на ручной копии продуктивной среды, то может так и сделать? Если вы выпускаете продукт на неограниченный круг лиц, например, мобильное приложение которое непонятно когда и кем будет установлено, то понятно, что если что-то пойдет назад, обновить будет сложно и важно выпустить действительно надежную систему. А если это модуль для внутренней системы, от простоя которого ничего не случится, а пользователи быстро дадут обратную связь, то наверно не стоит так сильно вкладываться в автоматизацию тестирования.

    2
    2
  2. Олег Скрынник

    Это провокация, разумеется 🙂

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

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

    1
    1
  3. Андрей другой

    Выскажусь.

    Есть кустарное производство и есть серийное, высоко технологическое производство. Можно собирать автомобиль у себя в гараже или производить его на современном конвейере с японским уровнем автоматизации/роботизации. Так и с производством ПО. Если вы серьезно относитесь к производству, то для перечисленных вами задач на рынке уже полно средств автоматизации(роботизации). Они (средства) сгруппированы в Release Autimation, Test Data Management и Test management/automation.

    Release Automation — автоматизация развертывания вашего вновь написанного ПО. Сценарий следующий — как только вы у себя в среде разработки нажали commit, АВТОМАТИЧЕСКИ запускается процесс сборки, затем процесс автоматического создания тестовой среды или развертывания в уже готовой, развертывание в тестовой среде, запуск автоматических тестов и т.д.

    Test Data Management — средства автоматизации подготовки тестовых данных со всеми особенностями. Там же есть возможность подготовки алгоритмов тестирования в полуавтоматическом режиме. Полу, поскольку в исходных требованиях пока надо вручную отмечать что есть требование, а что просто текст.

    Test management/automation — средства автоматического выполнения тестирования.

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

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

    0
    0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
18
Учебный курс:
Основы DevOps
ДЕК
20
Учебный курс:
Основы ITIL (очно)