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