![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Программистское мракобесие
Я почему-то думал, что когда 10 лет толпой людей разрабатывают сложные системы, там не делают так, как я - держа все знания по проекту только в виде кратких текстовых набросок по поводу архитектуры, часть информации в голове(чтобы можно было проектировать в уме в любое время), и основную часть - в виде структуры проектов и кода в системе контроля версий.
А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?
А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?
no subject
Это на фоне то Вашей последующей реплики? Я вижу, что жанр нашей переписки Вы уже выбрали совершенно однозначно.
(1) То что документацию, отдельную от кода, на практике в большом и длинном проекте невозможно держать в когерентном состоянии - это факт, с которым регулярно сталкиваются почти все. И возразить Вам на него по существу нечего. Эта проблема объективно существует, не так ли? Будем признавать наличие проблемы, спокойно, и без переходов на личности?
Есть проблема трудоёмкости, нет проблемы невозможности.
Сталкиваются почти все, поддерживают не все, спорить не буду.
Про невозможность - ну расскажите разработчикам из компании IBM например. Почему то у них такой проблемы нет.
Разумеется, никто не может постулировать 100% соответствие. Но и постоянное удержание 9x процентов - очень хорошая и полезная практика.
Мой тезис (3) состоит в том, что документация не есть адекватный способ обеспечить (2) в условиях наличия (1). Но это вовсе не означает, что способа нет. Вот, смотрите, здесь я подробно объясняю, почему (3), и показываю как эффективно и дешево достичь (2). Вот это -работает. Вот ЭТО я рекомендую.
Есть ли у Вас что-нибудь сказать по существу?
Да, есть.
Документация не является сама по себе единственным способом обеспечить как Вы выразились (2), но без её наличия адекватное (2) попросту невозможно.
Более того, наличие адекватной документации по системе критично для тех случаев, когда Вы открываете доступ к бывшим внутренним интерфейсам системы для сторонних разработчиков - т.к. в код их пускать малоинтересно, а такая необходимость возникает у многих и регулярно.
То, что наличие такой документации ускоряет адаптацию новых разработчиков к проекту - это факт, который не подлежит обсуждению, если мы только исходим из того, что у нас в команде работают не только мегазвёзды, но и середнячки или даже 'просто кодеры'.
Вопрос о том, каким образом собирается документация - с помощью каких-то полуавтоматических систем или вручную - это вопрос отдельный, но в любом случае, полностью автоматическая её генерация по комментам - вряд ли хорошая идея. Т.к. таким способом можно сделать текст быстрым, но невозможно сделать его хорошим с точки зрения человеческого восприятия.
no subject
Есть проблемы а) высокой трудоемкости, которая обеспечивает практическую невозможность, и б) целесообразности.
У Вас есть что сказать предметно по обеим проблемам?
> Разумеется, никто не может постулировать 100% соответствие. Но и постоянное удержание 9x процентов - очень хорошая и полезная практика.
Не вижу в Ваших словах никакой практики - только декларации. Опишите процесс поддержания документации, который сработает в ситуации поддержки, о которой я говорю. Если Вы не в курсе, что это такое и на что похоже, а Вы не в курсе - это когда у вас примерно половина разработки управляется запросами в трекере - частично дефектами, частично фичреквестами. Поток этих запросов большой, они по отдельности - относительно мелкие, и за год приводят к поистине удивительным транформациям кода и его расхождению с документацией.
> Да, есть.
> Документация не является сама по себе единственным способом обеспечить как Вы выразились (2), но без её наличия адекватное (2) попросту невозможно.
"Попросту невозможно" - это по существу! :))) Докажиземлюешь. :) Вот я Вам "попросту" объясняю в тексте по ссылкам, как это делать, чтобы было "возможно", и почему так. И почему ваши документы проблем не решают, объясняю. Более того - я прекрасно знаю, как это работает на практике. Видел неоднократно. Читать и понимать, что там написано, будем? По существу, предметные возражения - будут?
no subject
У Вас есть что сказать предметно по обеим проблемам?
Я уже Вам сказал, Вы не увидели. Трудоемкость высока, целесообразность возникает для любых предприятий с высокими технологическими требованиями. Для тех кто в танке привожу простой жизненный пример. Если у Вас есть софт, управляющий логикой работы некоего прибора в самолёте или там элемента АЭС - мало кого гребут Ваши творческие изыски по передаче знаний в коллективе.
Для проекта критично, чтобы в этом софте можно было быстро разобраться в любой конкретно взятый момент лет этак 30-40 после сдача объекта в эксплуатацию. Показанный Вами способ сопровождения системы реализации этого требования не обеспечивает. Точка.
Впрочем, можно и продолжить, указав на то, что та же самая проблема встаёт для любого предприятия, которое живёт чуть более, чем несколько лет и которое не связано с IT как таковой. Тиму Мазеру очень хорошу рулить компанией, которая производит софт. Потому что у него ничего кроме софта и нет, и он имеет возможность и полное право фокусировать своё внимание на софте.
Когда Вы делаете систему управления предприятием, занимающимся какой-то иной деятельностью - Вы обнаруживаете, что фокус внимания руководства компании сосредоточен отнюдь не на IT-подразделении.
Практически это означает, что вероятность более-менее резких смен состава IT-подразделения достаточно велика.
И тут (снова про трудоёмкость), если Вы экономите на написании документации - Вы экономите своё время за счёт чужого.
Подход понятный, но, как минимум, надо честно декларировать последствия тому, кто заказывает музыку.
Если Вы не в курсе, что это такое и на что похоже, а Вы не в курсе - это когда у вас примерно половина разработки управляется запросами в трекере - частично дефектами, частично фичреквестами. Поток этих запросов большой, они по отдельности - относительно мелкие, и за год приводят к поистине удивительным транформациям кода и его расхождению с документацией.
Кончайте высказываться в мой адрес, надоели уже эти глупости.
Вы просто не понимаете, где должна проходить граница между документацией и трекером - только и всего. Впрочем, подозреваю, что понимаете, но просто делаете вид из риторических соображений.
Попросту невозможно" - это по существу! :))) Докажиземлюешь. :) Вот я Вам "попросту" объясняю в тексте по ссылкам, как это делать, чтобы было "возможно", и почему так
Ваше объяснение - это не объяснение а рассказ в стиле 'у нас работает'. Вы мне расскажите, что с поддержкой Вашей системы произойдёт после того, как состав разработчиков сменится процентов так на 100% - нет рассказа, будем считать, что не возможно.
no subject
Я сейчас участвую в трех таких проектах одновременно, причем на всех трех я и архитектор и разработчик одновременно, а денег и времени на написание и поддержание документации никто не выделяет и выделять не собирается - т.к. если это будет медленнее и дороже, проекты просто станут никому не нужны.