?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Читай код

Posted on 2009.05.03 at 16:01

Comments:


Майк
glader at 2009-05-03 16:21 (UTC) (Link)
Извини, я не уловил мысль. Что надо делать, чтобы научиться вот так же быстро открывать нужный файл среди 50 Мб других? То есть как (без документации), получив задание на доработку системы, узнать, какой файл надо править?
Gaperton
gaperton at 2009-05-03 16:41 (UTC) (Link)
Что надо делать, чтобы научиться вот так же быстро открывать нужный файл среди 50 Мб других?

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

То есть как (без документации), получив задание на доработку системы, узнать, какой файл надо править?

- понимать, что в крупном проекте актуальной документации у тебя не будет _никогда_.
- прослушать лекции о Common Design Principles системы, что поможет ориентироваться в системе "вообще". Это _очень_ сильно экономит время.
- Уметь "читать код", пользоваться режимом "annotate" в системе контроля версий, и владеть reverse enginering - уметь восстанавливать дизайн и мысль автора из кода.
- Знать список "центральных" классов подсистемы, и их предназначение, чтобы с них начать. Это поможет съэкономить время.
- На самом деле, если хорошо умеешь читать код, не надо знать и предыдущего. Это довольно быстро восстанавливается из кода - "центральные" классы стоят обычно в центре графа связности.
- Обязательно проводить design review своих решений у знающих людей.
- Менеджерам - следить, чтобы в компании было как минимум два человека, занимающихся каждой подсистемой.
Денис Бесков
beskov at 2009-05-03 16:47 (UTC) (Link)
т.е. всё-таки архитектурная документация скорее нужна, чем нет?

и надо делать так, чтобы «лекции по архитектуре» разработчики прослушивали в первый месяц работы компании, а не через полгода?
Gaperton
gaperton at 2009-05-03 16:59 (UTC) (Link)
т.е. всё-таки архитектурная документация скорее нужна, чем нет?

- Common Design Principles - скорее нужна, чем нет. Это краткое описание "правильных" способов делать в системе разные вещи. Скажем, пользоваться вот такими смартпойнтерами, и для посылки сообщений - вот такими классами.

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

Короче, документы, которые имеет смысл писать - должны быть маленькими.

и надо делать так, чтобы «лекции по архитектуре» разработчики прослушивали в первый месяц работы компании, а не через полгода?

- При выдаче задания, чтобы пошло впрок и не выветрилось из головы. В моем случае раньше чем через полгода было невозможно - мне надо было поехать в Штаты для того, чтобы послушать лекцию.
Gaperton
gaperton at 2009-05-03 16:52 (UTC) (Link)
- понимать, что в крупном проекте актуальной документации у тебя не будет _никогда_.

если это не doxygen, что-то подобное, или просто комментарии в коде, что примерно одно и то же.

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

Описание Common Design Priciples не в счет, это штука полезная. И как раз этого документа практически ни у кого и нет - по причине что мало кто понимает, что это такое.
Ден Шергин
binstream at 2009-05-04 02:21 (UTC) (Link)
Исключения бывают: у middleware на продажу _необходимо_ поддерживать документацию в актуальном виде, хотя бы по API. Оверхед большой, но не смертельный - выделенный технический писатель, обладающий скилами разработчика.
Денис Бесков
beskov at 2009-05-03 16:53 (UTC) (Link)
1. интересно, насколько можно научиться быстрому восстановлению логики работы кода, если в программе плохо соблюдаются (отсутствуют) низкоуровневые принципы устройства кода и стандарты кодирования?

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

но на обучение через рефакторинг обычно нет времени, поэтому вопрос про 1 остаётся.
Gaperton
gaperton at 2009-05-03 17:15 (UTC) (Link)
1. интересно, насколько можно научиться быстрому восстановлению логики работы кода, если в программе плохо соблюдаются (отсутствуют) низкоуровневые принципы устройства кода и стандарты кодирования?

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

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

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

Кроме того, мне просто до чрезвычайности интересно, как Фаулер в процессе рефакторинга поймет, почему были выбраны те или иные решения, скажем, в подсистеме хранения котировок в CQG. Неужто "рефакторинг", который суть бездумное эквивалентное преобразования растусовки методов по классам, ему подскажет, что котировки до сих пор хранятся по одному файлу на день потому, что [historical reason]в 91 году диски были маленькие, и на диск помещалось всего порядка 4-7 файлов, которые надо было циклически удалять [/historical reason]?

