Как развить навык проектирования приложения или как стать Senior?
===================================================================

 Я довольно неплохо знаю PHP, долго разбирался с шаблонами проектирования, с кодом популярных фреймворков. Но все же когда начинаю писать свое приложения, делаю это как Junior (вообще где граница между junior и middle).   

Посоветуйте как развить в себе мышления senior программиста или хотя бы middle ? Как грамотно проектировать приложения? Как понять что здесь нужно создать класс или у наследовать его? 

 Вам помогут только время и большое количество реализованных проектов. Всё приходит с опытом.  

Я, например, каждые полгода делаю ревью собственного кода за предыдущие полгода и ужасаюсь - как я мог так писать? А ведь полгода назад я мнил себя профессионалом... и так каждые полгода )) 

 Писать код. Читать код. Например, популярные опенсорсные проекты на гитхабе. Если очень уж книгу хочется, то вот минимальный джентельменский набор:  

1. Совершенный код. С. Макконнелл  

2. Чистый код: создание, анализ и рефакторинг. Роберт Мартин  

3. Приёмы объектно-ориентированного проектирования. Паттерны проектирования. Банда четырех))  

4. PHP. Объекты, шаблоны и методики программирования. Мэт Зандстра  

5. Рефакторинг: улучшение существующего кода. Мартин Фаулер  

И т.д. Книг крайне много. И статей много. И простое их чтение мало что даст. Практика, много практики. Критичное отношение к своему коду, однако без перегибов - не стоит упираться в перфекционизм. 

 Писать много кода. Читать книги. Читать чужой(хороший) код. 

 Предлагаю определить Junior, Middle, Senior следующим образом, чтобы было понятно, куда двигаться:  
* Junior - вы только-только начали ориентироваться (в языке или , может быть, в предметной области, в которой работает компания), поэтому **вам говорят что делать и как это делать**. Вы задаёте вопросы "почему так, а не вот так?" и получаете ответы (иногда ищете сами). Для вашей работы готовы все необходимые каркасы,  

 вы делаете то, что для остальных очевидно. Вы с удовольствием фигачили бы код килобайтами, но пока много не знаете/не понимаете, поэтому основное время проводите в изучении: статей в интернет, мануалов по языку, чужого кода
* Middle - вы хорошо ориентируетесь (в язые или, может быть, в предметной области, понимаете употребляемый окружающими жаргон и можете поддержать беседу, рассказать о том, что узнать про это в интернете или конференциях), поэтому **самостоятельно решаете как делать то, что вам говорят сделать**, иногда оспаривая те или иные решения и предлагаю свои. Вы фигачите код килобайтами и даже мегабайтами и решаете не только стоящие перед вами задачи, но и учитесь делать что-то неизвестное ранее. Порой даже уговариваете менеджеров соглашаться на нереальные сроки и работаете по вечерам допоздна, лишь бы попробовать какую-то новую технологию/фреймворк/язык/etc
* Senior - вы свободно ориентируетесь (и в языке, и в предметной области, и в имеющемся в компании коде, вводите в обиход новые жаргонные словечки, которые подхватывают все), поэтому **самостоятельно решаете как сделать и что сделать на основании целей и проблем, описанных руководством/заказчиком,** иногда отговариваете их делать что-то ради того, чтобы сфокусировать команду и себя на важных вещах. Основная масса кода, который значится за вами в репозиториях сделаны в одном из первых коммитов, и включает в себя настройку подключенных фреймворков и создание каркаса для наполнения его силами Middle и Junior разработчиков. Вы отговариваете и убеждаете всех вокруг не делать то, чего делать не нужно, присматриваете за тем, чтобы Junior'ы (в большей степени) и Middle'ы (в меньшей степени) действовали согласовано и трактовали заложенный в проект каркас так, как вы это подразумевали.

 

 Исключительно опыт.  
  

Если писать проекты, и писать все более и более сложные проекты, а потом их еще и поддерживать, то постепенно вы будете приходить к пониманию, что изначально можно было сделать так, чтобы впоследствии было проще.  
  

Со временем, вы можете и сами прийти к world best practice, но нужно помнить, что в каждом проекте могут быть свои уникальные нюансы, и world best practice тоже нужно оценивать критически.  
  

Что делать?  

Участвовать в сложных проектах, интересоваться историей этого проекта - как пришли к тому или другому решению.  

Можно и нужно почитывать книги, но понимать, что не все решения легко интегрируются, особенно в середине. 

 1.Написать ручкой бейджик Senior.  

2.Повесить бейджик на грудь.  

3. Поздравляю вы Senior.  
  

А по сабжу:  

Все приходит с годами и опытом.  

Развивайтесь в нужном вам направлении. 

 на ошибках учатся, и не обязательно на своих 

 Все пишут что все с опытом, я согласен, но хочу добавить с каким именно опытом. Делая простые сайты визитки 10 лет ты будешь иметь опыт, скажем, не совсем тот что нужен сеньёру) Нужно участвовать в разработке больших, сложных проектов, и смотря как реализуются те или иные вещи, решая сложные задачи в рамках этих проектов приходит тот самый опыт - находить решения о которых еще не знаешь и как сделать что-то что уже давно придумали как делается(это про велосипеды) 

 Архитектура выкристаллизовывается по ходу работы над проектом. Ошибки в архитектуре, допущенные на начальном этапе разработки, очень дороги для исправления в последствии, но жизнь такова, что наперед никогда не знаешь всей предметной области и задач.  
  

На мой взгляд серебряную пулю по части архитектуры до сих пор не изобрели, поэтому тут кто во что горазд. На моем опыте относительно хорошая архитектура получается если переписать проект с нуля 3-4 раза самостоятельно, но такое редко возможно.  
  

Так же спасает автоматизация и кодогенерация, но тут необходим опыт. Я с 2006 года до 2011 собрал много грабель как фуллстэк веб девелопер, с 2009 года присматривался к ряду фреймворков, не срослось - написал свой, с тех пор полет нормальный. Необходимые задачи он решает и по части архитектуры берет на себя примерно 80% нагрузки. За 5+ лет я его потихоньку допиливаю когда возникают новые ситуации.   
  

Но это на бэкенде, а вот по части фронтенда полный ахтунг, да настолько, что пришлось снова перебирать доступные фреймворки. Остановился на реакте. Подумываю на бэкенде с пхп на ноду съехать, нужно будет переписать фреймворк, но там есть ряд сложностей, т.к. другие принципы работы приложения.  
  

В заключение добавлю, что как только появляются принципиально новые задачи, отработанная и отлаженная архитектура, хорошо показавшая себя за годы эксплуатации, может оказаться совершенно непригодной и придется прикручивать костыли и думать. Очень много думать... Снова...