Организаторы SoftwarePeople попросили меня написать какую-нибудь статью для сайта. Я собственно, написал нечто, и опубликовал сначала в своем блоге. Эта совершенно безобидная статья вызвала почему-то кучу шума. Топ яндекса, и концы — заломилась толпа, и какого-то дуба половина ЖЖ меня теперь обвиняет в том, что я "проповедую" отказ от любой документации во всех ее проявлениях — и что такой подход — враг всему "промышленному". С ума спятить. Причем, переубедить людей, и объяснить им, что статья вообще не о том, и что я ничего не проповедую — практически невозможно. Короче, вот, читайте .

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, за которое ратует Кнут. Как может человек, который не в состоянии внятно выразить свою мысль на неформальном, знакомом ему с детства естественном языке, выразить эту же мысль понятным образом на существенно более формальном языке программирования? Но это уже другая история.

Здравствуйте, Gaperton, Вы писали:

Добавлю. Код конечно лучшая документация, но он не отвечает на один очень важный вопрос: "Почему сделано именно так, а не иначе".
Вот это все-таки нужно документировать отдельно.

Здравствуйте, Eye of Hell, Вы писали:

EOH>Тол вообще не застрахован от того, что в самый ответственный момент его заклинание просто не сработает. Что он будет делать тогда? Ну и скорее всего существует некий объем кода по достижении которого заклинания Тола перестанут работать просто потому, что у него не хватит маны. Сто, сто пятьдесят, двести мегабайт — рано или поздно Тол попробует легко разобраться с наследованием в хитром метаклассе и его заклинание не сработает.

Да и вообще, вот заболеет он завтра менингитом и станет идиотом — никто от этого не застрахован.

EOH>ИМХО и только ИМХО — магия штука хорошая, но для разработки софта инженерный процесс как-то спокойнее. И людям его передавать проще, и завязки на колдунов нету. Тесты опять же, метрики.

Беда в том, что если вы строите процесс, который не зависит от личности, то все личности в вашем проекте становятся взаимозаменяемыми. А значит, вам всё равно, что чувак типа Тола, что Вася Пупкин с опытом 3 года, обученный процессу. Т.е., фактически, вы делаете так, что людям типа Тола в вашем проекте нет места. А тем самым, лишаете себя возможности разрабатывать софтварий, в котором без людей такого класса просто не обойтись.

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

Не айс. Использование магии в худшем смысле этого слова для решения практических задач. На некоем объеме проекта магия откажет Толу и он не сможет в уме перейти от кода к архитектуре. Тол крут, у него достаточно маны чтобы проделывать этот фокус с 50 мегабайтным проектом. Но магия отличается от инженерного дела одним маленьким, незначительным нюансом — она не гарантирует повторения результата при одинаковых начальных условиях. Тол вообще не застрахован от того, что в самый ответственный момент его заклинание просто не сработает. Что он будет делать тогда? Ну и скорее всего существует некий объем кода по достижении которого заклинания Тола перестанут работать просто потому, что у него не хватит маны. Сто, сто пятьдесят, двести мегабайт — рано или поздно Тол попробует легко разобраться с наследованием в хитром метаклассе и его заклинание не сработает.

ИМХО и только ИМХО — магия штука хорошая, но для разработки софта инженерный процесс как-то спокойнее. И людям его передавать проще, и завязки на колдунов нету. Тесты опять же, метрики.

Здравствуйте, Gaperton, Вы писали:

G>>>>Добавлю. Код конечно лучшая документация, но он не отвечает на один очень важный вопрос: "Почему сделано именно так, а не иначе".
G>>>Точно. Очень, очень своевременный вопрос. На этот вопрос отвечают комментарии к коммитам кода в VCS.
B>>тут засада. сырцы были перелиты из одного репозитория в другой не раз.
B>>и там уже давно первым стоит билд-мастер. и после несколько изменений для последних релизов.
B>>так что причину к-л решения найти можно только у старых в памяти.
G>Импортировать в репозиторий можно с историей коммитов.

угу... приходите в гости, я вас с деплоймент-инженером сведу, и вы ему расскажете, как надо переливать сырцы.
а он вам ответит, что в сырцах стоит не его имя, а прошлый спицилист. и репозиторий меняли уже 3 раза за прошедшие 4 года.

пошел обратно к статье.

Когда я заступил на работу в компанию CQG в конце 1999 года, у меня уже был, как мне казалось, достаточно большой опыт в разработке ПО – три года создания корпоративных приложений БД под заказ. Мне уже казалось, что я очень много знаю и умею, и я был крайне самоуверен.

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

Меня потряс объем приложения – почти 50 мегабайт основных исходников...разрабатывавшийся десятками людей на тот момент на протяжении десяти лет.

что же тут удивительного? все на месте. 5 мег за год — нормальный такой выход для даже маленькой команды. а уж для серьезного проекта...

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

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

...Тол, — Я тебе говорю – я не знаю, и поэтому я должен сам почитать код, чтобы ответить на твой вопрос. Поэтому, я открываю код.

дословно моя беседа с индусами.
но система была спроектирована так не потому, что так был написан код. а код был написан так, как была спроектирована данная система.

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

far. alt+f7

— Тебе, чтобы читать код, нужна документация? Прости – какая?

совершенно согласен. для чтения кода дока не нужна. для понимания смысла написания так как есть (почему сделано так, а не иначе) — нужна.

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

— Ну, там, диаграммы классов, например.

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

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

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

...рассматривая диаграмму. Ясности она не добавляла.

выше. про полезность диаграммы классов для своего решения.

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

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

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

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

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

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

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

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

Здравствуйте, genre, Вы писали:

G>Не нужно придавать программированию сакральности и таинства. Детальное следование регламентам и документированным процедурам в промышленном программирование первоочередная необходимость.

Нужно придавать и сокральность и таинство. Программирование это не работа на конвейере, но и не чистое изобретательство конвейера. Это одновременное изобретение конвейера и работа на нём. Мы создаём станок и тут же пилим на нём детали. Любая крайность, только работа на конвейере или только изобретательство, тут же дают сильный обратный эффект.

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

