![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Программистское мракобесие
Я почему-то думал, что когда 10 лет толпой людей разрабатывают сложные системы, там не делают так, как я - держа все знания по проекту только в виде кратких текстовых набросок по поводу архитектуры, часть информации в голове(чтобы можно было проектировать в уме в любое время), и основную часть - в виде структуры проектов и кода в системе контроля версий.
А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?
А вот оказывается, что так и делают:
К этому моменту я выкинул все свои диаграммы классов, за ненадобностью – зачем на них смотреть, если они давно уже в голове?
no subject
А ввести в курс дела можно и лично. Так будет гораздо быстрее и эффективнее, чем по документам. По крайней мере, если слушатель или докладчик деревянный - это будет заметно сразу.
Вообще, в статье доносится несколько другая мысль, которая глубже, чем призыв не писать документации. Я конечно понимаю, что у вас тут своя дискуссия, но все-таки.
no subject
no subject
Поэтому, этой "правильно" написанной с трудом документации даже в лучшем исходе (продукт успешен) никто не воспользуется. Такова суровая правда жизни. Идти против нее - писать против ветра, ИМХО.
no subject
Убил бы разработчиков за такое. Говорят (и я склонен верить), что в самом САПе не осталось ни одного человека, который представлял бы себе систему полностью. Что уж говорить о попытках самому по несоответствующей документации и тупорылых консультантах воссоздать картинку архитектуры и как там разработчики мыслили
Так что читать код -- это да. Но есть такой код, который жизни не хватит осознать.
no subject
no subject
no subject
no subject
no subject
Я говорю о коммерчески успешной системе, которая находится в поддержке и развитии. Никакого "лоха" в этом случае нет, давно идут продажи и эксплуатация.
> мне лично не везло в жизни с проектами, каюсь, там были ограниченные финансовые ресурсы и время и приходилось делать четко и быстро, а так без карты острова не получается
Эта "карта" будет выброшена в топку, через некоторое время после переходе системы в эксплуатацию и развитие. Вам действительно не везло с проектами - самое интересное начинается ПОСЛЕ того, как начинается эксплуатация. Только тогда ты и имеешь шанс посмотреть, как обойдутся с "картой".
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
А в жизни оказывается намного отвратительнее - перед тобой лежит недокументированная система с трэш-кодом, базой данных без схемы и на стенке лозунг "use
power, sources, Luke", старый разработчик свалил в Париж или в Непал 2 года назад и абсолютно некоммуникабелен.В результате тратится пол года на то, чтобы прочесть весь этот код чуть менее, чем целиком и хоть как-то въехать в архитектуру системы.
То, что Вы написали в своей статье - выглядит очень красиво с точки зрения крутого программерского профессионализма, а с точки зрения ведения бизнеса - это глюкавый долбодятлизм, уж извините. За такими профессионалами я дважды в своей жизни разгребал авгиевы конюшни - мне то что, я свои деньги взял, а у заказчика по нескольку месяцев ничего не работает и никто не может сказать почему и когда оно закончится.
Не солидаризуюсь с Вашей позицией, она мне не по нраву.
no subject
Ожидания, что у вас когда-нибудь будет документация, которая избавит вас от необходимости читать код - крайне наивны. Такого не бывает никогда.
> За такими профессионалами я дважды в своей жизни разгребал авгиевы конюшни... а с точки зрения ведения бизнеса - это глюкавый долбодятлизм, уж извините.
Таких профессионалов, о которых говорю я, вы и близко не видели. И не учите успешные компании, входящие в тройку лидеров в своей отрасли, вести бизнес.
no subject
А ещё было бы полезно прекратить делать вид, что существует только две эти возможности и что невозможно делать систему и с качественным понятным кодом и с проработанной документацией одновременно.
Ожидания, что у вас когда-нибудь будет документация, которая избавит вас от необходимости читать код - крайне наивны. Такого не бывает никогда.
А это не повод проповедовать отказ от документации.
Таких профессионалов, о которых говорю я, вы и близко не видели.
Да вот порассказывайте мне, каких профессионалов я видел, а каких нет.
Надо полагать, чужой жизненный опыт Вы на расстоянии дигностируете, так же как и все классы проекта помните наизусть.
Как раз таких - блестяще помнящих наизусть код громадной системы и не снисходящих до её документирования - понавидался достаточно.
И профессионализм их - за чужой счёт.
И не учите успешные компании, входящие в тройку лидеров в своей отрасли, вести бизнес.
Гы-гы-гы.
Вы - не успешная компания.
Вы - программист, нанятой успешной компанией.
В оценке того, как вести бизнес Вы, судя по всему слабо компетентны - иначе бы просто задумались о том, что стало бы с тем замечательным проектом, на котором Вас учили отказу от документации, если бы его центрального разработчика в одночасье переехал автомобиль. До того, как Вы чему-то научились.
И свои указания о том, кого чему учить Вы направляете человеку, который в бизнесе (именно в бизнесе, а не в кодинге и не в системной архитектуре) 12ый год. Чего для бизнеса стоит блестящий код, который удаётся понять только в процессе передачи эзотерических знаний от разработчика к разработчику я, как Вам уже написал, наблюдал вживую два раза. На примерах, когда эзотерическая связь в силу внешних обстоятельств, прерывалась неожиданно.
Повторю ещё раз - отказ от создания документации - это гнилые понты, оправданные разве что в условиях серьёзной нехватки ресурсов и жесточайших сроков на разработку. И разговоры о том, что документацию можно заменить "хорошим комментированием" - это дешёвая отмазка.
Если Вам ломы писать документацию вне программы меняя её логику, будут, очевидно, ломы и в актуализации комментариев.
no subject
Я не делаю этого "вида", а расставляю приоритеты.
> А это не повод проповедовать отказ от документации.
Я ничего не "проповедую", а рассказываю о пользе навыка чтения кода. Вы видите то, что хотите видеть.
>> И не учите успешные компании, входящие в тройку лидеров в своей отрасли, вести бизнес.
> Гы-гы-гы.
> В оценке того, как вести бизнес Вы, судя по всему слабо компетентны - иначе бы просто задумались о том, что стало бы с тем замечательным проектом, на котором Вас учили отказу от документации, если бы его центрального разработчика в одночасье переехал автомобиль. До того, как Вы чему-то научились.
Он попал в автокатастрофу пять лет назад, и погиб. Проект прекрасно развивается дальше. Я в этой компании, кстати, тоже давно не работаю. Проект продолжает успешно развиваться. Он с 90 года прекрасно развивается, и группа разработки большая, одно это уже должно было Вас натолкнуть на мысль, что все не завязано на одного человека.
> И свои указания о том, кого чему учить Вы направляете человеку, который в бизнесе (именно в бизнесе, а не в кодинге и не в системной архитектуре) 12ый год. Чего для бизнеса стоит блестящий код, который удаётся понять только в процессе передачи эзотерических знаний от разработчика к разработчику я, как Вам уже написал, наблюдал вживую два раза. На примерах, когда эзотерическая связь в силу внешних обстоятельств, прерывалась неожиданно.
Так обложитесь документацией - и посмотрите, что будет в третий раз. В четвертый раз Вы решите, что документации было мало, и напишете ее еще больше. В пятый - вылетите из бизнеса, если он у Вас вообще с разработкой связан. Че-то маловато вы себе цифирю написали - Вы напишите сразу 40. Звучите Вы пока так, как будто не разбираетесь ни в том, ни в другом. И не хотите разбираться.
> Повторю ещё раз - отказ от создания документации - это гнилые понты
Да хоть десять раз повторите. Когда Вы будете в таком бизнесе, в котором Вы сможете разработать программный комплекс хотя бы в пару миллионов строк, и Вы при этом сможете удержать разработку под контролем в течении лет хотя бы 8, тогда и будете мне что-то рассказывать про понты, колотить себя пяткой в грудь насчет того, сколько вы в бизнесе, и рассказывать как Вам удается все здорово докментировать. И будете учить компанию, существующую с 80 года, как ей вести дела и как организовывать разработку.
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)
(no subject)
(no subject)
no subject
Идея конечно хорошая, но в реальности получается так:
а) Заказчик не может предоставить достаточно информации о своих требованиях в виде, достаточном для того, чтобы можно было сделать завершенный проект. Не говоря уже об постоянном изменении законодательства.
б) Заплатить сразу деньги, достаточные для того, чтобы покрыть разработку и поддержание документации в актуальном виде, заказчик не может. Вот доплачивать за обслуживание мелкие суммы каждый месяц - нормально.
в) При обслуживании времени на доработку документации опять же нет. "Доработка нужна вчера"
г) Своих специалистов, способных понять техническую документацию на систему в полном объеме там банально нет. Не на кого оставлять систему.
Так что система, которой занимаюсь я, действительно представляет собой черный ящик, знания о ней основаны на устной передаче. И самое главное - я хотел бы написать по ней техническую документацию, но это совершенно не оправдает себя ни в каком смысле - система пишется для одного заказчика, априори является временным решением, которое или нужно будет развивать дальше(если за это вообще когда-нибудь заплатят), или выкидывать и заменять готовым софтом.
А уйти с нее они не могут - по всем вышеописанным причинам внедрить готовый софт они не в состоянии.
no subject
В исходном тексте, однако, разрабатываемый продукт - основной предмет бизнеса для заказчика.
no subject
Мании величия прикрутите фитилёк. Вы - не компания, существующая с 1980го года. Вы - человек, нанятый, судя по тому что Вы пишете, а не являющийся совладельцем бизнеса, последствия деятельности которого будет разгребать кто-то такой, как я. Лет через несколько, после того, как Вы перейдёте по своей карьерной лестницы куда-то ещё, а на старом месте настанет необходимость провести рефакторинг системы. Вам на это вполне предсказуемое будущее в целом наплевать - ну так судя по тому что Вы пишете, Вы бизнес не ведёте и не собираетесь вести.
Поэтому я, разумеется, не учу бизнесу ни Вас, ни нанявшую Вас компанию. Вас вообще бесполезно ему учить на текущий момент, а компанию свою в бизнес-качестве Вы явно не представляете. Да и если бы кого-то надо было бы хоть чему-то поучить - я бы это делал не в ЖЖо и денег бы за обучение взял.
Я просто даю трезвую оценку тому насколько целесообразно брать на работу подобных Вам 'системых архитекторов', которые вместо документирования внутренних API, Database Layout и проч. громко рассказывают о том, что 'лучшая документация - это код'.
Нецелесообразно. И если бы мне, на текущем месте деятельности, например, руководитель разработчиков что-то такое сообщил - я бы сильно подумал о том, что его надо заменить.
no subject
Случай тяжелый. У меня нет мании величия, уважаемый. Критикуя подход КОМПАНИИ в моем лице,, Вы пытаетесь учить жизни КОМПАНИЮ, а не меня. И не имеет никакого значения, совладелец я бизнеса, или нет. Разгребать "последствия моей деятельности" - Вы фитилек-то мании величия прикрутите, хорошо? :) Тим Мазер, владелец CQG, как нибудь все "разгребет" и без Ваших советов. Последние 29 лет он как-то без Ваших советов обходился, и ему это пошло впрок - умудрился стать мультимиллионером. А Вам до уровня, когда Вам потребуется архитектор, способный справится с миллионами строк кода - еще расти и расти. Растилку отрастите сначала, ок? :)
> Я просто даю трезвую оценку тому насколько целесообразно брать на работу подобных Вам 'системых архитекторов', которые вместо документирования внутренних API, Database Layout и проч. громко рассказывают о том, что 'лучшая документация - это код'.
Во-первых, отучайтесь лезть с оценками, когда Вас о них никто не просит. Есть неплохой шанс выставить себя клоуном.
Во-вторых, уважаемый, я менеджер, а не архитектор. Меня брать на работу архитектором действительно нецелесообразно - обойдусь слишком дорого. :)
И в третьих - Вы не в курсе, что давным давно есть возможность не пИсать против ветра, и всю "документацию по внутренним API" генерировать из кода и комментариев автоматически? А вы поинтересуйтесь, прежде чем чепуху-то молоть. К Вашему сведению, Вся документация по Java API генерируется именно таким образом. JavaDoc, если мне неизменяет память. Для С/С++ - Google "doxygen". Не забанили на гугле-то Вас, трезвый Вы оценщик архитекторов наш? :)
no subject
Уровень аргументации, мягко скажем, несерьёзный.
Вы путаете 'жизнь', 'бизнес' и 'технологическую дисциплину'.
Судя по тому, что Вы рассказали, Вы публично выступаете от имени компании по вопросам 'технологической дисциплины', а к бизнесу имеете опосредованное отношение.
Повторю ещё раз - я никого (включая Вас) вообще в данном случае ничему учить не собираюсь. Но находясь в публичном пространстве - имею право и буду давать свои оценки Вашим публичным высказываниям.
Разгребать "последствия моей деятельности" - Вы фитилек-то мании величия прикрутите, хорошо? :)
Пошлым образом манипулируете текстом. Я нигде не писал, что лично я буду последствия лично Вашей деятельности разгребать. Кому-то скорее всего придётся.
Тим Мазер, владелец CQG, как нибудь все "разгребет" и без Ваших советов. Последние 29 лет он как-то без Ваших советов обходился, и ему это пошло впрок - умудрился стать мультимиллионером. А Вам до уровня, когда Вам потребуется архитектор, способный справится с миллионами строк кода - еще расти и расти. Растилку отрастите сначала, ок? :)
Это всё разговоры из серии "да мы с Вовой Путиным".
Тиму Мазеру я не давал советов, а Вы сейчас пытаетесь сделать вид, что Вы с ним одно и тоже. Уясните себе разницу между действия владельца бизнеса и действиями нанимаемых им сотрудников - тогда у нас будет предмет для разговора, а пока у Вас просто отсутствует необходимый для такого разговора бэкграунд.
Про мой уровень просто молчали бы уже, сколько можно Вам позориться, швыряясь какашками? Я, замечу, в Ваш адрес не высказывался, что Вы, например, непрофессиональны или ещё что-то такое. Всё что было - это указание на то, что профессионализм не подразумевает сам по себе правильной практики ведения дел.
Во-первых, отучайтесь лезть с оценками, когда Вас о них никто не просит. Есть неплохой шанс выставить себя клоуном.
Во-первых, не говорите что мне делать - и я Вам не буду говорить, куда Вам пойти с такими советами.
Во-вторых, находясь, как я уже указал, в публичном пространстве, не рассчитывайте, что Ваши высказывания не будут комментироваться и оцениваться.
И не воспринимайте негативные оценки как персонально направленную агрессию. Мне то всё равно, а Вы лицо теряете.
Во-вторых, уважаемый, я менеджер, а не архитектор. Меня брать на работу архитектором действительно нецелесообразно - обойдусь слишком дорого. :)
Верю. И я написал уже, почему :)
И в третьих - Вы не в курсе, что давным давно есть возможность не пИсать против ветра, и всю "документацию по внутренним API" генерировать из кода и комментариев автоматически?
В курсе. Это всего лишь повод для разговора о том, какая часть описания системы должна генерироваться, какая - писаться руками, а какую - действительно не нужно писать. Но эта постановка вопроса далековато находится от Вашего тезиса о принципиальной некогерентности документации и проекта, которая якобы мешает эту документацию вести и которая не даёт документации приносить пользы.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
no subject
(no subject)