?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Читай код

Posted on 2009.05.03 at 16:01

Comments:


sardonyx13
sardonyx13 at 2009-05-03 20:09 (UTC) (Link)
Зря отказался от диаграмки 5-летней давности. В ней можно было бы увидеть идеи которые закладывались изначально, а не привнесены потом (начальные требования в конце концов). Особенно если успело погадить потом очень много народа.
P.S. при этом никто не отменяет критического отношения к ней.

P.P.S. вот не удержался и отписался всё-таки :-)

Gaperton
gaperton at 2009-05-03 20:27 (UTC) (Link)
А что мне на нее смотреть, на диаграмму ITL пятилетней давности? :) Я его и так вдоль и поперек разобрал по коду, включая дизайн и эволюцию. Реликтовые отложения - их по коду гораздо лучше видно. :)

Сначала не было операторов, были толко символы. Потом появлились простые (векторные) операторы и спреды. Потом кто-то придумал делать из них деревья, применяя один на другой. Потом, всех достали тормоза и большой расход памяти, и Мэтт придумал степовые операторы. Потом, Брайан придумал, что степовые операторы можно делать COM-операторами. Вот и вся цепочка, собственно. Не считая мелочей - например, как Мэтт придумал нагнуть ITL, чтобы заработали торговые системы, и как Брайан хитро придумал все захачить, чтобы получились операторы с переменной временной шкалой. За что ему отдельное спасибо - трахался полгода, переписывая его P&F. Никак не хотела работать, сволочь, пока не воспроизвел все глюканы Брайановского P&F один-в-один в своем.

Вот и вся дизайн-эволюция :). Впрочем, это ничто по сравнению с увлекательной историей T&S и BB :).
idispatch
idispatch at 2009-05-03 21:18 (UTC) (Link)
ну вот. вы сначала посчитайте время, потраченное одним человеком на написание архитектурной документации и сложите его с прочтением 10 человеками в вашей тиме, потом сраните это со временем, когда каждый будет по одиночке это говнище разгребать и читать, писать письма, подходить с простыми вопросами к одному дизайнеру, а потом, некто хитрый Тол, Мэтт, Брайан или кто у вас там, кто по идее должен был это документировать, это его обязанность, - все дизайн решения, но не делал это, правильно, а зачем, код то и так читается, зарплата платится и так. он и так получает зарплату, а код струячить по одиночке - оно коненчо интереснее, чем объяснять другим как и почему, а тем более писать документацию. пускаю сами разгребают. это назыавается безотвественность, с точки зрения конторы, а с вашей, программистской точки зрения - это называется джоб секьюрити, чем больше информации в голове - тем ты ценнее, тем меньше шанс, что выгонят. так как не выгонят того, кто все эти 50 мегабайт когда написал и незадокументировал, деньки то уже уплачены. сами себя обрекаете на постоянную работу с легаси системами. в общем - отсутсвие документации ( и юнит тестов, туда же) автоматически сводит ваш код в легаси, старья, и все ново пришедшие будут плеваться и дружно переписывать уже написанное (и, возможно, в какой то степени, отлаженное). ну, или за неимением возможности переписывать, втыкать костыли в код такие, что потом разобраться - что куда откуда и почему - будет очень сложно. в общем не убедили, это не экскьюз и не оправдание отсутствия документации по проекту. код читать можно, но это дорого для компании, считается количеством человек занятых на проекте помноженном на количесвто часо чтения легаси кода, копания, помноженного на количество строк - мегабайт кода. что я могу сказать - удачи, и удовольствия чтения. дешевле - иметь с самого начала библиотеку документации по коду, документирвоание всех дизайн решений, rationale, performance testing matrices, sadd, dad, и тд. в зависимости от выбранной модели в в вашей конторе. это не дорого, если разобраться. более того, это уменьшает риск разработки. код это конечно здорово, но вы нигде не указываете время которое тратят люди, на чтение и осмысление уже написанного, или написанного но удаленного, за ненадобностью, или не оправдашего себя по производительности и другим требованиям. этого вы в коде не прочтете, а в документах могли бы. поэтому тратите время на написание велосипедов.
Gaperton
gaperton at 2009-05-03 21:32 (UTC) (Link)
Ну почему тексты о пользе документации оформлены так, что отбивают не только охоту ее писать, но и читать? :)

