Что, если бы существовал способ исключить из уравнения мнения и личные предпочтения и однозначно определить, какой код лучше всего подходит для двух конкурирующих решений?
- Единственное, с чем должны согласиться разработчики, - это сама аксиома. С достижением единодушия в этом единственном пункте горы субъективных дискуссий внезапно теряют актуальность, и тратится драгоценное время.
- Уважение к нежелательной власти необязательно, поскольку мы продвигаемся к децентрализованному миру.
- У разработчиков появляется поручень, который помогает им принимать бесчисленные решения на протяжении всей своей жизни. На смену преследующему чувству неуверенности приходит долгожданная уверенность.
Я придумал эту идею около 5 лет назад, и с тех пор она выдержала тщательную проверку со стороны разработчиков и архитекторов в различных компаниях. Я думаю об этом бесчисленное количество раз в течение дня, когда пишу чистый код, который чрезвычайно сложно критиковать.
И без промедления вот она ...
Избегая любых подходов, противоречащих цели, посткомпиляция наименьшего размера файла превосходит любую альтернативу.
В этом утверждении можно поиграть с двумя обратными вещами.
- Цель. Конечно, это может означать много разных вещей. Возможно, вам нужно добавить больше кода, потому что цель требует определенного уровня производительности, безопасности, функций или проект должен быть завершен до крайнего срока.
- Посткомпиляция: поскольку аксиома сосредоточена вокруг посткомпилированного (или пост-минимизированного) кода, она позволяет обойти любые дискуссии о комментариях к коду, именовании переменных или синтаксическом сахаре. Компилятор может оставаться теоретическим, что дает некоторую свободу действий.
А как насчет оценки предварительно скомпилированного кода?
Как определить, какой код лучше «предварительная компиляция», требует отдельного обсуждения, и это решение будет принято после рассмотрения «посткомпилированного» решения. При этом трудно утверждать, что следование приоритету не является главным соображением.
А что насчет зависимостей?
Само собой разумеется, что зависимости увеличивают размер посткомпиляции кодовой базы. Кто является главным жизненным принципом, кто хочет утверждать, что зависимость лучше независимости? Помните разгром левого пэда? В идеальном мире без крайних сроков кодовая база должна стоять сама по себе… минималистичной, элегантной и последовательной.
Конечно, в какой-то момент появится цель и наложит на проект временные ограничения. Вот когда имеет смысл дотянуться до полки и включить зависимость, которая неизбежно содержит больше кода, чем вам потребуется.
Проведение границы между платформой и ее кодовой базой
На самом деле разработчик / команда должны стоять на плечах других. Однако есть свобода действий, когда дело доходит до проведения разделительной линии между кодовой базой и ее инфраструктурой. Если я создаю проект на AWS, это не означает, что какой-либо код Amazon необходимо учитывать при сравнении одного посткомпилированного решения с другим.
Что насчет программного стека (т.е. React, Node, Java, Linux и т. Д.). Можно спорить, что такое инфраструктура / платформа по сравнению с зависимостью. Однако в целом я бы рассмотрел что-то вроде React и Typescript как зависимость, которая включает в себя процедуру транспиляции и приводит к окончательному файлу сборки (посткомпиляция). Java и Node.js не отображаются в файле сборки (игнорируя что-то вроде Docker), поэтому я не считаю, что эти платформы / языки имеют какое-либо влияние на дебаты, в которых используется аксиома кодера.
Во многих случаях, когда оцениваются два конкурирующих решения, они все равно работают в одном стеке, поэтому рассмотрение размера платформы / инфраструктуры становится неактуальным.
А что насчет производительности?
Я часто слышал аргумент, что одна версия кода может быть больше, но, поскольку она более эффективна, она, следовательно, лучше. Что ж, только если цель такова! Вы когда-нибудь слышали мантру о том, что преждевременная оптимизация - корень всего зла? Другими словами, не тратьте время (или код) на повышение эффективности, если более мелкая / более простая альтернатива оказывается достаточной. .
Абстрагироваться или не абстрагироваться
Здесь действительно помогает аксиома Кодера. Слишком часто я вижу чрезмерно спроектированные системы, в которых структуры абстрагируются до того, как в этом возникнет необходимость. Ясно, что это без надобности увеличивает размер после компиляции.
Не ищите признаков повторения и абстрагирования, когда в этом возникает необходимость? В отличие от чрезмерного проектирования системы, недостаточное проектирование включает в себя дублирование шаблонов / процедур, которые увеличивают размер файла после компиляции.
Если вы не уверены, что в ближайшем будущем вам придется использовать функции несколько раз, выберите монолит. Просто не ленитесь, когда пора разбирать что-то по мере развития вашей системы. Таким образом, у вас всегда будет лучший (я имею в виду наименее неправильный) код для вашего сиюминутного контекста.
Монолит
Amazon и Netflix начинали как монолит, потому что это то, чем вы занимаетесь, когда только начинаете. Цель меняется со временем по мере увеличения трафика и добавления функций.
Вот что сказал Роб Бригам, старший менеджер Amazon AWS по управлению продуктами, на конференции 2015 года.
Не поймите меня неправильно. Он был спроектирован на нескольких уровнях, и на этих уровнях было много компонентов. Но все они очень тесно связаны друг с другом и вели себя как один большой монолит. Теперь многие стартапы и даже проекты внутри крупных компаний начинаются именно так. Они используют подход, ориентированный на монолит, потому что он очень быстрый, чтобы быстро двигаться. Но со временем, по мере того, как этот проект созревает, по мере того, как вы добавляете в него новых разработчиков, по мере его роста и расширения кодовой базы и усложнения архитектуры, этот монолит будет добавлять накладные расходы в ваш процесс, и этот жизненный цикл разработки программного обеспечения сокращается. собираюсь начать замедляться.
Меньше - больше
Хотите поспорить с бритвой Оккама?
Если у меня есть рабочее решение, которое отвечает цели, кто захочет быть на стороне добавления большего количества только для удовлетворения праведного принципа или отдаленного прогноза? Делайте это просто глупо и выбирайте элегантность. В конце концов, поскольку никто ничего не может сделать идеально, чем меньше этого мы делаем, тем лучше нам.
