Комментарии 29
Далеко не все могут глубоко разбираться, но при этом должны писать хороший код.
Мне кажется, это вообще странный подход «не может, но должен». Если не может, так ведь и не напишет, вне зависимости от того, следует он лучшим практикам или нет. Не разобраться в должной мере = лотерея. Лучше решить нужную задачу средненько, чем взять готовое, возможно хорошее решение от другой задачи. Чтобы понять, подходит ли оно вообще нужно больше, чем глубоко разобраться в своей задаче, нужно разобраться еще и в решении.
В общем случае, обсуждаемая проблема вообще не имеет никакого отношения к программированию.
Если общая проблема касается частной ситуации — почему нет? Ни к чему делать её ещё более частной, при этом. Вы считаете, что рассматривать поведенческую проблему в контексте отрасли нужно обязательно с примерами конкретных ошибок, спускаясь ещё на один уровень абстракции ниже? Ради чего именно?
Но если бы я своими глазами увидел кусок кода, написанный согласно best practice, но при этом неоправданно дорого обошедшийся в продакшне − уязвимый, неподдерживаемый, вызвавший потерю данных − тогда я поверил бы автору.
Частный пример не опровергает общую тенденцию — вы об этом никогда не слышали?
Любое общее утверждение не может быть опровергнуто частным примером, который ему противоречит, если утверждение не содержит квантор всеобщности.
В данном случае, утверждение, которое делается в статье — что слепое следование лучшим практикам — плохая идея, потому что они могут быть неприменимы к конкретной ситуации. Это утверждение не нуждается в примерах для того, чтобы быть правдой. Если вы считаете, что нуждается, вы ошибаетесь, логика так вообще не работает.
Но если бы я своими глазами увидел кусок кода,… − тогда я поверил бы автору.
Нет, тогда был бы срач вокруг этого куска кода, в котором потерялась бы более общая проблема.
Забыли упомянуть проблему корпоративной безответственности, потому что это именно та среда, где лучшие практики используют самым худшим и бездумным образом, ради того, чтобы всегда иметь возможность прикрыть задницу. Нередко — прекрасно осознавая проблемы с тем или иным решением, но всё равно отказываясь даже слегка его изменить или применить другое, более подходящее.
Возможно некоторые best practices и оказались не очень best, а вы как хотели? Программисты учатся программировать, иногда забредают не туда. Иногда от недостатка мозгов (а у кого они в достатке?), иногда просто из-за ограниченых возможностей языков, браузеров и проч.
Не знаю, за что заминусовали Tanner, примеров можно привести полно, просто вспомнив, что творилось в разработке лет 10 назад и дальше. Мне кажется, там все состояло из одной большой best practice, которую сейчас стыдно вспоминать. :-)
Подверженность людей эффекту новизны и любовь к хайпу были всегда. Казалось бы, программисты с их техническим складом ума и критическим мышлением точно понимают откуда они знают то, что знают, ан нет.
The hyperbole of The Architects Sketch may seem ridiculous, but consider how often we see software projects begin with adoption of the latest fad in architectural design, and only later discover whether or not the system requirements call for such an architecture. Design-by-buzzword is a common occurrence. t least some of this behavior within the software industry is due to a lack of understanding of why a given set of architectural constraints is useful. In other words, the reasoning behind good software architectures is not apparent to designers when those architectures are selected for reuse.
https://www.ics.uci.edu/~fielding/pubs/dissertation/introduction.htm
Это было написано 20 лет назад автором REST. Позже этот термин превратится в один из самых заезженных базввордов в ИТ
Как уже упоминалось, без примера и без конкретного альтернативного решения это просто водичка.
Ну допустим, TDD — не лучшая практика. А что тогда делать? Не применять ее? Применять частично? Применять другую практику (ага, значит тогда другая практика является лучшей)?
А выводы, типа: нам нужно тщательно, больше, глубже поощрять открытость, разбираться и прекратить уже наконец, научиться, увидеть и отказаться — это как-то не убедительно.
© Какой-то из заветов
Увы, люди ничему не учатся. Вся история человечества учит тому что история ничему не учит. Возникает чувство что мы обречены повторять одни и те же ошибки снова и снова.
Никто не хочет читать, думать, анализировать, сравнивать, просчитывать последствия и альтернативные варианты развития ситуации…
Увы-увы, чукча не читатель, чукча писатель…
Нет, не пример кода, конечно же — он тут не нужен. Пример подхода к работе. Большинство привыкло к тому, что есть всего два вида разработки — или вы делаете web api или stand-alone приложение. Но есть ещё и другие виды разработки и один из них — моя ниша — разработка плагинов под приложения.
В моей организации мы занимаемся разработкой плагинов под Revit и недавно у нас решили «делать все правильно». И это самое «правильно» сводится к тому, что мы маниакально следуем лучшим практикам: как можно более чистый mvvm, где представление существует чуть ли не в вакууме, послойная архитектура. На каждый (!) сервис мы пишем интерфейсы. Юзаем DI. Каждую мелочь обязательно выносим в конфиг-файл (недавно выносил в конфиг «случайное большое число»).
И может показаться, что мы все делаем правильно — послойная архитектура с интерфейсами и разделение представления и логики позволят писать авто тесты, конфиги позволять менять параметры приложения без перекомпиляции и т.д. Звучит как песня, НО!
Но тестов никто не пишет, ибо это просто невозможно. Так как мы пишем плагины под Revit, используя его API, то без запущенного Revit тестировать нельзя. Есть фанаты, которые делали фреймворк для тестирования — запускается Revit, открывается документ, запускается плагин и прогоняются тесты. Худо-бедно, но работает. Правда сложность создания этой фигни перекрывает собой сложность создания самого плагина. Ок, даже если решиться на такое тестирование, то тут же следующие проблемы — Revit вряд-ли поставишь на систему непрерывной интеграции (у нас teamcity). К тому-же тестирование на пустых проектах бесполезно, а реальные проекты могут только открываться вплоть до полу-часа!
При создании окон плагинов иногда приходится сильно мучаться, чтобы реализовать какое-то решение, которое легко делается в code-behind. Или, например, сделать ViewModel, которая «знает» о View (т.е. банально в конструктор ViewModel передать окно) решает многие проблемы. Надо свернуть-развернуть окно — две строчки кода. Но нет — мы же делаем «правильно» — поэтому надо сделать интерфейс, наследовать от него окно и передавать экземпляр в команду через параметр! А что это дает? Да ни-че-го!
А про конфиги вообще можно коротко сказать — ни разу никто из пользователей никогда не правил их вручную, чтобы поменять параметры приложения. И я уверен на 100% — никогда и не будут менять!
Мне пришлось поработать и с web api: делал бэк, использовал послойную архитектуру, ORM, CRUDS, даже немного Blazor поюзал. В таком контексте я понимаю зачем нужны все эти лучшие практики. Но когда лучшие практики начинают натягивать на другие контексты как сову на глобус, только лишь потому что «так принято», то получается просто трата времени. То, что можно написать за день, пишется за три.
P.S. Когда на все сервисы пишутся интерфейсы, то нажимая в IDE «Перейти к определению» мне открывается интерфейс. А если вы работаете через DI с внедрением, то к реализации не сможете так перескочить вообще. Только открывать вручную. Тоже дико бесит :)
Но, касаемо темы, на мой взгляд, о непригодности лучших практик, общеизвестных технологий и прочего, общепризнанного, чаще всего говорят люди, чья самоуверенность просто не дает им шансов банально ознакомиться с этими самыми общепризнанными вещами. Синдром NIH, в общем.
Культ лучших практик