Профессионализм

Предисловие

Явление деления разработчиков на уровни очень распространено. Даже в вакансиях чаще всего пишут не просто "Frontend-разработчик", а более развернуто - "Junior/Middle/Senior/${место для вашей должности} Frontend-разработчик". Для чего? С помощью такого деления легче делегировать задачи в команде. У каждого разработчика своя особая матрица компетенций, свои навыки, которые он оттачивал месяцами, а то и годами. С помощью такого деления процесс разработки ускоряется в разы.
Вообще на рынке (я смотрю на рынок стран СНГ) по состоянию на начало 2021 года среди Frontend-разработчиков имеют место быть такие должности (от низшего уровня, к наивысшему и без привязки к инструментам/библиотекам)

• Intern Frontend-developer - другими словами - стажер

• Junior Frontend-developer - уровень выше начального, уже более менее самостоятельная единица

• Middle Frontend-developer - самостоятельная единица, командный игрок, много умеет, но чаще всего в одной сфере / направлении. Через тернии к звездам или стремится к Senior

• Senior Frontend-developer* - старший, чаще всего в компаниях самый опытный. Человек, который попробовал многие инструменты, много может, много пробует.

• Architector Frontend-developer** - человек, который часто занимается вопросами выбора технологий, решений в вопросах архитектуры будущего приложения

• TeamLead - глава команды - распределеяет задачи, связующее звено между командой разработки и бизнесом. Хороший управленец и разработчик

* - он может быть также ведущим разработчиком, который выполняет все те же функци, что и выполнял senior, но при этом отчасти может выполнять функции архитектора. Я видел компании, где понятия "ведущий разработчик" и "Senior developer" отождествлялись.

** - Архитектор - достаточно размытое понятие. Иногда, в командах нет архитектора, но при этом есть techlead. Если загуглить, то он решает все те же задачи, что и архитектор.

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

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

Эта статья как раз о том сборнике книг для разработчиков уровня "Middle и выше".

Секреты Javascript Ниндзя. Джон Резиг, Беэр Бибо, Иосип Марас

У каждой книги есть своя цель, и у этой книги она тоже есть. Цель - напомнить вам о том, что есть в чистом js, что есть в браузере, что такое DOM и какие есть возможности у него.
Она буквально вам говорит: "Отвлекитесь от фреймворков и библиотек - посмотрите что умеет язык без этого!".
На страницах есть краткая информация для повторения основных понятий в js, некоторых стандартных приемов работы, например, с событиями. Все это приправлено от души хорошими примерами кода.
Книга хороша своим грамотным делением на главы и простым языком изложения. Тот самый случай, когда на ночь можно почитать не только с удовольствием, но и с пользой.

Рефакторинг кода на Javascript. Мартин Фаулер

Мы поняли как работают события, что такое замыкания, как использовать генераторы, как убежать от адской пирамиды вызовов и самое главное - с помощью чего. Теперь время писать код. Вот только мы не знаем самого главного в любом коде - способов его организации.
На просторах интернета и в книгах, о которых я напишу ниже вы сможете увидеть такие понятия как DRY, SOLID, KISS, YAGNI - это все общие положения, немного размытые, о построении архитектуры кода, приложения.
В Книге Фаулера идет полное описание каждого действия в момент рефакторинга кода. И да, Мартин Фаулер описал все способы - поверьте, Фаулер докопался и описал даже способ рефакторинга "Вынос в функцию". По факту - книга полноценный справочник или очень хорошая настольная энциклопедия, которая служит на благо архитектуры вашего кода.

Javascript для профессионалов. Джон Резиг.

Джон Резиг решил не вдаваться в подробности и не стал делать как многие авторы - описывать в первых главах все ключевые зарезервированные слова, встроенные методы перебора массивов и т. д.
Книга Резига имеет скорее обзорный характер, она рассказывает о языке в целом, о его перспективах, некоторых интересных и уже всеми забытых методах валидации форм, об интересных моментах в работе с событиями в браузерах и о браузерах в целом. Не скажу, что это мега-полезная книга. Книга скорее служит исторической справкой об языке. Может быть, у меня сложилось такое ощущения, потому что я первой прочел "Секреты Javascript ниндзя". В той книге информации было как-то больше, но обращу внимание на начало второго абзаца - Труд Резига имеет обзорный характер. Возможно, в этом есть свои плюсы.

Погружение в Паттерны Проектирования от RefactoringGuru

А что такое паттерны?

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

Взято с RefactoringGuru

Я уже говорил об DRY, SOLID, KISS, YAGNI. В электронной книге или на официальном сайте вы сможете ознакомиться с данными понятиями более подробно.
Авторов можно поддержать - купить электронную версию, что я советую всем сделать. Труд был проделан огромадный. Я всегда был сторонником идеи "Если можешь объяснить ребенку что-то - значит ты владеешь этим на все 100". Книга "Погружение в Паттерны Проектирования" будет понятна наверное даже ребенку, потому что все очень подробно описано как в главах об архитектуре кода, так и в главах про устройство и построение архитектуры всего приложения.

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

Чистая архитектура. Искусство разработки программного обеспечения. Роберт Мартин

