?

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
Tags: , , , ,
Эту статью я написал по просьбе организаторов специально для сайта конференции software people. Опубликована здесь: http://www.softwarepeople.ru/press/articles/09/

Когда я заступил на работу в компанию CQG в конце 1999 года, у меня уже был, как мне казалось, достаточно большой опыт в разработке ПО – три года создания корпоративных приложений БД под заказ. Мне уже казалось, что я очень много знаю и умею, и я был крайне самоуверен. Однако, возникла некоторая загвоздка – CQG не являлось приложением баз данных, основанном на комбинации готовых сторонних технологий, таких как MS SQL сервер, Visual Basic, Delphi, JavaScript, и 1C – к которым я привык. Меня потряс объем приложения – почти 50 мегабайт основных исходников, не считая свистулек, прибамбасов, разного рода служебных и системных штук, по размеру почему-то превосходящих размер основных исходников.


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

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

В этот раз, перед тем, как что-либо писать, я предусмотрительно показал свой предварительный дизайн (подход к решению проблемы) Толу Корину (Tal Korin), автору и главному архитектору данной системы, и он направил меня в правильном направлении. У Тола ушло на это 5 минут. Это был первый случай, когда я сам инициировал дизайн-ревью (не зная, как оно называется), и был рад найденным у меня проблемам. После успешного выполнения данного задания я поступил в распоряжение Тола Корина, поскольку, с его слов и к моему безмерному удивлению, я оказался одним из немногих, кому пошли впрок лекции по архитектуре.

Каких-либо иллюзий на свой счет, меж тем, к тому моменту у меня уже не осталось – я понял, что цена всем моим знаниям, университетскому образованию, и опыту – ломаный грош. Меня поражал простой факт – я был объективно образован в Computer Science гораздо лучше Тола, и _знал_ больше. При этом, и, после некоторого опыта работы, я был в этом абсолютно уверен – я бы не смог спроектировать и реализовать такую систему за год, как это десять лет назад с одним помощником сделал Тол. Сложность системы явно превосходила мои возможности - я бы по ходу работы закопался в деталях. И уж тем более, у меня не получилось сделать систему так гибко, чтобы она прожила 10 лет, и была до сих пор адекватна ситуации.

То есть, до меня начало доходить, что есть нечто очень важное, что совершенно перпендикулярно университетскому образованию, чего нас просто не учили даже замечать. Оно перпендикулярно «дизайн-паттернам» и книгам по ОО проектированию. И оно, это нечто, у Тола есть, а у меня – нет. Если мои знания не могут мне помочь сделать такую систему – то много ли они стоят? Понимание и знание требуется для действия, ни для чего другого – это не китайская декоративная ваза.

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

По большей части это напоминало дзен, когда вам дают задание, разрывающее мозг, вроде хлопка одной ладонью, и через некоторое время вы неожиданно ловите просветление. Удивительный опыт. Вот один небольшой пример, на что это было похоже.
- Тол, скажи, а как работает вот эта штука.
- Влад, вот этого я на самом деле не знаю. А ты почитай код, и разберись!
- Тол, ты издеваешься надо мной?! Здесь пятьдесят мегабайт этого гребанного недокументированного кода! Ты знаешь все Тол, и это ни для кого не секрет.
- Хорошо, смотри, – не стал спорить Тол, - Я тебе говорю – я не знаю, и поэтому я должен сам почитать код, чтобы ответить на твой вопрос. Поэтому, я открываю код.
Тол открывает правильный файл в одну попытку, продираясь через файловую систему, не пользуясь класс-браузером, мотает файл в правильную середину.
- Так. Ты сказал, вот эта фигня? Вот, открыл. Так… Тебе нужен вот этот метод. Читаем. Вот, смотри, он вызывает вот этого парня (так Тол называл классы и объекты – look – now this guy tell that guy to do this thing). Видишь? Вот, происходит тут то-то и то-то. Все просто.
- Спасибо, Тол! Теперь все ясно. А говорил – не знаешь!
- Я тебе говорю – код читай, блин! Все то же самое ты можешь сделать сам!
- Тол, ну в нем же нихрена не понятно без документации, - сказал я, будучи совершенно уверен, что я не смогу сделать того же сам. Происходящее напоминало ловкий фокус.
- Тебе, чтобы читать код, нужна документация? Прости – какая?
- Ну, там, диаграммы классов, например.
- У нас была одна, вроде, составленная лет пять назад. Она сейчас, мягко говоря, не соответствует действительности. Сам понимаешь, у нас 50 инженеров, и разработка идет очень активная. Но если ты уверен, что она тебе поможет, я могу поискать, – участливо смотрит на меня Тол, - ну так что, искать?
- Не, устаревшая, мне, пожалуй, не поможет, - подумав, ответил я, - это ж я все равно должен весь код изучить, чтобы понять, где ей можно доверять, а где нет.
- На самом деле, я не уверен, что тебе сильно поможет даже новая, и поэтому я тебе и говорю: код – лучшая документация! – терпеливо разъясняет Тол, - Она _всегда_ актуальна, и _никогда_ не устаревает, помимо того, что более информативна чем диаграмма классов, конечно.
- Хорошо, я понял, а может, ты мне еще объяснишь, вот в этом месте как работает…
- Нет. Это ты мне объяснишь, после того, как прочтешь. Мне как раз надо скоро будет туда правки вносить. Давай, парень, я не тебя рассчитываю. Иди - читай код.
- Хорошо, Тол, – обреченно сказал я, и пошел читать код.

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

