Всегда ли следует использовать лучшие методы кодирования [закрыто]

При кодировании программного обеспечения должна ли архитектура всегда быть передовой практикой или практической практикой в ​​отношении создаваемого приложения?

Если я создаю двухстраничное веб-приложение, которое может работать 5 лет и иметь 2 улучшения за эти 5 лет, я должен написать код для внедрения зависимостей, шаблонов проектирования, модель-представление-контроллер с моделями представления и т. Д.

Всегда ли следует использовать лучшие методы кодирования

Всегда? Нет, это глупо.

Лучшие практики - это рекомендации. Для большинства людей, для большинства ситуаций, если они реализованы с некоторой утонченностью, они дадут наилучшие результаты. Они там, где вы начинаете при рассмотрении решений. Но будут места, где лучшие практики можно и нужно игнорировать, потому что есть лучшие решения.

Проблема в том, что люди не могут заглянуть в будущее. И новички (и группа не новичков) неизбежно думают, что они находятся в том особом сценарии, где правила не применяются к ним. В случае сомнений используйте лучшие практики. Годы дискуссий и опыт работы с тоннами инженеров, умнее вас или меня, показали, что они дают неизменно хорошие результаты. Но никто (или почти никто) из них не знает вашей конкретной проблемы так же хорошо, как вы. Иногда вы можете столкнуться с исключительными случаями, когда правила могут быть согнуты.

Да. Это самоочевидно. Почему бы тебе не сделать то, что лучше?

Это не проблема, хотя. Сложнее всего выяснить, что является наилучшей практикой, потому что для ответа на этот вопрос вам необходимо точно знать, какие у вас требования и как проект может развиваться в течение многих лет, и это очень трудно.

Однако есть одно хорошее практическое правило: никогда не рекомендуется брать названия групп шаблонов и просто смешивать их, не задумываясь.

Кроме этого, на ваш вопрос действительно нельзя ответить. Выяснение того, что такое «лучшая практика» для данной ситуации, - вот что значит быть инженером-программистом. Тебе придется сузить круг, чтобы получить лучшие ответы.

Лучшая практика - это та, которая наиболее эффективно удовлетворяет функциональным и нефункциональным требованиям вашего программного обеспечения к функциям, удобству обслуживания, производительности и т. Д. Если такая практика соответствует некоторому «отраслевому стандарту», ​​это здорово. Но если это не так, прагматизм побеждает.

Там, где я сейчас работаю, мы создаем новый веб-интерфейс для нашего продукта с нуля. Это не будет RESTful в любом случае; он использует исключительно POST. Он не многоуровневый, не использует микросервисы и не использует базу данных NoSQL. Он не имеет какой-либо архитектуры, как Enterprise Java.

Другими словами, это совсем не бедро.

Но он включает в себя современный HTML5- фреймворк, который поддерживает Angular-подобную привязку данных, автоматическое масштабирование для различных типов устройств, таких как мобильные и настольные компьютеры, интеграцию с пользовательским интерфейсом Telerik Kendo для выполнения всех тяжелых работ, а также полностью зашифрованный и защищенный канал данных.

Лучше всего, что это будет сделано за 30 дней, и это подвиг, на который уйдет целый год разработчиков Java-приложений в архитектуре Enterprise. Код ES6 / Typescript; это один из самых чистых кодов, которые я когда-либо видел.

Нет . Лучшие практики - это вещи, которые обычно считаются лучшими в 99% случаев, но это не значит, что они всегда применимы к любой ситуации.

Как разработчик, вы должны знать и использовать эти лучшие практики, а также знать, когда их можно отбросить.

Это не должно быть саморекламой, но я недавно написал пост в блоге, посвященный моей работе на платформе Salesforce.com, в котором подробно описан один из этих случаев . Одно из золотых правил: «Никогда не выполняйте запрос внутри цикла», но недавно, впервые за 7 лет работы над платформой, у меня была совершенно веская причина не соблюдать это правило.

Суть в том, что у платформы есть ограничения на количество запросов, которые вы можете выполнить в данном контексте выполнения, но в этом случае мне пришлось делать запросы внутри цикла, чтобы избежать исчерпания пространства кучи, и знал, что я буду в пределах запроса предел.

