?

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 2
<<[1] [2] >>
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. Но сколько я к ней шёл... А если б мне сразу сказали...
lkinar
lkinar at 2009-05-04 06:32 (UTC) (Link)
Отличная статья, прекрасно иллюстрирующая фразу: "Опыт - лучший учитель". Спасибо.
Денис Бесков
beskov at 2009-05-04 07:44 (UTC) (Link)
Расскажите пожалуйста, какие действия вы собираетесь предпринимать в своей работе на основе этой статьи?
mr_flj
mr_flj at 2009-05-04 07:37 (UTC) (Link)
В точку. Афигенная статья.
Денис Бесков
beskov at 2009-05-04 07:44 (UTC) (Link)
Расскажите пожалуйста, какие действия вы собираетесь предпринимать в своей работе на основе этой статьи?
Sebastian
pufpuf at 2009-05-04 09:13 (UTC) (Link)
Нужно заметить, что такой подход хорошо работает, когда хорошо знаком с системой. Или же, во всяком случае, когда система спроектированна по одному из шаблонов, с которым доводилось сталкиваться. В общем, когда есть общая картина.
Если же общей картины нет, то составить ее -- в этом самая большая трудность. И, как верно замечено, в этом и состоит талант реверс инженера. Поэтому и важны комментарии в коде: чтобы не заставлять каждого быть РИ. Впрочем, я бы не говорил, что набор умений архитектора включает набор умений реверс инженера и наоборот. Лучше всего, конечно, когда есть и то, и то. :)

Так что код -- это самая лучшая документация (особенно, если выразительные способности языка позволяют приблизить его к языку предметной области), но про комментарии как обязательную часть кода тоже забывать не нужно.
xazuphu2 at 2009-05-04 14:44 (UTC) (Link)
+1
заболеет (устанет) Tal Korin
или переманят троих-пятерых ведущих програмеров - и пиздец системе.
пока наймут новых, пока те буквально за 3-5 месяцев начнут правильно реверс инженерить...


короче назови тему "как обеспесить себе Job Security"
a_zudin
a_zudin at 2009-05-04 17:10 (UTC) (Link)
Такой подход эффективен в долгосрочных масштабных проектах, которые длятся десятилетиями, и выполняются группой единомышленников, полностью уверенных друг в друге. Т.е., уверенных в том, что никто из основных разработчиков из проекта не уйдет, а при его расширении у новых участников будет время “врасти” в код при помощи стариков. Если эти условия соблюдены, экономия денег на разработке может быть колоссальной. Вдесятером можно сделать столько, что при других подходах потребовалось бы сто человек.

И еще, умение читать чужой код, и сразу видеть за ним алгоритм и концепцию, характерно для программистов старой школы, которые писали программы еще во времена перфокарт. Процесс получения результата после изменения кода тогда занимал не минуты, как сейчас, а часы или даже дни. Любая ошибка сильно удлиняла время разработки. Поэтому и код тщательно анализировался, и алгоритмы прокручивались вручную.
iash4 at 2009-05-11 17:28 (UTC) (Link)
1. Такой подход эффективен в любых проектах
2. группа единомышленников? ну это смешно особенно если говорить о больших проектах, может только небольших, иначе людей много, задач много, идей тоже много.
3. Старая школа, перфокарты?... сколько людей мне говорили что им не хватает времени подумать... ужос просто... а когда в каждом случае детально разбирались, то получался простой результат - люди просто не хотели думать (ни долго ни коротко...) и делали первое что приходило на ум, при этом настолько сложно, что просто дух захватывало... а что самое неправильное, каждый считал что он делает единственно правильное решение... хотя вокруг возможных вариантов было бесконечно много...
(Deleted comment)
Źmicier Łapcönak / Зьміцер Лапцёнак
zmila at 2009-05-05 09:03 (UTC) (Link)
пару замечаний:
(1) не раскрыт вопрос "как ориентироваться в мегабайтах исходников". в коментах Вы отвечали на это дважды, хорошо бы добавить в статью эти ответы (или ссылки) - так будет убедительнее. (ибо злобный наивный оппонент скажет: вы за 10-20 лет просто выучили код наизусть

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

ну и (3) существуют разные люди, с очень различными темпераментами и способностями. у кого-то огромная память, он помнит наизусть названия методов в сотне классов, другой постояннно использует поиск. у одного развито абстрактное мышление, он раз глянул и в голове сложилась картинка. другому надо постоянно рисовать квадратики и стрелочки.
не каждый может быть гениальным архитектором, но ведь и гениальный архитектор не всё сам кодит, он должен как-то передать идеи, дизайн другим сотрудникам.
хорошо бы в статье это отразить.
Cobalt
cobalt747 at 2009-05-14 14:24 (UTC) (Link)
Ctrl+F очень помогает ;-)
плюс, если работают профи, то они называют всё по смыслу.
Если же работают не профи, время врубания в смысл "несколько" увеличивается.
Николай (gorba) Горбунов
gorba at 2009-05-07 06:13 (UTC) (Link)
Охохонюшки.

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

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

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

