У меня уже получается писать код. В целом, всё что хочу, то уже могу каким то образом написать.
Но чем дальше разрабатываю приложение, тем чаще приходится переделывать структуру приложений, писать левые функции. И присутствует некая неуверенность. Часто пишу всё в кучу, а потом разгребаю всё это. Потому что иначе чресчур тяжелым становится логика, если делю сразу на куски. Иногда кажется что я прям очень часто выношу логику в функции и т.д, хоть и обоснование есть.
Пишу я сейчас на Vue и Node, но я думаю это не очень важно
Где можно научится архитектуре приложений, может книги или это только опыт? Мне советовали смотреть код чужой, но опять же тут столько ньансов
- Нельзя понять компетентность программиста, ведь могу наткнуться на код такого же, как и я
- Достаточно тяжело найти тот стек или хотя бы похожий на твой
По своему примеру: начал читать "синюю книгу" по DDD, помучал и бросил. Через какое-то время попал на проект, где более опытные ребята пытались реализовать DDD. Немного поработав на проекте снова вернулся к "синей книге" - и здесь она уже пошла: я читал книгу, вспоминал проект, понимал/осознавал, как мною прочитанное соотносится с тем, что в проекте.
Похожа картина была когда-то и с шаблонами проектирования: будучи "зелёным" осилил пару-тройку глав. После полутора лет работы книга зашла на ура.
По книжкам - не особо эффективно. Личный опыт и "насмотренность" взгляда здесь будут лучше учителя.
Работая на себя или делая фриланс, архитектура не имеет особого смысла. Архитектура обычно появляется
где есть какой-то конфликт. Например конфликт денег. Или людей. Или ресурсов. Или есть варианты как разрабатывать.
Если ты писал сплошняком (стеной) код и это работало то это и есть твоя архитектура. И тебе другое не надо.
Можешь почитать Макконнелла - Совершенный код. Но его лучше читать как-бы закрепляя то что
ты сам уже понял.
Есть шуточная статья на хабре где Java разработчик пишет расчет факториала по всем правилам шаблонов.
Это как-бы пример оверинжинеринга или того как не надо делать. И понять где архитектурное решение было нужно
а где не нужно - это как раз и есть опыт архитектора.
Если тебе интересна оценка твоего кода со стороны - то закжи себе code-review и просто послушай что
другие teammates говорят о твоем коде. Будет больная и неприятная правда. Это все - тоже части архитектур.
А такой вопрос. Я часто слышу, что иногда нужно отстаивать решение. Как понять верное ли замечание или нет? Одно дело компания, где такое бывает, а другое дело твой код, который человек видит первый раз и не понимает что и как тут устроенно.
Хотя я конечно и понимаю что это уже разные мнения и прочее, но может есть что сказать по этому поводу?
Личный опыт, фтыкание в чужой код, даже код-ревю - это всё не принесёт результата. Говорю это по личному опыту. Так получилось что на работе я сейчас единственный программист на моём стэке (а устроился с нуля после курсов). И несмотря на невероятную круть специалистов вокруг меня, я расту крайне медленно и не факт что в нужном направлении.
Я понял что просто теряю время. Чтобы расти в своём стэке - надо устраиваться в команду, которая активно использует именно его, плюс процессы там д.б. выстроены так чтобы у людей была возможность/желание меня растить. Т.е. надо менять работу, как это ни печально.
Если замечание обосновано как - "Если сделать так, то могут быть проблемы, тут, тут и вон там", то это верное замечание. Если замечание - "это все говно, переделай на паттерн name, потому что я бы именно так и сделал", то такое замечание идет на йух, оно ценности никакой не несет. Нельзя сказать верное ли замечание в сферическом вакууме. Решение может быть как плохим, так и хорошим только в рамках проекта, или даже отдельного модуля в проекте. Если например у вас микросервисы, и 2млн. сообщений в секунду, а человек предлагает использовать реббит mq, а не кафку, то это может сказаться плохо на проекте. Если у вас не так много сообщений, но сложная логика маршрутизации сообщений, то логично выбрать реббит. it depends короче.
Изучать теорию лучше всего по книжкам, конечно, а практику на практике, соответственно. Но есть один нюанс, чтобы понять парадигмы и шаблоны, нужно попасть в условия, для которых их придумали. То есть просто в пет-проекте в полной мере осознать тот же SOLID нереально, нужно продолжительное время поработать в крупном проекте, который на протяжении многих лет активно развивает большая команда.
Сложный
