Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 14
Но другие люди не дают вам эти факты, им просто не нравится идея, или они не понимают ваших фактов, или они не готовы принять ваше решение в данный момент.
Короче говоря, люди не хотят следовать вашему решению, не потому что оно неверно. Они просто не готовы принять его.
-Почему? (Я не согласен и не хочу)Извините, но в инженерной среде это выглядит дико. Я могу понять, если такое случится в деятельности связанной с искусством, т.к. там субъективно всё. Но в инженерии такого подхода быть не может, это первое зло. Только факты, умение их находить, принимать и опровергать другими фактами. Как раз конструктивный спор разработчиков с таким подходом помогает определить наиболее оптимальное решение задачи.
-Вы должны принять это, даже если вам не нравится.
А в инженерной среде у вас, я так полагаю, работают не люди и не с людьми?
«Такой подход» есть везде, где есть люди. Это есть у всех, включая и вас самих. Вопрос только в степени распространённости и выраженности. «Только фактами» вы, даже если искренне захотите и попробуете — решите далеко не всё (например, ставить табуляцию или пробел).
«Такой подход» есть везде, где есть люди. Это есть у всех, включая и вас самих. Вопрос только в степени распространённости и выраженности. «Только фактами» вы, даже если искренне захотите и попробуете — решите далеко не всё (например, ставить табуляцию или пробел).
Автор статьи явно об этом не говорил, но давайте отличать субъективное от объективного. Потому что табуляция с пробелами является субъективным восприятием, так же как и шрифт, цвет фона и т.д. Но технически никакой разницы нет, если только мы не пытаемся сэкономить < 2% объема репозитория из-за разницы табов и пробелов. И тем не менее есть много объективных причин и технических способов решать даже подобные субъективные проблемы. Толковая команда к этому естественно придёт, т.к. исход войны табов с пробелами — далеко не самоцель проекта.
давайте отличать субъективное от объективного
Давайте. И теперь я скажу, что подавляющее большинство проблем, которые решает отдельный взятый ИТ-работник умеренно высокого полёта — субъективные, выходящие на уровень «сделать так, чтоб людям понравилось» (начальнику ли, клиентам ли, владельцу бизнеса ли — не важно). Повышение доли голой объективщины (баги чинить и прочие «сетку тянуть») есть только на самом низком уровне, у тех людей, которых наняли не думать слишком глубоко, а руками делать то, что для них придумают другие.
Табы и пробелы — это жизненно важный вопрос. Как Вы не понимаете. Начать с того, что есть места, где это прям важно-важно (любые yaml, python код, makefile и сотни кейсов), вплоть до унификации кода (можно унифицировать насильно через линтеры). И точно речь не про экономию десятка байтов на каждом файле исходного кода
Причем основной момент именно в том, чтобы все делали единым образом, а не сферический в вакууме диспут «что лучше»
Причем основной момент именно в том, чтобы все делали единым образом, а не сферический в вакууме диспут «что лучше»
Ок, и это будет отличным аргументом, если в проекте используются инструменты, которые потенциально могут поломаться из-за табов. Я, если честно, на этом не спотыкался, т.к. использую только пробелы. Суть же не в этом, а в достаточно убедительной аргументации любого вопроса и умении окружающих её адекватно принимать или критиковать.
И именно его искоренем. У нас тоже есть разработчики «мне-это-не-нравится» и «моё-решение-круче», но мы умеем делать тесты и показываем что другое решение лучше (ну или их на самом деле лучше оказывается, так тоже бывает, но вывод — не из эмоций, это не инженерный подход).
А при чём здесь «эмоции»-то? Субъективная оценка факторов — это субъективная оценка факторов, а не эмоции. Один считает, что нужна расширяемость, другой — что не нужна. Один считает, что стоит заранее заложиться на масштабируемость в определенной системе, другой — считает, что не стоит. И так далее. Во многих случаях подвести объективный фундамент под подобные выводы без машины времени попросту невозможно.
Извините, но в инженерной среде это выглядит дико.
Как раз таки именно в инженерной среде это проявляется больше, т.к. в отличии от чистой науки и теории, где главенствуют факты и поиск истины разной степени фундаментальности, инженерия связана с практикой и опытом применения этой теории. А здесь уже больше главенствует комбинаторика, по критериям эффективности, экономическим критериям (соотношения трудозатрат и конечного результат), критериям надежности, сложности, технологичности.
И взгляды на перечисленные критерии просто физически не могут быть одинаковыми, т.к. все люди разные. У каждого свой опыт, в соответствии со своим набором умений и требований к жизни. Кто-то видит главным — масштабируемость, кто-то надежность, кто-то дешевизну. Об этом и говорит автор, что «решение» это определенный набор комбинации критериев, которые не всегда могут быть одинаковые у членов коллектива. А всем не угодишь: основные ресурсы — время и деньги всегда ограничены.
Исключение составляют жестко регламентируемые сферы, где шаг вправо-влево ограничен государственными и отраслевыми регламентами — законами, ГОСТами, СНиП, ПУЭ, ПТЭЭП и так далее. Здесь действительно — кто знает лучше факты из этих стандартов, тот и прав. Ну или на низком исполнительном уровне, где для размышления и философии реализации либо уже не остается места, либо она не имеет значения в данном проекте.
Но здесь речь шла больше применительно о новых разработках, где регламентизация как таковая не затрагивает основной цели и путей реализации проекта. И где нет возможности опереться на опыт использования технологии, т.к. технология как таковая находится в разработке.
Сложно с вами не согласиться, но ограниченность ресурсов это первое, чем должна руководствоваться команда. Другое дело, что не всеми качествами проекта можно произвольно манипулировать. Можно некоторые вещи сделать на 20% надежнее за счёт денег, или на 5% технологичнее за счёт времени. Но, например, масштабируемость подкрутить иногда нельзя совсем, т.к. изменения слишком глобальны. Короче говоря, всё сложно. Deal with it.
Чтобы избежать трений по поводу своего решения — делай сам, если возможно. Если требуется одобрение других — делай наглядный рабочий прототип. Считаю правильно говорил покойный Жак Фреско. Перефразирую его — до большинства людей нужно доносить идеи не словами, а показывать их наглядно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тёмные стороны деятельного человека