Обдумывать чужой код - PullRequest
       33

Обдумывать чужой код

8 голосов
/ 26 января 2009

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

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

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

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

Ответы [ 16 ]

1 голос
/ 27 января 2009

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

Очистка кода, правильное переименование методов, классов и пространств имен, извлечение методов - все структурные изменения, которые могут пролить свет на то, что должен делать фрагмент кода. Это может показаться нелогичным для рефакторинга кода, который вы «не знаете», но, поверьте мне, ReSharper действительно позволяет вам сделать это. Возьмем, к примеру, проблему мертвого кода красной сельди. Вы видите метод в классе или, возможно, переменную со странным именем. Вы можете начать с попытки поиска использования или, ungh, выполнить текстовый поиск, но ReSharper фактически обнаружит мертвый код и раскрасит его в серый цвет. Как только вы откроете файл, который вы увидите серым цветом с флагами полосы прокрутки, то, что в прошлом могло сбивать с толку красную сельдь.

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

Приветствие.

1 голос
/ 27 января 2009

Лично я много рисую диаграммы и разбираюсь в костях конструкции.

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

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

Это только я, однако. ;)

1 голос
/ 26 января 2009

хорошая IDE (EMACS или Eclipse) может помочь во многих случаях. Также на платформе UNIX есть несколько инструментов для перекрестных ссылок (etags, ctags) или проверки (lint) или gcc со многими включенными опциями предупреждений.

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

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

Со временем вы получите более приятный код, с которым вам нравится работать.

1 голос
/ 26 января 2009

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

1 голос
/ 26 января 2009

См. Модульное тестирование устаревших приложений веб-форм ASP.NET для получения советов о том, как получить контроль над устаревшими приложениями с помощью модульного тестирования.

Есть много похожих вопросов и ответов. Вот поиск https://stackoverflow.com/search?q=unit+test+legacy

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

0 голосов
/ 26 января 2009

Это все о стандартах и ​​правилах кодирования, которые использует ваша компания.

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

...