Где найти недостающие куски пазла, что лежат между сеньором и архитектором?
Я знаю С++, паттерны, имею представление о SOLID, что-то вокруг почитал. Рефакторинг там всякий...
Имею некоторый опыт десктопной разработки. Небольшой. Лет 20.
Но у меня есть чёткое ощущение, что я всё ещё болтаюсь где-то на уровне сеньора (в лучшем случае, хорошо если не миддла).
При этом я неплохо понимаю, что такое объекты-классы-шаблоны-модули-паттерны.
Но кажется, я не понимаю, а что же из этого всего получается, когда собирается некая общая конструкция.
Более того, я не могу аргументированно сказать, что вот эта структура классов ок, а эта - дно.
На мой вкус если код работает, то всё норм.
В общем, есть идеи, чтобы такого почитать, чтобы перейти на следующий уровень?
Книжки про архитектуру пробовал листать, но в гугле в основном попадаются про микросервисы, что несколько далековато от десктопной разработки. То ли надо искать не про архитектуру, а что-то из Мартина Фаулера (а внутри внезапно окажется архитектура, про которую на обложке ни слова), то ли переходить на видео.
Ну или может где-то водятся менторы, или как там это сейчас правильно называть?
20 лет в it это вечность, сменилось минимум пара эпох, переворачивающих все 'с ног на голову'.
архитектор это немного про другое, программист 'строит дом из кирпичей' и делает это на отлично, архитектор же говорит сколько комнат будет в доме, где будут окна и двери, и он понимает почему в данном месте нужна вентиляционная шахта и почему ее нельзя пододвинуть 'на другую сторону'.
Это очень далекие профессии, хоть и делают казалось бы одно дело, и из программистов становятся архитектором только большим опытом и/или незаурядными аналитическими способностями.
Архитектор КМК это не про количество прочитанных книг а про количество успешно созданных или внедрённых проектов. И архитектура - это не только объекты шаблоны. Это еще и общая хозяйственная деятельность.
Понимание стоимости владения. И умение красиво говорить в телефон или в скайп.
Вова, нет. Надо изучать подходы к развитию сложных проектов, набивать свои шишки, думать об изменениях наперед. Десктопные приложения, как собственно и микросервисы - это лишь единицы из сотен\тысяч элементов архитектуры полноценного продукта. Насмотренность и широта взглядов, вот что нужно к архитектору.
"Прокачка мозга" тут ни помощник.
Прежде всего, нет никакого "между". Сеньор - это грейд, а архитектор - это должность. Программисты в архитекторы не вырастают, а уходят, как и в менеджмент. По сути же вопроса, парадигмы, шаблоны проектирования и прочее можно выучить по книжкам, но по-настоящему понять можно только попав в условия, для которых они были придуманы. То есть это больше практический навык длительной работы в крупных, быстроизменяющихся проектах с большой командой. Ну, и стоит заметить, что проектирование систем - это не столько код, сколько стандарты, спецификации, схемы и ооочень много общения с бизнесом, разработкой, эксплуатацией, безопасниками и т.д. и т.п.
Araya, Во-первых, я интроверт. Мне проще спросить в интернетах, чем на работе.
Во-вторых, компании бывают разные. У нас, например, есть 100500 разных продуктов, и 100500 команд, которые их разрабатывают. Конкретно в нашей команде... 4 человека. И нет, там нет никакого архитектора. А есть ли он в соседних командах я не знаю.
Araya, Вообще, я предельно точно задал вопрос: что читать, и где искать ментора. Но это интернет, тут могут посоветовать всё что угодно, кроме того что надо.
Вова, для умения проектировать код начать можно с банды четырёх, Мартина и SICP. Начальное для проектирования систем - Клеппман, Нейгард, Фаулер. Книг превеликое множество, гуглятся они достаточно легко, но усваиваются обычно плохо без соответствующей почвы, как я уже написал. А вот ментора в этой области найти нереально, думаю. Архитектор - это обычно человек с очень дорогим временем и очень большой усталостью. Я в последнее время здесь-то все реже появляюсь.
Сергей Горностаев, Сергей, вы написали "Ну, и стоит заметить, что проектирование систем - это не столько код, сколько стандарты, спецификации, схемы и ооочень много общения с бизнесом, разработкой, эксплуатацией, безопасниками и т.д. и т.п."
Но разве этим не занимаются системные аналитики? Будьте любезны, расскажите с высоты вашего опыта где проходит граница между системным аналитиком и архитектором?
pavel_the_man, прежде всего в глубине понимания технической части. Кроме того спецификации и общение с бизнесом ведь тоже разные могут быть. Аналитики в основном работают с требованиями или документированием существующей системы, а архитекторы проектируют будущие системы или будущие версии существующих. Первые больше про понимание и формализацию того, что хочет бизнес. Вторые про понимание того, что возможно и какой ценой. Часто и те, и другие тесно работают друг с другом. В некоторых компаниях даже бывает, что один человек совмещает функции аналитика и архитектора, но я считаю это плохой практикой.
Вот если системный аналитик пишет разработчику техническое задание, где указывает как доработать базу данных (какие создать таблицы, какие будут поля и какие ограничения), а также пишет какие разработать апи-методы (какие эндпоинты,что будет передаваться в тело запроса, и что метод должен возвращать), то является ли это хорошей практикой работы системого аналитика, или он уже лезет в архитекторские дебри?
Или аналитик просто должен указать чего хочет бизнес (кликаю на кнопку и происходит то-то), а разработчик/архитектор сам спроектирует бэкенд системы?
pavel_the_man, на такой уровень и архитектору желательно не соваться, код и api отдельных компонентов - это ответственность программистов. Кроме разве что случаев, когда надо помочь советом или координацией разработчиков клиентской и серверной стороны. В ТЗ стоит описать необходимую функциональность и атрибутный состав данных. Но это моё мнение, в некоторых компаниях архитекторы спускают разработке и спецификацию api, и схему данных до начала разработки.
В общем, есть идеи, чтобы такого почитать, чтобы перейти на следующий уровень?
Мб посмотреть исходники проектов типа wireshark или libre office? Можно поискать курсы(скорее это серии видосов) по system design - можно так и вбить в ютуб/гугл "system design playlist/course", часто разбирают вполне рабочие решения
Чувак у тебя гигантский опыт в 20 лет и если ты не можешь ответить на эти вопросы то наверно уже и не надо, в целом этого срока достаточно чтобы уже уходить на пенсию
Представь себе, что не все люди развиваются по одному грейду в год. Я эти 20 лет потратил не только на работу, но и на то, чтобы сходить в аспирантуру, по-восстанавливаться после выгорания, завести ребёнка, позаниматься хобби. Плюс, у меня не было крутого ВУЗа в качестве фундамента. Поэтому я там, где я есть. Я просто сеньор, пишущий под винду.
Пума Тайланд, Хах, да. Я, в принципе, не против. Но размер моей пенсии будет, наверное, в 20 раз меньше, чем размер моей зарплаты. И на такие деньги я не проживу ;)
Нашёл что-то похожее на свой вопрос.
Лежит в гугле по словам 'Обзор книги “Staff Engineer” — Part I' :)
Там как раз рассматривается два варианта роста - менеджерский и разработческий.
Ссылки не будет, сейчас не разберёшь, какие ссылки легальные, а какие нет.
