Аксиомы

Human nature, Human factors, Human limitations, Human readable

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

Да, человек плох и неидеален, здесь я абсолютно с этим согласен. Однако этой аксиоме не хватает практических примеров.

Priority: People, Developpers, Machine

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

Быстрая программа - это удобно для пользователей и для программистов (быстрее итерация отладки -> скорость разработки)? Как добиться быстроты без оптимизации для компьютера?

Плюс здесь не учитывается вариант, когда впереди стоит не удобство, а надёжность для бизнеса пользователей.

Human nature more important than mathematics harmony

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

Опять же без примеров это всё пустые слова. К слову README (даже устаревшее на полгода) в каждой репе с описанием хотя бы архитектуры сделало бы всё наше ПО в 10 раз понятнее, чем сейчас.

Compatibility with low skills, low barrier to entry

и процесс и архитектура и код должны быть простые и понятные даже новичку студенту или школьнику.

Вопрос что делать с incompatibility with high skills в таком случае.

С кодом проще - можно использовать автоматические тулзы shellcheck/clang-checker/pylint для того, чтобы вовремя получать напоминания о том, что городишь сложную херню, поглядывать на размер файлов и всё такое.

Опять же, практические примеры о том, что делать в случае если:

  • мы начали продумывать архитектуру
  • у нас уже есть рабочий код средней запущенности и мы хотим стать понятны школьнику
  • у нас уже есть рабочий код сильной запущенности и мы хотим стать понятны школьнику

были бы в этой доке очень даже в тему.

Время жизни ПО и технологий ограниченно

разрабатывать 5 лет, чтобы потом 1 год использовать - это глупость, соотношение должно быть 1 год к 5 минимум.

К несчастью в своей жизни не видел примеров жизни ПО (принесения выгоды) после прекращения разработки.

Достаточно 80% качества, 100% это зло и потеря времени

Строго говоря достаточно двух первых аксиом, остальные необходимы для акцентирования и будущей систематизации

Depends on, depends on. Если бизнес требует 100% надёжности (не 99.99%, а именно 100%), тоже хватает 80% качества?

Плюс 20 и 80 процентов качества легко перепутать, как и любое другое значение ниже 99%.

Принципы и правила, вытекающие из аксиом

Программы пишутся для программистов и пользователей, все должно быть понятно для человека, НИКОГДА не жалеть памяти и проца. ЗАПРЕЩЕНО ОПТИМИЗИРОВАТЬ КОД ДЛЯ ПРОЦЕССОРА И ПАМЯТИ, кроме случаев когда рынок заставит это сделать. Оптимизация только в крайних случаях. Выделим отдельно НЕТ математике НЕТ экономии ресурсов. это сделать.

В принципе всё верно, но меня вот рынок сейчас заставил :)

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

Математика = логика, логичное = продуманное, продуманное как правило = короткое. Короткое = читаемое. Я не видел нечитаемых математически стройных программ, но видел много непродуманного нечитаемого ада, куда тяп ляп было налеплено сбоку куча всего. Короче не могу понять, как математическая стройность может противоречить читабельности, нужны конкретные примеры.

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

Два чаю этому господину. Для меня “кирпичик” = минимальный отлаживаемый по отдельности элемент.

Система должна учитывать что человек ошибается, ошибки программиста не падать, ошибки админа не падать.

Шо поделать с SEGFAULT в ядре или set -eu?:) Но вообще да, пытаться работать до последнего, не получилось так, попробуем сяк - относительно адекватный режим для продакшна.

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

Главное не забыть, что ошибок может быть много и это может забить диск и привести к ещё большим проблемам. Ротация ошибок - один из вариантов (keep first 10000 and last 10000 errors например).

Все строить не из принципа красиво и логично, в из принципа понятно для человека и удобно.

Опять не вижу противоречия между этими двумя вариантами.

ВСЕ ДОЛЖНО БЫТЬ МАКСИМАЛЬНО ТЕКСТОВОЕ И ЧЕЛОВЕКОЧИТАЕМОЕ. Протоколы и команды максимально текстовые и конфиги и отладка и логи тд.ВСЕ ДОЛЖНО БЫТЬ МАКСИМАЛЬНО ТЕКСТОВОЕ И ЧЕЛОВЕКОЧИТАЕМОЕ.

Но структура этих данных должна быть хоть как-то типизирована, потому что иначе это PHP и vTiger и ад, что будет приводить к переименованию переменных между уровнями и всё такое.

Живые легкие простые программы. Непрерывная разработка, микроитерации. Подробные стандартизированные логи, особенно при сбоях, возможность легкого дебага и отладки. Простота доработки и разработки в тч на лету Гибкость все можно переопределять через хуки и тп НЕ экономим память и процессор скорость и простота разработки важнее оптимальности работы программ.

Стандартизированные логи - вот за это бы на практике взяться и как-то забороть всю эту кашу.

Социальные приоритеты. (Комфорт для программистов и для пользователей. Agile в разработке и бизнесе)

Тут всё ок, да.

Коммуникации. Постоянная обратная связь с пользователями, от начала исследования потребностей, потом прототипирование, проектирование, и каждая неделя(спринт) разработки.

Общение через хелпдеск назвать коммуникацией тяжеловато, тем более там 1 к 1 общение. Когда клиентов много и нужно принимать решение, которое коснётся всех - у нас сейчас никакой внятной коммуникации нет вроде.

Архитектуру продумываем внимательно и долго, и прописываем, особенно независимость подсистем, уровни и модули. Скорость разработки архитектуры в 100 раз быстрее кодинга.

Тут всё ок, да. Только меня как-то мимо прошло :D