Дело не в гениях. Разброд и шатания начинаются тогда, когда эти гении создают только инструменты и только ради создания инструментов. Куча ненужных и непонятных тулов, заводы и фабрики по производству гвоздя (одного!) и т.п. Это не имеет отношения к гениальности, это косяк в управлении. Задача менеджера максимально утилизировать имеющиеся в наличии ресурсы, а не побрить их под самую плохую, но зато под одну гребёнку.

G>Взаимозаменяемость это гарантия того, что шоустоппер на live сервере каждая секунда простоя которого стоит бешеных денег будет пофикшен мгновенно, а не когда гуру вернется из отпуска.

Думаю, что без гуру шоустоппер на live вообще бы не появился. Возьми стотыщь индусов и пусть они напишут аналог live. Не напишут. Никакая взаимозаменяемость не поможет. Нельзя взять десять мозгов с IQ равным 20, сложить их и получить IQ равный 200. В данном случае работет функция Max, а не Add.

Здравствуйте, Mr.Cat, Вы писали:

G>>Ну, другими словами, абстрагируясь — чтобы читать код, надо знать и понимать Common Design Principles, в соответствии с которым он написан. Это нормально, фокусом не является, и это навык обычного программиста.
MC>+1. Вот, пожалуй, эти "Common Design Principles" и должны быть задокументированы.
Пожалуй, да. Кстати, я кажется даже знаю хороший пример, как это делается, дающий понимание, как это должно выглядеть.
http://erlang.org/doc/design_principles/part_frame.html

G>>Одно дело сориентироваться в чужом коде, и закрыть багу, и другое — в сжатые сроки восстановить дизайн подсистемы по коду, и "понять" ее — вот на это способен, мне кажется, уже не каждый средний программист. Или я плохо думаю о среднем программисте?
MC>Думаю, понять "как?" — это бывает сложно, но возможно. А вот понять, "почему?"...

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

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

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

Да, умение читать код очень важно.
Но и "картинки" тоже весьма полезны.
Просто они должны быть сделаны людьми и для людей, а не сгенерировыны тулом.
Сгенерировыны тулом картинки самые бесполезные.

На мой взляд, картинки полезны в 2 ситуациях:

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

Здравствуйте, Gaperton, Вы писали:

G>

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

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

Здравствуйте, Mr.Cat, Вы писали:

MC>

Здравствуйте, Gaperton, Вы писали:
G>Ну, другими словами, абстрагируясь — чтобы читать код, надо знать и понимать Common Design Principles, в соответствии с которым он написан. Это нормально, фокусом не является, и это навык обычного программиста.
+1. Вот, пожалуй, эти "Common Design Principles" и должны быть задокументированы.

G>Одно дело сориентироваться в чужом коде, и закрыть багу, и другое — в сжатые сроки восстановить дизайн подсистемы по коду, и "понять" ее — вот на это способен, мне кажется, уже не каждый средний программист. Или я плохо думаю о среднем программисте?
Думаю, понять "как?" — это бывает сложно, но возможно. А вот понять, "почему?"...

Здравствуйте, Gaperton, Вы писали:

G>Видишь ли, с одной стороны, средний программист обычно входит в ступор, пытаясь читать код CQG. Не потому, что он плохо написан — просто он зараза очень большой, и чтобы его читать, надо, скажем так, довольно много знать вещей на самом деле, специфичных для CQG. Скажем, наследование от Messenger означает, что класс умеет отправлять и принимать асинхронные сообщения — просто как пример. Ну, другими словами, абстрагируясь — чтобы читать код, надо знать и понимать Common Design Principles, в соответствии с которым он написан. Это нормально, фокусом не является, и это навык обычного программиста.

И все равно у меня тут есть, с чем не согласиться. Большой и даже очень большой, это не оправдание. Обычно, что-то большое, состоит из небольших подсистем. Подсистемы тоже внутри состоят из небольших кусков. Там в статье было упоминание о 50Мб исходников. Сам я учавствовал в проекте, наверное чуть меньшем, но мы как-то с ребятами считали, там было около 40Мб основного кода. Плюс бинарники сторонних вендоров. Для примера, подсистема мейнтейнером, которой я был, была одна из самых крупных, весила около 10Мб. Она же в свою очередь делилась на несколько подсистем. Кстати, история примерно похожа на твою, всей системе, тоже более 10 лет и живет она до сих пор благодоря своей очень гибкой, простой и прозрачной архитектуре. И был у меня такой же учитель-наставник Только учил он меня немного другому, тоже вроде банальной вещи, KISS, что самое простое рещение и есть самое правильное. Только я понимал это, но решения мои все равно громоздкие получались, только спустя кажется год я начал выдавать лаконичные, простые и красивые решения Что-то я отклонился от общей темы, ах да, время для новых сотрудников тратилось только в начале, чтобы вникнуть в архитектуру, понять, что и где находится, хотя бы примерно и до первого реального коммита проходило 3 мес, как раз к этому моменту у нас кончался испытательный срок А дальше уже, разобраться, что и где, внести изменения в какой-либо подсистеме все могли без проблем, и скорее всего это благодоря банальной KISS.

G>С другой стороны, уметь "читать код" можно тоже по разному — в этом деле есть разные уровни. Одно дело сориентироваться в чужом коде, и закрыть багу, и другое — в сжатые сроки восстановить дизайн подсистемы по коду, и "понять" ее — вот на это способен, мне кажется, уже не каждый средний программист. Или я плохо думаю о среднем программисте?

Ну в этом плане да, согласен.

Здравствуйте, IT, Вы писали:

G>>и другое — в сжатые сроки восстановить дизайн подсистемы по коду, и "понять" ее — вот на это способен, мне кажется, уже не каждый средний программист. Или я плохо думаю о среднем программисте?

IT>Это сильно зависит от того насколько программист знаком с исследуемой темой. Думаю, будет очень легко развеять ореол божественности, если попросить Тола Корина проделать тоже самое с исходниками другой незнакомой ему области. Можно, например, декомпилировать Linq 2 SQL и попросить восстановить за пять минут дизайн любой из его подсистем по коду.

Ты, вообще, совершенно прав — вопрос только в том, зачем развеивать ореол божественности.

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

