First commit
This commit is contained in:
commit
ed5c4b1623
1
.gitignore
vendored
Normal file
1
.gitignore
vendored
Normal file
@ -0,0 +1 @@
|
||||
.obsidian
|
7
README.md
Normal file
7
README.md
Normal file
@ -0,0 +1,7 @@
|
||||
# KRBL forever!
|
||||
|
||||
### В данном репозитории хранится информация о приципах кодирования, стеке, идеологии.
|
||||
|
||||
* [Стек разработки](./stack.md)
|
||||
* [План обработки заказа](./order_processing_plan.md)
|
||||
* [Безопасность](./security.md)
|
31
order_processing_plan.md
Normal file
31
order_processing_plan.md
Normal file
@ -0,0 +1,31 @@
|
||||
# План обработки заказа
|
||||
|
||||
1. Получение/согласование ТЗ по заказу
|
||||
|
||||
Для начала любых работ необходимо не только побеседовать с заказчиком, но и согласовать с ним ТЗ, в котором необходимо прописать все тонкости этого заказа как сто стороны клиента, так и с нашей стороны. Нужно минимизировать кол-во "очевидных" моментов с каждой из сторон.
|
||||
|
||||
2. "Дробление" ТЗ и выставление цены
|
||||
|
||||
Для уменьшения времени и увеличения качества разработки необходимо дробить проект на модули для повторного их использования. Таким образом можно написать код для создания платежных ссылок, а затем этот контейнер использовать ещё в множестве последующих проектов.
|
||||
|
||||
3. Разработка API
|
||||
|
||||
Перед тем как создавать интерфейс необходимо создать API и прописать к нему документацию для уменьшения кол-ва ситуаций, когда сайт переписывается целыми сегментами, так как инструментарий поменялся.
|
||||
|
||||
4. Тестирование
|
||||
1. Внутреннее тестирование
|
||||
|
||||
Перед публикацией кода необходимо провести внутреннее тестирование. Под этим подразумевается не только проверка документации и соответствие ей модуля, но и код этого модуля.
|
||||
|
||||
2. Тестирование заказчиком
|
||||
|
||||
Это необходимо сделать, так как даже при наличии ТЗ могут существовать функции, которые будут некорректно работать, но мы (как неразбирающие в теме люди) можем этого не заметить.
|
||||
|
||||
5. Разработка интерфейса
|
||||
6. Тестирование
|
||||
1. Внутреннее тестирование
|
||||
2. Тестирование заказчиком
|
||||
7. Приемка
|
||||
8. Дальнейшая поддержка
|
||||
|
||||
Дальнейшая поддержка осуществляется только при запросе модернизации продукта
|
3
security,md
Normal file
3
security,md
Normal file
@ -0,0 +1,3 @@
|
||||
# Безопасность
|
||||
|
||||
Для получения доступа к репозиториям необходимо подключить двухфакторную аутентефикацию, добавить в аккаунт SSH и GPG ключ.
|
17
stack.md
Normal file
17
stack.md
Normal file
@ -0,0 +1,17 @@
|
||||
# Стек разработки
|
||||
|
||||
На текущий момент стек следующий:
|
||||
|
||||
В бэкенде активно используем Golang. Для создания REST API - gin.
|
||||
Для маленьких программ - Python.
|
||||
|
||||
> Почему не C++ / Java?
|
||||
|
||||
Так как они не так хорошо подходят асинхронных программ. К тому же для написания программы на Golang требуется меньше времен, а по производительности будут примерно одинаковые результаты.
|
||||
|
||||
> Почему именно gin? Почему не mux или встроенный http?
|
||||
|
||||
Mux перестали активно поддерживать, а стандартный http не может в middleware.
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user