«Программисты, которые умеют писать алгоритмы, — нишевая профессия»
«Программисты, которые умеют писать алгоритмы, — нишевая профессия»

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

После этой ста­тьи у нас про­шёл раз­го­вор с чело­ве­ком, кото­рый про­фес­си­о­наль­но зани­ма­ет­ся раз­ра­бот­кой и нани­ма­ет людей — Колей Мити­ным из ком­па­нии «Кор­текс». И у него есть мне­ние, кото­рым мы хотим поде­лить­ся с вами.

👉 Будет полез­но всем, кто гото­вит­ся стать про­дук­то­вым раз­ра­бот­чи­ком и про­фес­си­о­наль­но созда­вать софт. 

Вот мысль: 

«Есть фило­соф­ская тема, про­сто подискутировать.

Я наконец-то нала­дил рабо­ту в «Кор­тек­се» и нани­маю раз­ра­бов. Вот у меня такие шту­ки в теку­щей раз­ра­бот­ке вызы­ва­ют сомне­ния. Пото­му что сей­час уме­ние писать код ста­но­вит­ся всё менее востребованным.

То есть, поста­вив зада­чу перед раз­ра­бот­чи­ком, я бы ожи­дал, что чело­век ско­рее при­не­сёт мне код:

pip install highlight-text

highlight_text(text, ['словоформы', 'для', 'подсветки'])

(То есть нашёл бы гото­вое реше­ние сре­ди суще­ству­ю­щих биб­лио­тек и при­ме­нил бы его в про­ек­те за пять минут, а не горо­дил бы целый алго­ритм с нуля. — Прим. ред.)

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

Смысл в том, что когда ты в про­ек­те напи­сал свой код, его надо обслу­жи­вать и тести­ро­вать. А если ты взял нор­маль­ную биб­лио­те­ку, то её обслу­жи­ва­ет сообщество. 

В ито­ге писать свой код ста­но­вит­ся очень дорого.»

Раз­вер­нём эту мысль по моти­вам даль­ней­шей бесе­ды с Колей.

Что не так с «олимпиадным программированием»

Есть такой взгляд на про­грам­ми­ро­ва­ние, что для реше­ния зада­чи нуж­но создать новый файл и с нуля при­ду­мать реше­ние (как это сде­ла­ли мы в сво­ём про­ек­те). Что­бы это реше­ние рабо­та­ло, нуж­но при­ду­мать какие-то алго­рит­мы: цик­лы, логи­ку, про­вер­ки и т. д. Обыч­но такие зада­чи дают на олим­пи­а­дах по про­грам­ми­ро­ва­нию, отсю­да и название. 

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

Но есть и проблемы: 

❌ Алго­ритм — это ещё не про­дукт. Что­бы от алго­рит­ма перей­ти к про­дук­ту, нуж­но напи­сать интер­фейс, под­го­то­вить сер­вер­ную инфра­струк­ту­ру, под­го­то­вить все вспо­мо­га­тель­ные моду­ли. Пред­ставь­те, сколь­ко все­го долж­но рабо­тать в интернет-магазине: авто­ри­за­ция, вос­ста­нов­ле­ние паро­ля, добав­ле­ние това­ра в базу, воз­врат това­ра, реко­мен­да­ции това­ров и т. д. Если вы напи­са­ли пусть даже гени­аль­ный алго­ритм реко­мен­да­ций това­ра, это толь­ко 5% раз­ра­бот­ки ваше­го интернет-магазина. 

❌ Раз­ра­бо­тать мало. Нуж­но под­дер­жи­вать. Про­дукт, кото­рый мы напи­шем сего­дня, нуж­но будет под­дер­жи­вать несколь­ко лет. За это вре­мя могут сме­нить­ся раз­ра­бот­чи­ки и тех­но­ло­гии. В какой-то момент наш опти­ми­зи­ро­ван­ный автор­ский алго­ритм может ока­зать­ся несов­ме­сти­мым с новы­ми технологиями. 

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

Коля Митин:

«Иметь свой код сей­час очень дорого.

Поэто­му мы даже свой код пишем «по учеб­ни­ку». То есть берём извест­ный фрейм­ворк и всё по бест-практисес. 

У нас вооб­ще в про­ек­тах ника­ких тай­ных зна­ний, всё либо в кон­фи­гах Докер­фай­лов или Анзи­б­лов или напи­са­но по хенд­бу­ку фреймворка.