И что показывает практика чтения этого текста? Две категории людей. Первая — (разумеется) — говорит, ну да, что тут собственно такого, это очевидно. Вторая говорит — "херня!" . Прям как я в 99 году .

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

IT>В остальном со всем согласен

Дык . "Просветленных" много. Это, к счастью, не редкость. Текст вообще для начинающих, да еще — лакмусовая бумажка для менеджеров. И тех, кто читать "что написано" не умеет — фильтрует охренительно. Статистика d ,kjut поразительная, кстати. Из тех, кто умеет писать — менее 10% умеют читать "что написано".

Знаешь, больше всего мне понравился коммент человека с членом в аватаре. Он истинно глубоко понимает дзен.

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

Здравствуйте, Eye of Hell, Вы писали:

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

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

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

Здравствуйте, Eye of Hell, Вы писали:

EOH>Я на самом деле зря на это ответил, что действия Тола тоже можно комментировать. Я с Вами согласен, что код гуру уровня Тола просто устроен, логично структурирован и литературен. Переформулирую — техпроцесс и документация не приравнивают Тола к Васе. Они не накладывают на Тола рамки . Техпроцесс сам по себе — это средства контроля а не направляющая рельса. Не вижу чем документация в коде помешает Толу писать такой же просто устроеный, логично структурированный и литературный код. А вот Васин сложный, нелогично структурированный и н.лр-й. код такой техпроцесс вполне сможет выправить, так чтобы потом не понадобилась магия при его чтении. Мы же не можем одних Толов в компанию нанять?

Комментарии есть неотъемлемая часть кода, и часть дисциплины написания кода. Я полагаю это до такой степени очевидным, что даже не стал акцентировать на этом внимание. Более того, код может быть "литературным" и понятным, не содержа и единого комментария, и напоминать тарелку со спагетти, даже если он "заправлен" комментариями на 50% как паста в американском ресторане. Так что правильный акцент — не "код должен содержать комментарии", а "код должен быть литературным", ибо "пишется в первую очередь для человека". Этот акцент в статье есть.

То же, что очевидным не является, и что часто игнорируется, например — важность комментариев к коммитам, и наличие процедур контроля вроде code review чтобы все перечисленное заработало на практике, я в дискуссии обозначил отдельно.

Здравствуйте, Gaperton, Вы писали:

SED>>Но если честно, в том виде, как эта статья есть — молодым показывать боюсь... ой как боюсь... Что то есть неуловимое для молодых и не испорченных умов. Это что то, на мой взгляд, и заставило большу толпу народа "нападать" на вас с обвинениями в том, что вы проповедуете отказ от кода. Выразить пока в словах не могу, но как только мысль сформируется — я поделюсь
G>Кстати, это свойство можно полезно эксплуатировать. Статью можно использовать как тест при приеме на работу
Что-то ты Макиавелли перечитался

Здравствуйте, yumi, Вы писали:

Y>Здравствуйте, Gaperton, Вы писали:

G>>

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

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

Для мотивации начинающих статья — самое оно, и отсыл к "высшей ступени" — это то, что надо.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Gaperton, Вы писали:

G>Организаторы SoftwarePeople попросили меня написать какую-нибудь статью для сайта. Я собственно, написал нечто, и опубликовал сначала в своем блоге.
О!, статья перебралась сюда Дождался (не хотелось там писать).

Хочу поделиться отличной статьей (маленькой, но толковой) о том как же вести проектную документацию.
Если кратко, то документировать нужно:
1) требования
2) высокоуровневая архитектура (aka CDP)
3) история принятия решений

Об этом же говорит Гапертон, но выделить эти пункты довольно таки сложно .


СУВ, Aikin

Здравствуйте, yumi, Вы писали:

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

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

Здравствуйте, genre, Вы писали:

G>Добавлю. Код конечно лучшая документация, но он не отвечает на один очень важный вопрос: "Почему сделано именно так, а не иначе".
G>Вот это все-таки нужно документировать отдельно.

Точно. Очень, очень своевременный вопрос. На этот вопрос отвечают комментарии к коммитам кода в VCS. В этих комментариях помимо описания rationale (кстати, и поэтому тоже многофайловые "транзакционные" коммиты рулят, когда коммитится только работоспособный код — вы видите связь разрозненных правок) может быть ссылка на дефект, фичреквест, или просто страничку в вики, где висит дизайн-документ, по реализации которого сейчас делается коммит.

И все. Следить на актуальностью документов при такой схеме не надо — все сделает режим просмотра файлов annotate (смотреть файл в веб морде репозитория контроля версий), где можно определить автора каждой строки и коммит, которой она добавлена, соответственно — в один клик почитать ее rationale, и в два клика — добраться до мегадизайна, описания дефекта, или фичи, если они есть.

Настоятельно рекомендую. Советы лучших собаководов, буквально .

Здравствуйте, Gaperton, Вы писали:

G>>Добавлю. Код конечно лучшая документация, но он не отвечает на один очень важный вопрос: "Почему сделано именно так, а не иначе".
G>Точно. Очень, очень своевременный вопрос. На этот вопрос отвечают комментарии к коммитам кода в VCS.

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

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

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

Здравствуйте, Gaperton, Вы писали:

G>С другой стороны, уметь "читать код" можно тоже по разному — в этом деле есть разные уровни. Одно дело сориентироваться в чужом коде, и закрыть багу,

Это тоже полезный навык, особенно, если закрыть и ничего при этом не сломать.

G>и другое — в сжатые сроки восстановить дизайн подсистемы по коду, и "понять" ее — вот на это способен, мне кажется, уже не каждый средний программист. Или я плохо думаю о среднем программисте?

Это сильно зависит от того насколько программист знаком с исследуемой темой. Думаю, будет очень легко развеять ореол божественности, если попросить Тола Корина проделать тоже самое с исходниками другой незнакомой ему области. Можно, например, декомпилировать Linq 2 SQL и попросить восстановить за пять минут дизайн любой из его подсистем по коду.

В остальном со всем согласен

Здравствуйте, bastrakov, Вы писали:

G>>Импортировать в репозиторий можно с историей коммитов.

