Я собрал несколько «What The F*» из проектов, над которыми работал, а также кое-что, что пробовал на протяжении многих лет. Если быть честным, некоторые из WTF я, возможно, сделал лично из-за плохой практики и опыта. Иногда ошибка была скрыта в отсутствии глубокого понимания библиотек и фреймворков.
В последние несколько лет я создал несколько личных проектов. Хорошая (а в данном случае и плохая с другой точки зрения) вещь в том, что вы фактически являетесь владельцем конечного продукта, творцом своей работы, особенно если вы используете ее ежедневно, заключается в том, что ошибки и несовершенства возникают сами по себе. вернуться к вам быстро, и вы должны исправить их, если вы хотите продолжать использовать свои собственные инструменты.
Если вы используете базу данных, поддерживающую транзакции — ИСПОЛЬЗУЙТЕ ИХ.
Транзакции в основном касаются серверных систем. На нем много науки — Уровни изоляции, Распределение транзакций (между системами, даже не расположенными на одном физическом устройстве и так далее. Лично я не углублялся, но достаточно для работы. Использование WebSQL (SQL в браузере) не так широко распространен, потому что он прекращен консорциумом World Wide Web. Но нативные мобильные платформы предоставляют какие-то базы данных — реляционные, объектные или noSQL. Вероятно, не все имеют транзакции как функцию, но когда они — транзакции ускорят приложения, я использовал его с моим последним приложением — Breathe In — и это сделало молниеносной экономию 100 датчиков (это мой размер страницы) и данных (по 1–4 записи каждого) датчиков.
Никогда не выбирайте все записи из таблицы без параметров filter(where) или limit и offset.
Никогда не выбирайте все записи из таблицы без параметра limit, если вы не абсолютно, АБСОЛЮТНО уверены, что этих записей никогда не будет много. Бэкенд-системы и даже фронтенд-платформы могут обрабатывать 1000 и более записей, но если их масштабировать, объем памяти в конечном итоге станет ужасным.
Попробуйте разделить проблемы и свободную связь (код).
Это то, что выходит за рамки конкретных вещей для разработчиков — инструменты программирования (IDE), языки программирования, компании, объектно-ориентированные или функциональные, внешний или внутренний интерфейс и т. д. Заставить один программный компонент делать только одну простую вещь — звучит просто, но если взяться за руки грязный с бизнес / клиентской логикой, дерьмо просто становится реальным.
Еще одна вещь, связанная с разделением задач, — это разделение кода. Это означает, что зависимости между программными компонентами сведены к минимуму. Современные языки и фреймворки используют механизм внедрения зависимостей — с начальными или централизованными конфигурациями или аннотациями кода и т. д., чтобы облегчить эту проблему.
Попробуйте шаблоны проектирования, но не слишком много.
Шаблоны проектирования — это методологии, с помощью которых часто реализуется разделение задач и разделение кода при использовании объектно-ориентированного языка. Они хороши для минимизации кода, но только когда применяются в правильных местах. Если они применяются без реальной необходимости, просто потому, что вы хотите их использовать, это может привести к увеличению длины и сложности кода.
Минимизируйте код и его дублирование
У одного моего коллеги есть поговорка — меньше кода всегда лучше. К сожалению, машины должны быть проинструктированы, протестированы и проверены, чтобы делать то, что мы от них хотим, и они делают то, что мы закладываем в код, а часто не то, что мы на самом деле хотим. Абсолютно нет вариантов кодирования для более простых вещей. Есть корпоративные инструменты с более продвинутыми функциями, но они в основном дорогие. Существуют библиотеки и платформы, которые автоматизируют вещи — визуальное программирование с перетаскиванием компонентов, генераторы кода (например, тот, который я создаю), платформы для ведения блогов, которые могут предлагать решения без кодирования и так далее, но все они имеют те же недостатки, что и ну и плюсы.
Стандартизация
Стандартизация — это то, что имеет много преимуществ для всей индустрии программного обеспечения — возможность интегрировать программные и/или аппаратные компоненты от разных производителей — это очень круто. К сожалению, для более продвинутых вещей большинство корпораций пытаются продвигать свои собственные пути, и интеграция затруднена.
Еще одна вещь с точки зрения стандартизации кода заключается в том, что инструменты могут потенциально обрабатывать (генерировать или автоматизировать) некоторую скрытую для конечного программиста логику и облегчать расширение программного обеспечения. Но если вам нужно что-то более продвинутое, вам лучше найти хорошую документацию. На многих платформах Java, фреймворках и инструментах разработки — существуют структуры кода/каталогов, которые они применяют и которым следуют. То же, что и файлы шаблонов WordPress. Дерьмо становится вонючим, когда вы не знаете стандарта, а документация скудна или неполна.