Так что это редко, но бывают случаи, когда лучшие практики не имеют отношения к сценарию, поэтому, если они не подходят, не заставляйте их.

Я предполагаю, что под «лучшими практиками» вы подразумеваете некоторый список правил, которые кто-то написал в книге. Конечно, если вы подразумеваете фразу буквально, то, конечно, вы всегда должны писать лучший код, какой только можете.

Нужно ли мне указывать, что не существует единого общепринятого набора «лучших практик»? Для любого правила, выдвигаемого одним экспертом, вы почти всегда можете найти другого эксперта с равными полномочиями, который скажет что-то другое.

Но к сути: краткий ответ: обычно, но не всегда.

Каждая область имеет свои «лучшие практики» и «решения для учебников». Они представляют собой накопленный опыт и мудрость многих, многих людей за многие годы, и их нельзя игнорировать. НО! Всегда существуют особые обстоятельства, дополнительные случаи и т. Д. Действительно способный человек в любой области знает, когда следует соблюдать правила и когда их нарушать.

Я бы сказал в целом: начните с соблюдения правил учебника. Если следование правилам учебника приводит к неприятностям - ненужной сложности, плохой производительности и т. Д., - тогда подумайте, может ли нарушение этого единственного правила на этот раз не лучшая идея.

Если вы игнорируете правила и идете туда, куда вас ведет ваша прихоть, ваш код, скорее всего, будет беспорядочным. Независимо от того, насколько вы умны, вы не первый программист в мире. Имеет смысл учиться на опыте других. Вот почему в нашей повседневной жизни у нас есть родители, учителя и проповедники: поэтому нам не нужно повторять каждую глупую ошибку, чтобы понять, что это глупая ошибка.

Но если вы неукоснительно будете следовать списку правил из какой-то книги 100% времени, вы часто будете вбивать квадратный колышек в круглое отверстие. Люди, которые написали свод правил, возможно, не сталкивались с делом, похожим на ваше. И даже если они имеют, если это достаточно редко, они, возможно, проигнорировали это. Правило, которое работает 80% времени, является превосходным правилом - если вы понимаете, что оно работает 80% времени, а не 100% времени.

Я написал книгу по проектированию баз данных, в которой есть много правил, которым я советую следовать разработчикам баз данных. (Я воздержусь от присвоения названия, поэтому я не выгляжу бесстыдно в саморекламе.) Я, конечно, призываю всех, кто хочет создать базу данных, прочитать книгу, подобную моей, и узнать из нее все, что они могут. , Но, конечно, бывают случаи, когда вы должны нарушать правила, которые я перечисляю.

Однажды я написал документ по стандартам программирования для команды разработчиков, которой руководил в то время. И последнее правило звучало примерно так: «Если у вас есть веская причина нарушить одно из вышеприведенных правил, продолжайте, НО вы должны включить в свой код комментарий, объясняющий, почему вы нарушили правило. Если вы не можете прийти Если у вас есть веская причина, тогда следуйте правилу. Если написание комментария доставляет больше хлопот, чем следования правилу, тогда следуйте правилу ». У нас было всего несколько раз, когда кто-то обнаружил, что нарушение правила стоит того, чтобы объяснить почему.

Под передовой практикой я полагаю, что вы имеете в виду «неформальные правила, которые сообщество разработчиков программного обеспечения усвоило с течением времени, которые могут помочь улучшить качество программного обеспечения», а не какой-то буквально лучший способ решения конкретной задачи.

Да, пока у вас нет причин не делать этого. Это должно быть серьезной причиной, по которой вы серьезно рассмотрели и применили обстоятельства и ограничения поставленной задачи. Это означает, что вы полностью понимаете практику и можете применять ее. Давайте не будем вдаваться в это понятие, что если вы не понимаете этого, то это не должно быть лучшим видом мышления. Смотрите определение.

Ты не всегда будешь делать то, что лучше. Когда босс говорит вам: «Отправь этот кусок дерьма, или ты уволен!» Вы отправите его и, возможно, отправитесь искать другую работу, но вы все равно отправите его. Иногда вы обнаружите, что делаете что-то достаточно хорошее. Конечно, вы не хотите делать это привычкой, но иногда вам приходится заводить повозки, и вы не можете беспокоиться о слепоте лошадей.

