Почему отделочные работы от разработки?

Question

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

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

Есть ли что-нибудь еще, кроме отказа от "старого кода" для простых смертных?

Уроки, извлеченные из содержания своего «мусора», имеют гораздо большую ценность? Разве исправление дефектов не намного эффективнее, если их совершают те, кто их начал?

Я пропускаю какие-либо реальные причины, по которым может быть выгодно иметь отдельную группу обслуживания?

Answer 1

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

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

Пример игры в реальной жизни:

Вам назначен 1500-часовой проект разработки, и вы также несете ответственность за обслуживание и поддержку ваших последних 3 приложений. Во время этого нового проекта вас в среднем прерывали 7 раз в неделю, чтобы поддержать эти 3 приложения. Каждый раз, когда вы начинаете работать над тремя другими приложениями, вы тратите 20 минут на то, чтобы сосредоточиться на проблеме. После устранения проблемы вы потратите 20 минут на то, чтобы вновь обдумать код, который вы в последний раз касались в своем новом приложении. Это общая стоимость 40 минут за прерывание или 280 минут в неделю. Это означает, что вы потеряли 2,67 часа продуктивности за неделю, просто переключившись на поддержку этих приложений.

Answer 2

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

Взять, к примеру, микростанцию ​​Bentley. Это дизайнерское приложение для 3d (архитектура, дизайн завода, рельсы, дороги, мосты и т. Д.). Теперь предположим, что у нас есть v8, v9, v10 на рынке. Они имеют различные функции, и формат файла значительно изменился по сравнению с версиями. Но проекты настолько велики (или клиенты так важны), что вам приходится поддерживать клиентов v8 и v9, а также разрабатывать v10. Поэтому необходимо, чтобы в компании была команда поддержки (или время), выделенная для предыдущих версий. Кроме того, обычно эти группы называются группами настройки, если ваш продукт поддерживает настройку и вышеупомянутый сценарий.

Answer 3

Проблема более практичная, я думаю:

• старый код был написан людьми, которых больше нет в компании или команде;
• старый код был написан сторонними разработчиками;

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

Если вы можете избежать этого случая, это хорошо для вас, но будьте уверены, что он всегда временный.

Answer 4

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

Короче говоря, большую часть времени это делается по политическим / непрактичным причинам.

Answer 5

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

Я догадываюсь:

• Делает новую разработку более предсказуемой, более простой в планировании: поскольку разработчики не отзываются к ней, чтобы исправить неизвестное заранее количество проблем с поддержкой

• Возможность обучать новых разработчиков (например, меня)

Кроме того, код, который я поддерживал, не был «мусорным» - это было программное обеспечение телекоммуникационной компании, ранняя сеть с коммутацией пакетов, которая была развернута для таких клиентов, как Bell и т. Д. Она была хорошо разработана, хорошо написана, тестируема ( комплекты автоматизированных тестовых случаев), поддерживаемые, множество файлов журналов, некоторая проектная документация ...

... кажется, что подзаголовок к вашему OP: «Чувак, этот код воняет! Хотел бы я получить оригинального разработчика, и потрите его его нос: , что научит его! "

Так что, когда код уже хорошо написан, этот аргумент (обучение оригинальных разработчиков) не применим.

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

[Я анализирую и диагностирую проблему и пишу исправление; и специалист по тестированию добавит новый соответствующий тестовый набор в автоматизированный набор тестов.]

Answer 6

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

Answer 7

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

Кроме того, «обслуживание» может относиться к множеству действий, таких как развертывание, настройка, резервное копирование и т. Д., Которые должны определенно выполняться другой группой.