B>угу... приходите в гости, я вас с деплоймент-инженером сведу, и вы ему расскажете, как надо переливать сырцы.
B>а он вам ответит, что в сырцах стоит не его имя, а прошлый спицилист. и репозиторий меняли уже 3 раза за прошедшие 4 года.

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

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

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

Умение "читать" впрямую связано с умением "писать". Кстати, об умении читать — это не статья о ключевых знаниях для проектирования сложных систем.

B>совершенно согласен. для чтения кода дока не нужна. для понимания смысла написания так как есть (почему сделано так, а не иначе) — нужна.

Нужно знание, а не дока, "дока" всего лишь один из возможных его носителей. Знание же может быть получено самыми разными способами.

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

Первый способ соответствует "документации" в качестве носителя информации, второй — живой обмен знаниями, который я описывал недавно в топике про code и design review. Второй способ на практике работает лучше, и наличие документации при его использовании совершенно не критично. Исключая случаи, когда документы фиксируют некоторую договоренность группы людей о чем то, которую важно соблюдать, и не могут быть сгенерированы из кода автоматически. Таких случаев не так много.

B>

B>...тут я «вслепую», без всяких класс-браузеров, продираюсь к «правильному» файлу, открываю его, и поиском нахожу нужный метод,...

B>почему? ну почему вы не показали, как вы находите, а не что вы находите?!..

По памяти я нахожу. Потому, что уже умею ориентироваться в коде — я просто знаю, где оно лежит. Что тут надо показывать?

B>он же потом со следующим методом придет. ...хотя...ну да. обычно "ловить рыбу" не учат. иначе выпрут из "ловцов рыбы".

Со временем научится сам, это не фокус.

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

B>угу. только это не часть процесса создания. это часть процесса поддержки.

Поддержка неотделима от создания в случае "живой", развивающейся системы, которая коммерчески успешна.

B>после недели медитации над чужим кодом, я могу переписать это за пару часов гораздо проще, и мне пофиг, че там реверс наинженерит.

"За пару часов" вы в самом лучшем случае напишете 100 строк отлаженного кода. Изолированного кода, а в старом коде очень много неявных контрактов, и заставить работать "переписанное" гораздо тяжелее. Не умея реверс инженирить, ничего вы не перепишете, либо все сломаете, либо раздуете код, налепив сбоку соплей, и его зарубят на code review.

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

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

B>"любой дурак", я надеюсь, художественное преувеличение?..

Нет, правда жизни. И чем больший дурак, тем больше он напишет кода.

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

Мало-ли кто что готов. Разработка управляется не эстетическими чувствами, а принципом value-cost. Результат переделки в большинстве случаев будет иметь такой cost, что не стоить value.

B>не согласен. хороший архитектор поднимается на уровень вверх. а там кода уже совсем нет.

Я видел как минимум одного очень хорошего архитектора, компетенция которого была налицо, и который думает так, как я написал. И я видел много плохих "архитекторов", думающих иначе. Собственно, они в массе своей больше хотели называться "архитекторами", чем реально являлись ими. Можете соглашаться, можете нет — я свое мнение никому не навязываю.

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

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

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

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

P.S. Регулярно читаю Ваш блог и очень высого мнения о Ваших знаниях в предметной области .

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

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

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

Но это если конь сферический и в вакууме. Изредка ошибки встречаются везде. Чемпион россии по MTG при мне проиграл мелкий турнир, потому что ему фатально не повезло с раздачей карт, а оппоненту фатально повезло. Такое бывает. Но бывает, заметьте, изредка. Когда он играет со мной, я проигрываю 19 партий из 20. Потому что он объективно играет на пару порядков лучше, чем я.

К чему я клоню? К тому, что если ошибок вообще избежать вряд ли получится, то можно уменьшить частоту их получения и сроки их нахождения. Почему я говорю что магия — ненадежный архитектурный инструмент? Потому что она мало от нас зависит. У мага может *просто не получиться*. Не с той ноги встал. И мы с этим ни-че-го не сделаем. Тоесть вообще ничего. Сидит Тод, тупит в код, и у него "не прет". А мы, соответственно, сидим рядом и поняимаем, что без магии тут разобраться часов двадцать-тридцать. Разберемся, конечно, но нас не радует прокол на пустом месте. Потому что совокупность проколов на пустом месте дает как раз ту разницу, которая отличает просто хорошего игрока в MTG от чемпиона России.

Что можно сделать? Я уже не первый год занимаюсь техническим сопровождением когнитивной составляющей в разработке ПО и полностью с Вами согласен в том, что все плохо. На документацию забивают большой и длинный, в вики никто не пишет, систему управления задачами читают из-под палки и все равно предпочитают тестировщикам выдавать задачи устно, со всеми вытекающими. Напрашиваются несколько выводов. Во-первых, архитектура и комментарии должны быть записаны в коде. Тоесть никаких .doc файлов, mediawiki и прочих 1С:Мироздание. Прямо в сорцах расставляем в комментариях теги и записываем что нам надо. Doxygen, Natural Docs, javadoc и еще большая куча технологий и инструментов в помощь. Если это развернуть, то мы имеем документацию по проекту, которая всегда синхронизирована с исходниками и всегда актуальна. Потому что она из них генерится.

В этом случае, когда у Тода не получилось, потому что у него вчера заболела жена и он потратил весь запас маны на неделю вперед чтобы ее вылечить, мы не сидим грустно и не считаем на пальцах лидов, которых у нас мало. Мы открывает браузер документации, на страничке "вид сверху". Тыкаем в нужную подсистему на Главной Картинки. Затем тыкаем в нужный паттерн. Затем в нужную функцию. Затем на нужный файл. Он открываетс в редакторе и радостный Тод, имея справа редактор а слева автогенеренную историю по данной функциональности (мы ведь не только из сорцов автогенерим, да?) все делает за пять минут и идет пить кофе.

С интересом выслушаю встречные вопросы, бо методология достаточно сырая . You opinion counts (c).

Здравствуйте, Eye of Hell, Вы писали:

EOH>

Empiric process, не зависимый от людей — это абсурд. У Джоела, кстати, была очень простая и убедительная статья об этом — про "голого шеф-повара".

