Анализ кода

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

как-то в 1с:зарплата и кадры приходилось отлаживать процедуру на 25 тыс. строчек.. как оно работает я не понял :)

http://scg.unibe.ch/download/oorp/index.html

часто вижу в резюме нечто вроде expert in OOP & OOAD & code analysis & refactoring. Тока чото никто не может объяснить, какого черта все эти слова значат.

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

спасибо, о гуру
съем в ближайшее время, бампну тред с вопросами

http://en.wikipedia.org/wiki/Object-oriented_programming

http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design

http://en.wikipedia.org/wiki/Refactoring

Уж прости за ссылки на букварь.

Незачто :) Я, правда, сам ещё не читал, просто знаю, что она есть.

UML же, не?

Стало интересно, насколько продвинулась наука в этом деле

Лично я не верю, что программирование - это наука. Больше похоже на ремесло. Практика все равно сильно доминирует над теорией.

Тока чото никто не может объяснить, какого черта все эти слова значат

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

А маны по чтению манов тебе не надо?

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

пропустил тэг «ирония»

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

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

Это если в двух словах, ибо у меня есть целая статья про несостоятельность UML в действительно серьезной и сложной разработке :)

Если у ТС есть UML - да, ты прав. - по нему можно нужно изучить работу функции. Если его нет, что более вероятно, то придется методично читать код сверху вниз, иного пути нет.

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

Интересно, а что ТС думает о классике. Найти нечто вроде «точки входа» и попытаться пройтись далее по коду. Выщемить некую более или менее законченную мысль. Понять стиль «писателя». :)

Ну и так много повторить много раз, пока не наступит состояние просветления.

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

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

Хотя попробовать можно. Раз на раз не приходится. Иногда глянешь бегло - говнокод, а потом присмотришься, да вроде и ничего. Просто люди мыслят по разному.

Вот как раз антиговнокод малевать и не надо - сиди и читай. А вот с говнокодом получаются такие катрины, что и 2д бумаги не хватает, было бы не плохо иметь ещё пару измерений или пару квадратных метров дополнительно хотя бы.

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

есть целая статья про несостоятельность UML в действительно серьезной и сложной разработке :)

А у Лармана есть целая книга о полезности uml в том же самом

придется методично читать код сверху вниз

А разве uml тулзы не рисуют примитивные диаграммы по коду?

А у Лармана есть целая книга о полезности uml в том же самом

Бумагомарательство и бюрократия, имхо (см. манифест программиста).

А разве uml тулзы не рисуют примитивные диаграммы по коду?

Не видел ни одной такой, выдающей _внятный и понятный_ результат. Если назовешь - буду признателен, правда, самому интересно.

зато есть кусок говнокода, класс размером 10 тысяч строк

в жабе есть dependency checkers которые визуально рисуют схемы зависимостей классов. но для класса из 10000 строк это наверняка не сработает

Вот как раз антиговнокод малевать и не надо...

Я вот когда пишу свой код часто рисую... WAIT, OH SHI...

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

wikipedia.org

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

> [..]класс размером 10 тысяч строк.[..]

Сомневаюсь, что там ООП.

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

а этот код нужно будет впоследствии как-то рефакторить или поддерживать? не проще ли пойти по методике, которую пропогандирует в своей книге «Clean Code» Robert Martin (и не только он, как я понял)?

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

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

Для графов, ещё необходимо чтобы graphviz стоял, сам он не строит.

вот, годно.

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

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

а для быстрого анализа с учетом тотальной неполноты информации, нужны какие-то эвристики.
И хорошо бы, чтобы они были описаны не как выше по треду «читаю код, моделирую, а что будет, если здесь такие данные, там другие и т.д». При всем уважении к интуиции, это не промышленный метод. Хорошо бы иметь конкретный набор техник и best practices, которыми можно было бы оперировать формально.
Например, нам не хватает ресурсов на полный анализ call hierarchy. Какую часть дерева call hierarchy брать? Какая оптимальная глубина и ширина для анализа? Что делать с повторениями, циклами, неиспользованными и возможно ненужными блоками, итп. Как side effect - как писать код так, чтобы реверс-инженеру (твоему будущему заместителю на посту суппорта или коллеге) было удобно загрузить в голову код?

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

когда изобретут конвейер, все программисты резко переквалифицируются в дворники :)

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

При всем уважении к интуиции, это не промышленный метод

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

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

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

как писать код так, чтобы реверс-инженеру (твоему будущему заместителю на посту суппорта

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

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

//Требуй и ты станешь на работе героем. :)

к тому времени как это случится работа дворника будет уже лет 50 как автоматизирована

При приёме на работу по поддержке кода с многолетней историей костылестроения перестали требовать скилл «навыки чтения чужого кода», который ТС пытается прокачать? Пичаль.

Вкратце:

1. Прочитать 10 раз по диагонали (начиная с заголовка, да). В зависимости от опыта что-то станет понятно.

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

3. После получения задачи, применять методы микрорефакторинга (каждое изменение не более 5-10 строк) там, где приходится вносить изменения. После нескольких десятков итераций код сам приведётся в порядок.

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

Что за феерический бред? Без тестов рефакторить и поддерживать код - абсолютно неблагодарное занятие.

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

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

Добро пожаловать в реальный мир. Он жесток. Бизнесу часто нужно, чтобы вы внесли изменения A,B,C,D...Z и каждое из них - за неделю. Если вы собиратесь возиться с A,B,C два месяца, а потом ещё делать по букве каждый день - вы не подходите, вас могут послать и отдать работу тому, кто будет, как сказано, трудолюбиво по неделе вкорячивать каждую фичу, раздувая говнокод. Возможно, он окажется индусом или ветераном сбербанка.

> Добро пожаловать в реальный мир. Он жесток.

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

зависимости от невменяемости начальства

особенно если начальство - ты сам ;)

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

если платят за загнивание, надо загнивать :)

1) Связаться с автором кода, фамилия и/или адрес электронной почты котрого часто бывает рядом с его творением;
2) изучить предметную область, если код призван решать прикладную задачу.

В зависимости от успехов в 1 и 2 следует либо садиться копать код, либо искать другого человека (или людей), котрые займутся этой частью.

Паттерны, чеклисты, фишки.

что

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

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

Michael Feathers, Working effectively with legacy code.

Самый простой и быстрый способ - дебаггер.

тесты костылям не мешают

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

> тесты костылям не мешают

святая правда

Годную информацию по теме я бы и сам почитал.

Из своего опыта:

1. Запихать проект в систему контроля версий, и далее при каждом законченном изменении — коммит.

2. Выделять осмысленные участки, приделывать к ним коммент-шапку: что делается, зачем делается, почему именно так. Не стесняться писать WTF, TODO и FIXME где что-то непонятно.

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

4. К коротким методам писать тесты, прогонять их. Откатываться, если юнит-тесты и/или проект в целом перестали работать.

Ненаучно и, главное, небыстро, но работает.

Заодно рекомендую прочесть «Рефакторинг» Мартина Фаулера. Полезная книга, пригодится, когда будете убирать TODO и FIXME.

Может быть, ты убьешь себя об стену сам? Говорю из практического опыта.