Часто ли меняются требования к коду спагетти?

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

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

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

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

Ответ 6

Уход за частыми изменениями требований заключается в следующем:

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

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

Ответ 7

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

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