EOH>Я знаю. Читал. Я над этим работаю .
EOH>Тут есть некий хитрый чит. Если каким-то хитрым образом изогнуться и сделать так чтобы *результаты* работы колдунов протоколировались, то можно сделать следующее: добрый волшебник творит свою архитектурную и технологическиую магию, при этом она почти на автомате протоколируется. В результате с тем, что волшебник уже сделал можно впоследствии разобраться силами менее квалифицированных товарищей. Теоретически, получаем лучшее из двух миров — волшебники творят чудеса, при этом уже сотворенные чудеса можно поддерживать без волшебников.

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

Код волшебника очень просто устроен, логично структурирован, и _литературен_. В нем _легко_ разбираться. Его не надо отдельно протоколировать — соблюдения дисциплины работы с комментариями к коммитам в VCS, и записям в трекере достаточно. Даже для не по делу сложного и кривоватого кода, написанного начинающими волшебниками.

Соблюдение дисциплины оформления самого кода, проверяющейся на код-ревью (предполагают эти правила оформления комментариев в doxygen-подобном стиле или нет — неважно), так же достаточно для того, чтобы все было так, как я пишу. Отсутствия код ревью — достаточно, чтобы все стало плохо и при наличии документации.

Здравствуйте, Gaperton, Вы писали:

G>Организаторы SoftwarePeople попросили меня написать какую-нибудь статью для сайта. Я собственно, написал нечто, и опубликовал сначала в своем блоге. Эта совершенно безобидная статья вызвала почему-то кучу шума. Топ яндекса, и концы — заломилась толпа, и какого-то дуба половина ЖЖ меня теперь обвиняет в том, что я "проповедую" отказ от любой документации во всех ее проявлениях — и что такой подход — враг всему "промышленному". С ума спятить. Причем, переубедить людей, и объяснить им, что статья вообще не о том, и что я ничего не проповедую — практически невозможно. Короче, вот, читайте .

Спасибо за статью. Мне она напомнила одну вешь. В стакан 200 мл налили 100 мл воды. Так вот есть люди, которые скажут что стакан на половину полон, а другие скажут что стакан на половину пуст. Так и здесь. Опытные программисты, прочитав вашу статью говорили мне — так это же очивидно! А вот молодежь говорит — я так и знал! Документация не нужна. Но при этом прочитать код опытного можеть кто угодно. А вот над кодом молодого... в общем учится, учится и еще раз учится!
Но если честно, в том виде, как эта статья есть — молодым показывать боюсь... ой как боюсь... Что то есть неуловимое для молодых и не испорченных умов. Это что то, на мой взгляд, и заставило большу толпу народа "нападать" на вас с обвинениями в том, что вы проповедуете отказ от кода. Выразить пока в словах не могу, но как только мысль сформируется — я поделюсь

Здравствуйте, genre, Вы писали:

G>Это не так. Процесс в котором люди невзаимозаменяемы вообще ни копейки не стоит. Он не поддается ни планированию, ни маштабированию.

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

PS: Это чистая практика. Именно такую ситуацию я имею счастье наблюдать воочию..... К счастью, не в моем проекте и не в отделе, где я работаю.

Здравствуйте, Vlad_SP, Вы писали:

V_S>Здесь я бы возразил: процесс, в котором люди абсолютно взаимозаменяемы — стоит еще меньше. Ибо в нем люди низведены до состояния "заменяемых винтиков", и их мотивация эффективно работать по проекту — не только стремится к нулю, но и устремляется к отрицательному значению. Главным становится другое — мелочное и детальное следование "регламентам", "документированным процедурам" и прочим бюрократическим брейнфакингам. Результат же работы по проекту — для сотрудника-"винтика" не имеет значения, сотрудник в нем нисколько не заинтересован; ибо сегодня "винтик" работает на одном проекте, завтра — на другом, послезавтра — вообще на третьем.

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

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

Здравствуйте, Vlad_SP, Вы писали:

V_S>Да я, в общем-то, не утверждаю об "ореоле сакральности и таинства" в программировании и не возражаю против осмысленного следования регламентам и процедурам. Они необходимы. Я возражаю — против низведения сотрудников до уровня "винтиков", этаких "рядовых программистских войск" — со всеми вытекающими из такого действа последствиями, о чем отлично написал коллега mrozov в посте 06.06.08 13:45 (за что ему отдельное спасибо).

я честно говоря не очень понимаю почему "взаимозаменяемость" сотрудников ставят в один рад с "винтиками". это разные вещи

Здравствуйте, yumi, Вы писали:

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

Да, пожалуй, это действительно навык senior software developer. Надо поправить. Эта фраза у меня вызывала какие-то смутные колебания.

Видишь ли, с одной стороны, средний программист обычно входит в ступор, пытаясь читать код CQG. Не потому, что он плохо написан — просто он зараза очень большой, и чтобы его читать, надо, скажем так, довольно много знать вещей на самом деле, специфичных для CQG. Скажем, наследование от Messenger означает, что класс умеет отправлять и принимать асинхронные сообщения — просто как пример. Ну, другими словами, абстрагируясь — чтобы читать код, надо знать и понимать Common Design Principles, в соответствии с которым он написан. Это нормально, фокусом не является, и это навык обычного программиста.

С другой стороны, уметь "читать код" можно тоже по разному — в этом деле есть разные уровни. Одно дело сориентироваться в чужом коде, и закрыть багу, и другое — в сжатые сроки восстановить дизайн подсистемы по коду, и "понять" ее — вот на это способен, мне кажется, уже не каждый средний программист. Или я плохо думаю о среднем программисте?

Здравствуйте, Gaperton, Вы писали:

Все правильно. Код — лучшая документация. Но, только тогда, когда его пишут профессионалы в соответствии с принятыми в компании нормами. Хочу работать в такой компании )

Здравствуйте, Sshur, Вы писали:

S>Все правильно. Код — лучшая документация. Но, только тогда, когда его пишут профессионалы в соответствии с принятыми в компании нормами. Хочу работать в такой компании )
Даже если код пишут индусы в худшем случае этого слова, и даже если есть документация — один черт даже ужасный индусский код будет лучшей документацией. И в любом случае придется лезть в этот код, чтобы что-то понять. Так как та документация, которая есть — она даже близко не будет соответствовать коду, так как писалась скорее всего на заре становления системы, и потом на нее никто не смотрел и все писали абы как.

