Принципы
Различия
Здесь показаны различия между двумя версиями данной страницы.
| Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
|
foxdev_7:принципы [15.01.2018 10:37] admin |
foxdev_7:принципы [20.05.2019 15:18] (текущий) |
||
|---|---|---|---|
| Строка 4: | Строка 4: | ||
| Пока без систематизации | Пока без систематизации | ||
| + | * 2018 Читаемость и сопровождаемость кода важней удобства написания. | ||
| * Программы пишутся для пользователей и программистов, а не для компьютера, все должно быть понятно для человека. ЗАПРЕЩЕНО жалеть в коде память, проц и диск, пока этого не потребует рынок, но в архитектуре продумать будущую оптимизации нужно. | * Программы пишутся для пользователей и программистов, а не для компьютера, все должно быть понятно для человека. ЗАПРЕЩЕНО жалеть в коде память, проц и диск, пока этого не потребует рынок, но в архитектуре продумать будущую оптимизации нужно. | ||
| * ЗАПРЕЩЕНО ОПТИМИЗИРОВАТЬ КОД, кроме случаев когда рынок **заставит** это сделать. Оптимизация только в крайних случаях. Выделим отдельно НЕТ математике НЕТ экономии ресурсов. | * ЗАПРЕЩЕНО ОПТИМИЗИРОВАТЬ КОД, кроме случаев когда рынок **заставит** это сделать. Оптимизация только в крайних случаях. Выделим отдельно НЕТ математике НЕТ экономии ресурсов. | ||
| * Максимальная читаемость кода, учитывать ограниченные возможности человека и ошибки, и недостаток колва профи специалистов. | * Максимальная читаемость кода, учитывать ограниченные возможности человека и ошибки, и недостаток колва профи специалистов. | ||
| - | * Запрещено делать математическую стройности в ущерб читаемости кода или стройность ради стройности. | + | * Запрещено делать математическую стройность в ущерб читаемости кода или стройность ради стройности. |
| * Строить надо из маленьких кирпичиков, каждый из которых полностью понятен одному человеку, студенту, школьнику, ребенку. | * Строить надо из маленьких кирпичиков, каждый из которых полностью понятен одному человеку, студенту, школьнику, ребенку. | ||
| * Система должна учитывать, что человек ошибается, ошибки программиста - не падать, ошибки админа - не падать. | * Система должна учитывать, что человек ошибается, ошибки программиста - не падать, ошибки админа - не падать. | ||
| * Алгоритм отдельно, данные отдельно, задачи отдельно. Падение обработки одной задачи не должны убивать программу или портить данные, задача должна пытаться обработаться заново, или отбрасываться или помещаться в корзину плохие данные и логироваться или отправлять емейл админу. | * Алгоритм отдельно, данные отдельно, задачи отдельно. Падение обработки одной задачи не должны убивать программу или портить данные, задача должна пытаться обработаться заново, или отбрасываться или помещаться в корзину плохие данные и логироваться или отправлять емейл админу. | ||
| - | * Все строить не из принципа красиво и логично, в из принципа понятно для человека и удобно. Это сложно для понимания тк многие считают что математически стройно всегда красиво и удобно, но это не так ибо природа человека далека от чистой математики. | + | * Все строить не из принципа красиво и логично, а из принципа понятно для человека и удобно. Это сложно для понимания тк многие считают что математически стройно всегда красиво и удобно, но это не так ибо природа человека далека от чистой математики. |
| * ВСЕ ДОЛЖНО БЫТЬ МАКСИМАЛЬНО ТЕКСТОВОЕ И ЧЕЛОВЕКОЧИТАЕМОЕ. Протоколы и команды максимально текстовые и конфиги и отладка и логи тд. ВСЕ БИНАРНЫЕ ПРОТОКОЛЫ ДОЛЖНЫ УМЕРЕТЬ или уйти на уровень электроники. | * ВСЕ ДОЛЖНО БЫТЬ МАКСИМАЛЬНО ТЕКСТОВОЕ И ЧЕЛОВЕКОЧИТАЕМОЕ. Протоколы и команды максимально текстовые и конфиги и отладка и логи тд. ВСЕ БИНАРНЫЕ ПРОТОКОЛЫ ДОЛЖНЫ УМЕРЕТЬ или уйти на уровень электроники. | ||
| * Пляшем от конфига, а кто его реализут postfix, sendmail или exchange это уже вторично. Конфиг надо выбирать по стандарту готовому или аля uri, или свой, но удобный для человека, на основе одного конфига можно генерировать несколько для программ с другими конфигами. | * Пляшем от конфига, а кто его реализут postfix, sendmail или exchange это уже вторично. Конфиг надо выбирать по стандарту готовому или аля uri, или свой, но удобный для человека, на основе одного конфига можно генерировать несколько для программ с другими конфигами. | ||
| - | * Живые легкие простые программы или микросервисы. Непрерывная разработка, микроитерации. Подробные стандартизированные логи, особенно при сбоях, возможность легкого дебага и отладки. Простойотки и разработки в тч на лету Гибкость все можно переопределять через хуки и тп НЕ экономим память и процессор скорость и простота разработки важнее оптимальности работы программ. | + | * Живые легкие простые программы или микросервисы. Непрерывная разработка, микроитерации. Подробные стандартизированные логи, особенно при сбоях, возможность легкого дебага и отладки. Простота настройки и разработки, в т.ч. на лету. Гибкость: всё можно переопределять, через хуки и тп НЕ экономим память и процессор скорость и простота разработки важнее оптимальности работы программ. |
| * Социальные приоритеты. (Комфорт для программистов и для пользователей. Agile в разработке и бизнесе) | * Социальные приоритеты. (Комфорт для программистов и для пользователей. Agile в разработке и бизнесе) | ||
| * Коммуникации. Постоянная обратная связь с пользователями, от начала исследования потребностей, потом прототипирование, проектирование, и каждая неделя(спринт) разработки. | * Коммуникации. Постоянная обратная связь с пользователями, от начала исследования потребностей, потом прототипирование, проектирование, и каждая неделя(спринт) разработки. | ||
| Строка 23: | Строка 23: | ||
| * Автотесты и тесты обязательны. Система тестирования должна быть полностью автоматизирована, функциональные и интеграционные тесты важней и первичней, чем юнит-тесты. | * Автотесты и тесты обязательны. Система тестирования должна быть полностью автоматизирована, функциональные и интеграционные тесты важней и первичней, чем юнит-тесты. | ||
| * Программа должна быть громкой и писать о проблемах на экран с указанием строки и файла, при этом ошибки перехватывать нельзя, а если перехватили, то текст нижних уровней обязательно сохраняется в ошибке и свой добавляется к нему. | * Программа должна быть громкой и писать о проблемах на экран с указанием строки и файла, при этом ошибки перехватывать нельзя, а если перехватили, то текст нижних уровней обязательно сохраняется в ошибке и свой добавляется к нему. | ||
| - | * Взаимный кодревью обязателен, либо взаимный мердж реквест, даже тимлид не должен добавлять код в рабочии ветки без ревью другим кодером. | + | * Взаимный кодревью обязателен, либо взаимный мердж реквест, даже тимлид не должен добавлять код в рабочие ветки без ревью другим кодером. |
| * Библиотеки, фреймворки обязательны всегда, свое писать только в крайних случаях. | * Библиотеки, фреймворки обязательны всегда, свое писать только в крайних случаях. | ||
| * Безопасность на этапе проектирования ДА, на этапе разработки только в крайних случаях и разумных пределах. Лучше использовать готовые проверенные средства безопасности, чем придумывать свои. | * Безопасность на этапе проектирования ДА, на этапе разработки только в крайних случаях и разумных пределах. Лучше использовать готовые проверенные средства безопасности, чем придумывать свои. | ||
| * Безопасность. Многоуровневая безопасность. Взлом одной части не должен давать полный доступ. Превентивная безопасность, предполагать что взлом будет одного из уровней и делать защиту для тех дыр которых еще нет. Понимать, что общая безопасность равна безопасности самого слабого звена. Превентивная безопасность, если взломали стандартными средствами, то ничего не получится, стандартные эксплоиты не должны работать. | * Безопасность. Многоуровневая безопасность. Взлом одной части не должен давать полный доступ. Превентивная безопасность, предполагать что взлом будет одного из уровней и делать защиту для тех дыр которых еще нет. Понимать, что общая безопасность равна безопасности самого слабого звена. Превентивная безопасность, если взломали стандартными средствами, то ничего не получится, стандартные эксплоиты не должны работать. | ||
| * Конфиги, данные, подходы и задачи важнее, чем алгоритмы, программы и демоны. | * Конфиги, данные, подходы и задачи важнее, чем алгоритмы, программы и демоны. | ||
| - | * Самостоятельные живые программы. Независимые, отказоустойчивые, живучие, самодокументированные программы. Могут ставить и работать без админа и пользователь сам разберется. В случае сбоев восстанавливается. Любой программер садится и дорабатывает. Концепция, все должно быть без админа работать неадминистрируемая интеллектуальная система. | + | * Самостоятельные живые программы. Независимые, отказоустойчивые, живучие, самодокументированные программы. Могут ставить и работать без админа и пользователь сам разберется. В случае сбоев восстанавливается. Любой программер садится и дорабатывает. Концепция, все должно без админа работать, неадминистрируемая интеллектуальная система. |
| * В идеале документация должна быть в коде или в файлах рядом с кодом. | * В идеале документация должна быть в коде или в файлах рядом с кодом. | ||
| - | * В каком случае делать рефакторинг и улучшения программы, только если она будет использоваться еще 3 года. | + | * В каком случае делать рефакторинг и улучшения программы? Только если она будет использоваться еще 3 года. |
| * В каком случае делать автоматизацию, с учетом частоты рутины раз в неделю раз в мес раз в год и сколько денег сэкономит автоматизация с учетом уменьшения человекоошибок. Помнить что ничего вечно не используется и возможно достаточно инструкций. | * В каком случае делать автоматизацию, с учетом частоты рутины раз в неделю раз в мес раз в год и сколько денег сэкономит автоматизация с учетом уменьшения человекоошибок. Помнить что ничего вечно не используется и возможно достаточно инструкций. | ||
| * Автоматизация процесса разработки, это важна в первую очередь для освобождения мозга программиста и только во вторую для экономии времени. | * Автоматизация процесса разработки, это важна в первую очередь для освобождения мозга программиста и только во вторую для экономии времени. | ||
| Строка 51: | Строка 51: | ||
| * База-base-гипервизор-нода-хост, не обязаны быть микроосью, можно использовать и обычную ОС, но все файлы базы лежат в одном каталоге по принципу DAAP, стараемся максимально не зависеть от ОС, если крон и прочее то симлинками на себя из cron.d или автоконфигурирование каждый старт. Переустановка ОС не должна влиять на работу базы. Отличия от гипервизора, то что службы можно не только стартовать, но и настраивать через файл описания службы, через веб интерфейс и т.д. | * База-base-гипервизор-нода-хост, не обязаны быть микроосью, можно использовать и обычную ОС, но все файлы базы лежат в одном каталоге по принципу DAAP, стараемся максимально не зависеть от ОС, если крон и прочее то симлинками на себя из cron.d или автоконфигурирование каждый старт. Переустановка ОС не должна влиять на работу базы. Отличия от гипервизора, то что службы можно не только стартовать, но и настраивать через файл описания службы, через веб интерфейс и т.д. | ||
| * Возможность централизовано управлять всеми конфигами организации через единый интерфейс, например git, carbon_rtsh и тп | * Возможность централизовано управлять всеми конфигами организации через единый интерфейс, например git, carbon_rtsh и тп | ||
| + | * Принцип посмотри свысока свежим взглядом, защита от переусложнения! Часто разработка софта, архитектуры или правил уходит в глубокую бесконечную идеализацию, возникает множество деталей. Важно посмотреть на все сверху от главных процессов от первичной задачи проекта, возможно не окупится такая идеальная проработка. | ||
| Если есть желающие систематизировать и отсортировать, сделать примеры, расширить и тд, все скажут спасибо. | Если есть желающие систематизировать и отсортировать, сделать примеры, расширить и тд, все скажут спасибо. | ||
| - | [[open_carbon_7:инструкция_программиста|Читать далее: инструкция_программиста]] | + | [[foxdev_7:инструкция_программиста|Читать далее: инструкция_программиста]] |
| + | ~~OWNERAPPROVE~~ | ||
admin