Простите, Вы не могли бы разбить свой текст на абзацы - такой длинный текст сплошняком совершенно нечитабелен. Абзац - он отделяет мысли друг от друга.
Gaperton
gaperton at 2009-05-03 21:41 (UTC) (Link)
Выглядит, как поток сознания какой-то. Крэшдамп. Слава богу, в UTF-8, а не в шестнадцатеричном виде. Вы документацию свою так же оформляете?
n0way
n0way at 2009-05-03 22:46 (UTC) (Link)
человек резонно возражает. а вам, похоже, нечего ответить.
Gaperton
gaperton at 2009-05-03 23:42 (UTC) (Link)
А что, вы правда считаете это сколько-нибудь серьезным возражением? Эту "резонную" песню в разных обработках все неоднократно слышали от разных людей, и читали в умных книгах. Оно конечно понятно, что если бы волшебным образом была понятная документация, которая всегда актуальна, написана кратко, и по существу, да еще появлялась и обновлялась бы бесплатно - то тогда да. Никто бы никогда код не читал, все б такую замечательную документацию только и смотрели.

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

Все об этом говорят, что хорошо бы так, да. Но на практике этого неуловимого Джо почему-то никто не видел. Это не наводит ни на какие мысли? Покажите мне хотя бы один долгоживущий КОММЕРЧЕСКИ УСПЕШНЫЙ проект, в котором есть актуальная и подробная проектная документация по коду, которая не "уплыла" бы ПРИ РАЗВИТИИ И ПОДДЕРЖКЕ, и поддерживается в актуальном состоянии. Нет таких проектов.

Исключения составляют случаи, когда документация генерируется из кода автоматически, а это как раз то, о чем я говорю. А если вам кажется, что не смотря ни на что есть - то я ни в жисть вам не поверю, пока не увижу описания процесса контроля качества, поддерживающего ее в актуальном состоянии в случае РАЗВИТИЯ И ПОДДЕРЖКИ. А после того, как будет приведено описание процесса (в чем я лично сомневаюсь), а не пионерское бла-бла-бла с биением себя пяткой в грудь (что мы пока наблюдаем), можно будет сначала
1) половить процесс на "дырки", которые приведут к расползанию документации с кодом. Выяснится, что дырок этих будет дофига, и что качество и актуальность документации на самом деле ничем не гарантирована. А потом
2) посчитать его оверхэд и спросить окружающих, считают ли они такие затраты оправданными. Если процесс будет хоть что-то гарантировать, затраты будут огромными, и зависеть примерно квадратично от размера кода. Ответ окружающих вас удивит - в здравом уме на это пойдет только идиот. Впрочем, подождем описания процесса, зачем делать за пионеров работу. Держу пари, будет ссылка на общий стандарт, если вообще будет, потому что нихрена на самом деле он не знает.

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

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

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

К тому же, всем, ВСЕМ, у кого есть мало-мальский реальный опыт, известно, как составляется проектная документация в данных случаях, воспринимаемая исполнителем как бесполезное, никому не нужное зло. Она на практике даже в этих случаях outdated, и не соответствует действительности, ибо стоимость процедур контроля качества для РЕАЛЬНОГО обеспечения ее актуальности ужасающая. Ее соответствие нерентабельно даже проверять в большинстве заказных проектов, не говоря о том, что вести разработку строго по ней, так как чистый "ватерфол" в природе попросту невозможен.

Зная это, и то, что заказчик также не произведет проверки, в реальности в большинстве случаев вполне сознательно производится тонна документации, ПРИМЕРНО, в общих чертах напоминающей результат. Она на практике читается заказчиком один раз, если вообще читается.

Исключения из этого настолько редки, что из них глупо делать правило, и в любом случае не имеют значения, так как заказчик при развитии системы документацию все равно выбросит, вместо того, чтобы поддерживать в актуальном состоянии.
Gaperton
gaperton at 2009-05-03 23:45 (UTC) (Link)
"Что вовсе не означает, что они есть."
->
"Что вовсе не означает, что их нет".
metaclass
metaclass at 2009-05-04 06:56 (UTC) (Link)
Возражает может и обоснованно, но прочитать невозможно.
Если так писать документацию - то лучше бы ее вообще не было.
Макс Лапшин
levgem at 2009-06-09 07:05 (UTC) (Link)
отнюдь. Я попытался прочитать и сломался на третьей строчке.
Always crashing in the same car
debose at 2009-06-14 15:43 (UTC) (Link)
+1
Previous Entry  Next Entry