Сперва ответьте себе на вопрос: стоит ли туда идти прямо сейчас с текущим опытом? И с какой целью?
Если рассмотреть инженера в компании, где налажены процессы и есть понятное разделение ответственности, то умение проектировать системы ожидают от старших разработчиков ближе к уровню синьор.
Зачастую собеседования на такой грейд сопровождаются классическим system-design interview, где вас попросят спроектировать твиттер, ютуб или другую популярную систему.
Конечно, не мало стартапов или гос. компаний, где джуны занимаются проектированием сложной системы, но это нездоровая практика и мы не будем про нее говорить.
Важно понимать: одно дело научиться правильному проектному мышлению и совсем другое - проходить интервью.
В идеале, чтобы из первого следовало второе. Но бывает, что цель - пройти секцию по системному дизайну, тогда натаскивание через мок-собеседования, конечно, поможет преуспеть, но уверенный навык не выработает. Про подготовку к собеседованиям сказано очень много, поэтому мы в эту тему не идем.
Потребность в навыках system design на разных этапах:
Представим ситуацию, что человек имеет небольшой опыт (до 2-х лет) и занимает позицию junior/middle- разработчик. В таком случае (на мой взгляд) углубляться в проектирование может оказаться даже вредным, так как легко закопаться в обилии материала, потерять мотивацию и основной рабочий фокус.
Если же вы пришли из другой области в веб (как я когда-то), то будет полезным на верхнем уровне изучить как это все устроено, чтобы сложить общую картину. Лучше этой книжки, насколько я знаю, пока не придумали.
Итак, вы в разработке уверенных 2-3 года, четко обозначили себе цель (продвижение к синьорскому грейду) и хотите к ней как можно быстрее прийти. При этом вам важно выработать уверенный навык проектирования, а не просто пройти очередное интервью.
Так как первые пункты по своей сути тривиальны, то стоит внимательнее рассмотреть №3, о чем дальше и пойдет речь.
Избранные ресурсы
У меня в закладках давно живут:
И еще немало крутого материала, который стараюсь время от времени почитывать.
Если у вас отличная дисциплина и есть четкое понимание как выстроить учебный план, то самостоятельное обучение по материалам может сработать.
Но этим летом я решил подойти к вопросу комплексно, так как увидел потребность и немного устал лавировать по бесконечным материалам.
В моем фокусе оказалось 2 проекта:
- курс по анализу систем (АС)
- курс по объектно-ориентированному анализу и проектированию (ООАП)
Второй курс более прикладной и объектно-ориентированный, в ходе которого написал консольную игру. Его стоит рассматривать как пет-проект, так как обратной связи он не предполагал.
Первый же был ориентирован на работу с требованиями, анализа бизнеса, выбора подходящей архитектуры. В самом начале курса крупным открытием для меня было узнать про воркшоп Event Storming. Поставил себе цель - провести его в своей команде. Это действительно захватывающий подход к проектированию, и я про него расскажу отдельно.
Так как же все-таки научиться проектировать системы, если решили, что хотите в этом разобраться?
Самый очевидный ответ - через практику. Хорошо, если есть возможность методом проб и ошибок делать это на работе, но такая роскошь не всегда доступна, а иногда и опасна, так как бизнес будет терять деньги, пока вы набиваете шишки.
Поэтому практика должна быть под чутким руководством более опытных коллег/менторов/преподавателей - они помогут не заплутать. Помните: во время обучения обратная связь - это все, без нее очень легко забуксовать. Хорошим вариантом может стать разбор архитектурных кат с наставником.
Начните проектировать. Собирайте обратную связь по своему дизайну. Снова проектируйте, улучшая первоначальное решение.
В конечном итоге, вы сделаете ощутимый скачок в своем развитии.
Читайте оригинальный пост и присоединяйтесь к обсуждению в Телеграм: @time2code