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