Здравствуйте, Gaperton, Вы писали:

G>Настоятельно рекомендую. Советы лучших собаководов, буквально .

Методы решения я знаю, я просто хотел заметить, что в статье слишком однозначно сказано, что документация не нужна. А все-таки дизайн-дока в вики проявилась

Здравствуйте, genre, Вы писали:

G>>Настоятельно рекомендую. Советы лучших собаководов, буквально .

G>Методы решения я знаю, я просто хотел заметить, что в статье слишком однозначно сказано, что документация не нужна. А все-таки дизайн-дока в вики проявилась

Через пять лет дизайн-дока в вики у вас будет именно такая, как сказано в статье — пятилетней давности, и код перестанет ей соответствовать. Это — не наталкивает не на какие мысли?

Здравствуйте, Gaperton, Вы писали:

G>Через пять лет дизайн-дока в вики у вас будет именно такая, как сказано в статье — пятилетней давности, и код перестанет ей соответствовать. Это — не наталкивает не на какие мысли?

Не-не. Дизайн-дока появилась не у меня, а у вас. Я наверное неправильно выразился.
еще раз цитирую:

G>Точно. Очень, очень своевременный вопрос. На этот вопрос отвечают комментарии к коммитам кода в VCS. В этих комментариях помимо описания rationale (кстати, и поэтому тоже многофайловые "транзакционные" коммиты рулят, когда коммитится только работоспособный код — вы видите связь разрозненных правок) может быть ссылка на дефект, фичреквест, или просто страничку в вики, где висит дизайн-документ, по реализации которого сейчас делается коммит.

я выделил.

Здравствуйте, genre, Вы писали:

G>>Через пять лет дизайн-дока в вики у вас будет именно такая, как сказано в статье — пятилетней давности, и код перестанет ей соответствовать. Это — не наталкивает не на какие мысли?

G>Не-не. Дизайн-дока появилась не у меня, а у вас. Я наверное неправильно выразился.

Это так принципиально?

Здравствуйте, bastrakov, Вы писали:

B>Здравствуйте, Gaperton, Вы писали:

G>>>Добавлю. Код конечно лучшая документация, но он не отвечает на один очень важный вопрос: "Почему сделано именно так, а не иначе".
G>>Точно. Очень, очень своевременный вопрос. На этот вопрос отвечают комментарии к коммитам кода в VCS.

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

Импортировать в репозиторий можно с историей коммитов.

bkat пишет:
>
>
> Да, умение читать код очень важно.
> Но и "картинки" тоже весьма полезны.
Мдас, что-то с программерами нынешними рускоговорящими неладное
твориться. Единственный внятный пост в этой теме и ни одного плюсика...

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, genre, Вы писали:

G>>>Через пять лет дизайн-дока в вики у вас будет именно такая, как сказано в статье — пятилетней давности, и код перестанет ей соответствовать. Это — не наталкивает не на какие мысли?

G>>Не-не. Дизайн-дока появилась не у меня, а у вас. Я наверное неправильно выразился.

G>Это так принципиально?

Конечно. Это означает, что дизайн-дока может не отвечать на вопрос почему сделано именно так, а не иначе.

Здравствуйте, genre, Вы писали:

G>>>>Через пять лет дизайн-дока в вики у вас будет именно такая, как сказано в статье — пятилетней давности, и код перестанет ей соответствовать. Это — не наталкивает не на какие мысли?

G>>>Не-не. Дизайн-дока появилась не у меня, а у вас. Я наверное неправильно выразился.

G>>Это так принципиально?

G>Конечно. Это означает, что дизайн-дока может не отвечать на вопрос почему сделано именно так, а не иначе.

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

Через 5 лет после большого количества относительно мелких правок кода она и у вас не будет отвечать на этот вопрос. Вовсе не потому, что вы не умеете их писать.

Здравствуйте, Gaperton, Вы писали:

G>Импортировать в репозиторий можно с историей коммитов.

Особенно если старый и новый репозитории хостятся на раных моделях сорс-контролов? Не одним SVN живо человечество, есть еще много прочих VSS/Perforce/etc

В качестве домашнего задания, возьмите три любых сорс-контрола (A, B и C), пролейте сырцы сквозняком "A -> B -> C -> A" и проверьте полную историю коммитов. Точнее, хотя бы её наличие

Здравствуйте, Аноним, Вы писали:
А>Особенно если старый и новый репозитории хостятся на раных моделях сорс-контролов? Не одним SVN живо человечество, есть еще много прочих VSS/Perforce/etc

Нормальные VCS умеют конвертировать историю как минимум из/в SVN, а часто — и друг между другом.

Здравствуйте, Gaperton, Вы писали:

G>Хотите сказать, что я плохо умею писать дизайн доки, а вы хорошо? Ох уж эти пионерские переходы на личности, ну не могут никак люди без них

G>Через 5 лет после большого количества относительно мелких правок кода она и у вас не будет отвечать на этот вопрос. Вовсе не потому, что вы не умеете их писать.

Блин. Да какие переходы на личности. Будте внимательней просто к вопросу на который отвечаете.
Вот наш диалог вкратце:
Вы: Читайте код, доки в сад.
Я: А как быть вот с этим?
Вы: В комментарии к коммиту оставить ссылку на доку с дизайном.
Я: То есть некоторые доки все-таки нужны?
Вы: нет, не нужны, они устареют

короче либо я либо вас понял не так, либо вы меня

Здравствуйте, genre, Вы писали:

G>Блин. Да какие переходы на личности...

Извиняюсь, что вмешиваюсь. Один из переходов выделен:
G>Блин. Да какие переходы на личности. Будте внимательней просто к вопросу на который отвечаете.

Здравствуйте, Eye of Hell, Вы писали:

EOH>ИМХО и только ИМХО — магия штука хорошая, но для разработки софта инженерный процесс как-то спокойнее. И людям его передавать проще, и завязки на колдунов нету. Тесты опять же, метрики.

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

Здравствуйте, Eye of Hell, Вы писали:

EOH>

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

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