- Слушай, Влад, не поможешь, объясни, как работает вот эта подсистема?
Я вяло поднимаю глаза на коллегу, вижу безнадежность в его взгляде, тяжело вздыхаю, и решаю ему помочь. Хоть я ничего и не понимаю в этой подсистеме – так, рядом проходил.
- Хорошо, смотри, – тут я «вслепую», без всяких класс-браузеров, продираюсь к «правильному» файлу, открываю его, и поиском нахожу нужный метод, - видишь, вот здесь что происходит?

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

- Вот, видишь, как все просто, - заканчиваю я. И к своему чудовищному удивлению добавляю, то, что надо сказать, потому что это правда:
- А вообще - читай код. Код – лучшая документация. Ты вот думаешь, я разбираюсь в этой подсистеме? Нет, я этот код вижу в первый раз, так же как и ты.
- Но этот код совершенно не документирован! Диаграммы хоть какие-нибудь бы!
- Смотри, - говорю я улыбаясь, окончательно осознавая, что Тол в очередной раз, как и всегда, оказался прав, - вот я запускаю Rational Rose, где у меня всосана вся наша система в режиме reverse engineering, и бросаю на чистый лист эти пять классов. Видишь? Вот тебе свежая, актуальная диаграмма. Какой смысл тратить усилия на документирование того, что устаревает за год, и может быть в любой момент восстановлено за пару минут? Если она тебе сильно поможет, я сейчас ее тебе распечатаю. Распечатать?
- Да нет, пожалуй, - задумчиво отвечает коллега, рассматривая диаграмму. Ясности она не добавляла.
- Вот. Диаграммы не стоят ничего, ценны мыслительные процессы, происходящие у тебя в голове в процессе их составления. Поэтому я и говорю: код – лучшая документация. Читай код.

Разумеется, Тол хотел мне показать не только и не столько практическую бесполезность проектной документации, как это могло показалось на первый взгляд. Философия "код - лучшая документация" дает гораздо большее, чем отсутствие документации. Это необходимое ограничение, только приняв и осознав которое, и в результате - рассчитывая только на свои силы, понимая - что код - основной источник информации, его нельзя боятся, с ним надо столкнуться в лоб, и этого не получится избежать, обойти, и перепрыгнуть, - можно достичь мастерства в reverse engineering и вообще понять, что это такое.

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

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

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

Comments:


Page 1 of 3
<<[1] [2] [3] >>
Anatoli Stoyanovski
skyer at 2009-05-03 13:26 (UTC) (Link)
Какой парадоксальный вывод - нацеленность компании на поддержку документации в актуальном состоянии означает признание того, что разработчики не умеют ориентироваться в собственном продукте.
Gaperton
gaperton at 2009-05-03 13:48 (UTC) (Link)
А это так и есть на самом деле. Так же как и большие усилия на документацию для администраторов свидетельствуют о неудобном и неинтуитивном админском интерфейсе, например. Сдвиг акцента на документацию с основной деятельности - всегда дурно пахнет. Больший объем документации не решает проблем, он их усугубляет, и часто является симптомом. Собственно, я добавил к статье:

