Является ли DRY врагом управления программными проектами?

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

Каковы задачи, которыми легко управлять (оценка, график, контроль)? Верно, повторяющиеся задачи, именно те задачи, которых следует избегать в соответствии с DRY.

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

Если вместо этого вы применяете принцип СУХОЙ и пытаетесь найти абстракцию, которая более или менее устраняет дублирующийся код, все иначе. Обычно есть много возможностей, вы должны принимать решения, заниматься исследованиями, быть творческими. Вы можете найти лучшее решение в более короткие сроки, но вы также можете потерпеть неудачу. Большую часть времени вы не можете сказать, сколько осталось работы. Вы худший кошмар менеджера проекта.

Конечно, я преувеличиваю, но, очевидно, возникает дилемма. Мои вопросы: по каким критериям решить, если разработчик переусердствовал с СУХОЙ? Как мы можем найти хороший компромисс? Или есть способ полностью преодолеть эту дилемму, а не просто найти компромисс?

Примечание: этот вопрос основан на той же идее, что и мой предыдущий, « Объем рутинной работы в разработке программного обеспечения и его влияние на оценку» , но я думаю, что это проясняет мою точку зрения, извините за повторение :).

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

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

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

Если бы единственная цель премьер-министра состояла в том, чтобы произвести точные оценки, то это было бы легко. Просто добавьте оценки в 10 раз, и пусть разработчики играют в игры для остальных, если они заканчивают рано. На самом деле это было бы лучше, чем ваше предложение использовать копирование-вставку busywork для экономии времени, так как игра в игры не снизит удобство обслуживания продукта.

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

В любом случае, я оспариваю ваше предположение, что повторяющаяся ручная работа более предсказуема, чем автоматизированная. Весь опыт показывает, что повторяющаяся ручная работа более подвержена ошибкам. А что если в скопированном коде обнаружена ошибка? Внезапно стоимость исправления ошибки умножается на количество повторений, что вызывает неопределенность.

Вы правы - копирование-вставка прекрасно работает, и DRY не имеет смысла, когда ваша задача - создать программу, для которой ни копируемый шаблон, ни копия не будут нуждаться в поддержке или развитии в будущем. Когда эти два программных компонента имеют совершенно разный жизненный цикл, объединение их вместе путем рефакторинга общего кода в общую библиотеку, которая сама находится в стадии интенсивной разработки, может действительно иметь непредсказуемые последствия для усилий. С другой стороны, при копировании разделов кода внутри одной программы или программной системы все эти части обычно имеют одинаковый жизненный цикл. Ниже я проиллюстрирую, что это значит для СУХОГО и управления проектами.

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

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

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

пример

В качестве дополнения позвольте мне объяснить реальный пример того, что означает «исправление ошибок и обслуживание», и как это приводит к непредсказуемости при планировании, особенно внутри одного продукта. Я действительно видел, что такого рода вещи случаются в реальности, вероятно, не со 100 экземплярами, но проблемы могут начаться, даже если у вас есть только один дубликат экземпляра.

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

Разработчик, который получает эту задачу, создает первое (допустим, что это занимает 3 дня), после того, как некоторые изменения или незначительные исправления ошибок из-за QA и проверки клиентов завершены, кажется, что все работает нормально. Затем он начал создавать следующий отчет, вставив копию и изменив все, затем следующий, и для каждого нового отчета ему нужно в среднем ~ 1 день. Очень предсказуемо, на первый взгляд ...

Теперь, после того, как 100 отчетов «готовы», программа переходит в реальное производство, и возникают некоторые проблемы, которые были упущены во время QA. Может быть, есть проблемы с производительностью, может быть, отчеты сбои на регулярной основе, может быть, другие вещи не работают, как задумано Теперь, когда был применен принцип СУХОГО, 90% этих проблем можно было бы решить, изменив кодовую базу в одном месте. Но благодаря подходу копирования и вставки, проблема должна решаться 100 раз, а не один раз. И из-за изменений, уже внесенных из одного отчета в другой, разработчик не может быстро скопировать и вставить исправление для первого отчета в другой 99. Он должен просмотреть все 100 отчетов, прочитать их, перевести изменение в измененный сообщите, протестируйте и, возможно, отладьте каждый из них в отдельности. Для ПМ, это начинает становиться действительно трудным - он, конечно, может потратить время на «обычное» исправление ошибки (скажем, 3 часа) и умножить это на 100, но на самом деле, это, скорее всего, неправильная оценка, некоторые из исправлений могут быть легче сделать, чем другие, другие могут быть сложнее. И даже если эта оценка верна, затраты на отладку в 100 раз больше, чем нужно, обойдутся вашей компании в большие деньги.