Форумы поистине делают с людьми страшные вещи, что тут спорить . После мрака в ЖЖ, я уже нервно дергаюсь при каждом новом коменте на эту тему. Прошу, кстати, это учесть.

EOH> Я с этим согласен, но, в свою очередь, отметил неприятное свойство магии: не гарантирует результат и напрямую зависит от запаса маны, тоесть плохо масштабируется.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Беда в том, что если вы строите процесс, который не зависит от личности, то все личности в вашем проекте становятся взаимозаменяемыми. А значит, вам всё равно, что чувак типа Тола, что Вася Пупкин с опытом 3 года, обученный процессу. Т.е., фактически, вы делаете так, что людям типа Тола в вашем проекте нет места. А тем самым, лишаете себя возможности разрабатывать софтварий, в котором без людей такого класса просто не обойтись.

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

Empiric process, не зависимый от людей — это абсурд. У Джоела, кстати, была очень простая и убедительная статья об этом — про "голого шеф-повара".

Empiric process, не зависимый от людей — это абсурд. У Джоела, кстати, была очень простая и убедительная статья об этом — про "голого шеф-повара".

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

Где-то так .

Здравствуйте, Eye of Hell, Вы писали:

EOH>

Empiric process, не зависимый от людей — это абсурд. У Джоела, кстати, была очень простая и убедительная статья об этом — про "голого шеф-повара".

EOH>Я знаю. Читал. Я над этим работаю .
EOH>Тут есть некий хитрый чит. Если каким-то хитрым образом изогнуться и сделать так чтобы *результаты* работы колдунов протоколировались, то можно сделать следующее: добрый волшебник творит свою архитектурную и технологическиую магию, при этом она почти на автомате протоколируется. В результате с тем, что волшебник уже сделал можно впоследствии разобраться силами менее квалифицированных товарищей. Теоретически, получаем лучшее из двух миров — волшебники творят чудеса, при этом уже сотворенные чудеса можно поддерживать без волшебников.

EOH>Где-то так .
Чтобы протоколировать действия одного волшебника нужен на порядок более дорогой волшебник. Это как то связано с тем, что смысл не равен сумме смыслов частей. Так что пока это экономически не оправданно никто так делать не будет. По крайней мере при мне все случается именно так
Буду рад узнать что я был не прав и это просто такой неудачный опыт.

Здравствуйте, Pzz, Вы писали:

Pzz>Беда в том, что если вы строите процесс, который не зависит от личности, то все личности в вашем проекте становятся взаимозаменяемыми. А значит, вам всё равно, что чувак типа Тола, что Вася Пупкин с опытом 3 года, обученный процессу. Т.е., фактически, вы делаете так, что людям типа Тола в вашем проекте нет места. А тем самым, лишаете себя возможности разрабатывать софтварий, в котором без людей такого класса просто не обойтись.

Это не так. Процесс в котором люди невзаимозаменяемы вообще ни копейки не стоит. Он не поддается ни планированию, ни маштабированию.

Просто стремится к абсолютной взаимозаменяемости не следует. Достаточно, чтобы человека мог заменить некий процент других членов команды. Процент в каждом случае свой. Ну например в достаточно большой команде человек если человека можно легко заменить 4-5 другими, а еще скажем 5-10 нельзя, то это уже достаточный уровень взаимозаменяемости.
А теперь впишем в эту схему Тола. Те 90% работы которую он делает в режиме "обычный программист" мы встраиваем в общую схему, а те 10% что в режиме "супер-гуру" — они остаются незаменимыми.

Здравствуйте, Au1, Вы писали:

Au1>

Au1> Прямо в сорцах расставляем в комментариях теги и записываем что нам надо. Doxygen, Natural Docs, javadoc и еще большая куча технологий и инструментов в помощь. Если это развернуть, то мы имеем документацию по проекту, которая всегда синхронизирована с исходниками и всегда актуальна. Потому что она из них генерится.

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

Комментарии есть неотъемлемая часть кода. Для контроля данного аспекта качества которого служит code review.

Здравствуйте, genre, Вы писали:

G>А теперь впишем в эту схему Тола. Те 90% работы которую он делает в режиме "обычный программист" мы встраиваем в общую схему, а те 10% что в режиме "супер-гуру" — они остаются незаменимыми.

В реальности, у нас было как минимум 3 человека, которые в совокупности дублировали и перекрывали его компетенции. Один из них — я, его скромный ученик . А если кого-то из нас не стало бы, знание было бы чуточку более распределено, ибо и каждый из этих трех многократно отдублирован. Но не пропало. Скажем, у меня в команде был человек, который мог полностью меня заметить. И, кстати, заменил, когда я уволился.

Код волшебника очень просто устроен, логично структурирован, и _литературен_. В нем _легко_ разбираться. Его не надо отдельно протоколировать.

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

В подветке была обрисована идея, что:

А значит, вам всё равно, что чувак типа Тола, что Вася Пупкин с опытом 3 года, обученный процессу. Т.е., фактически, вы делаете так, что людям типа Тола в вашем проекте нет места. А тем самым, лишаете себя возможности разрабатывать софтварий, в котором без людей такого класса просто не обойтись.

Я на самом деле зря на это ответил, что действия Тола тоже можно комментировать. Я с Вами согласен, что код гуру уровня Тола просто устроен, логично структурирован и литературен. Переформулирую — техпроцесс и документация не приравнивают Тола к Васе. Они не накладывают на Тола рамки . Техпроцесс сам по себе — это средства контроля а не направляющая рельса. Не вижу чем документация в коде помешает Толу писать такой же просто устроеный, логично структурированный и литературный код. А вот Васин сложный, нелогично структурированный и н.лр-й. код такой техпроцесс вполне сможет выправить, так чтобы потом не понадобилась магия при его чтении. Мы же не можем одних Толов в компанию нанять?

Здравствуйте, genre,

G>Здравствуйте, Vlad_SP, Вы писали:

