Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, abibok, Вы писали:
A>>Или когда вместо продуктивной работы начинают играться в раскладывание карандашей на столе, то есть "настраивать под себя" инструменты разработки, пытаясь сэкономить одно нажатие на кнопку и два клика.
Z>Это не имеет никакого отношения к карго культу. Это другое явление. У него есть и плюсы и минусы, но это не карго культ.
Опять же из трудов классика, речь шла о 3 этапах:
1. "одинокий волк" не хочет следовать принципам.
2. группа перенимает готовую методологию и сосредотачивается на деталях
3. делают упор на принципы и понимают, что методология не универсальна.
Суть очевидно в том, что переход на более высокий уровень — это обучение, усилия, практика и время. И не все в состоянии перейти на другой уровень.
Здравствуйте, abibok, Вы писали:
A>Видишь, что введение юнит-тестов, code review, CI, системы контроля версий с бранчами здорово поможет. Рассказываешь, убеждаешь, вроде согласились попробовать. Но вместо юнит-тестов пишут какую-то ерунду, куча тестов регулярно сломана, code review игнорируют или придираются к мелочам вроде стиля, не пытаясь анализировать смысл изменения, и т.д.
Нет, это как раз опыт. Попробовали, не понравилось — в топку.
Карго культ это когда, к прмеру, пихают юнит-тесты во все щели, гонятся за процентами покрытия кода и пишут велосипедные атомные реакторы для моканья окружения. Как это всё влияет на разработку — неизвестно, как померять эффективность применения этих практик мы даже не представляем но это — путь самурая и иначе нельзя. Потому что это модно и молодёжно. И гуру так сказал.
Погнались за внешней атрибутикой и надеялись, что оно как-то само образуется. Вот это и есть культ карго.(с)
Здравствуйте, jeeist, Вы писали:
J>А более конкретно — насколько культовый статус имеет Макконнелл и его книги.
Какой культ Макконелла? это yet another bible
Почти никто его книгу не читал,
а если кто и читал, то не помнят или не понимают,
а если кто и помнит и понимает, то не применяет, (ибо якобы жизнь другая)
а если и применяет, то лишь очень малую часть.
Здравствуйте, Nuseraro, Вы писали:
J>>А более конкретно — насколько культовый статус имеет Макконнелл и его книги.
N>Какой культ Макконелла? это yet another bible N>Почти никто его книгу не читал, N>а если кто и читал, то не помнят или не понимают, N>а если кто и помнит и понимает, то не применяет, (ибо якобы жизнь другая) N>а если и применяет, то лишь очень малую часть.
Я читал, нихрена не помню, осталась только одна заповедь в голове: "пиши свой код так, как будто его будет поддерживать маньяк убийца, знающий твой адресс".
Так что да, все как у тебя, библия библией.
Пока писал вспомнил еще: код больше читается чем пишется. Но это в последнее время только ленивый не повторял.
Здравствуйте, Nuseraro, Вы писали:
N>Здравствуйте, jeeist, Вы писали:
J>>А более конкретно — насколько культовый статус имеет Макконнелл и его книги.
N>Какой культ Макконелла? это yet another bible
N>Почти никто его книгу не читал, N>а если кто и читал, то не помнят или не понимают, N>а если кто и помнит и понимает, то не применяет, (ибо якобы жизнь другая) N>а если и применяет, то лишь очень малую часть.
В принципе учит жизнь — годы, десятилетия, а не книги Но иногда книга помогает разложить все по полкам, систематизировать, правильно назвать вещи, показать направление, куда копать, итд. итп.
A>Видишь, что введение юнит-тестов, code review, CI, системы контроля версий с бранчами здорово поможет. Рассказываешь, убеждаешь, вроде согласились попробовать. Но вместо юнит-тестов пишут какую-то ерунду, куча тестов регулярно сломана, code review игнорируют или придираются к мелочам вроде стиля, не пытаясь анализировать смысл изменения, и т.д.
"Мы в ответе за тех, кого приручили". Поздравляю, вы убедили всех внедрять практику. Только почему вы после этого самоустранились из процесса? Нужно же обучить остальных, как правильно писать юнит тесты, зачем нужен ревью (и как его проводить). При этом нужно не просто обучать, но и контроллировать правильность понимания процесса. Например, участвовать в ревью и проводить потом "ревью ревью".
A>То есть вроде что-то делается, но делается халтурно и поверхностно, без желания разобраться и использовать инструмент как положено.
Ну а как вы хотели? Человек — существо ленивое. Вы всех убеждали "давайте внедрим вот это". Убедили, отлично. Остальные решают попробовать. И тут вдруг выясняется, что им еще нужно приложить кучу усилий и самостоятельно разобраться во всех тонкостях процесса и внедрить его! Получается, что агитировали вы, а делать то им. И им сложнее — вы уже знаете, что хотите, а они плохо представляют, чего хотите вы. При этом от вас никакой помощи (вы их работу считаете халтурой). Результат вполне предсказуем.
A>Разумеется ничего не выходят. На тебя обижаются "столько времени даром потратили на твои игрушки, некогда нам, надо кодить". Погнались за внешней атрибутикой и надеялись, что оно как-то само образуется. Вот это и есть культ карго.
Правильно обижаются. Я бы тоже обиделся. От меня чего-то хотят, при этом нормально не объясняют (говорят, ищи и учи сам) и говорят, что я халтурю! Если уж вы затеяли внедрение процесса, то внедрять надо упорно и до конца. Следить и корректировать в процессе внедрения, например. Предоставлять обратную связь (конструктивную) другим участникам. Объяснять, что неправильно (и что правильно тоже), какие бонусы уже получили, что еще предстоит получить и как этого добиться. Инициатива наказуема. Нужно же не только внешнюю атрибутику показать. Нужно рассказать, как и почему оно внутри работает (не надеясь, что сами разберутся). А потом и проконтролировать правильность понимания (без этого могут быть проблемы).
Так что в данной ситуации культа карго нет. Команда внутренней составляющей не знала (причины могут быть разные, скорее всего просто не показали). Применила ритуалы. Ритуалы не помогли. Команда сделала вывод, что внешние ритуалы не рулят (что правильно) и отказалась от технологии.
Z>К примеру я напишу скрипт деплоя, даже если я убежден, что этот деплой будет производиться раз в год.
Вы путаете КК и эффективность реализации. Я не имею ничего против горы усилий, если это приводит к решению задачи и получению опыта. КК — это когда решение задачи подменяется чисто внешней и поверхностной суетой-активностью. Например, когда человек настраивает неделями подбирает себе IDE, настраивает цвета-шорткаты, но в итоге так ничего и не пишет, для работы не использует. Или когда внедряют юнит-тесты, потому что так сказано в книжке, но эти тесты никакой реальной пользы не приносят, потому что писали их без понимая сути. Или когда начинают без повода наворачивать "архитектуру" и везде совать шаблоны проектирования, не потому что это необходимо для проекта, а потому что так положено.
A>Я читал, нихрена не помню, осталась только одна заповедь в голове: "пиши свой код так, как будто его будет поддерживать маньяк убийца, знающий твой адресс".
Эта фраза принадлежит John F. Woods, а не Макконеллу. Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
M>"Мы в ответе за тех, кого приручили". Поздравляю, вы убедили всех внедрять практику. Только почему вы после этого самоустранились из процесса? Нужно же обучить остальных, как правильно писать юнит тесты, зачем нужен ревью (и как его проводить). При этом нужно не просто обучать, но и контроллировать правильность понимания процесса. Например, участвовать в ревью и проводить потом "ревью ревью".
Э, нет, это не мой проект. Я показал направление, как внешний эксперт, а дальше сами.
M>Так что в данной ситуации культа карго нет. Команда внутренней составляющей не знала (причины могут быть разные, скорее всего просто не показали). Применила ритуалы. Ритуалы не помогли. Команда сделала вывод, что внешние ритуалы не рулят (что правильно) и отказалась от технологии.
Команда не хотела работать и учиться, а выбрала легкий путь. Облом был ожидаем. Плохо, что эти люди теперь будут противниками технологии и не станут пытаться попробовать снова.
Здравствуйте, abibok, Вы писали:
A>Вы путаете КК и эффективность реализации. Я не имею ничего против горы усилий, если это приводит к решению задачи и получению опыта. КК — это когда решение задачи подменяется чисто внешней и поверхностной суетой-активностью. Например, когда человек настраивает неделями подбирает себе IDE, настраивает цвета-шорткаты, но в итоге так ничего и не пишет, для работы не использует.
Нет, это не КК. Если человек неделями подбирает под себя IDE, но в итоге ничего не пишет этому может быть множество объяснений, но не КК. Чаще всего он просто не знает, что и как ему писать.
A>Или когда внедряют юнит-тесты, потому что так сказано в книжке, но эти тесты никакой реальной пользы не приносят, потому что писали их без понимая сути. Или когда начинают без повода наворачивать "архитектуру" и везде совать шаблоны проектирования, не потому что это необходимо для проекта, а потому что так положено.
Это тоже не КК, это издержки знаний полученных в отрыве от практики. Пока на практике шишек не набьешь всегда будешь в той или иной мере ошибаться с применением книжных знаний.
Здравствуйте, abibok, Вы писали:
A>>Я читал, нихрена не помню, осталась только одна заповедь в голове: "пиши свой код так, как будто его будет поддерживать маньяк убийца, знающий твой адресс".
A>Эта фраза принадлежит John F. Woods, а не Макконеллу. Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Тем более. Библия библией))))
Здравствуйте, abibok, Вы писали:
M>>"Мы в ответе за тех, кого приручили". Поздравляю, вы убедили всех внедрять практику. Только почему вы после этого самоустранились из процесса? Нужно же обучить остальных, как правильно писать юнит тесты, зачем нужен ревью (и как его проводить). При этом нужно не просто обучать, но и контроллировать правильность понимания процесса. Например, участвовать в ревью и проводить потом "ревью ревью". A>Э, нет, это не мой проект. Я показал направление, как внешний эксперт, а дальше сами.
Все равно плохой вариант. Мне кажется, правильнее было бы не показывать направление, а указать проблемы и требовать их решить. Какими методами — это уже их проблемы. Могут — вашими методами, могут — своими. Но проблемы должны быть решены. Это хотя бы ориентир дает при применении практик. Или заинтересованного человека найти, который бы следил за тем, что задачи решаются (и при необходимости обращался к вам). Просто направления "идти туда 10 километров" мало будет.
M>>Так что в данной ситуации культа карго нет. Команда внутренней составляющей не знала (причины могут быть разные, скорее всего просто не показали). Применила ритуалы. Ритуалы не помогли. Команда сделала вывод, что внешние ритуалы не рулят (что правильно) и отказалась от технологии. A>Команда не хотела работать и учиться, а выбрала легкий путь. Облом был ожидаем. Плохо, что эти люди теперь будут противниками технологии и не станут пытаться попробовать снова.
Там что угодно могло быть. Может, от них требуют работу так же, как и раньше делать. Когда там учиться? В свободное время? За это пообещать нужно было что-нибудь. А противниками технологии они не станут, не переживайте. Когда (и если) они осознают проблему, то смогут выбрать и ту технологию, которая у них когда-то не получилась. По-умолчанию в проект ее брать не будут (потому что может не получиться), но это тоже хорошо.
Хотя результат, конечно, был ожидаемый. Никому ваша помощь не нужна была. Вас пригласили, чтобы создать видимость "заинтересованности" в проекте. Если бы хоть кто-то действительно хотел, могло бы получиться лучше.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Alexey Sudachen, Вы писали:
AS>>Дык, оно часто и не работает ))))
AVK>Ну, я такого чтобы часто не работало не видел.
очень часто наблюдаю написание юнит-тестов, которые запускают один единственный раз (сразу после написания), т.о. 99.9999% всех тестов в проекте давно поломаны (код уже двадцать раз уже успели поправить, а тесты так и оставили)
вы уже либо крестик снимите, иль трусы наденьте...
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>очень часто наблюдаю написание юнит-тестов, которые запускают один единственный раз (сразу после написания), т.о. 99.9999% всех тестов в проекте давно поломаны (код уже двадцать раз уже успели поправить, а тесты так и оставили)
По моему опыту так происходит, когда тесты изначально были безполезны, например, потому что тестируют детали реализации. Периодически встречается, как кто-нибудь хочет написать тест на то, что его функция не выделяет динамической памяти, хотя по контракту этой функции такого вообще не требуется. Т.е. вполне возможна реализация, которая будет выделять, и что тогда? "А тогда перепишем тест, чтобы он проверял сколько именно она выделяет!" Рано или поздно подобного рода юнит тестов становится много, и на каждый чих ломается по нескольку тестов, в которых нужно тупо пойти и подправить в соответствии с текущей реализацией. Я взял себе за правило такие тесты просто удалять.
Здравствуйте, Alexéy Sudachén, Вы писали:
AS>Как-то вот подумалось — ведь огромная часть людей из индустрии фактически являются последователями карго-культа.
Угу. И "паттерны проектирования" тому лучший пример.
24.04.2013 10:03, Кодёнок пишет: > То, что он выковырял ртуть (выковырял? она же жидкая и скользкая?) еще не значит, что он не понимает причину и следствие. Он мог тестировать гипотезу, что барометр вызывает дождь — в этом нет абсолютно ничего глупого. Важно что он делал после — продолжал ли с тех пор всю жизнь выковыривать барометры и ждать дождя, несмотря на отсутствие результата? Такие люди есть, но далеко не все, даже если они дикари.
Дикарь чешет свой нос и тут начинается дождь. «О!» — думает дикарь и
когда снова нужен дождь начинает чесать нос: слева, справа, сверху,
снизу, левой рукой, правой... Начинается дождь. «О!» — думает дикарь: «Я
имею учиться на своих ошибках». Далее всю оставшуюся жизнь он посвящает
разработке сложнейшей системы чесания носа, совершенствуя ритуал в
зависимости от того, начинает идти дождь или нет. Он не только
разрабатывает эту систему, но и передает ее по наследству своим детям и
внукам, а те создают целую касту, школу, академию. И уже на изучение
великой науки вызывания дождя требуются годы упорного труда и только
самые способные и талантливые могут ее постичь, хотя до полного
совершенства доходят немногие. Ведь на исполнение полного ритуала уходит
до 8-9 месяцев. Зато достигшие совершенства могут с гордостью сказать:
"Не было еще ни одного случая, чтобы я не смог вызвать дождь."
Здравствуйте, Философ, Вы писали:
Ф>очень часто наблюдаю написание юнит-тестов, которые запускают один единственный раз (сразу после написания), т.о. 99.9999% всех тестов в проекте давно поломаны (код уже двадцать раз уже успели поправить, а тесты так и оставили)
Это какой-то вырожденный случай. Тесты должны автоматом прогоняться на CI сервере, иначе их смысл теряется. Они регулярно ломаются и редкий программист, случайно обнаруживший давно упавший тест, станет его чинить.
Здравствуйте, Ziaw, Вы писали:
Ф>>очень часто наблюдаю написание юнит-тестов, которые запускают один единственный раз (сразу после написания), т.о. 99.9999% всех тестов в проекте давно поломаны (код уже двадцать раз уже успели поправить, а тесты так и оставили)
Z>Это какой-то вырожденный случай.
Не вырожденный. Я такое очень часто вижу. Да что говорить, на моем текущем проекте тесты тоже в стол пишутся. На предыдущем CI сервер был развернут только на моей машине и я пинал других когда они ломали тесты.
Z>Тесты должны автоматом прогоняться на CI сервере, иначе их смысл теряется. Они регулярно ломаются и редкий программист, случайно обнаруживший давно упавший тест, станет его чинить.
Вот это 100% паравда.
Здравствуйте, Aikin, Вы писали:
A>Не вырожденный. Я такое очень часто вижу. Да что говорить, на моем текущем проекте тесты тоже в стол пишутся. На предыдущем CI сервер был развернут только на моей машине и я пинал других когда они ломали тесты.
А зачем они тогда пишутся? Это огромный перерасход ресурсов, писать тесты и не использовать их потом.
Но иногда книга помогает разложить все по полкам, систематизировать, правильно назвать вещи, показать направление, куда копать, итд. итп.
