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

[metaclass]

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

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

Comments

[gaperton.livejournal.com]

> Есть проблема трудоёмкости, нет проблемы невозможности.

Есть проблемы а) высокой трудоемкости, которая обеспечивает практическую невозможность, и б) целесообразности.

У Вас есть что сказать предметно по обеим проблемам?

> Разумеется, никто не может постулировать 100% соответствие. Но и постоянное удержание 9x процентов - очень хорошая и полезная практика.

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

> Да, есть.
> Документация не является сама по себе единственным способом обеспечить как Вы выразились (2), но без её наличия адекватное (2) попросту невозможно.

"Попросту невозможно" - это по существу! :))) Докажиземлюешь. :) Вот я Вам "попросту" объясняю в тексте по ссылкам, как это делать, чтобы было "возможно", и почему так. И почему ваши документы проблем не решают, объясняю. Более того - я прекрасно знаю, как это работает на практике. Видел неоднократно. Читать и понимать, что там написано, будем? По существу, предметные возражения - будут?

[golosptic.livejournal.com]

Есть проблемы а) высокой трудоемкости, которая обеспечивает практическую невозможность, и б) целесообразности.
У Вас есть что сказать предметно по обеим проблемам?

Я уже Вам сказал, Вы не увидели. Трудоемкость высока, целесообразность возникает для любых предприятий с высокими технологическими требованиями. Для тех кто в танке привожу простой жизненный пример. Если у Вас есть софт, управляющий логикой работы некоего прибора в самолёте или там элемента АЭС - мало кого гребут Ваши творческие изыски по передаче знаний в коллективе.
Для проекта критично, чтобы в этом софте можно было быстро разобраться в любой конкретно взятый момент лет этак 30-40 после сдача объекта в эксплуатацию. Показанный Вами способ сопровождения системы реализации этого требования не обеспечивает. Точка.

Впрочем, можно и продолжить, указав на то, что та же самая проблема встаёт для любого предприятия, которое живёт чуть более, чем несколько лет и которое не связано с IT как таковой. Тиму Мазеру очень хорошу рулить компанией, которая производит софт. Потому что у него ничего кроме софта и нет, и он имеет возможность и полное право фокусировать своё внимание на софте.

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

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

Попросту невозможно" - это по существу! :))) Докажиземлюешь. :) Вот я Вам "попросту" объясняю в тексте по ссылкам, как это делать, чтобы было "возможно", и почему так
Ваше объяснение - это не объяснение а рассказ в стиле 'у нас работает'. Вы мне расскажите, что с поддержкой Вашей системы произойдёт после того, как состав разработчиков сменится процентов так на 100% - нет рассказа, будем считать, что не возможно.

[metaclass.livejournal.com]

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

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