Аксиомы

Правило 1.1 Делай только требуемое.
Разрабатывай только более 5 лет нужное рынку, обществу или тебе(хотя бы для саморазвития) и это, в чем то существенном, должно быть лучше других.

Правило 1.2 Архитектуру и прототип продумывай много и долго.
Прототип нарисованный на бумаге или в графическом редакторе или в конструкторе сайтов экономит гигантское количество времени. Архитектура важней качественного кода, особенно принцип изоляции, тк можно потом заменить целый модуль или уровень или протокол более качественной реализацией.
Правильная архитектура может ускорить процесс разработки в разы.
Разработка архитектуры и прототипа в 100 раз быстрей, чем кодинг и отладка.
Исправить плохую архитектуру практически невозможно без переписывания с нуля.

Правило 1.3 Разрабатывай очень быстро, чтобы просто работало.
Если потребуется потом доделаем, переделаем, оптимизируем код.
Нельзя делать очень качественно без мнений потребителя о первичном продукте.
Идеализация - это тормоз прогресса. Достаточно 80% качества, 100% - это зло и потеря времени.
Время жизни ПО и технологий ограниченно, разрабатывать 5 лет, чтобы потом 1 год использовать - это глупость, соотношение должно быть 1 год разработки к 5 лет использования минимум.

Правило 1.4 Priority: Users, Developers, Machine
Приоритет при выборе решений: сначала удобство для пользователей, потом удобство для программистов, и только при самой крайней необходимости, оптимизация для компьютера.

Правило 1.5 Все должно работать сразу
У программы должны быть дефалты на все, чтоб без чтения док и без правки конфига можно было использовать, документация должна быть встроенной и обязательно с конкретными примерами. Большинство OpenSource программ не работает из коробки, например postfix,squid,nginx мы считаем это неверным, все должно работать сразу или с минимальными обязательными параметрами.

Правило 2.1 Не усложняй, используй бритву Оккама и принцип KISS.

Правило 2.2 Используй готовое.
Не надо разрабатывать с нуля, используй готовое, используй стандарты, либы, каркасы, паттерны и тп, но только если это не противоречит Правилу 2.1 «Не усложняй…»

Правило 2.3 Запечатывай сложное в простое и человеку понятное, абстрагируй.
Все алгоритмы и структуры должны работать с небольшим количеством объектов, небольшим количеством методов, при минимальном количестве правил. Дели на изолированные уровни, работай с блоками, используй готовое, стандартизируй.

Правило 2.3 Фрактальность
Только из маленьких и проверенных кирпичиков можно построить большие блоки и из них большое здание.
Правила постройки кирпичиков, блоков и зданий схожи.

Human nature, Human factors, Human limitations, Human readable, Different skills - миссия, идея, продукт, процесс разработки, архитектура ПО, стиль кода и все все все остальное должны учитывать человеческую природу, ограниченность человеческих возможностей.

Правило 3.1 Используй способы понятные для skill-1
Чтобы разрабатывать быстро, и разрабатывать большие, сложные и развиваемые системы нужно иметь запас прочности по сложности.
Не нужно разрабатывать на пределе сложности понимания.

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

Если получилось сложно, опиши, и сделай простым использование и развитие, изолируй сложное, сделай сложное заменяемым и удаляемым.

Правило 3.2 Учитывай физические ограничения мозга и зрения, колво строк, символов, объектов, правил
Одновременно мозг может работать с 5-9 объектами и методами, и видеть 20-60 строк. Учитывай это в сути алгоритма, декомпозируй, объединяй, изолируй, поясняй.

При выборе решений построения архитектуры и кода необходимо в первую очередь делать понятный читаемый и удобный для человека код/структуру/архитектуру даже если это идет в ущерб математической стройности ПО. Например, идеальная нормальная формы БД часто избыточная, сложная и неудобная в использовании и кодинге и не надо делать кривой и неудобный код ради третьей формы.

Правило 3.3 Учитывай языковые и социальные особенности
Код должен читаться слева направо простым английским или русским языком без коверканья.

Правило 3.4 Делай отказоустойчиво от ошибок людей
Разработчик и пользователь всегда делает ошибки, хорошая система должна это учитывать.
В идеале разделять обработчики и задачи, если обработчик сломался - можно запустить новый, если задача кривая можно положить в пул кривых задач.
Ссылки лучше не занулять, а перенаправлять на нулобъект с фиктивными методами и прочие хаки.
Система(Программа) должна максимально выживать и обеспечивать сервис.
Уточнение демон,ядро,сайт,сервис не должны умирать после плохих данных, они должны их отложить в невалидные и обрабатывать новые данные.
При этом демоны не нужно путать со скриптом, скрипт должен падать сразу как найдена ошибка аля set -eu, при этом он считается живым тк можно его вызвать заново с другими данными.
Функция должна максимально быстро возвращать error, но при этом алгоритм должен уметь работать далее удалив кривые данные из всех списков и структур при это демон или ядро не должны умирать.
Другими словами Обработчики не должны портиться от кривых данных.

Правило 3.5 Делай Человекочитаемо, дебагопонятно, громко.
Максимально везде использовать обычный человекочитаемый язык и протоколы.
Много логировать.
Выводить подробный стек ошибок до строчки кода прямо пользователю в расширенное окно ошибки.
Для облачного сервиса и аутсорсинга ошибки можно слать админу разработчика, но очень громко.
Лучше лишний раз послать ошибку директору или клиенту, чем потерять ее и не исправить.
Человекопонятные имена и константы.
Человекочитаемые текстовые протоколы.

Правило 3.6 Производительность труда.
Избыточная уверенность присуща новичкам - именно это мешает вырасти новичкам до профи, и профи до гуру и это объяснят дикую разность в производительности труда при равном интеллекте.
Уровни профскила-паранои включают предыдущий:

• 0. Не верь иногда - Новичок.
• 1. Не верь никому: ни гуру, ни клиенту, ни руководителю - Ремесленник.
• 2. Не верь утилитам и логам - Профи.
• 3. Не верь себе - Гуру.

Голова должна быть свободна, все должно быть записано в блокнот, все идеи, все туду, все буферы обмена.
Devops и CI, чем выше скил, тем больше должно быть автоматизации труда, devops, и возможно постоянный помощник тестировщик, чтобы меньше держать в голове и думать только о текущей задаче, а не просто для ускорения сборки.
Все что часто используется - скриптуется и шаблонизируется.

Автотесты рулят.
Кодревью рулит.
Вики example и howto рулят.
Делай по образу и подобию рулит.

туду учесть саморазвитие, геймификацию, и минимум 20/% на интересные задачи.
Близкие подходы:
Keep it short and simple https://ru.wikipedia.org/wiki/KISS_(принцип)

Почему опытные разработчики пишут тупой код https://habrahabr.ru/post/347166/
Код — это общение между людьми и инструкции для компьютера, но значительно больше первое, чем второе. Компилятор сам заботится о преобразовании написанного программистом в машинный код. Часто имеет место несколько слоёв такого преобразования, например, когда Java компилируется в байт-код, который считывается виртуальной машиной и транслируется в итоге в нули и единицы.
 
Но код — это человеческий язык. Он объясняет все «кто», «что», «когда», «где», «как» и «почему» задачи, заодно давая инструкции компьютеру. Он должен иметь смысл и пять лет спустя, когда компания будет продана, и новая команда, никогда не видевшая этого кода, откроет его для улучшения и исправления.

Читать далее: Принципы Foxdev 7

~~OWNERAPPROVE~~