Учитываем что программирование это 10-15% времени, остальное отладка, тестирование и поиск багов.

Дай бог 5%. Ещё проблемы клиентов вообще не связанные с кодом продукта есть.

Написал строчку кода проверь, не проверил - пишешь объяснительную.

Три чая этому господину!

Автотесты и тесты обязательны.

Gitlab CI мне запилил бы кто ещё, а то куча тестов есть, а нормально гонять её не выходит.

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

Вываливать в логи питоновые трэйсбэки на каждый чих?

Взаимный кодревью обязателен.

Тут всё ок, да.

Биллиотеки, фреймворки обязательны всегда, свое писать только в крайних случаях.

Угу, в итоге пишем свой ansible в биллинге :)

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

Тут у меня небольшая бомбёжка:

#linux #selinux ### отключить selinux
#linux #selinux echo 0 > /selinux/enforce
#linux #selinux vi /etc/selinux/config
#linux #selinux SELINUX=disabled
#linux #selinux SELINUXTYPE=targeted
#linux #selinux SETLOCALDEFS=0

Конфиги и данные и задачи важнее, чем алгоритмы. Алгоритмы можно потом заменить.

Тут всё верно. Но вот с тулингом у наших конфигов - грустновато.

Самостоятельные программы. Независимые, отказоустойчивые, живучие, самодокументированные программы. Могут ставить и работать без админа и пользователь сам разберется. В случая сбоев восстанавливается. Любой программер садится и дорабатывает. Концепция, все должно быть без админа работать неадминистрируемая интеллектуальная система.

У гугла в srebook описывается похожий подход, что мне очень даже нравится. Они называют это автономными системами (а не автоматизированными).

Только такое (обеспечение автономности одновременно с развитием и разработкой программы) невозможно без мониторинга и разработчиков, которые следят за каждой установкой программы как за своей собственной.

Документация должна быть в коде

В таком случае у нас должны быть стандарты документации в коде, хотя бы для основных языков, иначе это будет каша и мешать читать и понимать код.

В каком случае делать рефакторинг и улучшения программы: только если она будет использоваться еще 3 года.

Ок.

В каком случае делать автоматизацию, с учетом частоты рутины раз в неделю раз в мес раз в год и сколько денег сэкономит автоматизация с учетом уменьшения человекоошибок.

Ещё бы учитывать суммарное время, отнимаемое разными рутинами у человека.

Автоматизация процесса разработки важна в первую очередь для освобождения мозга программиста и только во вторую для экономии времени. Цикл от строчки кода до отладки и теста не должен быть больше 1-3 секунд, от кода до чистового тестирования дистрибутива не более 1-10 минут. Поэтому разрабатывать лучше с rsync на рабочую среду и тестировать сразу и все это скриптануть. Не нужно собирать весь дистрибутив для теста одной программки.

Разумно. Ещё бы все эти “скриптануть” было запроектировано как делать, где хранить и всё такое (в репе, не в репе, как менеджить куда rsync, ip, ssh-ключи), а ещё лучше было бы более менее универсально расписано. В голову лезут хуки сборки, приведённые к тупо конфигам, но это маловероятно в реальном мире.

Тестирование и отладка максимально близко к среде использования и данным использования и объему использования.

Четыре чая этому господину. Однако не стоит забывать, что чем ближе исполнение кода к десктопу разработчика, тем быстрее разработка. А на десктопе абсолютно аналогичную среду не получить. + лично меня корёжит сложность разработки вдали от офиса и без интернета (без виртуалки никак, а крутить виртуалку на ноутбуке - боль).

Все ножницы одинаковые. Все инструменты всех разработчиков должны быть одинаковые в пределах одной команды, а лучше одной компании.

Но при этом инструменты должны подходить тому, кто ими пользуется. Хочешь чтобы юзали всё - будь бобр, обеспечь всем удобство использования. Гайды, советы, готовые конфиги, вот это всё.

Тесты должны тестировать в тч время и ресурсы и если они утекли тест файлед.

У меня были не совсем тесты, а сбор статистики по времени работы. В принципе к ним прикрутить алертер можно было, но тут всё надо правильно запускать, обновлять и правильно запускать (многие вещи зависят друг от друга). В принципе если выделить время и обновить gitlab, чтобы всем этим рулил CI - могу запилить.

Максимальное Разделение сервисов, ресурсов и данных и программ, и принцип разделения и независимости, изоляция. В тч для удобства и отказоустойчивости.

@ chroot’ы в PL5

Контроль версий и сборка их исходников, TDD

Ок

Проект должен быть международным, желательно комменты писать на русском и английском

Проект должен быть международным, желательно комменты писать на русском

Проект должен быть, желательно комменты писать на русском

Проект должен быть, желательно комменты писать

Проект должен быть, желательно писать

Проект должен быть

Шутка с долей правды. Энивэй, писать комменты на двух языках - зло, либо английский, либо русский, либо оба варианта в доке, но не в коде.

На этапе разработки и первого года внедрения, технологичность и динамика развития важнее, чем стабильность и надежность, даже в ущерб количеству клиентов

Разумно.

TODO

Описать unix style, new unixstyle git, примеры и почему это правильно

Описать почему зло создавать лишние уровни абстракций

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

бритва Оккама же. А вообще это должно обеспечиваться либами, где все эти имена определены заранее.

Глобальные переменные и глобальные конфиги и готу иногда зло это хорошо

Единственные три места, где глобальные переменные хорошо - то, где они:

  1. readonly
  2. счётчики в С
  3. что угодно в bash-скрипте на меньше, чем 20 строчек.

Других сценариев, где глобальные переменные адекватны - не знаю.

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

От простого к простому, чтоб реализовать сложное

А как иначе?