если бы классов, которые используют counter было мало, я бы так и сделал
но они подключаются очень много где и будет очень трудоемко везде сделать так
плюс в таком подходе мне придется пробрасывать созданный экземпляр counter внутрь приложения во все файлы и методы, которые его используют, это тоже сравнимо с тем что все придется переписать
я на вооружение я это приму, спасибо, но сейчас не оч хочется так делать...
Валентин, Можете скинуть ссылки на пару примеров того, что получается в итоге? Или как-то кратко описать, чтобы было понятнее стоит изучить это или нет))
Да, новый функционал вынесен в отдельные места и имеются DI ветвления в зависимости от.
Если нет смысла вести детальную документацию, то кто будет знать все о проекте?)) Я верю что наш проект - это миллиметр по сравнению с проектами в крупных компаниях. Как у них обстоят дела тогда?)
В проекте код организован хорошо (на мой взгляд).
Логирование да, надо выделить из этого вопроса. Но опять же вопрос про логирование - что логировать?
Допустим доступ к базе идет только через "модели". Если я просто буду логировать "Запись изменена" - это ничего не даст. Важнее знать - по какой причине она изменена, какой сценарий был запущен. Такое впечатление что придется в начале каждого метода каждого класса писать строку кода с логированием но это как-то странно.
Я и еще пара людей могут ответить на нужные вопросы (например перечисленные в теме), но на это уходит время + нет 100% уверенности, что я чего-то не забыл.
Для уверенности, допустим решили сделать документацию. Но вопрос - как она должна выглядеть, чтобы я смог по ней найти нужную тему? Расписывать классы и их методы - пустая трата, думаю надо расписать сценарии. Но на это надо потратить время + поддерживать постоянно...
По поводу переписать проект - в этом нет необходимости, на мой взгляд с архитектурой там все в порядке.
Заранее описать все модели, бизнес процессы никогда не представляется возможным, т.к. эти вещи меняются в процессе задумки, разработки, эксплуатации и тд. Всегда идет разработка от прототипа и в конечном итоге может получиться абсолютно другой проект. Да и издержки на поддержку документации в актуальном состоянии будут одинаковыми, пиши их с начала проекта или с середины
Я и хотел узнать как люди себе это представляют =)
Думаю что код документировать не нужно (если я правильно понимаю что имеется ввиду)
Лучше обойтись описанием компонентов и добавить теги, например #userstatus и потом искать по ним.
Но заранее я не могу сказать какие теги мне понадобятся в будущем. Какие логи мне понадобятся в будущем.
Как понять что стоит логировать а что нет? Сейчас стоит вопрос - кто меняет статус? завтра встанет вопрос - почему у этой новости нет названия? или доверять ли пользователю, что он не трогал этот раздел сайта, а в нем пропала информация?
Алексей Тен, Сейчас при атаке страдают все сайты и ждут загрузку страницы примерно 15-20 секунд. Если мы баним адрес на 10-15 сек, для этого человека разницы не будет, я думаю.
но они подключаются очень много где и будет очень трудоемко везде сделать так
плюс в таком подходе мне придется пробрасывать созданный экземпляр counter внутрь приложения во все файлы и методы, которые его используют, это тоже сравнимо с тем что все придется переписать
я на вооружение я это приму, спасибо, но сейчас не оч хочется так делать...