![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Программистское мракобесие
Я почему-то думал, что когда 10 лет толпой людей разрабатывают сложные системы, там не делают так, как я - держа все знания по проекту только в виде кратких текстовых набросок по поводу архитектуры, часть информации в голове(чтобы можно было проектировать в уме в любое время), и основную часть - в виде структуры проектов и кода в системе контроля версий.
А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?
А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?
no subject
Совсем нетяжело и невредно если руководитель тима программеров перед кодированием опишет что и как они собираются делать, и совсем неплохо если каждый программер перед кодированием опишет аналогичто что он собрался делать и после кодирования проапдейтил. Подробности - в коде, а в общем будь любезен в документик. Это не больно, а вносит порядок.
no subject
no subject
Мой пост не является призывом не писать никаких документов, он вообще о другом. Но раз уж зашла речь о документах, могу внести пояснения. Документация и документирование - не цель, не решение проблем, это средство. Которое в целом, очень плохо подходит для решения описанных проблем. Почему так.
1) Завязанность компетенции на единичные ключевые фигуры никак не связана с наличием и отсутствием документации. Вообще. Документация - не единственный и во многих случаях не лучший способ передачи знания. Лучшая защита от такой ситуации - поддержание как минимум двух человек на каждой теме, и налаживание среды для передачи знаний. Например, этому способствуют практики design review, имея передачу знаний своим побочным эффектом.
2) Если пропущен пункт 1, то проблемы будут точно, ибо наличие документации само по себе никак не поможет при уходе ключевых фигур. Во-первых, спагетти-говнокоду не поможет никакая документация. Во-вторых, эта документация никогда на практике не соответствует коду, поэтому она практически бесполезна. Поможет только хорошо написанный, и понятно структурированный, и по делу комментированный код, и соблюдение дисциплины работы с VCS - содержательные комментарии к коммитам критичны. Наличие перечисленного, в свою очередь, также никак не связанно с наличием или отсутствием описательной проектной документации, и определяется наличием coding standard, практики перекрестного code review, и практики design review.
Ваша позиция является следствием убеждения, что факта документирования достаточно для надежной передачи знаний. Это не работает на практике на "живых" проектах, у которых поддержка идет одновременно с разработкой (про что я рассказываю) - документация стремительно устаревает, практически всегда out of date, и кроме того, ее мало кто читает. Кроме того, это просто не главное - в реальности упомянутые факторы связываются с наличием документации исключительно искусственным образом.
no subject
ага, всегда в вашей конторе, в нормальных конторах в основном соответствует, иначе кодер банально открывает дефект на "писальщика дизайна", например. Вы просто не работали в такой методологии.
Не знаю где вы увидели у меня убеждения что факта документирования достаточно, однозначно недостаточно, моё убеждение ДОКУМЕНТИРОВАНИЕ ОБЯЗАТЕЛЬНО.
no subject
ага, всегда в вашей конторе, в нормальных конторах в основном соответствует, иначе кодер банально открывает дефект на "писальщика дизайна", например. Вы просто не работали в такой методологии.
Что касательно "методологии", в которой дизайнеры не пишут код - она сама по себе большая редкость, эффективность ее сомнительна, а ваш процесс поддержания их в актуальном состоянии выглядит научной фантастикой.
1) Как у вас контроллируется, что код соответствует дизайну? Когда это проверяется? Кто на кого дефект открывает?
2) Вот у вас этот код, созданный по дизайн-документу попал в тестирование, и его автору пошли дефекты. "Кодер" каждый раз будет багу открывать, чтобы вы документ поправили, если исправление касается дизайна? А если он этого не сделает (а он не сделает) - как вы это проверите?
3) Вот у вас этот код попал в эксплуатацию, и через год пришли дефекты, исправление которых требует изменения дизайна. Опишите подробно процедуру, которая гарантирует отражение этой правки в документе. Для исправлений дефектов и реализации фичреквестов вы тоже дизайн-документы писать будете, да? И открывать дефекты на эти документы?
Вы работали на "живом" проекте когда нибудь, когда он развивается находясь в эксплуатации? Такого, у которого объем исчисляется миллионами строк кода, и которому не менее 5-8 лет? Поработайте.
> Не знаю где вы увидели у меня убеждения что факта документирования достаточно, однозначно недостаточно, моё убеждение ДОКУМЕНТИРОВАНИЕ ОБЯЗАТЕЛЬНО.
В мои планы не входит спорить с вашими ДОГМАМИ, и вас переубеждать. Я деже не буде комментировать вашу "методологию разработки" - хоть на голове пишите, это ваше дело. Я прояснил свою позицию. Чтобы ее понять, я написал достаточно.
no subject
в процессе тестирования контроллируется, может тест кейсы вы тоже без документов пишете?
2) Вот у вас этот код, созданный по дизайн-документу попал в тестирование, и его автору пошли дефекты. "Кодер" каждый раз будет багу открывать, чтобы вы документ поправили, если исправление касается дизайна? А если он этого не сделает (а он не сделает) - как вы это проверите?
тест кейс создаётся на основании дизайна, если на этапе тестирования открывается дефект а оказывается что это правильно с точки зрения дизайна но неправильно с точки зрения тест кейса то дефект закрывается на основании "бай дизайн", меняется тест кейс так чтобы соответствовал дизайну. Иначе - это косяк кодера. Если у кодера есть притензии к дизайну - открывает дефекты или, как это нередко бывает, сам меняет, потому что сам его и писал.
3) Вот у вас этот код попал в эксплуатацию, и через год пришли дефекты, исправление которых требует изменения дизайна. Опишите подробно процедуру, которая гарантирует отражение этой правки в документе. Для исправлений дефектов и реализации фичреквестов вы тоже дизайн-документы писать будете, да? И открывать дефекты на эти документы?
Зависит от методологии. Если система сделано по дизайну, то это не дефекты а чендж реквесты. Если в рамках поддержки оказалось что в дизайне проблемы - естественно исправлять дизайн, он должен соответствовать системе.
Вот вы говорите год... а вы работали на проекте где разработка закончена 10 лет назад? При этом использован десяток разных технологий и пяток языков программирования?
Вот я вчера взяло документ написанный 7 лет назад. На основании этого документа сегодня можно сесть и написать ту же функциональность. Человек, который это писал (он же и кодировал) давно не работает в фирме, да что человек, того отдела давно не существует. А так я имую полную картинку. Вы пробовали работать в фирме в которой дизайн ведётся в одном месте, разработка во втором а тестирование в третьем? Я никогда не был в Индии или в США, я никогда не видел людей, которые делают то, что мне нужно. Я беру документы с других проектов, анализирую, если они мне подходят - беру код с этих проектов, иначе пришлось бы писать два раза.
"В мои планы не входит спорить с вашими ДОГМАМИ, и вас переубеждать. Я деже не буде комментировать вашу "методологию разработки" - хоть на голове пишите, это ваше дело. Я прояснил свою позицию. Чтобы ее понять, я написал достаточно."
вы просто скажите в каких методологиях вы работали? А то я вижу у вас вся карьера в фирмах до 50 работников, может вы и правда не знаете что такое методология и зачем она нужна. В таких маленьких фирмах она естественно не нужна, лишняя перегрузка. Ну разве что методология экстремального программирования.
no subject
>в процессе тестирования контроллируется,"
В процессе тестирования контроллируется функциональность, соответствие дизайна коду в процессе тестирования никак проверить нельзя. Может быть, вы что-то необычное понимаете под дизайном?
>"может тест кейсы вы тоже без документов пишете?"
Может, и так? Может, тест-кейсы можно хранить не в документах, а в записях в базе данных? Может, эта база - единый трекер дефектов и фич?
>>2) Вот у вас этот код, созданный по дизайн-документу попал в тестирование, и его автору пошли дефекты. "Кодер" каждый раз будет багу открывать, чтобы вы документ поправили, если исправление касается дизайна? А если он этого не сделает (а он не сделает) - как вы это проверите?
> тест кейс создаётся на основании дизайна,
Правда? А может, тест-кейс все-таки, как у всех людей, создается на основании требований? Что вы вообще "дизайном" называете? Вы по какой-такой методологии работаете? Название в студию, плиз.
> Если у кодера есть притензии к дизайну - открывает дефекты или, как это нередко бывает, сам меняет, потому что сам его и писал.
Вопрос остается открыт. Что заставит его отразить изменение в документе? А если он этого не сделает (а он не сделает) - как вы это проверите?
Это "дыра" в вашем процессе, приводящая к расхождению дизайна и кода. Вторая "дыра".
вы просто скажите в каких методологиях вы работали?
А то я вижу у вас вся карьера в фирмах до 50 работников, может вы и правда не знаете что такое методология и зачем она нужна.
>>3) Вот у вас этот код попал в эксплуатацию, и через год пришли дефекты, исправление которых >>требует изменения дизайна. Опишите подробно процедуру, которая гарантирует отражение этой правки >>в документе. Для исправлений дефектов и реализации фичреквестов вы тоже дизайн-документы писать >>будете, да? И открывать дефекты на эти документы?
>Зависит от методологии.
Вы по какой методологии работаете?
>Если система сделано по дизайну, то это не дефекты а чендж реквесты. Если в рамках поддержки оказалось что в дизайне проблемы - естественно исправлять дизайн, он должен соответствовать системе.
Вопрос не снят. Опишите подробно процедуру, которая гарантирует отражение этой правки >>в документе. Где у вас описание процедуры? Нету.
> а вы работали на проекте где разработка закончена 10 лет назад?
Я уже рассказывал, в каком проекте я работал.
> вы просто скажите в каких методологиях вы работали?
Просто говорю. PSP/TSP (эта штука конформна CMMI Level 5), и Feature Drivem Development (к этому процессу очень близок подход CQG, он работает для больших команд из сотен людей, и отлично работает для банковского софта тоже). Еще - по ГОСТ-ам, 19-й программерский, и 24-й ралиоэлектронный. Не считая военного радиоэлектронного, номер забыл, но они походи. А ВЫ по каким "методологиям" работали?
> А то я вижу у вас вся карьера в фирмах до 50 работников, может вы и правда не знаете что такое методология и зачем она нужна. В таких маленьких фирмах она естественно не нужна, лишняя перегрузка. Ну разве что методология экстремального программирования.
Все надеетесь найти мне повод сказать, что я что-то важного не понимаю? :) А ВЫ в каких фирмах работали?
pt. 2
Опять же, наличие предварительного проектирования никак не связано с наличием или отсуствием документов. Проконтроллировать факт его наличия вы можете только проведя design review, а не факт наличия документа, а review во многих случаях можно провести без документа, в форме семинара с докладом у маркерной доски. От чего ему, review, станет только лучше.
Писать документ необходимо только в случаях, если документ фиксирует договоренность группы людей о чем-то, иои проходит процедуру design review, на предмет вылова ошибок. Срок жизни этого документа не превышает срока актуальности этой договоренности, а во втором случае, после дизайн ревью им вообще пользуется только автор.
Важным является следующее - кто и как пользуется документами. Не понимая этого, их не имеет смысла вообще писать.
1) Документы первого вида не имеет смысла поддерживать после того, как договоренность потеряла смысл - они теряют ценность. Как следствие, например, документы-спецификации внутренних интерфейсов живут до фазы интеграции, после чего по факту не поддерживаются, ибо уже нафиг не нужны. Действие, ради которого нужна была договоренность - то есть написание кода группой лиц по предварительному сговору - совершено. Все.
2) Документ второго вида вообще не имеет смысл поддерживать в актуальном состоянии, у него четко определенная цель.
На практике, так все и происходит, и именно поэтому вы НИКОГДА не увидите актуальной документации на живом проекте в развитии и поддержке, если она не генерируется из кода. Касательно документации по уже существующему коду, ее дешевле (и на самом деле, это вообще единственный работающий на практике способ) получать из самого кода автоматически. Для C/C++ используйте doxygen. И это и будет как раз тот самый случай, когда код - лучшая документация, ибо doxygen-документация и есть не более чем специальным образом комментированный код. Просто кому-то приятнее его смотреть в браузере - что на самом деле не принципиально.
Re: pt. 2
"На практике, так все и происходит, и именно поэтому вы НИКОГДА не увидите актуальной документации на живом проекте в развитии и поддержке, если она не генерируется из кода."
Просто блин лечь и умереть, я КАЖДЫЙ ДЕНЬ вижу актуальную документацию.
Re: pt. 2
В нашей "конторе" продукт успешно развивается с 90 года, и к коду возвращаются постоянно. Он - живой, и один и тот же. Поработайте с системой такого возраста и размера (сейчас в ней почти десяток миллионов строк кода), а потом я может быть послушаю ваше мнение о лени, бардаке, и о том, как весело кодеров от дизайнеров разделять.
> Просто блин лечь и умереть...
Валяйте, я не против. Не люблю говорить с людьми, не читающими, что им отвечают. Смысла никакого.
Re: pt. 2
пиписьками хотите померяться? Да вы крутой, и проекты у вас самые крутые в мире (аж с 10 миллионами строк, гыгыгыгыгы :), спорить не буду.
Re: pt. 2
Не самые крутые, есть и "покруче" и посерьезнее. Это, вообще _мелкий_ проект, не идущий ни в какое сравнение, например, с микроэлектронными САПР. Хотя, превосходит по сложности MS SQL, и таки да, достаточно серьезный. В чем проблема-то у вас? Хочется в лени и безалаберности кого-то пообвинять, да не выходит? Или что еще?
> пиписьками хотите померяться?
Боже упаси. Да нафига мне это надо. Я вам отвечаю на ваши "обвинения" в лени и бардаке, не более чем. Вот на это:
"такой подход может быть лишь как оправдание банальной лени и неорганизованности, и ведёт к полному бардаку."
Re: pt. 2
Я сделаю попытку телепатии предыдущего комментатора.
Речь идёт о "конторах" где много мелких "бизнес-приложений" или "веб-сайтов".
Каждый разрабатываемый "веб-сайт" отличается от другого "веб-сайта" той же конторы всем, кроме программирования.
Чем отличительны эти компании?
* Большим количеством разработчиков.
* Большим количеством проектов.
* Отсутствием ярко выраженной тематики бизнеса - т.е. они делают "всё подряд".
* Даже если они делает не "всё подряд", то пересечения наблюдаются только в предметной области, используемых языках, инструментах и никогда - в дизайне или архитектуре
* Либо 90% разработчиков дешёвые и "заменяемые" а 10% "нужные", либо "дорогие" все, но на их эффективность всем положить прибор.
Писал с портрета двух компаний, одна очень мелкая, а другая очень крупная.
С мелкой сталкивается любой россияин, но не замечает её или не знает о ней, с крупной сталкивается почти любой пользовать PC
Re: pt. 2
Пропустил слово.
Re: pt. 2
Предыдущий комментатор вообще вроде как описал свою "контору" - банковский софт, что-то вроде "диасофта" скорее всего. Там в разработке - конвейр. Явно выделяются компоненты, пригодные к повторному использованию, они хорошо документируются, и используются в качестве "кубиков" на заказных проектах. Некий подход.
Только это не "продуктовая" компания, и проблема, о которой я говорю, в ней почти не возникает. Код, во-первых, у них слабосвязен и относительно устойчив - и это основное отличительное свойство, его поддерживать легко.
Во-вторых, данные приложения построены в основном на комбинации покупных технологий, своих собственных технологий там нет.
В третьих, они просто меньше, и очень просто устроены и структурированы по сравнению с биржевыми системами системами класса CQG, которым требуется как собственной разработки сервера БД для работы с таймсериями (SQL-сервера в этом классе задач сосут), так и собственные графические фреймворки (графики навороченные рисовать), так и собственные DSL (трейдерские индикаторы и стратегии описывать). Требования к банковскому софту помягче - нет требований рилтайма, не надо уметь работать в отказоустойчивом кластере на сотне серверов, и не требуется собрать котировки со всех бирж по всему миру в единый "фид". Короче, простой он, банковский софт, на самом деле.
Или, скажем, если сравнить с тем же MS Office. Майкрософт, впрочем, предпочитает в случае с офисом просто избавляться от старого кода в новой версии (речь не о Visio с Project - это как раз legacy), и не иметь названных проблем, переписывая его нафиг - средства позволяют. Или, скажем, с сервером компьютерной телефонии или коллцентром.
Но при этом, оратор считает, что он знает все, и люди говорящие о поддержке больших систем - просто ленивы и безалаберны. Даже это понятно - он другого-то софта не видел, кроме банковского, с чем ему сравнивать. Короче, все понятно, что тут телепатировать. :)
Re: pt. 2
Я просто сделал две ошибки:
1) повторил его грех "знаю всё" и начал телепатить.
2) предположил, что поскольку Вы работали над long-time-support системы, то Вы, возможно, не знаете как обстоит дела в лавках пишуших "одноразовые приложение". Похоже, Вы это знаете куда лучше меня =)