![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Программистское мракобесие
Я почему-то думал, что когда 10 лет толпой людей разрабатывают сложные системы, там не делают так, как я - держа все знания по проекту только в виде кратких текстовых набросок по поводу архитектуры, часть информации в голове(чтобы можно было проектировать в уме в любое время), и основную часть - в виде структуры проектов и кода в системе контроля версий.
А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?
А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?
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 работников, может вы и правда не знаете что такое методология и зачем она нужна. В таких маленьких фирмах она естественно не нужна, лишняя перегрузка. Ну разве что методология экстремального программирования.
Все надеетесь найти мне повод сказать, что я что-то важного не понимаю? :) А ВЫ в каких фирмах работали?