2018 Читаемость и сопровождаемость кода важней удобства написания.
Программы пишутся для пользователей и программистов, а не для компьютера, все должно быть понятно для человека. ЗАПРЕЩЕНО жалеть в коде память, проц и диск, пока этого не потребует рынок, но в архитектуре продумать будущую оптимизации нужно.
ЗАПРЕЩЕНО ОПТИМИЗИРОВАТЬ КОД, кроме случаев когда рынок заставит это сделать. Оптимизация только в крайних случаях. Выделим отдельно НЕТ математике НЕТ экономии ресурсов.
Максимальная читаемость кода, учитывать ограниченные возможности человека и ошибки, и недостаток колва профи специалистов.
Запрещено делать математическую стройность в ущерб читаемости кода или стройность ради стройности.
Строить надо из маленьких кирпичиков, каждый из которых полностью понятен одному человеку, студенту, школьнику, ребенку.
Система должна учитывать, что человек ошибается, ошибки программиста - не падать, ошибки админа - не падать.
Алгоритм отдельно, данные отдельно, задачи отдельно. Падение обработки одной задачи не должны убивать программу или портить данные, задача должна пытаться обработаться заново, или отбрасываться или помещаться в корзину плохие данные и логироваться или отправлять емейл админу.
Все строить не из принципа красиво и логично, а из принципа понятно для человека и удобно. Это сложно для понимания тк многие считают что математически стройно всегда красиво и удобно, но это не так ибо природа человека далека от чистой математики.
ВСЕ ДОЛЖНО БЫТЬ МАКСИМАЛЬНО ТЕКСТОВОЕ И ЧЕЛОВЕКОЧИТАЕМОЕ. Протоколы и команды максимально текстовые и конфиги и отладка и логи тд. ВСЕ БИНАРНЫЕ ПРОТОКОЛЫ ДОЛЖНЫ УМЕРЕТЬ или уйти на уровень электроники.
Пляшем от конфига, а кто его реализут postfix, sendmail или exchange это уже вторично. Конфиг надо выбирать по стандарту готовому или аля uri, или свой, но удобный для человека, на основе одного конфига можно генерировать несколько для программ с другими конфигами.
Живые легкие простые программы или микросервисы. Непрерывная разработка, микроитерации. Подробные стандартизированные логи, особенно при сбоях, возможность легкого дебага и отладки. Простота настройки и разработки, в т.ч. на лету. Гибкость: всё можно переопределять, через хуки и тп НЕ экономим память и процессор скорость и простота разработки важнее оптимальности работы программ.
Социальные приоритеты. (Комфорт для программистов и для пользователей. Agile в разработке и бизнесе)
Коммуникации. Постоянная обратная связь с пользователями, от начала исследования потребностей, потом прототипирование, проектирование, и каждая неделя(спринт) разработки.
Архитектуру продумываем внимательно и долго, и прописываем, особенно независимость подсистем, уровни и модули. Скорость разработки архитектуры в 100 раз быстрее кодинга.
Учитываем что программирование это 10-15% времени, остальное отладка, тестирование и поиск багов.
Написал строчку кода - проверь. Если не проверил - пишешь письмо команде о важности проверки КАЖДОЙ строки кода на своем примере, или на скраме рассказываешь команде.
Автотесты и тесты обязательны. Система тестирования должна быть полностью автоматизирована, функциональные и интеграционные тесты важней и первичней, чем юнит-тесты.
Программа должна быть громкой и писать о проблемах на экран с указанием строки и файла, при этом ошибки перехватывать нельзя, а если перехватили, то текст нижних уровней обязательно сохраняется в ошибке и свой добавляется к нему.
Взаимный кодревью обязателен, либо взаимный мердж реквест, даже тимлид не должен добавлять код в рабочие ветки без ревью другим кодером.
Библиотеки, фреймворки обязательны всегда, свое писать только в крайних случаях.
Безопасность на этапе проектирования ДА, на этапе разработки только в крайних случаях и разумных пределах. Лучше использовать готовые проверенные средства безопасности, чем придумывать свои.
Безопасность. Многоуровневая безопасность. Взлом одной части не должен давать полный доступ. Превентивная безопасность, предполагать что взлом будет одного из уровней и делать защиту для тех дыр которых еще нет. Понимать, что общая безопасность равна безопасности самого слабого звена. Превентивная безопасность, если взломали стандартными средствами, то ничего не получится, стандартные эксплоиты не должны работать.
Конфиги, данные, подходы и задачи важнее, чем алгоритмы, программы и демоны.
Самостоятельные живые программы. Независимые, отказоустойчивые, живучие, самодокументированные программы. Могут ставить и работать без админа и пользователь сам разберется. В случае сбоев восстанавливается. Любой программер садится и дорабатывает. Концепция, все должно без админа работать, неадминистрируемая интеллектуальная система.
В идеале документация должна быть в коде или в файлах рядом с кодом.
В каком случае делать рефакторинг и улучшения программы? Только если она будет использоваться еще 3 года.
В каком случае делать автоматизацию, с учетом частоты рутины раз в неделю раз в мес раз в год и сколько денег сэкономит автоматизация с учетом уменьшения человекоошибок. Помнить что ничего вечно не используется и возможно достаточно инструкций.
Автоматизация процесса разработки, это важна в первую очередь для освобождения мозга программиста и только во вторую для экономии времени.
Цикл от строчки кода до отладки и теста не должен быть больше 1-3 секунд, от кода до чистового тестирования дистрибутива не более 1-10 минут. Поэтому разрабатывать лучше с rsync на рабочую среду и тестировать сразу и все это скриптануть. Не нужно собирать весь дистрибутив для теста одной программки.
Тестирование и отладка максимально близко к среде использования и данным использования и объему использования или больше и жестче.
Все ножницы одинаковые. Все инструменты всех разработчиков должны быть одинаковые в пределах одной команды, а лучше одной компании.
Тесты должны тестировать в тч время выполнения, отзывчивость и ресурсы и если они утекли тест файлед.
Но все программы всегда текут, поэтому демоны всегда должны форкать триды-воркеры, которые закрываются посе 300-1000 обрабработок. Либо делать рестарт демона раз в день или неделю.
Максимальное Разделение сервисов, ресурсов и данных и программ, и принцип разделения и независимости, изоляция. В тч для удобства и отказоустойчивости.
Контроль версий, сборка из чистых исходников без хаков, TDD.
Проект должен быть международным, желательно комменты писать на русском и английском(на русском обязательно)
На этапе разработки и первого года внедрения, технологичность и динамика развития важнее, чем стабильность и надежность, даже в ущерб количеству клиентов.
TODO Описать unix style, new unix style, git ctl style, DirAsService, примеры и почему это правильно
Описать почему зло создавать лишние уровни абстракций
Описать про имена переменных, префиксы, переприсвоения, глобальные, cfg.xxx, файл как объект и тп подходы.
Чистый проброс данные и имен между уровнями и протоколами, в крайнем случае, добавляется префикс или суффикс.
Имена одних сущностей должны быть везде одинаковые или иметь суффикс уровня или префикс уровня
Глобальные переменные и глобальные конфиги и готу иногда зло это хорошо
От простого к простому, чтоб реализовать сложное. Большое или сложное строится только из простого иерархически.
База-base-гипервизор-нода-хост, не обязаны быть микроосью, можно использовать и обычную ОС, но все файлы базы лежат в одном каталоге по принципу DAAP, стараемся максимально не зависеть от ОС, если крон и прочее то симлинками на себя из cron.d или автоконфигурирование каждый старт. Переустановка ОС не должна влиять на работу базы. Отличия от гипервизора, то что службы можно не только стартовать, но и настраивать через файл описания службы, через веб интерфейс и т.д.
Возможность централизовано управлять всеми конфигами организации через единый интерфейс, например git, carbon_rtsh и тп
Принцип посмотри свысока свежим взглядом, защита от переусложнения! Часто разработка софта, архитектуры или правил уходит в глубокую бесконечную идеализацию, возникает множество деталей. Важно посмотреть на все сверху от главных процессов от первичной задачи проекта, возможно не окупится такая идеальная проработка.
Если есть желающие систематизировать и отсортировать, сделать примеры, расширить и тд, все скажут спасибо.