![[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)
(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)
(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)
(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)