Как читать тысячи строк кода без какой-либо документации? [закрыто]

Ранее я искал хороший элемент управления TimeLine для проекта WPF. Я нашел ответ в этом , которые направляют меня в этот проект CodePlex .

Теперь я хочу изменить код, чтобы удовлетворить потребности моей культуры. Но есть некоторые несоответствия!

Мой вопрос:

Как вы взаимодействуете с такими тысячами строк кода?

РЕДАКТИРОВАТЬ:

Любой ярлык будет отличным!

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

1. Шаг через код
2. Переименовать по мере необходимости
3. Рефакторинг по мере необходимости
4. Повторяйте, пока полностью не поймете

... и код поблагодарит вас за это. ;-)

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

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

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

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

О, да, я все еще иногда попадаю в эту ловушку. «Делай, как я говорю, а не как я», и все такое. :)

SE-Radio взял интервью у Дейва Томаса на эту тему

В этом эпизоде ​​подкаста есть много советов и приемов, которые помогут вам проникнуть в «культуру» проекта и понять, как жили исконные жители.

Я должен был сделать это недавно с проектом более 100 000 LOC. Моя первая идея заключалась в том, что шаблоны из 100 или даже 1000 узлов легче увидеть, чем из 100 000 строк текста.

Поэтому я потратил 45 минут и написал короткую (<100LOC) программу на Python, чтобы проанализировать из нее то, что мне нужно, и нарисовать объектные отношения. Я сгенерировал исходный код Graphviz , который очень легко генерировать. (Здесь нет ничего особенного в Python: Ruby или C # или Common Lisp или что-то еще, что может сделать это так же хорошо.)

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

(Возможно, это из-за того, что я взял компиляторы , но я нахожу странным, что когда программист сталкивается с проблемой, ответом всегда будет «написать программу!», За исключением случаев, когда проблема связана с исходным кодом программы.: - )

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

Поймите, что на самом деле нет никаких путей к полному гроккингу. (И если у вас возникли проблемы с этой фразой, ваше образование, ПОЖАЛУЙСТА, игнорируется. Оно написано Робертом А. Хайнлайном из книги «Незнакомец в чужой стране».)

Прочитайте его, одну страницу за раз, одну процедуру за раз. Добавьте комментарии. Нарисуйте картины основных структур данных. Распознать алгоритмы. Опираться на предыдущие знания.

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

Что бы вы ни делали, записывайте столько, сколько сможете, чтобы никто не оказался в том же положении, что и вы.

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

чтение 14 тысяч строк кода Java не имеет никакого смысла. Функциональность поиска - ваша жизнь

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

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

Конечно, когда вы понимаете биты, прокомментируйте их за то, что вы знаете в то время, возможно, добавив заметки о том, чего вы не понимаете.

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

Я бы начал с использования Leo Editor в режиме @shadow с активным использованием клонированных узлов . Это позволяет добавлять примечания и комментарии для каждого раздела изучаемого кода без изменения кода , и аннотации всегда будут в контексте, рядом с кодом, о котором идет речь. Вот пример рабочего процесса документации:

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

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

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

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

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

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

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

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

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

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

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

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

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

И я просмотрел официальный документ http://queue.acm.org/detail.cfm?id=2063168, в котором говорится о стиле кодирования или о том, как мы можем использовать пробел, отступ, изменение шрифта, как большинство IDE, которые мы можем использовать для написания MUCH. Код CLEANER, где мы, люди, можем понять столько же, сколько машины. Больше внимания уделяется написанию кода без комментариев, чтобы наш код отображался в виде абзацев.