То же самое произойдет в следующий раз, когда клиент попросит изменить цвет эмблемы своей компании во всех этих отчетах, настроить размер страницы или установить какое-либо другое новое требование, которое аналогичным образом влияет на все отчеты. Таким образом, если это произойдет, вы можете сделать оценку затрат и выставить счет клиенту в 100 раз дороже, чем он должен был заплатить, если код был СУХИМ. Однако попробуйте сделать это несколько раз, и тогда клиент отменит проект, потому что он, вероятно, не захочет оплачивать ваши непомерные затраты на развитие. И, возможно, в этот момент кто-то задаст вопрос, почему это произошло, и покажет пальцем на человека, который принял решение для этого программирования копирования-вставки.

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

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

Ваше базовое утверждение неверно.

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

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

Программирование "вырезать и вставить" в конечном итоге приводит к отказу от программного обеспечения. Я был подрядчиком системы заказа услуг проводной связи в очень крупной телефонной компании. Система была вырезана и вставлена ​​до тошноты, потому что все тестирование проводилось вручную, и они не хотели менять какой-либо рабочий код. Самое маленькое улучшение может привести к новой копии сотен строк кода. Первоначально приложение было написано для обработки учетных записей до двенадцати физических строк. Конечно, это ограничение было сделано в сотнях мест в коде. Примерно через четыре года бизнес спросил команду, что потребуется для обработки больших счетов. Они оценили около 18 миллионов долларов. В этот момент проект был передан оффшорной команде для минимального технического обслуживания. Существующая команда была уволена.

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

Часто забытая максима, которая применяется здесь, является правилом 3 . Это говорит о том, что можно скопировать код один раз, но кроме этого его следует заменить общим кодом.

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

Хотя неплохо иметь СУХОЙ код, могут быть случаи, когда бизнес-логика диктует исключение, и поэтому вам приходится создавать два или более фрагмента кода из исходного кода, который был ранее универсальным.

Так что делать? Код для статус-кво (в конце концов, YAGNI ). В то время как код должен быть написан для простоты модификации, написание целого ряда наворотов для чего-то, что может не понадобиться, - это просто сжигание денег.

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

Я думаю, что другая проблема заключается в том, что вы принимаете DRY, концепцию, касающуюся повторения информации, и пытаетесь применить ее для управления задачами. DRY просто говорит, что у вас должно быть только одно официальное представление информации. Менеджеры проектов должны принять это, поскольку это означает, что каждый будет знать, куда обращаться за информацией, сообщать об изменениях будет легко, а изменениями можно будет контролировать и управлять ими. СУХОЙ, используя многократно используемые части, помогает снизить долгосрочные затраты, помогает поддерживать долгосрочные графики и улучшать качество - три части к треугольнику управления проектами . Требуются определенные затраты времени и денег, чтобы эффективно сделать вещи СУХОЙ, но работа менеджера проекта заключается в том, чтобы найти компромисс между временем, стоимостью, графиком и качеством.

Написание нового кода - это лишь небольшая часть задачи.

Ваше предложение облегчит оценку части первоначального написания нового кода. Однако для того, чтобы действительно принести что-то новое (независимо от того, является ли это совершенно новой системой, добавлением функции или изменением функциональности), этого недостаточно, и это всего лишь незначительная часть работы - оценки, приведенные в литературе, говорят, что на практике это часть это что-то вроде 20% -40% от общей работы.

Таким образом, большую часть работы (которая включает адаптацию вашей первоначальной разработки к тому, что было действительно необходимо, интеграцию, тестирование, переписывание, повторное тестирование) оценить не легче; наоборот, намеренно избегая СУХОГО, мы сделали эту часть намного больше, сложнее и с более переменными оценками - такой ошибки или необходимости изменения, которая требует изменения всех клонированных частей, может не произойти, но если это произойдет, тогда ваши оценки будут совершенно не правы.

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

СУХОЙ полезна, но она также завышена. Некоторые люди могут зайти слишком далеко. Многие разработчики не могут понять, что всякий раз, когда вы внедряете DRY для использования одного и того же метода для двух (слегка) разных целей, вы вводите своего рода очень тесную связь между различными видами использования. Теперь каждый раз, когда вы меняете код для первого варианта использования, вы также должны проверять, регрессирует ли он для второго варианта использования. Если это широко независимые варианты использования, то очень сомнительно, должны ли они быть тесно связаны - вероятно, не должно быть.

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

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

РЕДАКТИРОВАТЬ: за комментарий, я согласен, однако, что, поскольку это облегчает оценку времени разработки, избегая DRY может иногда уменьшить количество неопределенности. Но я полагаю, что это незначительная проблема в связи с более насущными вопросами: (1) как долго будут соблюдаться требования бизнеса, (2) какая техническая задолженность берется на вооружение в процессе, и (3) риски для общей стоимости право собственности на архитектурный выбор - делать ли СУХОЙ или нет во многих случаях - это выбор дизайна, который должен основываться больше на риске / вознаграждении за эти факторы, чем на том, облегчает ли это предоставление менеджерам проектов более точной информации ,

Я думаю, что вы неправильно понимаете СУХОЙ.

Давайте использовать пример:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

public Class B
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }

    public int Add(int x, int y)
    {
        return x + y;
    }
}

против

public Class C : A
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}

Заменив класс B на C, мы следовали принципу DRY и сократили дублирование кода. Но мы не увеличили неизвестность или риск для проекта (если вы никогда не делали наследование раньше).

Я думаю, что вы имеете в виду, когда говорите о «СУХОЙ», что-то вроде дизайнерской задачи. То есть:

public Class A
{
    public int Multiply(int x, int y)
    {
        return x * y;
    }
}

!!! Новое требование! Некоторые клиенты должны иметь возможность умножать удвоения !!

// Use class B for new clients!!
public Class B
{
    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

против

public Class A // Version 2
{
    public int Multiply(int x, int y)
    {
        return Multiply(x as double, y as double);
    }

    public int Multiply(double x, double y)
    {
        return x * y;
    }
}

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

Итак, мы должны взять B или A версию 2 в этом случае?

• B будет более конкретным для фактического запрашиваемого изменения с меньшим количеством побочных эффектов и будет легче оценить и быстрее сделать.

• Версия 2 приведет к уменьшению общего объема кода и станет более элегантным решением.

Я снова скажу, что все сводится к качеству спецификации и требованиям.

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

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

Абзац за абзацем

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

Верный.

Каковы задачи, которыми легко управлять (оценка, график, контроль)? Верно, повторяющиеся задачи, именно те задачи, которых следует избегать в соответствии с DRY.

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

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

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

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

Если вместо этого вы применяете принцип СУХОЙ и пытаетесь найти абстракцию, которая более или менее устраняет дублирующийся код, все иначе. Обычно есть много возможностей, вы должны принимать решения, заниматься исследованиями, быть творческими. Вы можете найти лучшее решение в более короткие сроки, но вы также можете потерпеть неудачу. Большую часть времени вы не можете сказать, сколько осталось работы. Вы худший кошмар менеджера проекта.

Удаление дубликатов приводит к единой точке отказа. Если что-то не получается, вы можете быть уверены, где это произойдет. SOLID и Design Patterns помогут решить именно эту проблему. Слишком короткие сроки имеют тенденцию провоцировать процессуальный стиль «кодирования». Больше времени, потраченного на один проект, чтобы создать что-то многократно используемое, означает, что в следующем проекте должно быть минимальное количество времени, затрачиваемое на повторное использование функции, но она должна быть настраиваемой в первую очередь.

Конечно, я преувеличиваю, но, очевидно, возникает дилемма. Мои вопросы: по каким критериям решить, если разработчик переусердствовал с СУХОЙ? Как мы можем найти хороший компромисс? Или есть способ полностью преодолеть эту дилемму, а не просто найти компромисс?

Многие люди указали, что здесь нет дилеммы. И да и нет.

Если у вас есть что-то очень экспериментальное, чего еще никогда не делали - дилеммы нет. В противном случае, если у вас есть что-то, что нужно сделать снова, например, новая система бронирования, у вас уже есть абстракции, зависит только то, что вам нужно.

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

речь идет вовсе не о проектировании для повторного использования в будущем или о принципе YAGNI. Речь идет о повторении кода в текущем рабочем пакете.

Это абсолютно о дизайне. Возможно не повторное использование как таковое, но, тем не менее, дизайн.

Каковы критерии, чтобы решить, переусердствует ли разработчик с СУХОЙ?

Опыт и ваше существующее окружение / ситуация. Для данной проблемы вы получите сильное понимание принципа Прадо, когда будете пытаться достичь большей степени СУХИ. Тогда вдруг соображения управления вступают в игру. Время, цели, заказчик, управление долгосрочным кодом (кто-то сказал технический долг ) и т. Д. Сообщат ваш план атаки.

Как мы можем найти хороший компромисс?

Э-э ... дизайн? Рефакторинг - это дизайн, ну, это должно быть. Сфера DRYing может легко расширяться, как сверхновая, из цикла в метод, в класс (ы). Был там, сделал это. Но вы не можете знать, пока не изучите проблему - это дизайн.

Как это не может быть проблемой дизайна? Вы должны рассмотреть проблему более широко, чем непосредственный дублированный код под рукой. Это проектная деятельность, будь то существующий код или чистый лист; будь то «метод извлечения» или создание новых классов и модулей.

эпилог

... упомянутый вопрос и его ответы не охватывают аспект управления проектом.

Типичное управление, игнорируя время проектирования. В идеале мы бы разработали избыточную избыточность повторяемости до кодирования. Вместо этого руководство думает, что разработка (и исправление ошибок) - это единое олимпийское событие - кодирование, - когда это фактически десятиборье. И они измеряют до 1/1000 секунды, потому что они думают, что это все аналог.

Если вместо этого вы применяете принцип СУХОЙ и пытаетесь найти абстракцию, которая более или менее устраняет дублирующийся код, все иначе.

У меня был такой опыт: «Я потратил два дня на написание этой строки (формы с графическим интерфейсом) и два часа на написание остальной части формы». Я имею в виду, что я потратил время на то, чтобы определить повторно используемые классы - СУХОЙ - естественный побочный эффект - строку формы GUI и некоторые другие. После отладки они использовались индивидуально и в составе всей формы, которая теперь очень быстро кодируется, и тестирование было исключительно быстрым, несмотря на сложность построения. И это также прошло через формальное тестирование с удивительно низким уровнем ошибок.

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

Я тоже не знал, но я верил, что первоначальные усилия по проектированию окупятся. Мы все так говорим, но, в частности, руководство не доверяет этому. Менеджмент подумал бы, что я облажался. «Два дня, а у вас даже 2% этого кода не закодировано!»

В одном случае мы прилепились к нашему оружию, когда руководство заявило: «Вы тратите слишком много времени на разработку, начинайте». И коллеги говорят: «Это слишком много классов». Ну, гораздо менее сложный подпроект должен был занять около 1 месяца (я думал, что это нормально), но занял 5 месяцев. 3 месяца из этого были в тестировании / исправлении, потому что это был такой POS. «Но у нас не было времени на дизайн!». Они на самом деле так сказали.

Мои вопросы: по каким критериям решить, если разработчик переусердствовал с СУХОЙ? Как мы можем найти хороший компромисс? Или есть способ полностью преодолеть эту дилемму, а не просто найти компромисс?

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