metaclass | Программистское мракобесие

Программистское мракобесие

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

А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?

Threaded | Top-Level Comments Only

Документировать код можно легко и безболезненно. Может быть это ООП так негативно влияет на архитектуру?
В целом же правило такое - чем выше уровень программы (или более обще - чем больше совокупная сложность модуля), тем более развёрнутый должна быть документация. Зависимость практически линейная, за исключением хитрых хаков на низком уровне.

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

Лучше хорошо комментированная система с хорошим понятным кодом и минимумом документации, которая актуальна, чем сильно документированная система с треш-кодом, который этой документации не соответствует.

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

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

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

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

Я вот знаю один такой крупный продукт. Который в активной поддержке и документация к которому слабо соответствует действительности. Называется SAP.
Убил бы разработчиков за такое. Говорят (и я склонен верить), что в самом САПе не осталось ни одного человека, который представлял бы себе систему полностью. Что уж говорить о попытках самому по несоответствующей документации и тупорылых консультантах воссоздать картинку архитектуры и как там разработчики мыслили

Так что читать код -- это да. Но есть такой код, который жизни не хватит осознать.

> Ты понимаешь разницу между пользовательской документацией и проектной?

для некоторых систем этой разницы нет

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

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

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

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

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

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

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

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

У кого иллюзию - а у кого и обоснованную уверенность.

ППКС

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

Это, собственно, основы process theory. Еще примеры занятий, где встречается empiric process - разработка новых моделей автомобилей, и военное дело. Нет никакой технологии, точное соблюдение которой позволит выиграть войну, это достаточно очевидно. Хотя бы потому, что вклад боевого духа войск к прочим факторам оценивается многими специалистами как 3 к одному.

Точно также Вы можете посадить кучу идиотов под CMMI Level 5, и не получить на выход ничего ценного. Или получить продукт, вызывающий зевоту на рынке. В этом разница.

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

> так ведь я же написал, что для инновационных проектов (задач) нужен немного свой подход

Любой проект по разработке ПО сопряжен с решением проблем, и является в той или иной степени "инновационным". Проект по внедрению готового ПО - нет.

> "военное дело" - т.е. уставы и руководства вообще не имеют право быть в военном деле? все можно выиграть только "силой духа"? :)

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

> "Вы можете посадить кучу идиотов под CMMI Level 5, и не получить на выход ничего ценного" ну уж я этим заниматься не буду. :) и рекомендовать это делать никому не буду.

Это я привел для иллюстрации того, чем разработка ПО отличается от изготовления гамбургера. Соблюдение технологии не _гарантирует_ вам успеха. Таких гарантий у вас нет и быть не может.

> CMMI я порекмендую применять именно в том объеме и в том виде, которые позволят получать более предсказуемый (по бюджету, качеству и т.д. - тут уж выбор - дело частное) результат

Тезис CMMI про снижение рисков при повышении уровня - как минимум спорен, и многие уважаемые и опытные специалисты его не разделяют, см. аргументацию по этому поводу Тома ДеМарко в Peopleware в качестве примера. Это при том, что те же люди сходятся на том, что критерии зрелости CMMI, в целом, неплохая штука, основанная на best practices.

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

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

1) Завязанность компетенции на единичные ключевые фигуры никак не связана с наличием и отсутствием документации. Вообще. Документация - не единственный и во многих случаях не лучший способ передачи знания. Лучшая защита от такой ситуации - поддержание как минимум двух человек на каждой теме, и налаживание среды для передачи знаний. Например, этому способствуют практики design review, имея передачу знаний своим побочным эффектом.
2) Если пропущен пункт 1, то проблемы будут точно, ибо наличие документации само по себе никак не поможет при уходе ключевых фигур. Во-первых, спагетти-говнокоду не поможет никакая документация. Во-вторых, эта документация никогда на практике не соответствует коду, поэтому она практически бесполезна. Поможет только хорошо написанный, и понятно структурированный, и по делу комментированный код, и соблюдение дисциплины работы с VCS - содержательные комментарии к коммитам критичны. Наличие перечисленного, в свою очередь, также никак не связанно с наличием или отсутствием описательной проектной документации, и определяется наличием coding standard, практики перекрестного code review, и практики design review.

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

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

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

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

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