V_S>>Здесь я бы возразил: процесс, в котором люди абсолютно взаимозаменяемы — стоит еще меньше. Ибо в нем люди низведены до состояния "заменяемых винтиков", и их мотивация эффективно работать по проекту — не только стремится к нулю, но и устремляется к отрицательному значению. Главным становится другое — мелочное и детальное следование "регламентам", "документированным процедурам" и прочим бюрократическим брейнфакингам. Результат же работы по проекту — для сотрудника-"винтика" не имеет значения, сотрудник в нем нисколько не заинтересован; ибо сегодня "винтик" работает на одном проекте, завтра — на другом, послезавтра — вообще на третьем.

G>Не нужно придавать программированию сакральности и таинства. Детальное следование регламентам и документированным процедурам в промышленном программирование первоочередная необходимость.
G>Как только из программирования делают таинство гениев-одиночек с настолько тонкой душевной организацией, что аж прям дышать нельзя начинается такой разброд и шатания, что думать страшно.

G>Взаимозаменяемость это гарантия того, что шоустоппер на live сервере каждая секунда простоя которого стоит бешеных денег будет пофикшен мгновенно, а не когда гуру вернется из отпуска.

Да я, в общем-то, не утверждаю об "ореоле сакральности и таинства" в программировании и не возражаю против осмысленного следования регламентам и процедурам. Они необходимы. Я возражаю — против низведения сотрудников до уровня "винтиков", этаких "рядовых программистских войск" — со всеми вытекающими из такого действа последствиями, о чем отлично написал коллега mrozov в посте 06.06.08 13:45 (за что ему отдельное спасибо).

PS: просьба к модераторам вырезать оверквотинг, произошедший по недосмотру.

Здравствуйте, SEDEGOFF, Вы писали:

SED>Спасибо за статью. Мне она напомнила одну вешь. В стакан 200 мл налили 100 мл воды. Так вот есть люди, которые скажут что стакан на половину полон, а другие скажут что стакан на половину пуст. Так и здесь. Опытные программисты, прочитав вашу статью говорили мне — так это же очивидно! А вот молодежь говорит — я так и знал! Документация не нужна. Но при этом прочитать код опытного можеть кто угодно. А вот над кодом молодого... в общем учится, учится и еще раз учится!

SED>Но если честно, в том виде, как эта статья есть — молодым показывать боюсь... ой как боюсь... Что то есть неуловимое для молодых и не испорченных умов. Это что то, на мой взгляд, и заставило большу толпу народа "нападать" на вас с обвинениями в том, что вы проповедуете отказ от кода. Выразить пока в словах не могу, но как только мысль сформируется — я поделюсь

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

То есть, я хотел это сказать. Сказал по факту, видимо, что-то другое . Ну тут уж что получилось — то получилось .

Здравствуйте, SEDEGOFF, Вы писали:

SED>Но если честно, в том виде, как эта статья есть — молодым показывать боюсь... ой как боюсь... Что то есть неуловимое для молодых и не испорченных умов. Это что то, на мой взгляд, и заставило большу толпу народа "нападать" на вас с обвинениями в том, что вы проповедуете отказ от кода. Выразить пока в словах не могу, но как только мысль сформируется — я поделюсь

Кстати, это свойство можно полезно эксплуатировать. Статью можно использовать как тест при приеме на работу

Здравствуйте, Cyberax, Вы писали:

SED>>>Но если честно, в том виде, как эта статья есть — молодым показывать боюсь... ой как боюсь... Что то есть неуловимое для молодых и не испорченных умов. Это что то, на мой взгляд, и заставило большу толпу народа "нападать" на вас с обвинениями в том, что вы проповедуете отказ от кода. Выразить пока в словах не могу, но как только мысль сформируется — я поделюсь
G>>Кстати, это свойство можно полезно эксплуатировать. Статью можно использовать как тест при приеме на работу
C>Что-то ты Макиавелли перечитался

А что такого? Обычная косвенная методика тестирования

Здравствуйте, IT, Вы писали:

IT>Нужно придавать и сокральность и таинство. Программирование это не работа на конвейере, но и не чистое изобретательство конвейера. Это одновременное изобретение конвейера и работа на нём. Мы создаём станок и тут же пилим на нём детали. Любая крайность, только работа на конвейере или только изобретательство, тут же дают сильный обратный эффект.

вот только изобретательство это и есть сакральность и таинство. Этого и не нужно привносить.

G>>Как только из программирования делают таинство гениев-одиночек с настолько тонкой душевной организацией, что аж прям дышать нельзя начинается такой разброд и шатания, что думать страшно.
IT>Дело не в гениях. Разброд и шатания начинаются тогда, когда эти гении создают только инструменты и только ради создания инструментов. Куча ненужных и непонятных тулов, заводы и фабрики по броизводству гвоздя (одного!) и т.п. Это не имеет отношения к гениальности, это косяк в управлении. Задача менеджера максимально утилизировать имеющиеся в наличии ресурсы, а не побрить их под самую плохую, но зато под одну гребёнку.
Вообще твое утверждение не противоречит моему. И так плохо и так плохо.

G>>Взаимозаменяемость это гарантия того, что шоустоппер на live сервере каждая секунда простоя которого стоит бешеных денег будет пофикшен мгновенно, а не когда гуру вернется из отпуска.
IT>Думаю, что без гуру шоустоппер на live вообще бы не появился. Возьми стотыщь индусов и пусть они напишут аналог live. Не напишут. Никакая взаимозаменяемость не поможет. Нельзя взять десять мозгов с IQ равным 20, сложить их и получить IQ равный 200. В данном случае работет функции Max, а не Add.
Как собственно и здесь. без гуру плохо. но и с незаменимым гуру не очень хорошо.

Здравствуйте, genre, Вы писали:

G>Как собственно и здесь. без гуру плохо. но и с незаменимым гуру не очень хорошо.

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

Здравствуйте, IT, Вы писали:

G>>Как собственно и здесь. без гуру плохо. но и с незаменимым гуру не очень хорошо.
IT>Вопрос только что хуже

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

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

В хорошем коде функционал не может быть сильно далёк от заголовка

Здравствуйте, Gaperton, Вы писали:

G> Организаторы SoftwarePeople попросили меня написать какую-нибудь статью для сайта. Я собственно, написал нечто, и опубликовал сначала в своем блоге.

Не по теме. У тебя в блоге закрыты комментарии при авторизации по OpenID, а иногда хочется ответить