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

[metaclass]

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

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

Comments

pt. 2

[gaperton.livejournal.com]

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

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

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

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

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

Re: pt. 2

[sergiej.livejournal.com]

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

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

Re: pt. 2

[gaperton.livejournal.com]

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

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

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

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

Re: pt. 2

[sergiej.livejournal.com]

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

Re: pt. 2

[gaperton.livejournal.com]

> Да вы крутой, и проекты у вас самые крутые в мире (аж с 10 миллионами строк, гыгыгыгыгы :), спорить не буду.

Не самые крутые, есть и "покруче" и посерьезнее. Это, вообще _мелкий_ проект, не идущий ни в какое сравнение, например, с микроэлектронными САПР. Хотя, превосходит по сложности MS SQL, и таки да, достаточно серьезный. В чем проблема-то у вас? Хочется в лени и безалаберности кого-то пообвинять, да не выходит? Или что еще?

> пиписьками хотите померяться?

Боже упаси. Да нафига мне это надо. Я вам отвечаю на ваши "обвинения" в лени и бардаке, не более чем. Вот на это:
"такой подход может быть лишь как оправдание банальной лени и неорганизованности, и ведёт к полному бардаку."

Re: pt. 2

[zamotivator.livejournal.com]

В нашей "конторе" продукт успешно развивается с 90 года, и к коду возвращаются постоянно. Он - живой, и один и тот же. Поработайте с системой такого возраста и размера (сейчас в ней почти десяток миллионов строк кода), а потом я может быть послушаю ваше мнение о лени, бардаке, и о том, как весело кодеров от дизайнеров разделять.
Я сделаю попытку телепатии предыдущего комментатора.
Речь идёт о "конторах" где много мелких "бизнес-приложений" или "веб-сайтов".
Каждый разрабатываемый "веб-сайт" отличается от другого "веб-сайта" той же конторы всем, кроме программирования.
Чем отличительны эти компании?
* Большим количеством разработчиков.
* Большим количеством проектов.
* Отсутствием ярко выраженной тематики бизнеса - т.е. они делают "всё подряд".
* Даже если они делает не "всё подряд", то пересечения наблюдаются только в предметной области, используемых языках, инструментах и никогда - в дизайне или архитектуре
* Либо 90% разработчиков дешёвые и "заменяемые" а 10% "нужные", либо "дорогие" все, но на их эффективность всем положить прибор.

Писал с портрета двух компаний, одна очень мелкая, а другая очень крупная.
С мелкой сталкивается любой россияин, но не замечает её или не знает о ней, с крупной сталкивается почти любой пользовать PC

Re: pt. 2

[zamotivator.livejournal.com]

всем, кроме языка программирования
Пропустил слово.

Re: pt. 2

[gaperton.livejournal.com]

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

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

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

Или, скажем, если сравнить с тем же MS Office. Майкрософт, впрочем, предпочитает в случае с офисом просто избавляться от старого кода в новой версии (речь не о Visio с Project - это как раз legacy), и не иметь названных проблем, переписывая его нафиг - средства позволяют. Или, скажем, с сервером компьютерной телефонии или коллцентром.

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

Re: pt. 2

[zamotivator.livejournal.com]

Мда, Вы предложили неожиданный для меня взгляд.
Я просто сделал две ошибки:
1) повторил его грех "знаю всё" и начал телепатить.
2) предположил, что поскольку Вы работали над long-time-support системы, то Вы, возможно, не знаете как обстоит дела в лавках пишуших "одноразовые приложение". Похоже, Вы это знаете куда лучше меня =)