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

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

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

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

Threaded | Top-Level Comments Only

Страшнее отсутствия документации только документация, написанная людьми, которые ее обычно не пишут, считая, что все заключено в коде и комментариях. Не зависимо от уровня человека как программиста, выражать мысли в документации как правило умеют сущие единицы. У людей реально сносит башню, и "документация" превращается в презентацию, хай-левел дизайн и спецификацию по классам и методам одновременно, причем, желательно все на одном листе. Люди реально не знают, что же требуется отразить "на бумаге", для каких целей это пишется, кто целевая аудитория и когда следует остановится.
ЗЫ. В этом плане поучительна книга Фаулера УМЛ Дистеллед на фоне фолиантов и справочников от Бутча и Ко:)

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

конечно, сначала лиаемся "идеальных" управленцев, потом "идеальных" архитекторов, потом "идеальных" программистов, ну и как следствие "идеального" продукта :) и всё начинает идти под девизом "поздно думать - надо делать".. а где же я этот дивиз слышал? ах да, я его слышал в российской армии, которая идеал для ИТ компаний в плане соотношения производительность/стоимость труда :)

Вы правда не можете думать без документов? :) Эк тяжело-то. :)

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

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

Ну кто ж так не считал, будучи студентом. :) Все мы грешны :). Могу, ой скока могу :)! Самому страшно. :)

ну студентам лучше знать :)

Помимо всего прочего поддержание актуальной документации создаёт у начальства:
а) Иллюзию заменяемости исполнителя.
б) Недовольство замедленными темпами разработки.
Результат очевиден. ;)

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

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

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

О да, начальство это всегда дедушки-крестьяне с Марса! И по-другому, думаете Вы, и быть не может!

Булшит. Начальство занимается доками не потому, что хочет людей заманать. А потому что иначе всё упадёт до уровня советских минских НИИ.

> А как же постулат из Peopleware

Люди бывают разными. Есть дебилы, им приятнее в Макдональдсе работать без всяких ЦММАй. Или вот зеки по тюрьмам сидят, тоже интересно им. А мы люди скучные, пишем ерунду всякую, получаем свою зарплату, ни тебе зубы кому-нибудь выбить, ни украсть, ни изнасиловать. Скучно живём.

Ты понимаешь разницу между пользовательской документацией и проектной? Или для тебя это одно и то же? Когда обратишь внимание на эту разницу, волшебства вдруг не станет.

Ты видел их внутреннюю, проектную документацию? Ну конечно не видел, откуда тебе. А вот знакомые из группы MS SQL мне говорили, что у них при переписывании MS SQL c 6.5 на 7.0 не было даже спецификации. Вместо нее был сам 6.5. Волшебство, не правда-ли?

Кроме того, хочу обратить твое внимание на маленькую деталь. Я говорю о продукте на этапе поддержки и развития, когда ему уже лет 5. И о проблемах поддержания документации в актуальном состоянии. Сложно этого не заметить, цитируя фразу
> Все равно от нее ничего не останется после пары лет поддержки.
Или если очень хочется, то можно?

Ну почему по другому не может быть. Может. Я вот, например, самое настоящее "начальство".

И могу тебе от лица "начальства" заявить, что ЕСПД, по которым оформляли документацию Минские НИИ, во-первых, весьма неплохая штука, во-вторых, никак не покрывает цикл развития и поддержки продукта. И вообще, все ГОСТ, касающиеся документации, регламентируют отношения заказчик-исполнитель, и к делу никакого отношения не имеют.

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

У большинства индусов у самих CMM 4 и 5.

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

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

Только вот получается дороже чем в штатах, медленнее, и глючнее. Так что CMM 4+, помноженное на национальные особенности, это гиря на цепочке.

А вот, кстати, еще пример разбирательства "по коду". Я постоянно на своей шкуре чувствую, когда за тобой потом изучаю то, что ты написал. И есть две вещи, которые замедляют "читабельность с первого раза" в 10 раз: это грамотно развязанный код с целью исключения зависимостей, когда 5 штук классов с наследованной дополняемой функциональностью, или опосредствованный обмен между классами через посредников (щину). Тут только бумагу в руки и рисовать :) Иначе фиг поймешь.

Это всё очень мило, если исходить из того, что команда разработчиков не меняется, или меняется плавно.

А в жизни оказывается намного отвратительнее - перед тобой лежит недокументированная система с трэш-кодом, базой данных без схемы и на стенке лозунг "use ~~power~~, sources, Luke", старый разработчик свалил в Париж или в Непал 2 года назад и абсолютно некоммуникабелен.

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

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

Не солидаризуюсь с Вашей позицией, она мне не по нраву.

Edited 2009-05-04 05:41 (UTC)

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

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

"Ненавижу тебя, Чака!" (с) Гарри Гаррисон.
Надо же так мерзко и достоверно описать расклад.

Дык точки входов и назначение объектов - это самое главное. То, чего обычно больше всего не хватает.

Threaded | Top-Level Comments Only

Page 2 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

Re: кстати

no subject

no subject

no subject

no subject

no subject

no subject

no subject

Re: кстати

no subject

no subject