Во-первых, я попытался бы связаться с теми людьми, которые первоначально разрабатывали код или, по крайней мере, поддерживали его до меня, надеясь получить достаточно информации, чтобы получить общее представление о коде в целом, чтобы вы могли начать добавлять полезные комментарии к нему.
Может быть, вы даже можете заставить кого-то описать наиболее важные API (включая их сигнатуру, возвращаемые значения и назначение) для кода. Если глобальное состояние модифицируется функцией, это также следует сделать явным. Точно так же начните различать функции и процедуры, а также регистры ввода / вывода.
Вы должны четко дать понять своему работодателю, что эта информация требуется, если они вам не верят, попросите их сесть с вами перед этим кодом, пока вы описываете, что вы должны делать и как вы должен сделать это (обратный инжиниринг). В этом случае полезно иметь работодателя с опытом работы в области вычислительной техники и программирования!
Если у вашего работодателя нет такой технической подготовки, попросите его пригласить другого программиста / коллегу, чтобы объяснить ему ваши шаги, это фактически покажет ему, что вы серьезно и честно относитесь к этому, потому что это реальная проблема - не только с вашей точки зрения (убедитесь, что есть коллеги, которые знают об этом «проекте»).
Если это возможно и возможно, я бы также дал понять, что заключение контрактов (или, по крайней мере, связывание) с бывшими разработчиками / сопровождающими (если они больше не работают в вашей компании, то есть) для оказания помощи в документировании этого кода быть предварительным условием для реального улучшения кода в течение короткого промежутка времени и обеспечения его более легкого сопровождения в будущем.
Подчеркните, что вся эта ситуация обусловлена недостатками в предыдущем процессе разработки программного обеспечения и что эти шаги помогут улучшить базу кода. Таким образом, кодовая база в ее нынешнем виде является растущей проблемой, и все, что делается сейчас для решения этой проблемы, является инвестицией в будущее.
Это само по себе также важно, чтобы помочь им оценить и понять вашу ситуацию: делать то, что вы должны делать сейчас, далеко не тривиально, и они должны знать об этом - хотя бы для того, чтобы оправдать свои ожидания (например, относительно сроков) и сложность задачи).
Кроме того, лично я бы начал добавлять модульные тесты для тех частей, которые я достаточно хорошо понимаю, чтобы я мог медленно начать рефакторинг / переписывание некоторого кода.
Другими словами, хорошая документация и комментарии к исходному тексту - это одно, а наличие всеобъемлющего набора тестов - это еще одна важная вещь, никто не может реально ожидать изменения незнакомой базы кода без какого-либо установленного способа тестирования функциональности ключа.
Учитывая, что код имеет размер 10 КБ, я также рассмотрел бы выделение подпрограмм в отдельные файлы, чтобы сделать компоненты более узнаваемыми, предпочтительно используя оболочки доступа вместо глобальных переменных, а также интуитивно понятные имена файлов.
Кроме того, я бы рассмотрел шаги для дальнейшего улучшения читабельности исходного кода за счет уменьшения сложности, наличия подпрограмм с несколькими точками входа (и, возможно, даже с различными сигнатурами параметров?), Которые выглядят как верный способ запутать код без необходимости ,
Аналогично, огромные подпрограммы также могут быть преобразованы в более мелкие, чтобы улучшить читаемость.
Итак, одна из самых первых вещей, которые я хотел бы рассмотреть, заключается в определении тех вещей, которые действительно усложняют получение кода и затем переделывают эти части, например, путем разделения огромных подпрограмм с несколькими записями. указывает на отдельные подпрограммы, которые вместо этого вызывают друг друга.
Если это невозможно сделать из-за соображений производительности или из-за проблем с вызовом, используйте вместо этого макросы.
Кроме того, если это жизнеспособный вариант, я хотел бы рассмотреть возможность поэтапного переписывания частей кода с использованием языка более высокого уровня, либо с использованием подмножества C, либо, по крайней мере, из-за довольно чрезмерного использования макросов сборки, чтобы помочь стандартизировать кодовую базу, а также помочь локализовать потенциальные ошибки.
Если возможна дополнительная инкрементная перезапись в C, одним из возможных способов начать было бы превращение всех очевидных функций в функции C, тела которых - в начале - скопированы / вставлены из файла сборки, так что вы завершаете с функциями C с большим количеством встроенной сборки.
Лично я также попытался бы запустить код в симуляторе / эмуляторе , чтобы легко пройти по коду и, надеюсь, начать понимать наиболее важные строительные блоки (при изучении использования регистров и стеков), хороший 8051 Симулятор со встроенным отладчиком должен быть доступен для вас, если вам действительно нужно делать это в основном самостоятельно.
Это также поможет вам придумать последовательность инициализации и структуру основного цикла, а также таблицу вызовов.
Может быть, вы даже можете найти хороший симулятор 80851 с открытым исходным кодом, который можно легко модифицировать, чтобы он также автоматически предоставил полный граф вызовов, просто выполнив быстрый поиск, я нашел gsim51 , но, очевидно, есть несколько других варианты, а также различные проприетарные.
Если бы я находился в вашей ситуации, я бы даже подумал о том, чтобы отдать на аутсорсинг усилия по модификации моих инструментов, чтобы упростить работу с этим исходным кодом, то есть многие проекты sourceforge принимают пожертвования, и, возможно, вы можете убедить своего работодателя спонсировать такую модификацию.
Если не в финансовом отношении, может быть, вы предоставили ему соответствующие патчи?
Если вы уже используете проприетарный продукт, вы можете даже поговорить с производителем этого программного обеспечения и подробно рассказать о ваших требованиях и спросить их, хотят ли они улучшить этот продукт таким образом или, по крайней мере, могут предоставить интерфейс, позволяющий клиентам выполнять такие настройки (некоторая форма внутреннего API или, может быть, даже простые скриптовые сценарии).
Если они не реагируют, укажите, что ваш работодатель уже некоторое время думает об использовании другого продукта и что вы были единственным, кто настаивал на том, что этот конкретный продукт будет использоваться ...; -)
Если программное обеспечение ожидает определенные аппаратные и периферийные устройства ввода / вывода, вы можете даже захотеть написать соответствующий цикл аппаратного моделирования для запуска программного обеспечения в эмуляторе.
В конце концов, я точно знаю, что лично мне гораздо больше понравился бы процесс настройки другого программного обеспечения, помогающего мне понять такого монстра спагетти-кода, чем ручное пошаговое выполнение кода и игра на эмуляторе, независимо от того, сколько галлонов кофе я могу получить.
Получение полезного списка вызовов из эмулятора с открытым исходным кодом 8051 не должно занимать намного больше времени, чем, скажем, выходные (максимум), потому что это в основном означает поиск кодов операций CALL и запись их адресов (позиции и цели), так что все сбрасывается в файл для последующей проверки.
Наличие доступа к внутренним компонентам эмулятора на самом деле также было бы отличным способом дальнейшей проверки кода, например, чтобы найти повторяющиеся шаблоны кодов операций (скажем, 20-50+), которые могут быть учтены в отдельных функциях / процедурах, на самом деле это может помочь еще больше уменьшить размер и сложность кода.
Следующим шагом, вероятно, будет проверка использования стека и регистрация. И для определения типа / размера используемых параметров функции, а также диапазона их значений - чтобы вы могли представить соответствующие модульные тесты.
Использование инструментов типа dot / graphviz для визуализации структуры последовательности инициализации и самого основного цикла будет чистой радостью по сравнению с выполнением всего этого вручную.
Кроме того, на самом деле вы получите полезные данные и документы, которые могут послужить основой для более качественной документации в долгосрочной перспективе.