Принципы
Различия
Здесь показаны различия между двумя версиями данной страницы.
| Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
|
foxdev_7:принципы [15.01.2019 07:13] admin Approved(admin 2019/01/15 07:13) |
foxdev_7:принципы [20.05.2019 15:18] (текущий) |
||
|---|---|---|---|
| Строка 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~~ | ~~OWNERAPPROVE~~ | ||
admin