Существует ли способ избежать запутанного кода за эти годы? [закрытый]
Примечание: Неинициализированное смещение строки: *
Как видно из названия, возникает такой тип ошибки, когда вы, скорее всего, пытаетесь перебрать или найти значение из массива с не- существующий ключ.
Считаем, что вы пытаетесь показать каждую букву из $string
$string = 'ABCD';
for ($i=0, $len = strlen($string); $i <= $len; $i++){
echo "$string[$i] \n";
}
. Вышеприведенный пример сгенерирует ( онлайн-демонстрацию ):
A
B
C
D
Notice: Uninitialized string offset: 4 in XXX on line X
И, как только скрипт заканчивается эхом D, вы получите ошибку, потому что внутри цикла for() вы сказали PHP, чтобы показать вам от первого до пятого символа строки из 'ABCD' Что, существует, но поскольку цикл начинает отсчитываться от 0 и эха D к моменту достижения значения 4, он выдает ошибку смещения.
Аналогичные ошибки:
19 ответов
Безжалостное усердие, объединенное с постоянным поблочным тестированием, является единственным способом предотвратить запутанный код. Даже тогда это - только временное решение. Как только Вы прекращаете обращать внимание, прибывает паста.
Очень часто я нахожу, что запутанный код представлен, потому что кто-то просто ленив в тот день. Они знают, что существует лучший способ сделать это и просто не имеет времени. Когда Вы видите, что происходят существует только одна вещь сделать.
Вызывают их на нем и просят, чтобы они изменили его
, я нахожу, что указания на лучший путь во время обзора кода обычно достаточно для получения людей, идущих. Если они будут регистрировать его, и я чувствую сильно, я осуществлю рефакторинг его сам.
я иногда отрываюсь как немного эксцентриковый? Я уверен, что делаю. Откровенно, хотя я не возражаю. Я не придурок об этом и приближаюсь к этому самым лучшим социальным способом. Однако разрешение плохому коду быть зарегистрированным в значительной степени гарантирует, что я оказываюсь перед необходимостью отлаживать его в какой-то момент в будущем. Я взял бы немного зенитного огня теперь и вложил бы правильный код.
я также чувствую, что культура поблочного тестирования также помогает предотвратить запутанный код. Намного более трудно к запутанному коду модульного теста, что хорошо учел код. Со временем это вынуждает людей сохранить свой код несколько учтенным.
Начните создавать модульные тесты, это поможет Вам разъединить свой код и избежать, развивают ошибки исправления ошибок. Это у Вас есть хорошее покрытие, это облегчит для Вас удалять неиспользованный код также.
Больше обзоров кода и возможно кодирует владение.
, Если Вы просто взламываете некоторый случайный код тогда, Вы не заботитесь так же что касается кода, которым Вы "владеете". Если это - Ваша обязанность поддержать один модуль проекта, Вы хотите блистать.
И обзоры кода время, когда Вы показываете свой код.
Берег и Начальник Искусство Гибкой разработки является замечательной книгой с разделом по "Применению XP к Существующему Проекту" (в главе 4). Проекты ухудшаются со временем, если Вы не упорно боретесь: преодоление такого технического долга трудно и сделает все больше трудным поставить приемлемые выпуски. Единственное решение состоит в том, чтобы уменьшить уровень, на котором Вы обеспечиваете новые возможности и проводите время, сэкономленное, улучшая тестовое покрытие и рефакторинг.
Обычно, проекты не имеют большого тестового покрытия и не имеют опции выполнения 10-минутного автоматизированного сценария, который создаст и осуществит Ваш код довольно полностью. Вместо этого большая часть кода структурирована так, чтобы было трудно протестировать. Наилучший вариант тогда состоит в том, чтобы добавить простое тестовое покрытие, где Вы можете, начиная осуществлять рефакторинг в целях создания кода, абстрагированного таким образом, что легче протестировать.
, Хотя команда должна будет провести время, улучшая код, чтобы заставить его убрать и тестируемый, Вы, вероятно, не будете в состоянии прекратить поставлять в течение времени, которое потребовалось бы, "заканчивают" очистку. Так, необходимо сделать это шаг за шагом, также добавляя новые опции. Это хорошо, выберите худшие области сначала и не ожидайте очевидное преимущество сразу же. Сохраните в нем, потому что в конечном счете Вы доберетесь там. Не слушайте речь, которая говорит, что все крупные проекты плохи.
Короче говоря, проводите немного времени каждую неделю, убираясь и удостоверяйтесь, что код лучше на следующей неделе, чем это на этой неделе.
Непрерывный рефакторинг. Вы имеете для рефакторинга, когда Вы идете, особенно на уровне дизайна. Когда Вы видите поврежденный код или дизайн, быть готовыми зафиксировать его. Это часто - случай фиксации чего-то, что не повреждается по сути. За исключением того, что это..., это просто не проявляет, это - уязвимость... все же.
отслеживание дефектов и производительности различных частей системы позволит Вам определять проблемы. Поскольку системы изменяются, плохо разработанные или записанные функции или модули будут иметь более высокий уровень дефектов. Когда "проблемный" модуль определяется, решение может быть принято для перезаписи модуля (НЕ приложение).
Необходимо применить методы разработки программного обеспечения тесно. Должны быть обзоры кода и модульный тест, что constastantly удостоверяются, что обновления влияют на другие вещи в системе. 20 - 50 devs много, но это может быть сделано. Реализация хороших процессов является единственной вещью, которая сохранит Вас в этой среде. Вынужденные стандарты кодирования являются также ключевыми.
Самая большая проблема в промышленности программного обеспечения состоит в том, что качество кода программы просматривается как субъективная проблема. Без некоторой четко определенной метрики, просто будучи аккуратным и опрятным, и в соответствии с соглашениями не достаточно, чтобы гарантировать, что качество приемлемо.
существуют попытки измениться это , но они вряд ли получат достаточный интерес или принятие, прежде всего, потому что общепринятая культура программистов находится в попытке очень трудно, чтобы избегать чего-либо, что напоминает разработку. "Чистая художественная" философия программирования означает, что Ваши 20-50 разработчиков все собираются крутиться в коде их собственным уникальным способом, так, чтобы, неважно, как хороший отдельные кодеры, суммарный итог усилия группы всегда будет "большим комком грязи".
Для предотвращения этого, или получают все кодеры на той же 'странице', делают нормализованную часть кода соглашения или преследование после того, как задания были группами разработчиков, меньше (1-3 человека), и Вы - большая кахуна. Когда-нибудь многочисленные команды могут найти способ создать лучший материал, но до тех пор даже лучшие из них чрезвычайно удачны, если они могут просто быть рядом с 6 из 10. Мы создаем низкокачественное программное обеспечение, потому что это - то, что мы настроили нашу промышленность, чтобы сделать...
Paul.
Не позволяйте коду фиксироваться, пока по крайней мере две пары глаз не видели его.
Я не думаю, что это нормально. Действительно трудно бороться с этой вещью, когда это было там в течение нескольких лет.
единственный способ избежать его состоит в том, чтобы изменить отношение:
отношение “The, которое гибкие разработчики имеют к дизайну программного обеспечения, является тем же отношением, которое хирурги имеют к стерильной процедуре. Стерильная процедура - то, что делает хирургию возможной . Без него риск заражения был бы слишком высок для признания. Гибкие разработчики чувствуют то же самое по отношению к своим проектам. Риск разрешения даже самому крошечному биту гнили начаться слишком высок для признания. Принципы ” MartinВ C.В Robert “Agile, Шаблоны и Методы в C#”
я настоятельно рекомендую изучить эту книгу для советов. Это называет все "запахи дизайна", причины их существования и последствия отъезда их. Май это поможет Вам убедить свое управление, что текущая ситуация не является соответствующей.
Удачи!
Я думаю слабая связь, которую можно получить с полноценным использованием внедрения зависимости, техническая характеристика, которая может помочь много. Когда Вы разобьете части приложения, Вы, менее вероятно, получите спагетти, следующие из "интересного" повторного использования.
Вы можете направиться к чрезмерной фрагментации вместо этого, но это - другая проблема и меньше глобальной структурной проблемы.
Это кажется, что многие не следуют за некоторыми основными принципами инкапсуляции и хорошего дизайна.
вещи Хранения, изолированные и неуверенные в других частях, важны для предотвращения проблемы, которую Вы описываете. Вам, возможно, понадобились бы некоторый высокоуровневый разработчик или архитектор. Это - типичный сценарий, где люди выровняли по ширине некоторые драконовские процессы и управление изменениями. (Я не защищаю это)
, необходимо избежать зависимостей и взаимосвязей и определить и использовать открытые интерфейсы только. Это, конечно - упрощение, но Вы, вероятно, изучите много некоторыми метриками на Вашем коде - сложность классов, открытых методов, диаграммы UML, созданные из инженерного анализа кода, и т.д.
Обзоры кода, кодируя стандарты и твердые политики.
следующее применимо к нашему магазину - так как я не знаю, какой магазин Вы имеете, Ваш пробег может варьироваться. При перемещении в Сервер Основы Команды значительная часть нашего фокуса была на поддержании качества кода - или по крайней мере помощь поддержать качество любым возможным путем. Некоторые примеры того, что мы добавляем:
- Рабочий процесс Обзора Кода - Осуществляет обзор кода как часть процесса. Содержит политику, которая предотвратит регистрации, если код не был рассмотрен.
- TeamReview - Делает обзоры кода менее болезненными путем обеспечения полного "в IDE" опыт.
- политики Регистрации (в целом) - Многие спокойные положительные герои, доступные для управления поток кода. Вещи как проверка, что открытые и защищенные методы документируются до регистрации к проверке, что ни в какой работе нельзя зарегистрироваться без соответствующего объекта работы.
Как я сказал, если Вы используете различную платформу, возможно, доступные инструменты и что можно сделать, отличается. Но не исключайте инструменты для помощи любым возможным путем. Если можно использовать его, чтобы улучшить, управлять и контролировать рабочий процесс и объекты, которые перемещаются в нем, это должно быть, по крайней мере, достойно рассмотрения.
Помнят, любые изменения в процессе собираются включить pushback. Способ, которым мы помогли упростить это, состоит в том, чтобы встроить политики в обучение переходу от нашего старого управления версиями / дефектная система слежения.
Я думаю, что основной момент - когда Вы говорите
, Вы просто хотите переписать все с нуля
Просто объятие он.
Использование как можно больше модульных тестов, затем позвольте рефакторингу быть обычной практикой .
Автоматизированный и модульный тест гарантирует, что изменения не представят регрессии; посвящение определенного процента времени к рефакторингу старого кода (и это означает, меньше новых возможностей !) гарантируют, что существующая кодовая база не станет старой, или по крайней мере не настолько быстро.
Создайте "брандмауэры" между различными областями кода. Вы делаете это путем определения различных областей или слоев кода, и определения единственного API (в Java, это обычно делается с интерфейсом), на который отвечает каждый слой. Должны быть базовые интерфейсы или классы, которые API использует, но которые ничего не "знают" о внутренностях тех слоев. Например, gui не должен знать или заботиться, как Вы храните данные, и Ваша база данных не должна знать или заботиться, как данные представлены конечному пользователю.
Эти API не должны быть брошены в камне - необходимо быть в состоянии добавить вещи по мере необходимости, пока Вы удостоверяетесь, что не загрязняете брандмауэры.
20 - 50 разработчиков являются, вероятно, проблемой. Это довольно высоко и нуждалось бы в большом количестве управления и ресурсов для контроля над всем.
я рассмотрел бы разделение проекта в меньшие допускающие повторное использование сегменты. Абстрактные определенные слои далеко от базовой системы.
Я полагаю, что ключ к предотвращению гнили кода находится в звуковых восходящих методологиях разработки и реализации (я верю ему так сильно, что я назвал свой бизнес - Думают Вверх дном - после него!). Предпочтительные инструменты здесь:
- Программирование Многоуровневой структурой контракта
- Внимание на разъединение
- Всегда сборка с повторным использованием в памяти, ища универсальные решения
- Сохраняет платформы легкими, простыми и сфокусировалась
, Как предложили другие респонденты, необходимо поймать проблемы рано. С зелеными разработчиками это означает воспитывать (парное программирование является большим здесь), и обзоры (код и анализ проекта). С более старшими разработчиками это означает бдительность.
Больше всего, не бойтесь рефакторинга. При рефакторинге волнений Вы Вы уже снижаетесь. Если рефакторинг рассматривается как "плохой", то существует что-то не так с Вашим бизнесом.
при фиксации чего-то зафиксируйте его правильно. Я использую термин "fux" для описания фиксации, которая была сделана неправильный путь: это просто "fux" Ваша кодовая база.
С наилучшими пожеланиями,
Dan
Борется, сохраняют дизайн максимально чистым. Это не легко, но это стоит усилия.