Да, последние книги про архитектуру, но иначе никак - разработчик не должен писать код ради кода, он должен думать о пригодности этого кода в будущем. Даже не так - разработчик должен писать код ради бизнеса. А чтобы он был ради бизнеса, он должен быть поддерживаемым в будущем.
Роберт Мартин писал книгу не для Frontend-developer`ов, а для всех разработчиков и им сочувствующих. Мартин объяснил почему стоит уделять внимание архитектуре, как проводить архитектурный рефакторинг, с основными принципами, о которых также написано в refactoringGuru. (в refactoringGuru, как по мне, более подробно раскрыты некоторые моменты).

Вопрос архитектуры приложений всегда для нас будет стоять ребром, потому что размер приложений с каждым днем увеличивается, а следовательно увеличивается их сложность. Если мы изначально будем строить неструктурированный продукт - бизнес загнется, а вместе с ним и мы с вами.

Заключение

Лучший код там, где нас нет. Лучший код тот, который мы не писали. Любой код, который напишет один человек всегда будет заставлять другого напрягать голову и читать его.
Именно поэтому в этой части, я уделил больше внимания архитектуре приложений, а не возможностям функционального, структурного, объектно-ориентированного программирования на javascript.
Уделите время на архитектуру - она поможет другому разработчику чувствовать себя увереннее в вашем коде.

Спасибо за внимание!

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

Счастье и удволетворенность работой

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

В мире разработки ПО (software development) есть ряд препятствий, которые не позволяют воспользоваться этим путем к получению удовольствия от работы. Например, разработчик, как профессионал своего дела, может считать, что поддерживаемость системы, проработанная архитектура и правильная организация процессов делают систему более устойчивой к изменениям, тем самым позволяя быстрее разрабатывать новую функциональность и адаптироваться под меняющийся рынок прямая польза для бизнеса. Но представители бизнеса могут считать это ненужной тратой ресурса времени разработчиков.

В чем проблема?

Проблема в том, что бизнес не всегда знает, что для него лучше. Представители бизнеса менеджеры, специалисты по продукту, аналитики и многие другие профессионалы намного лучше разработчика умеют отвечать на вопрос что делать? (произведение Н. Чернышевского не имеет к этому никакого отношения). Но никто не обладает большей экспертизой в разработке ПО чем разработчики (а также архитекторы, технические менеджеры и другие специалисты обладающие знаниями и hard skills в области разработки). Их задача предоставить бизнесу свою экспертизу, валидировать его идеи и отвечать на вопрос как делать?. Идея такого взаимодействия лежит в основе методологии Agile (https://agilemanifesto.org/).

Внимательный читатель заметит, как я прибегаю к приему *argumentum ad auctoritatem (аргумент к авторитету).* Но в мире мнений и субъективных суждений, в котором мы живем это хороший прием, и я советую прибегать в том числе и к нему для донесения профессионалом своей идеи.

Мнение профессионала о том, что полезно для бизнеса субъективно. Это мнение, которое, возможно, не является истиной в последней инстанции и, как любое мнение, может быть ошибочно errare humanum est. Тем не менее, я считаю что разработчику стоит бороться за те идеи, в которые он верит как профессионал.

Что можно попробовать сделать?

Я буду приводить в пример внедрение best practices разработки, хотя это относится к любой идее, в которую профессионал верит и считает частью своей экспертизы. Привносить полезные для бизнеса идеи стоит это хорошо. Проблема в том, что привнесение профессионалом своих идей может встречать сопротивление со стороны коллег других разработчиков, менеджера, высшего начальства и других людей. Возникает вопрос готов ли разработчик бороться за них, какие ставки в этой борьбе и каков ее возможный исход.

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

Конечно, результат попытки донести свою идею до бизнеса совсем не бинарный. Он просто таким не может быть, так как иначе разработчик окажется без таких важнейших инструментов переговоров, как компромисс. Тем не менее я разделю исходы на возможный успех и возможный провал. Успех когда идея разработчика принята в той мере, которая позволяет ему больше применять свой профессионализм и быть довольным той работой, которую он выполняет.

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

Кого и как убеждать?

Если с идеей разработчика согласны все, кто влияет на ее принятие, тогда она принимается и результатом становится однозначный успех. Но эта ситуация выглядит идеализированной, и, скорее всего, возникнут спорные ситуации, которые потребуют разрешения. Я считаю, что в случае разработки ПО есть две стороны, которые разработчик может убедить в правоте своих суждений. Первая горизонтальная это другие разработчики, так как невозможно внедрить практики, например TDD (разработка через тестирование) или code review, если это делает один человек в команде. Вторая вертикальная представители бизнеса, так как применение best practices, особенно когда их внедрение только начинаются, требует времени разработчиков.

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

А использование административного ресурса это как раз возможная необходимость разрешения вертикальных споров. Разработчику необходимо убедить представителей бизнеса в том, что его идея принесет пользу компании. Бизнесу нужна причина тратить ресурсы, поэтому нужно ясно объяснить, что внедрение best practices разработки это инвестиция. Здесь также инструментами убеждения являются все возможные приемы риторики, а также, возможно, работа с данными, поиск примеров и апелляция к авторитету.

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

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

Заключение

Эта статья глубоко субъективное мнение о том, как разработчику получать больше удовольствия от своей работы за счет проявления профессионализма и донесения до бизнеса субъективных идей, которые разработчик, как профессионал, считает верными. Статья во многом вдохновлена идеями Agile, книгой Clean Architecture Роберта Мартина, а также собственным опытом, переживаниями и опытом знакомых и коллег.