?

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 мегабайт основных исходников, не считая свистулек, прибамбасов, разного рода служебных и системных штук, по размеру почему-то превосходящих размер основных исходников.

moreCollapse )

Comments:


Page 2 of 3
<<[1] [2] [3] >>
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. Старая школа, перфокарты?... сколько людей мне говорили что им не хватает времени подумать... ужос просто... а когда в каждом случае детально разбирались, то получался простой результат - люди просто не хотели думать (ни долго ни коротко...) и делали первое что приходило на ум, при этом настолько сложно, что просто дух захватывало... а что самое неправильное, каждый считал что он делает единственно правильное решение... хотя вокруг возможных вариантов было бесконечно много...
Ź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 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)
Умение читать и понимать код - это замечательно. Ещё замечательнее - умение понимать систему без кода.

Но дело-то в том, что программисты не любят (громче: ненавидят!) писать хоть какую-то документацию, даже документацию для конечного пользователя или техподдержки.
Николай Горбунов
gorba at 2009-05-14 08:49 (UTC) (Link)
Кстати - читая Cranky PM, наткнулся на вот эту статью. По-моему, очень хороший полярный взгляд
bananos
bananos at 2009-05-29 10:30 (UTC) (Link)
отличный пост, дал ссылку у себя
Васятка
babr at 2009-05-29 10:45 (UTC) (Link)
хехе
узнаю

меня именно так и учили. жестко, но эффективно. щаз я сам всех так учу.
Lev Walkin
lionet at 2009-06-08 14:57 (UTC) (Link)
I was not able to get across to any of
my students this love for that kind of
scholarship—reading source material.
I was a complete failure at passing this
on to the people that I worked with the
most closely.


Donald Knuth // Communications of the ACM, July 2008, Vol. 51, No. 7, p. 36.
ext_134706 at 2009-07-29 12:11 (UTC) (Link)
Отлично.

Основная заслуга Тола в том, что код системы через 10 лет разработки остался читабельным :-)
Previous Entry  Next Entry