На практике, так все и происходит, и именно поэтому вы НИКОГДА не увидите актуальной документации на живом проекте в развитии и поддержке, если она не генерируется из кода. Касательно документации по уже существующему коду, ее дешевле (и на самом деле, это вообще единственный работающий на практике способ) получать из самого кода автоматически. Для C/C++ используйте doxygen. И это и будет как раз тот самый случай, когда код - лучшая документация, ибо doxygen-документация и есть не более чем специальным образом комментированный код. Просто кому-то приятнее его смотреть в браузере - что на самом деле не принципиально.

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

"На практике, так все и происходит, и именно поэтому вы НИКОГДА не увидите актуальной документации на живом проекте в развитии и поддержке, если она не генерируется из кода."
Просто блин лечь и умереть, я КАЖДЫЙ ДЕНЬ вижу актуальную документацию.

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

Что касательно "методологии", в которой дизайнеры не пишут код - она сама по себе большая редкость, эффективность ее сомнительна, а ваш процесс поддержания их в актуальном состоянии выглядит научной фантастикой.
1) Как у вас контроллируется, что код соответствует дизайну? Когда это проверяется? Кто на кого дефект открывает?
2) Вот у вас этот код, созданный по дизайн-документу попал в тестирование, и его автору пошли дефекты. "Кодер" каждый раз будет багу открывать, чтобы вы документ поправили, если исправление касается дизайна? А если он этого не сделает (а он не сделает) - как вы это проверите?
3) Вот у вас этот код попал в эксплуатацию, и через год пришли дефекты, исправление которых требует изменения дизайна. Опишите подробно процедуру, которая гарантирует отражение этой правки в документе. Для исправлений дефектов и реализации фичреквестов вы тоже дизайн-документы писать будете, да? И открывать дефекты на эти документы?

Вы работали на "живом" проекте когда нибудь, когда он развивается находясь в эксплуатации? Такого, у которого объем исчисляется миллионами строк кода, и которому не менее 5-8 лет? Поработайте.

> Не знаю где вы увидели у меня убеждения что факта документирования достаточно, однозначно недостаточно, моё убеждение ДОКУМЕНТИРОВАНИЕ ОБЯЗАТЕЛЬНО.

В мои планы не входит спорить с вашими ДОГМАМИ, и вас переубеждать. Я деже не буде комментировать вашу "методологию разработки" - хоть на голове пишите, это ваше дело. Я прояснил свою позицию. Чтобы ее понять, я написал достаточно.

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

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

> Просто блин лечь и умереть...

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

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

Я не делаю этого "вида", а расставляю приоритеты.

> А это не повод проповедовать отказ от документации.

Я ничего не "проповедую", а рассказываю о пользе навыка чтения кода. Вы видите то, что хотите видеть.

>> И не учите успешные компании, входящие в тройку лидеров в своей отрасли, вести бизнес.
> Гы-гы-гы.
> В оценке того, как вести бизнес Вы, судя по всему слабо компетентны - иначе бы просто задумались о том, что стало бы с тем замечательным проектом, на котором Вас учили отказу от документации, если бы его центрального разработчика в одночасье переехал автомобиль. До того, как Вы чему-то научились.

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

> И свои указания о том, кого чему учить Вы направляете человеку, который в бизнесе (именно в бизнесе, а не в кодинге и не в системной архитектуре) 12ый год. Чего для бизнеса стоит блестящий код, который удаётся понять только в процессе передачи эзотерических знаний от разработчика к разработчику я, как Вам уже написал, наблюдал вживую два раза. На примерах, когда эзотерическая связь в силу внешних обстоятельств, прерывалась неожиданно.

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

> Повторю ещё раз - отказ от создания документации - это гнилые понты

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

Я не делаю этого "вида", а расставляю приоритеты.
Я ничего не "проповедую", а рассказываю о пользе навыка чтения кода. Вы видите то, что хотите видеть.

Я вижу то, что Вы написали.

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

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

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

Че-то маловато вы себе цифирю написали - Вы напишите сразу 40. Звучите Вы пока так, как будто не разбираетесь ни в том, ни в другом. И не хотите разбираться.
Бла-бла-бла.
Вы начали с перехода на личности в первом сообщении и продолжаете тут вместо того, чтобы сосредоточиться на аргументах по существу.
Это не случайно, потому что на единственный мой тезис - что сопровождаемость системы не должна зависеть от 'живой передачи традиции', а должна опираться на документированность системы, Вам кроме разговоров о том, что документацию невозможно держать в когерентном состоянии с системой ответить нечего.

