Есть ли способ избежать спагетти код на протяжении многих лет?

Ответ 1

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

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

Вызовите их и попросите их изменить его

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

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

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

Ответ 2

Я считаю, что ключ к предотвращению гниения кода лежит в продуманной методологии проектирования и реализации (я считаю это настолько сильно, что я назвал свой бизнес - Think Bottom Up - после него!). Инструменты выбора здесь:

• Программирование по контракту
• Многоуровневая конструкция
• Фокус на развязке
• Всегда строите с повторным использованием, ищите общие решения.
• Сохраняйте рамки легкими, простыми и ориентированными.

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

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

Когда вы что-то исправите, исправьте его правильно. Я использую термин "fux" для описания исправления, которое было сделано не так: это просто "фьюкс" для вашей базы кода.

Приветствия,

Dan

Ответ 3

От 20 до 50 разработчиков, вероятно, проблема. Это довольно высоко и потребует много управления и ресурсов, чтобы держать все под контролем.

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

Ответ 4

Создайте "межсетевые экраны" между разными областями кода. Вы делаете это, определяя разные области или уровни кода и определяя один API (в Java это обычно делается с интерфейсом), на который реагирует каждый уровень. Должны существовать простые цели или классы, используемые API, но которые ничего не знают о внутренних компонентах этих слоев. Например, gui не должен знать или ухаживать за тем, как вы храните данные, и ваша база данных не должна знать или заботиться о том, как данные предоставляются конечному пользователю.

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

Ответ 5

Я думаю, что главное - когда вы говорите

вы просто хотите переписать все с нуля

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

Ответ 6

Кодовые обзоры, стандарты кодирования и политики фирмы.

В нашем магазине применимо следующее: поскольку я не знаю, какой у вас магазин, ваш пробег может отличаться. При переходе на Team Foundation Server большая часть нашего внимания заключалась в поддержании качества кода - или, по крайней мере, помогая поддерживать качество любым возможным способом. Некоторые примеры того, что мы добавляем:

• Обзор рабочего процесса кода. Обеспечивает проверку кода как часть процесса. Содержит политику, которая предотвратит выполнение проверок, если код не был просмотрен.
• TeamReview - делает обзоры кода менее болезненными, предоставляя полный "внутри среды IDE".
• Политики регистрации (в общем) - Многие полезные свойства доступны для управления потоком кода. Такие вещи, как убедиться, что общедоступные и защищенные методы документированы до регистрации, чтобы убедиться, что никакая работа не может быть проверена без соответствующего рабочего элемента.

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

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

Refactoring

Удерживайте конструкцию как можно более чистой. Это непросто, но это стоит усилий.

Ответ 11

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

Единственный способ избежать этого - изменить отношение:

"Отношение, которое гибкие разработчики имеют к дизайну программного обеспечения, - это то же отношение, что и хирурги к стерильной процедуре. Стерильная процедура - это то, что делает возможной хирургическую операцию. Без этого риск заражения будет слишком высоким, чтобы терпеть. Гибкие разработчики так же относятся к своим проектам. Риск позволить даже самому маленькому кусочку гниения слишком высок, чтобы терпеть".   Martin C. Роберт "Гибкие принципы, шаблоны и практики в С#"

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

Удачи!

Ответ 12

Нет

:)

Ответ 13

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

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

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

Павел.

Ответ 14

Вы должны внимательно следить за практикой разработки программного обеспечения. Там должны быть обзоры кода, и unit test, которые постоянно проверяют, что обновления влияют на другие вещи в системе. 20 - 50 разработчиков много, но это можно сделать. Реализация хороших процессов - единственное, что спасет вас в этой среде. Принудительные стандарты кодирования также являются ключевыми.

Ответ 15

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

Ответ 16

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

Ответ 17

Shore and Warden The Art of Agile Development - отличная книга с разделом "Применение XP к существующему проекту" (в Глава 4). Проекты еще хуже с течением времени, если не бороться трудно: преодоление такой технической задолженности трудно и сделать его более трудным для того чтобы грузить приемлемые выбросы. Единственное решение - уменьшить скорость, с которой вы доставляете новые функции, и тратить время на сохранение тестового покрытия и рефакторинг.

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

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

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

Ответ 18

Дополнительные обзоры кода и, возможно, право собственности на код.

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

И просмотры кода - это время, когда вы показываете свой код.

Ответ 19

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