Прием в чужой код

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

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

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

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

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

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

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

В первую очередь я начинаю с базы данных.

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

Все, что говорили все, верно для изучения того, что сделал кодировщик.

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

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

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

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

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

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

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

Настройте ведение журнала, чтобы наблюдать, в какой последовательности что-то происходит.

Прочтите здесь: Нанят в качестве разработчика для поддержки и обновления текущей базы кода, без документации!

Ведение журнала позволяет увидеть, что делает код.

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

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

Документация? Чтение самого кода без запуска отладчика?

В остальном вы делаете то же, что и я.

Исправьте в нем простую проблему.

Изменить: Затем устраните более серьезные проблемы и начните писать документацию и модульные тесты в тех областях, в которых вы разбираетесь. Развивайте эти области, и однажды вы сможете понять всю систему.

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

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

One thing that helps me learn systems faster is writing the documentation myself.

• I get a overview
• I will see many bugs/bad design decisions. Which makes it easier to order and prio them. (instead of picking a irrelevant bug and solving it, I will fix those that really matters)
• I later on have an documentation.
• Documentation will make it easier to justify refactoring/rewrite to the suit's

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

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

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