Даже если нуж­но про­сто пере­ка­тать дан­ные из одной базы в дру­гую, то мы дела­ем моде­ли, допи­сы­ва­ем сер­ви­сы и всё вот это вот. Пото­му что это не так дол­го и страш­но, если уме­ешь, а про­чи­тать и понять код смо­жет любой, кто зна­ком с несу­щим фреймворком.»

А как тогда делать?

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

Что это даёт: 

✅ Боль­шие про­дук­ты созда­ют­ся быст­ро. Теперь раз­ра­бот­ка сво­дит­ся не к тому, что­бы сочи­нить алго­ритм. Вме­сто это­го ты нахо­дишь нуж­ные биб­лио­те­ки, скле­и­ва­ешь их и тести­ру­ешь. Это гораз­до быстрее. 

✅ Доку­мен­та­ция на всё. Пуб­лич­но доступ­ные фрейм­вор­ки и биб­лио­те­ки тща­тель­но задо­ку­мен­ти­ро­ва­ны, к ним есть учеб­ни­ки, спра­воч­ни­ки, пра­ви­ла и best practices. Если у вас ушёл один раз­ра­бот­чик и при­шёл дру­гой, кото­рый не раз­би­ра­ет­ся в вашей тех­но­ло­гии, — он лег­ко обу­чит­ся по обще­до­ступ­ным справочникам. 

✅ Под­держ­ка — у сооб­ще­ства. У откры­тых биб­лио­тек и фрейм­вор­ков есть люди, кото­рые их под­дер­жи­ва­ют. Дру­гие люди пред­ла­га­ют улуч­ше­ния и исправ­ля­ют баги. Тре­тьи иссле­ду­ют без­опас­ность этих реше­ний. Если на биб­лио­те­ку кри­ти­че­ски посмот­ре­ло сто раз­ра­бот­чи­ков, это явно более надёж­ная биб­лио­те­ка, чем если её напи­сал один про­грам­мист в вашем офисе. 

А что делать с тем, что каждый квартал появляется новый фреймворк?

Коля Митин, Кор­текс:

Это такой про­грам­мер­ский миф. В целом у под­дер­жи­ва­е­мой тех­но­ло­гии жиз­нен­ный цикл око­ло 10 лет. За это вре­мя обыч­но про­ект бро­са­ют, кон­сер­ви­руя, или два раза пере­пи­сы­ва­ют, пото­му что кон­цеп­ция поменялась.

К тому же что­бы взять новый мод­ный фрейм­ворк в про­дакшн, его вер­сия как мини­мум долж­на начи­нать­ся с 2, а луч­ше с 3. Тогда понят­но, что он про­шёл про­вер­ку временем.

И это хоро­шо рабо­та­ет, пото­му что вер­сии 1 обыч­но исполь­зу­ют вся­кие early adopters в част­ных про­ек­тах. Там они ловят все про­бле­мы пер­вой вер­сии (и исправляют).

Алгоритмы ещё нужны, но не всем

Это не зна­чит, что писать алго­рит­мы с нуля боль­ше не нуж­но. Про­сто теперь это не всё про­грам­ми­ро­ва­ние, а лишь его часть, при­чём не самая большая. 

Вот при­ме­ры, где алго­рит­мы всё ещё нуж­ны и полезны:

  • Внут­ри слож­ных про­дук­тов или в боль­ших ком­па­ни­ях типа Google и Facebook. 
  • В раз­ра­бот­ке, где кри­ти­че­ски важ­на опти­ми­за­ция — напри­мер, в высо­ко­на­гру­жен­ных систе­мах, в созда­нии драй­ве­ров, про­грам­ми­ро­ва­нии микроконтроллеров.
  • Для созда­ния соб­ствен­ных биб­лио­тек, фрейм­вор­ков и язы­ков программирования. 
  • В обу­че­нии осно­вам информатики. 

Что нужно, чтобы быть востребованным продуктовым разработчиком

Про­ци­ти­ру­ем пост Коли из его кана­ла «Коля Митин гово­рит»:

Оче­вид­но, что раз­ра­бот­чи­ки сей­час пишут кучу оди­на­ко­во­го кода каж­дую секун­ду по все­му миру.

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

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

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

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

Вы работодатель? Вам слово

Если вы нани­ма­е­те раз­ра­бот­чи­ков, мене­дже­ров или ана­ли­ти­ков в ИТ-командах и у вас есть взгляд на состо­я­ние рын­ка — вел­ком: maxim.ilyahov@yandex.ru

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