Post #817

Религия и холивары Если вы работаете в IT, то наверняка вам приходилось быть свидетелем, а может, и участником споров по поводу того, какое решение лучше - А или Б. Кто-то, например, готов насмерть стоять за то, что всегда и везде нужно использовать микросервисную архитектуру. Кто-то любит ORM, а кто-то является принципиальным противником. Кто-то за WIndows, кто-то против. И таких тем бесконечное количество. Когда у человека есть стойкое убеждение, что решение А - самое верное, и никак иначе нельзя, "просто потому что" - это в насмешку называется "религиозными убеждениями" - потому что речь идёт о каких-то догмах, в которые человек верит свято и непреклонно, и от которых не готов отступать ни при каких обстоятельствах. В целом, у всех с опытом формируется некий набор личных предпочтений о том, как нужно писать код и какие технологии использовать. Но вопрос в том, насколько вы гибки в своих подходах и готовы их адаптировать под различные ситуации. Всё IT - это всего лишь набор различных инструментов, и каждый инструмент удобен для одних случаев, а в каких-то других случаях наоборот - только мешает. И это относится ко всему - от языков программирования, текстовых редакторов, операционных систем, СУБД, фреймворков до парадигм программирования, паттернов проектирования и видов архитектуры. Бывают ситуации, когда самый ужасный говнокод - и есть правильный выбор, без всяких там классов и красивой архитектуры. Например, вам нужно на своем локальном компьютере проверить какую-то гипотезу и за 5 минут набросать скрипт, который будет её проверять - тут важно сделать быстро, и совсем неважно, насколько красив будет код. А любители бесконечно спорить о парадигмах и подходах зачастую просто попусту тратят деньги работодателя - за время потраченное на споры, они могли бы сделать что-то более полезное. Иногда продуктивнее выбрать хоть какое-то решение и уже приступить к разработке, пусть даже это решение будет не идеальным. Если ваш начальник очень хочет написать монолит, а вы настаиваете на микросервисах - продуктивнее будет свернуть этот спор, и уже написать работающую программу, чем стопорить разработку бесконечными препираниями. С другой стороны - если цена ошибки очень высока, и вы совершенно убеждены, что именно ваше решение поможет вам избежать ряда критичных проблем - тогда имеет смысл стоять на своём до победного и подробно расписать все ваши аргументы. Вопрос всегда в том, чего требует конкретная ситуация.