Знакомство с кодом других людей

Я настоятельно рекомендую BOUML. Это бесплатный инструмент моделирования UML, который:

• работает очень быстро (самый быстрый инструмент UML из когда-либо созданных, ознакомьтесь с тестами),
• имеет надежную поддержку импорта C ++,
• имеет отличную поддержку экспорта SVG, что важно, потому что просмотр больших графиков в векторном формате, который быстро масштабируется, например, Firefox, очень удобен (вы можете быстро переключаться между представлением "с высоты птичьего полета" и представлением сведений о классе),
• полнофункциональный, интенсивно разрабатываемый (посмотрите историю разработки, трудно поверить, что такой быстрый прогресс возможно).

Итак: импортируйте свой код в BOUML и просмотрите его там или экспортируйте в SVG и просмотрите его в Firefox.

Хм, это сложно, так много сказать, так мало времени ...

1) Если вы можете запустить код, это очень упрощает жизнь, точки останова (особенно условные) вам подойдут.

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

3) ReSharper хорошо показывает, где что-то используется, что вызывает метод, например, он статичен, но хорошее начало, и помогает с рефакторингом.

4) Многие события .net кодируются как общедоступные, и в лучшем случае их может быть сложно отлаживать. Перекодируйте их в частные и используйте свойство с добавлением / удалением. Затем вы можете использовать точку останова, чтобы увидеть, что слушает событие.

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

В прошлом меня просили стать владельцем некоторого кода NASTY - как для работы, так и для «игры».

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

Я обнаружил, что лучший / единственный способ разобраться в коде - это начать с точки входа ОС [main ()] и построить свою собственную диаграмму стека вызовов, показывающую дерево вызовов. На самом деле вам не обязательно строить полное дерево с самого начала. Просто проследите через разделы, над которыми вы работаете на каждом этапе, и вы получите достаточно хорошее представление о вещах, чтобы иметь возможность работать с ним.

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

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

Я делаю это регулярно. И разработали некоторые инструменты и уловки.

• Постарайтесь получить общий обзор (диаграмма объектов или другое).
• Задокументируйте свои выводы.
• Проверьте свои предположения (особенно для расплывчатого кода).

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

Обычно я использую диаграммы последовательности UML для различных ключевых способов использования компонента. Я не знаю каких-либо инструментов, которые могут генерировать их автоматически, но многие инструменты UML, такие как BoUML и EA Sparx, могут создавать классы / операции из исходного кода, что позволяет сэкономить на вводе текста.

Окончательный текст по этой ситуации - это работа Майкла Фезерса «Эффективная работа с устаревшим кодом». Как указано в S. Лотт говорит, что нужно провести несколько модульных тестов, чтобы установить поведение запаздывающего кода. Как только они у вас появятся, вы можете приступить к рефакторингу. Кажется, есть образец главы, доступный на веб-сайте Object Mentor.

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

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

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

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

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

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

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

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

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

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

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

Но это только я. ;)

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

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

Есть десятки других уловок и, вероятно, ряд других инструментов, которые могут делать похожие вещи, но я помешан на ReSharper.

Ваше здоровье.

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

• Распечатки
• Доски
• Много почтовой бумаги
• Много Starbucks

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

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

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

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

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

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

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

Один из методов, которые я использую, - это попытаться понять значение именования переменных, методов, классов и т. Д. Это полезно, потому что оно (надеюсь, все чаще) включает высокоуровневый взгляд на ход мыслей с атомарного уровня.

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

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

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