И зачем интересно это делать в процессе рефакторинга, если информация об этом лежит в комментариях к коммитам и в базе данных фич/дефектов в явном виде, а если нет - то можно просто спросить людей, и они скажут?
ex_alexeych at 2009-05-03 18:59 (UTC) (Link)
Относительно первого: Попробуйте без исходного кода, после этого стандарты кодирования вас больше волновать не будут =)))) Можно ещё в качестве тренировки искать баги по корке для чужого проекта, сие очень хорошо развивает чувство кода не как синтаксического артефакта, но как живой системы.
Енотинька
raccoon at 2009-05-04 12:27 (UTC) (Link)
Поддержу предыдущего оратора.

Кроме необходимости введения в курс дела новичков, иногда в жизни случаются такие нестандартные ситуации, когда - не дай Бог - в компании предстоит:

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

b. Покупка компании или части ее акций другой компанией, а также разнообразные "слияния и поглощения", весьма модные в наши времена. Аудит, анализ кода, рефакторинг. За всю свою историю жизни в IT я четырежды переживала такой бедлам. Наученная печальным опытом, на предпоследнем месте работы начала процесс документирования системной архитектуры "с самого начала". И как в воду глядела: ходят слухи, что недалек тот день, когда две компании, ведущие разработки в смежных областях, сольются.

c. Наконец, "это просто удобно". Особенно - если мы пишем не систему для автоматизации бизнес-процессов компании "Unique International", а вполне себе коробочный продукт, а еще лучше - систему, из которой при некоторой "доработке напильником" может получиться система, скажем, следящая за действиями сотрудников корпорации в Интернете, а может - система, собирающая статистику для контекстной рекламы; и две системы, имеющие общее архитектурное ядро, разделятся на два самостоятельных проекта, каждый из которых живет своей собственной внутренней жизнью, но тем не менее обязан поддерживать совместимость с "партнером", у которого существуют свои собственные стратегические задачи. У Microsoft, кстати, существовала в давние времена похожая проблема, когда они вели совместные разработки с Sybase (как всем известно, MS SQL Server изначально - это всего лишь клон Sybase SQL Server, и до 4-ой с какой-то точкой версии MS SQL Server - если мне не изменяет память, то до 4.9 - Microsoft и Sybase SQL Server имели очень много общего кода и согласовывали друг с другом все вносимые в этот код изменения; полный доступ к собственному коду, разумеется, ни одна из конкурирующих компаний своему партнеру не предоставляла).
=========================================================
d. Разумеется, любое документирование системной архитектуры, в соответствии с любыми выбранными стандартами, не отменяет необходимости включать голову и читать код.

Я думаю, что beskov как раз говорит не об отмене данной необходимости, а лишь о ее облегчении.
(Deleted comment)
alll
alll at 2009-05-03 20:40 (UTC) (Link)
Это всё относительно очевидно и для проекта на несколько сот килобайт кода не вызывает особых проблем. Но как читать 50 Мб кода, это же совершенно неперевариваемый "стихийными методами" размер? Может быть порекомендуете какие-либо приёмы-инструменты? Вот, скажем, упомянутый "граф связности" - он каким-то инструментом строится-визуализируется или тоже всё в голове?
Gaperton
gaperton at 2009-05-03 21:01 (UTC) (Link)
Сначала я пытался найти инструменты. Взял Rational Rose, натравил на "свою" подсистему, и несколько дней занимался расстановкой нескольких сотен классов на листке бумаги, чтобы получился планарный граф :). Потом игра в "пятнашки" меня достала, и я понял, что волшебной тулзы, которая поможет мне понять код не читая его, я не найду.

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

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

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

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

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

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

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

Вообще, я бы дал ссылку на пост, но РСДН лежит.
htonus at 2009-05-29 11:25 (UTC) (Link)

Все это правильно и верно...

если исходить из предпосылки что написан код правильно и без мусора. Проблема больших проектов в том что через них проходит великая масса "программеров" которые оставляют весьма удручающий след в коде. Это и криво написанные методы, и не уважение к предкам перегруженных методов. И просто осколки кода - методы и атрибуты которые устарели и просто не вызываются или не используются. Такой код читается, но понять архитектуру не возможно, и сложно оценить его валидность. И если нет документации или хотя бы комментов в нем - то тут никакое понимание и воображение не поможет. Хотя в целом с автором согласен: чтение кода - наиболее быстрый и верный путь к пониманию архитектуры проекта.
социопат в социальной сети
bopm at 2009-05-07 12:57 (UTC) (Link)
Сочетать полнотекстовый поиск по коду проекта с просмотром истории коммитов VCS и главное с пониманием структуры проекта.
Для последнего придется первое время исполнять код проекта в собственной голове.
Previous Entry  Next Entry