Некоторые вещи важны, некоторые нет.

Вы должны адаптировать свой выбор языка и стиля к конкретной проблеме.

Например, «Лучшая практика» для обработки исключений может заключаться в том, чтобы всегда перехватывать исключения и регистрировать их, но при создании модульного теста лучше всего избегать их выброса, чтобы инфраструктура модульного тестирования могла сообщать о них правильно.

С другой стороны, рассмотрим правило «СУХОЙ». Стремление к коду, который не повторяется сам по себе, всегда хорошо, не только по очевидным причинам, но и потому, что чем больше вы кодируете таким образом, тем лучше становитесь кодер - это отличный способ улучшить свои навыки кодирования / мышления вместо того, чтобы печатать и копировать / вставлять навыки, и в долгосрочной перспективе вы, как правило, будете чувствовать себя лучше, пересматривая свой код (даже если ожидаете, что он будет одноразовым), если будете следовать некоторым разумным правилам.

Подводя итог, будьте гибкими, но не просто кодируйте нечитаемый мусор, потому что вы думаете, что это - одноразовый код.

Я постараюсь посмотреть с другой точки зрения.

Сегодняшние современные фреймворки позволяют очень легко настроить базовый проект с помощью mvc, внедрения зависимостей, многоуровневой архитектуры и т. Д. (Весенний загрузчик здесь). Я бы сказал, начать с созданной базы и использовать инструменты, предоставленные для вас, пока вы не столкнетесь с чем-то, что требует решения ручной работы. Тогда вы можете отказаться от этих лучших практик.

Нетруднее использовать что-то вроде Spring Boot для двухстраничного веб-приложения, а затем использовать собственные сервлеты, запросы jdbc и другие.

По моему опыту есть только одна лучшая практика, которую я считаю обязательной:

Сохраняй это простым, глупым (ПОЦЕЛУЙ)

Другими словами: независимо от того, какие инструменты, API, архитектуры и т. Д. Вы выберете - если вы будете сохранять простоту, с большей вероятностью будет легче работать в будущем, меньше ошибок, скорость, память и все остальное, что вы можете пожелать.

Все те вещи, о которых люди говорят: принципы, шаблоны, практики и т. Д. - я считаю, что это набор инструментов, из которых я могу выбирать, выбирая те, которые лучше всего подходят для проекта, над которым я работаю. Все они предоставляют методы и идеи для решения проблем. Хитрость в том, чтобы выяснить, есть ли у вас эти проблемы.

Лучшие "Best Practices" всегда содержат раздел, в котором вы должны использовать свой интеллект и опыт, чтобы определить, когда элементы в руководстве неуместны. Они также могут содержать раздел, посвященный рассмотрению, утверждению и документированию таких исключений и включению их в «лучшие» практики.

При кодировании программного обеспечения должна ли архитектура всегда быть передовой практикой или практической практикой в ​​отношении создаваемого приложения?

В теории да.

В реальном мире [все еще] да, если вы можете себе это позволить.

Что, конечно, означает «нет».

Время и деньги всегда будут пытаться подтолкнуть вас к «быстрому и грязному» решению, потому что оно приносит «лучшую» ценность для клиента. Как это реализовано, не представляет интереса для клиента или его бухгалтеров. Если вы можете сделать работу [плохо] за два дня или идеально за три месяца, как вы думаете, о чем они вас попросят?

Разрыв между этими двумя принципами - наилучшей практикой и тем, с чем вам придется «сойти», - называется «Технический долг»; это вполне приемлемо, если у вас есть план «погасить» его, то есть вернуться и улучшить ситуацию позже. Опять же, не то, на что вы всегда (когда-либо?) Получаете бюджет.

Одна из тактик состоит в том, чтобы выпустить раннюю бета-версию с «быстрым» исправлением, но при этом обеспечить приоритетность необходимых архитектурных улучшений перед «полным» выпуском. Опять же, не то, что вы всегда (когда-либо?) Делаете.