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