Портал №1 по управлению цифровыми
и информационными технологиями

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

Опубликовано 23 ноября 2017
Рубрики: Обо всём на свете
Комментарии

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

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

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

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

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

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

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

Учебные курсы и сертификация на русском языке
специалистов по ИТ-менеджменту

Комментариев: 5

  • Александр

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

  • Это провокация, разумеется 🙂
    Потому что в “обычной” жизни, когда разработчики пишут только продуктивный код, всё равно тесты писать приходится – пусть и кому-то другому. И создавать среды (вручную) приходится, тоже кому-то другому. И эксплуатировать, и решать инциденты, и всё остальное. То есть затраты есть в любом случае, и немалые.
    Когда же речь идёт про инфраструктуру как код – затраты снижаются за счёт автоматизации повторяемых операций и уменьшения хрупкости. При этом код для развёртывания инфраструктуры могут создавать не разработчики, создающие “функциональный код”, а бывшие системные администраторы, чья работа теперь выполняется исключительно через скрипты. То есть – все вдруг стали программистами, а не программисты стали всем.

  • Реал айтиэсэм в стэковерфлоу превратить задумали?

    • Вячеслав Алпатов

      Я бы сказал “жизнь заставила” 🙂

  • Андрей другой

    Выскажусь.
    Есть кустарное производство и есть серийное, высоко технологическое производство. Можно собирать автомобиль у себя в гараже или производить его на современном конвейере с японским уровнем автоматизации/роботизации. Так и с производством ПО. Если вы серьезно относитесь к производству, то для перечисленных вами задач на рынке уже полно средств автоматизации(роботизации). Они (средства) сгруппированы в Release Autimation, Test Data Management и Test management/automation.
    Release Automation – автоматизация развертывания вашего вновь написанного ПО. Сценарий следующий – как только вы у себя в среде разработки нажали commit, АВТОМАТИЧЕСКИ запускается процесс сборки, затем процесс автоматического создания тестовой среды или развертывания в уже готовой, развертывание в тестовой среде, запуск автоматических тестов и т.д.
    Test Data Management – средства автоматизации подготовки тестовых данных со всеми особенностями. Там же есть возможность подготовки алгоритмов тестирования в полуавтоматическом режиме. Полу, поскольку в исходных требованиях пока надо вручную отмечать что есть требование, а что просто текст.
    Test management/automation – средства автоматического выполнения тестирования.
    Сюда же еще можно добавить виртуализацию сервисов для выполнения тестирования, на пример в случаях, когда внешние системы еще не готовы или не доступны в режиме тестирования (SWIFT, на пример, вряд ли разрешит вам тестироваться на живой системе)
    В общем – все уже есть. Просто это серьезные инвестиции, а наши даже очень крупные производители ПО все еще хотят создать высоко технологический конвейер, не закупая дорогостоящего оборудования. Но так им 350 релизов в день не сделать.


Добавить комментарий для Олег СкрынникОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM