Приводит ли частое изменение требований к коду спагетти?

Question

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

Answer 1

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

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

Есть несколько советов, чтобы избежать этого:

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

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

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

• Всегда рефакторинг при кодировании. По моему опыту, небольшие рефакторинги, такие как перемещение избыточного кода из нескольких мест в один метод или класс, наиболее эффективны для поддержания чистоты вашего кода. Всегда следите за запахами кода и удаляйте их как можно быстрее, чтобы облегчить вашу работу. Это требует некоторого опыта, но сейчас самое время начать тренироваться так: -)

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

Answer 2

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

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

Answer 3

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

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

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

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

Для получения хороших советов по написанию слабосвязанного кода проведите исследование внедрение зависимостей .

Answer 4

1. предвидеть изменения, если / когда вы можете, и обобщить требования, если это возможно
2. что более важно, предвидеть время между изменениями
3. разделить работу / функции / итерации так, чтобы они могли быть выполнены за время между изменениями
4. вуаля! теперь вы делаете проворство на лету и постоянные изменения кажутся нормальными 8-P
5. принять аспирин, скулить на босса, вернуться к # 1; -)

Answer 5

Хорошее тестовое покрытие - лучшая защита от частых изменений.

Answer 6

Если вы уходите с одним советом: Рефакторинг, рефакторинг, рефакторинг! Часто!

Все остальное - детали того, как сделать рефакторинг проще.

Answer 7

Часто изменяющиеся требования - это проблема, для решения которой были разработаны Agile-методы - они были созданы, по крайней мере частично, для признания проблемы, что требования do меняются, часто по очень веским причинам.

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

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

Answer 8

анализ ползучести / плохих требований (постоянно меняется):

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

Лучшее решение - установить вехи и узнать, когда показывать эту ссылку тому, кто постоянно меняет требования.

Вы можете быть сверхчеловеком в своем подходе, думая «из коробки» и делая код максимально простым для изменения, но вы все равно ужасно потерпите неудачу, если просто скажете «да» всем функциям, не понимая, как это должно повлиять на проект. Quality-Time-Scope пирамида.

Answer 9

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

http://www.dreamsongs.org/Files/DesignBeyondHumanAbilitiesSimp.pdf было бы полезно.

Answer 10

Питание для частых изменений требований является целью следующего:

• Объектно-ориентированный дизайн (абстрагирование бизнес-области и разделение ее на управляемые, ориентированные на цель концепции)
• Шаблоны проектирования (повторное использование устоявшихся решений для кодирования)
• Разработка на основе MVC (Разделение данных, Бизнес-логика и Представление / представление)
• Разработка на основе архитектурного фреймворка (Вы проектируете архитектурный фреймворк прежде, чем совершать какие-либо проекты и разработки для конкретного проекта)

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