У меня есть статистика проектов, на которых была поставлена поддержка управления требованиями (когда вся работа строилась вокруг "живого" документа - единой точки сборки требований), и на которых не была. Объем реворка реально отличается в 2+ раза.
Gaperton
gaperton at 2009-05-07 11:46 (UTC) (Link)
> К хорошему продукту дока не нужна, это правда, но чтобы его сделать, нужно где-то записывать, о чем договорились делающие его люди. Иначе все сделают кто в лес, кто по дрова - именно это везде и происходит.

С этим никто и не спорит. Когда система создается, как нетрудно заметить, кода просто пока еще нет. :)

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

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

Поэтому разумные люди вместо попыток пИсать против ветра, поддерживая доки в синхронном состоянии, просто генерируют доки из кода автоматически, и все. Не считая Common Design Principles, конечно - это должно быть описано так же, как и Coding Standard.

> мало того, код читать может только девелопер.

И даже более того - и писать его может тоже только девелопер :).

>Управлять требованиями на основе тикетов в багтрекере - это вообще содомия.

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

> У меня есть статистика проектов, на которых была поставлена поддержка управления требованиями (когда вся работа строилась вокруг "живого" документа - единой точки сборки требований), и на которых не была. Объем реворка реально отличается в 2+ раза.

Вообще-то я про управление требованиями ничего не говорил, я говорил про документацию относящуюся к коду. Однако, несмотря на то, что это оффтоп, почему бы Вам не привести столь интересную статистику. Интересно же.
yoeme at 2009-05-10 05:49 (UTC) (Link)
Ну "читай код" - это банальность, так на любом крупном проекте происходит, другой вопрос, что знания об архитектуры системы быть должны, сам говоришь, что они тебе здорово помогли.

Лекции не должны описывать детали, детали это код, они должны описывать концепции, механизмы. Сначала ты их послушаешь, а потом ты их увидишь в коде. Естественно можно и без них, но согласитесь лучше иметь подсказки, чем не иметь их вообще.
Gaperton
gaperton at 2009-05-10 10:10 (UTC) (Link)
"Читай код" - это не большая банальность, чем "знания об архитектуры системы быть должны". И кстати, эта "банальность" вызвала почему-то удивительно много шума.

"Естественно можно и без них, но согласитесь лучше иметь подсказки, чем не иметь их вообще."
- Мне надо еще раз согласиться с тем, что я сам и так говорю? :) Хорошо, соглашаюсь. :)
grez_ua
grez_ua at 2009-05-10 20:02 (UTC) (Link)
Спасибо за статью. Оч познавательно.
Оказуеться процедура разбирания того, как работает код, называеться "реверс енжениренгом". И оказуеться для этого нынче нужны специальные навыки...
А я то наивный думал, что любой программист, и так в состоянии его зделать.
Gaperton
gaperton at 2009-05-10 20:12 (UTC) (Link)
> И оказуеться для этого нынче нужны специальные навыки...
> А я то наивный думал, что любой программист, и так в состоянии его зделать.

Нет, что Вы, какие навыки. Конечно каждый умеет это сразу от рождения. Так же, как и писать программы на С++.

ЗЫ: Не надо в таком тоне комментировать. Терпения у меня на вас уже не осталось, вышло все. Есть что сказать - говорите нормально. Если мне _покажется_ в вашем посте хоть _малейший_ переход на личности - удалю коммент и забаню, и все. Да, я понимаю, что пока перехода наличности нет, а есть только провоцирующий пост - но вы движетесь в этом направлении.
Ignoramus Alex
_iga at 2009-05-11 08:56 (UTC) (Link)
Умение читать и понимать код - это замечательно. Ещё замечательнее - умение понимать систему без кода.

Но дело-то в том, что программисты не любят (громче: ненавидят!) писать хоть какую-то документацию, даже документацию для конечного пользователя или техподдержки.
Previous Entry  Next Entry