![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Программистское мракобесие
Я почему-то думал, что когда 10 лет толпой людей разрабатывают сложные системы, там не делают так, как я - держа все знания по проекту только в виде кратких текстовых набросок по поводу архитектуры, часть информации в голове(чтобы можно было проектировать в уме в любое время), и основную часть - в виде структуры проектов и кода в системе контроля версий.
А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?
А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?
no subject
Я ничего не "проповедую", а рассказываю о пользе навыка чтения кода. Вы видите то, что хотите видеть.
Я вижу то, что Вы написали.
Он попал в автокатастрофу пять лет назад, и погиб. Проект прекрасно развивается дальше. Я в этой компании, кстати, тоже давно не работаю. Проект продолжает успешно развиваться. Он с 90 года прекрасно развивается, и группа разработки большая, одно это уже должно было Вас натолкнуть на мысль, что все не завязано на одного человека.
Не принципиально, насчёт размера группы. К сожалению, в реальности Вы не можете гарантировать преемственность разработки на уровне коллектива - завтра одновременно свалят несколько ключевых людей, знающих архитектуру системы и будет та же самая проблема.
Так обложитесь документацией - и посмотрите, что будет в третий раз. В четвертый раз Вы решите, что документации было мало, и напишете ее еще больше. В пятый - вылетите из бизнеса, если он у Вас вообще с разработкой связан.
Не вижу никаких причин, с чего бы мне вылетать из бизнеса, кроме как для того, чтобы потрафить Вашему эго.
Пока что у меня идёт всё достаточно неплохо и мне не стыдно перед моими заказчиками за то, что как некоторые завязываю системы на себя и оставляю полунаркотическую зависимость и потребность в сопровождении через большое время после того, как расстались.
А вот такие как Вы орлы сами себе делают вполне определённую репутацию, т.к. что ни шаг по жизни сделают - за спиною у них россыпи чёрных ящиков. Впрочем, я не утверждаю, что лично Ваша деятельность не будет успешна. Я просто считаю такое отношение к заказчику/работодателю несколько нечестным.
Че-то маловато вы себе цифирю написали - Вы напишите сразу 40. Звучите Вы пока так, как будто не разбираетесь ни в том, ни в другом. И не хотите разбираться.
Бла-бла-бла.
Вы начали с перехода на личности в первом сообщении и продолжаете тут вместо того, чтобы сосредоточиться на аргументах по существу.
Это не случайно, потому что на единственный мой тезис - что сопровождаемость системы не должна зависеть от 'живой передачи традиции', а должна опираться на документированность системы, Вам кроме разговоров о том, что документацию невозможно держать в когерентном состоянии с системой ответить нечего.
Ну Вам это может быть невозможно действительно, не умеете, чего уж там.
Так учиться надо. Это не сложно, на самом деле, если система не делается в виде монолитного оковалка, а бьётся на модули. Попробуйте, хотя бы для интересу, может вдруг начнёт получаться :)
Этот путь намного продуктивнее, чем придумывать про неуспешность чужой биографии - я то, замечу, не говорю о том, что Вы лузер или ещё какие-нибудь благоглупости :)
no subject
Хотите разговора по существу? Ок, я не против. Давайте проверим, насколько Вы способны поддерживать беседу по существу. Не переходя на личности.
> Это не случайно, потому что на единственный мой тезис - что сопровождаемость системы не должна зависеть от 'живой передачи традиции', а должна опираться на документированность системы, Вам кроме разговоров о том, что документацию невозможно держать в когерентном состоянии с системой ответить нечего.
(1) То что документацию, отдельную от кода, на практике в большом и длинном проекте невозможно держать в когерентном состоянии - это факт, с которым регулярно сталкиваются почти все. И возразить Вам на него по существу нечего. Эта проблема объективно существует, не так ли? Будем признавать наличие проблемы, спокойно, и без переходов на личности?
(2) То, что сопровождаемость системы не должна зависеть от небольшого количества людей - это тоже вполне понятный факт, и я с этим не спорю.
Мой тезис (3) состоит в том, что документация не есть адекватный способ обеспечить (2) в условиях наличия (1). Но это вовсе не означает, что способа нет. Вот, смотрите, здесь я подробно объясняю, почему (3), и показываю как эффективно и дешево достичь (2). Вот это - работает. Вот ЭТО я рекомендую.
http://metaclass.livejournal.com/367614.html?thread=2743294#t2743294
http://metaclass.livejournal.com/367614.html?thread=2743550#t2743550
Есть ли у Вас что-нибудь сказать по существу?
Если Вам что-то непонятно, например, как проводить code review, или как работает design review, или каким образом происходит устаревание Вашей документации - так Вы, вместо того, чтобы опять колотить себя пяткой в грудь, и рассказывать мне сколько лет Вы в бизнесе (что мне ни в малейшей степени не интересно) - не стесняйтесь - спросите. Я Вам все объясню и покажу, и дам ссылки.
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
Я сейчас участвую в трех таких проектах одновременно, причем на всех трех я и архитектор и разработчик одновременно, а денег и времени на написание и поддержание документации никто не выделяет и выделять не собирается - т.к. если это будет медленнее и дороже, проекты просто станут никому не нужны.
no subject
Идея конечно хорошая, но в реальности получается так:
а) Заказчик не может предоставить достаточно информации о своих требованиях в виде, достаточном для того, чтобы можно было сделать завершенный проект. Не говоря уже об постоянном изменении законодательства.
б) Заплатить сразу деньги, достаточные для того, чтобы покрыть разработку и поддержание документации в актуальном виде, заказчик не может. Вот доплачивать за обслуживание мелкие суммы каждый месяц - нормально.
в) При обслуживании времени на доработку документации опять же нет. "Доработка нужна вчера"
г) Своих специалистов, способных понять техническую документацию на систему в полном объеме там банально нет. Не на кого оставлять систему.
Так что система, которой занимаюсь я, действительно представляет собой черный ящик, знания о ней основаны на устной передаче. И самое главное - я хотел бы написать по ней техническую документацию, но это совершенно не оправдает себя ни в каком смысле - система пишется для одного заказчика, априори является временным решением, которое или нужно будет развивать дальше(если за это вообще когда-нибудь заплатят), или выкидывать и заменять готовым софтом.
А уйти с нее они не могут - по всем вышеописанным причинам внедрить готовый софт они не в состоянии.
no subject
В исходном тексте, однако, разрабатываемый продукт - основной предмет бизнеса для заказчика.