18. Все части системы должны оперировать временем в одной временной зоне (стандарт - UTC)
Если фронтенд передаёт бэкенду время в часовом поясе +04, бэкенд оперирует временем в часовом поясе +00, а база данных - хранит время в часовом поясе +03, то очень скоро вы устанете конвертировать все эти значения между друг-другом и объяснять всем заинтерсованным лицам причины различий одних и тех же даты и времени на всех трёх уровнях.
И это самый простой пример, в котором всего 3 приложения, относящихся к одной вертикали. Если сюда добавить ещё парочку сторонних приложений со своими часовыми поясами, то объём "веселья" увеличится многократно.
Чтобы не усложнять себе работу, используйте в настройках всех частей своей системы одинаковый часовой пояс.
19. Если в базе данных делаем связанные таблицы, то при их создании явно указываем внешние ключи
В этом суть реляционных баз данных - в связях. Для этого они и нужны. Именно при работе со связями реляционные базы даных раскрывают большую часть своего потенциала. Глупо, вместо исользования таких возможностей базы данных, искать обходные пути и строить "велосипеды" в коде приложения.
20. При создании связанных таблиц также прописываем каскадное удаление
Это нужно, чтобы в подчинённых таблицах не оставалось "сирот" после удаления данных из родительской таблицы. Исключение из этого правила - когда бизнес-требованиями установлен запрет на физическое удаление данных из базы данных.
21. Если видим, что для поиска нужен индекс - делаем индекс
Это правило тоже не абсолютное. Во всём нужен сбалансированный разумный подход.
Правило создано, в основном, для тех случаев, когда разработчку прямо никто не поставил задачу "добавить индекс" и не установил требования "не добавлять индексы, не прошедшие пяти-ступенчатую процедуру согласования в архитектурных комитетах".
22. В базе данных необходимо устанавливать те же ограничения на данные, что и в коде приложения
Если видим, что для правильного функционирования бизнес-логики на уровне базы данных (на случай, если кто-то залезет туда руками) нужны такие ограничения - делаем.
Часто, кроме самого приложения, к базе данных имеют доступ люди, которым бывает необходимо добавить или изменить данные. Если в базе данных ограничения на таблицах (колонках) будут отличаться от ограничений, установленных в коде приложения, то при первом же ручном изменения базы данных мы рискуем получить целую охапку трудноуловимых ошибок в работе нашей системы.
23. Если видим, что при описании задачи была допущена явная техническая ошибка - согласовываем с тем, кто поставил задачу, исправление ее описания
Очень часто разработчики занимают нейтральную позицию и реализуют задачу буквально так, как она написана, несмотря на явные технические или архитектурные недоработки в её описании.
Я сторонник такого мнения: разработчик несёт ответственность (моральную, конечно же) за свой код. Нельзя реализовывать недоработанную задачу. При наличии любых сомнений в правильности постановки задачи, нужно принять все доступые меры для их разрешения.
Сознательно реализованная в коде ошибка - это всё равно, что диверсия на проекте. Такого быть не должно.
Продожение следует.