"Второй аспект этой философии - понимание того, что код пишется в первую очередь для человека, и только во вторую - для компьютера. Это приводит нас к идеям, близким по духу к literate programming, за которое ратует Кнут."
zhiraffanjut
zhiraffanjut at 2009-05-03 16:08 (UTC) (Link)
Именно поэтому было очень удобно работать в Together/J, ибо там код и документация были неразделимы Ж-) Жаль что её больше нет.
Gaperton
gaperton at 2009-05-03 17:19 (UTC) (Link)
Ой, не верю я в эти штуки-дрюки. :) Together у нас помню не пошел - он не умел избирательно скрывать методы и данные классов. А их в центральных классах у нас было, гхм, порядка сотни. Представляешь, как весело это на диаграмме смотрится?

Rational Rose - умеет. В ней реально любую диаграмму нарисовать за пару минут. Я ее использовал для подготовки документов, когда требовалось. Бросил нужные классы, они сами связались стрелками, выделил, вставил в документ, добавил описание проблемы, решения, rationale, и отослал почтой. Документ нужен для design review, и после совещаний идет фтопку.
Майк
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 своих решений у знающих людей.
- Менеджерам - следить, чтобы в компании было как минимум два человека, занимающихся каждой подсистемой.
(Deleted comment)
vp at 2009-05-03 18:06 (UTC) (Link)
Тут явно должен быть какой-то разумный компромисс. В другой крайности бурно развивается "синдром генерального конструктора", когда основные идеи находятся у автора в голове, и они настолько сложны для передачи кому-то, либо эта передача оценивается настолько дорого, что контора начинает жить мыслью "Только бы он не помер".
ЗЫ Мой подход в этом деле - это вставлять куски документации прямо в код, в модули, с обильными комментариями. Если делаем, к примеру, парсер протокола, то в коде всегда будут куски примеров протокола с расшифровками и т.п. Я думаю, это подход достаточно оправданный, плюс пишется все ОДНОВРЕМЕННО с кодом (!), плюс ничто никуда не потеряется.
Gaperton
gaperton at 2009-05-03 18:13 (UTC) (Link)
Это и есть примерно то, о чем я говорю.
b00ter
b00ter at 2009-05-03 19:39 (UTC) (Link)
Хорошая притча. Надо бы ее студентам рассказывать в обязательном порядке.
sardonyx13
sardonyx13 at 2009-05-03 20:09 (UTC) (Link)
Зря отказался от диаграмки 5-летней давности. В ней можно было бы увидеть идеи которые закладывались изначально, а не привнесены потом (начальные требования в конце концов). Особенно если успело погадить потом очень много народа.
P.S. при этом никто не отменяет критического отношения к ней.

P.P.S. вот не удержался и отписался всё-таки :-)

Gaperton
gaperton at 2009-05-03 20:27 (UTC) (Link)
А что мне на нее смотреть, на диаграмму ITL пятилетней давности? :) Я его и так вдоль и поперек разобрал по коду, включая дизайн и эволюцию. Реликтовые отложения - их по коду гораздо лучше видно. :)

Сначала не было операторов, были толко символы. Потом появлились простые (векторные) операторы и спреды. Потом кто-то придумал делать из них деревья, применяя один на другой. Потом, всех достали тормоза и большой расход памяти, и Мэтт придумал степовые операторы. Потом, Брайан придумал, что степовые операторы можно делать COM-операторами. Вот и вся цепочка, собственно. Не считая мелочей - например, как Мэтт придумал нагнуть ITL, чтобы заработали торговые системы, и как Брайан хитро придумал все захачить, чтобы получились операторы с переменной временной шкалой. За что ему отдельное спасибо - трахался полгода, переписывая его P&F. Никак не хотела работать, сволочь, пока не воспроизвел все глюканы Брайановского P&F один-в-один в своем.

Вот и вся дизайн-эволюция :). Впрочем, это ничто по сравнению с увлекательной историей T&S и BB :).
Андрій Тихонов
atykhonov at 2009-05-03 20:52 (UTC) (Link)
Спасибо большое за статью! Очень познавательно. Скажите пожалуйста, а можно ли её скопировать (возможно с переводом) в свой блог с посылкой на оригинал?
Gaperton
gaperton at 2009-05-03 21:08 (UTC) (Link)
Конечно. Только пожалуйста, дайте мне ссылку на перевод, чтобы я смог посмотреть. Возможно, я попрошу Вас дать ссылку на оригинал на сайте software people, когда статья там появится, а не на блог.
9000 at 2009-05-03 20:59 (UTC) (Link)
Чего мне вечно не хватает при приходе в новый большой проект — это описания системы "с высоты птичьего полёта". Что в ней есть и зачем.

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

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

