Советы по обслуживанию кода [закрыто]

Эту проблему можно легко решить, добавив больше ОЗУ. 1-2 ГБ должны помочь.

Ключи к обслуживанию:

• SCM . В Windows я бы порекомендовал что-то вроде Mercurial ( Клиент TortoiseHg ). Создайте центральный благословенный репозиторий, где другие могут получить программное обеспечение, а исправления - из частных репозиториев разработчиков.

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

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

5K LoC - это немного. Наличие SCM помогает отслеживать изменения и возвращаться в случае регресса. Отслеживание проблем помогает команде совместно решать проблемы. Делайте второстепенные выпуски, когда исправляете проблемы (например, ваш malloc, новый или утечки памяти). Сделайте основные выпуски для более крупных исправлений и функций (например, для поддержки больших наборов данных).

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

5000 LoC - это неплохо. Считай, что тебе повезло.

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

1. Замените каждое использование malloc на новое .
2. Исправить предупреждения компилятора.
3. Замените массивы векторами (или более подходящими структурами данных).
4. По возможности заменяйте необработанные указатели на переменные / ссылки стека, а если нет - на интеллектуальные указатели. Не беспокойтесь о серьезных изменениях архитектуры или 100% конверсии - сосредоточьтесь на низко висящих фруктах и ​​устраните некоторые из основных утечек памяти.
5. Приступите к изменению архитектуры приложения.
   1. Выберите дискретное поведение / задачу в приложении.
   2. Примерно выясните, как работает .
   3. Выясните, как вы хотите, чтобы он работал (концентрируясь на интерфейсе).
   4. Разработайте план перехода.
   5. Выполните свой план.
   6. Повторить.

Я бы посоветовал выполнить некоторые шаги, которые Майкл Фезерс описывает в своей книге «Эффективная работа с устаревшим кодом». А именно: получить тестируемый код как можно скорее.

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

Я знаю, однако, что сказать это намного легче, чем на самом деле СДЕЛАТЬ. Прочтите эту главу о швах (части кода, которые вы можете переопределить / перехватить, чтобы упростить тестирование кода): http://www.informit.com/articles/article.aspx?p=359417&seqNum=3 См. Также это в CppUnit и CppUnitLite, фреймворке для модульного тестирования на C ++: http://c2.com/cgi/wiki?CppUnitLite

Выполните код через профилировщик памяти. См. Эту ссылку SO: https://stackoverflow.com/questions/818673/memory-profiler-for-c Это поможет вам отследить места, где вам нужно начать размещать операторы delete / free. Я бы также начал пытаться сделать распределение памяти по крайней мере согласованным в используемом API.

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

Сколько времени у вас под рукой? Вы понимаете реализованные алгоритмы?
5kLoC не так уж и много, особенно когда это все мелочи. Когда вы знаете основные алгоритмы и имеете достаточно времени под рукой, переписать его до 2k строк легко понятного кода может быть лучше , чем пытаться исправить это.

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

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

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

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

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

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

Я бы подошел к этому следующим образом:

• Найдите все места в коде, которые вызывают malloc () . Внимательно посмотрите на них и попробуйте заменить их вызовами new , так что вам придется иметь дело только с одним типом управления памятью, что упростит переход к следующему шагу.
• Найдите все места, где вызывается new , и посмотрите, можете ли вы заменить необработанные указатели, которым присвоены результаты new , на boost :: shared_ptr <> . Это должно, по крайней мере, дать вам своего рода сборщик мусора для бедняков; конечно, вам также следует изменить все прототипы функций, получающих эти указатели, чтобы они принимали shared_ptr <> вместо необработанных указателей, иначе вы просто нарядили беспорядок и по-настоящему ничего не улучшили. На самом деле я бы сказал, что вы все изменили к худшему ...

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

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

Не сказав этого, вы можете получить больше проблем, чем уже имеете :)

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

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

Ключевое решение, которое необходимо принять здесь: (a) Пройтись ли вам по программе и исправить кучу ошибок в деталях по одной за раз? (b) Провести серьезную реструктуризацию и очистку? Или (c) выбросить ее и переписать с нуля. В подобных случаях я часто склоняюсь к выбору (c), потому что кажется, что переписывание будет меньшей работой, чем уборка беспорядка, но вполне вероятно, что в существующем коде заложено множество детальных логических решений. Если у вас нет подробной, актуальной документации по требованиям - а это настолько маловероятная возможность, что я сразу же отвергну ее под раскаты смеха при одной мысли об этом - единственный способ узнать все правила - это прочитать существующий код и понять, что он задумал. В этот момент (a) или (b) становятся гораздо более эффективными, чем (c).

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

Замените каждый:

Type* data = (Type*)malloc(123*sizeof(Type));

на

std::vector<Type> data(123);

Все управление памятью удалено! Легко, как пирог. Затем просто передаем векторы по значению.

Похоже на полный беспорядок. Рефакторинг - это меньшее, что вам нужно сделать. Смесь new и malloc - это верный путь к катастрофе!

Думаю, вам, вероятно, придется переписать почти все. К счастью, 5000 SLOC не огромная и не займет много времени.

Похоже, хорошее упражнение!

Рефакторинг кода, одно изменение за раз, пока оно не станет для вас осмысленным. Важнее всего не точная стратегия кодирования, а то, что вы понимаете, что он делает и почему.

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

Напишите набор тестов прямо сейчас.

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