main

Author: pvaviloff

readme.md

@@ -33,11 +33,11 @@
 
 Первые проблемы начинаются с неявно описанных тасков и плохо спроектированной базы. Если при прочтении таска у вас возникли вопросы в первую очередь пишем их в таск комментарием, обращаемся к ПМ-у. Часто бывают ситуации, когда уточнение задачи вы обсуждаете напрямую с постановщиком. Если такое случается берем за правило оповестить ПМ-а про изменения/уточнения. Просим постановщика подправить сам таск или даже просто в таск скинуть переписку в которой вы решили непонятные моменты. В таске обязательно должны быть зафиксированы все уточнения и/или изменения задачи. Это может привести к переэстимейту таска.
 
-Что делать с существующей базой? Если вам не понятна структура базы или логика работы обращаемся к тим лиду. Он или подскажет или направит к человеку, который разрабатывал функционал и/или знает ответы на ваши вопросы. Советуем визуализировать часть таблиц, с которой вы работаете. Делаем это в https://www.dbdesigner.net/ Описанную структуру можно закинуть в таск комментарием. Это может помочь вам в будущем при переоткрытии таска через время, или другому человеку при выполнении связанных тасков. Так же описанная структура таблиц может лечь в основу документации к функционалу.
+Что делать с существующей базой? Если вам не понятна структура базы или логика работы обращаемся к тим лиду. Он или подскажет или направит к человеку, который разрабатывал функционал и/или знает ответы на ваши вопросы. Советуем визуализировать часть таблиц, с которой вы работаете. Делаем это в [https://oino.uno/db-architecture](https://oino.uno/db-architecture) или [https://www.dbdesigner.net/](https://www.dbdesigner.net/) Описанную структуру можно закинуть в таск комментарием. Это может помочь вам в будущем при переоткрытии таска через время, или другому человеку при выполнении связанных тасков. Так же описанная структура таблиц может лечь в основу документации к функционалу.
 
 Что делать если логика, которая описана в таске не совпадает с реализацией в проекте? Это зачастую связанно со старым функционалом. Особенно если постановщик больше не работает в компании, и его функционал отдали другому человеку. В таком случае необходимо сообщить об этом ПМ-у, отписать в таск. Дальше действовать по ситуации.
 
-Для понимания бизнес логики старой/новой желательно ее визуализировать https://app.diagrams.net/ Блок-схема не обязана совпадать полностью с написанным кодом. Она должна визуализировать бизнес логику. В дальнейшем эта схема может так же стать фундаментом для документации.
+Для понимания бизнес логики старой/новой желательно ее визуализировать [https://oino.uno/diagrams](https://oino.uno/diagrams) или [https://app.diagrams.net](https://app.diagrams.net/) Блок-схема не обязана совпадать полностью с написанным кодом. Она должна визуализировать бизнес логику. В дальнейшем эта схема может так же стать фундаментом для документации.
 
 Нужно ли писать документацию? Документация нужна только для функционала, который имеет сложную для понимания логику, которую необходимо визуализировать. Что такое "сложная логика"? Если у вас начали появляться вопросы при реализации/рефакторинге/доработке как функционал должен работать. Тогда в обязательном порядке должна появиться страница в Confluence с описанием структуры базы и блок-схемой бизнес логики как минимум. Страницу вам заводит ПМ. В документации должно быть меньше слов, больше визуальных схем с описанием. Легче воспринимать информацию визуально чем через полотна текста.