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