Ну Вам это может быть невозможно действительно, не умеете, чего уж там.

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

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

Да хоть десять раз повторите. Когда Вы будете в таком бизнесе, в котором Вы сможете разработать программный комплекс хотя бы в пару миллионов строк, и Вы при этом сможете удержать разработку под контролем в течении лет хотя бы 8, тогда и будете мне что-то рассказывать про понты, колотить себя пяткой в грудь насчет того, сколько вы в бизнесе, и рассказывать как Вам удается все здорово докментировать. И будете учить компанию, существующую с 80 года, как ей вести дела и как организовывать разработку.
Мании величия прикрутите фитилёк. Вы - не компания, существующая с 1980го года. Вы - человек, нанятый, судя по тому что Вы пишете, а не являющийся совладельцем бизнеса, последствия деятельности которого будет разгребать кто-то такой, как я. Лет через несколько, после того, как Вы перейдёте по своей карьерной лестницы куда-то ещё, а на старом месте настанет необходимость провести рефакторинг системы. Вам на это вполне предсказуемое будущее в целом наплевать - ну так судя по тому что Вы пишете, Вы бизнес не ведёте и не собираетесь вести.
Поэтому я, разумеется, не учу бизнесу ни Вас, ни нанявшую Вас компанию. Вас вообще бесполезно ему учить на текущий момент, а компанию свою в бизнес-качестве Вы явно не представляете. Да и если бы кого-то надо было бы хоть чему-то поучить - я бы это делал не в ЖЖо и денег бы за обучение взял.

Я просто даю трезвую оценку тому насколько целесообразно брать на работу подобных Вам 'системых архитекторов', которые вместо документирования внутренних API, Database Layout и проч. громко рассказывают о том, что 'лучшая документация - это код'.
Нецелесообразно. И если бы мне, на текущем месте деятельности, например, руководитель разработчиков что-то такое сообщил - я бы сильно подумал о том, что его надо заменить.

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

Хотите разговора по существу? Ок, я не против. Давайте проверим, насколько Вы способны поддерживать беседу по существу. Не переходя на личности.

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

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

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

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

http://metaclass.livejournal.com/367614.html?thread=2743294#t2743294
http://metaclass.livejournal.com/367614.html?thread=2743550#t2743550

Есть ли у Вас что-нибудь сказать по существу?

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

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

Случай тяжелый. У меня нет мании величия, уважаемый. Критикуя подход КОМПАНИИ в моем лице,, Вы пытаетесь учить жизни КОМПАНИЮ, а не меня. И не имеет никакого значения, совладелец я бизнеса, или нет. Разгребать "последствия моей деятельности" - Вы фитилек-то мании величия прикрутите, хорошо? :) Тим Мазер, владелец CQG, как нибудь все "разгребет" и без Ваших советов. Последние 29 лет он как-то без Ваших советов обходился, и ему это пошло впрок - умудрился стать мультимиллионером. А Вам до уровня, когда Вам потребуется архитектор, способный справится с миллионами строк кода - еще расти и расти. Растилку отрастите сначала, ок? :)

> Я просто даю трезвую оценку тому насколько целесообразно брать на работу подобных Вам 'системых архитекторов', которые вместо документирования внутренних API, Database Layout и проч. громко рассказывают о том, что 'лучшая документация - это код'.

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

Во-вторых, уважаемый, я менеджер, а не архитектор. Меня брать на работу архитектором действительно нецелесообразно - обойдусь слишком дорого. :)

И в третьих - Вы не в курсе, что давным давно есть возможность не пИсать против ветра, и всю "документацию по внутренним API" генерировать из кода и комментариев автоматически? А вы поинтересуйтесь, прежде чем чепуху-то молоть. К Вашему сведению, Вся документация по Java API генерируется именно таким образом. JavaDoc, если мне неизменяет память. Для С/С++ - Google "doxygen". Не забанили на гугле-то Вас, трезвый Вы оценщик архитекторов наш? :)

Threaded | Top-Level Comments Only

Page 3 of 5

Программистское мракобесие

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

Re: кстати

no subject

no subject

no subject

no subject

no subject

pt. 2

no subject

Re: pt. 2

no subject

Re: pt. 2

no subject

no subject

no subject

no subject

no subject