А дальше, конечно, начинает рулить код, желательно — здраво откомментированный и с понятными примерами использования (т.е. когда понятно, какую примерно задачу решал использовавший).
Źmicier Łapcönak / Зьміцер Лапцёнак
zmila at 2009-05-05 09:07 (UTC) (Link)
во! дельный комент.
похожее хотел и я написать.
all is full of love
tired_dusk at 2009-05-03 22:33 (UTC) (Link)
не имею никакого отношения к программированию, но тем не менее отмечу: замечательную аналогию подобрали с дзеном.
здесь аналогия работает не только относительно процедуры постановки и решения проблем. весь подход, который вы описали, очень напоминает классические коаны о том, что тот кто смотрит на окружающий мир, не нуждается в учебниках, его документирующих.
но это к делу, я так понимаю, не особо относиться.
посему - просто примите благодарность за текст
Gaperton
gaperton at 2009-05-08 22:35 (UTC) (Link)
Это очень даже относится к делу.

Вы показали мне неожиданную грань, которую я не осознавал, то, что я сам в тексте не видел в момент написания. Я сразу вспомнил коан "что ты делаешь - что ты говоришь!". :)

Вы, не будучи программистом, смогли меж тем в отличии от 90% "специалистов" прочитать что написано. Вы, безусловно, понимаете дзен. Спасибо.
fireox
fireox at 2009-05-03 22:50 (UTC) (Link)
идея правильная. один момент: документация часто выражает намерение, а код - готовую реализацию, которая может не соответствовать намерению. вывод - надо аккуратно и много коментировать код, ибо сверять код с документацией геморойно, а когда коментарий не соответствует строке кода после него - это сразу в глаза бросается
smalgin at 2009-05-03 23:50 (UTC) (Link)
Так оно по жизни и бывает, чего там.

Документашки нужны для design review, а потом они стремительно устаревают, если не попадают в public API. Но тогда их поддержкой занимаются специально отведенные люди.

Gaperton
gaperton at 2009-05-04 00:04 (UTC) (Link)
Вот. Именно так.
Lost In Paradox
localstorm at 2009-05-04 04:04 (UTC) (Link)
Да, очень разумно. Пару раз участвовал в очень крупных проектах -- везде то же самое. Напервом этапе -- тропинки и хитрые проводники. Без них никуда.
Алексей Кирюшкин
malgarr at 2009-05-04 04:29 (UTC) (Link)
>С этого момента я начал внимательно наблюдать за Толом, изучать его решения и подход, и твердо решил разобраться, что же это такое за неуловимая штука, которой я не понимаю.

оч.интересно

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

здрасте. И причем здесь архитектор? Разобраться, восстановить, развить и продолжить - это именно квалифицированный инженер-программист. У меня например именно это получается довольно неплохо - внести изменения в готовую систему именно по ходу мысли автора, а не поперек её. Но когда доходило дело до разработки своей системы, с нуля, на пустом месте (т.е. именно до работы архитектора) - получалась... скажем так - не совсем конфекта. Так что архитектора - архитектором делает что-то другое.
vp at 2009-05-04 05:02 (UTC) (Link)
здрасте. И причем здесь архитектор? Разобраться, восстановить, развить и продолжить - это именно квалифицированный инженер-программист. У меня например именно это получается довольно неплохо - внести изменения в готовую систему именно по ходу мысли автора

Смотря "изменения" или "доработку". Если система сконструирована, с учтом всех жаб, жуков и змей в голове архитектора, а потом он умер, и на его место взяли другого, то тут задача - полный набор всех ужасов, и это именно кошмар для архитектора, второго.
Колесников Михаил
kolemik at 2009-05-04 04:50 (UTC) (Link)

Так не хватает такого учителя!

Где раздают? :)

Вот эта фраза "эффективно решить свою задачу в рамках чужого подхода к проблеме" - определяет мою личную стратегию программирования с использование чужих API. Но сколько я к ней шёл... А если б мне сразу сказали...
Previous Entry  Next Entry