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

Вопрос «как достигнуть высокого уровня профессионального совершенства и что для этого нужно» мучил меня последние 20 лет. Помимо чтения-перечтения правильных книг, изучения исходников правильных программ и периодического ныряния в Computer Science — приходилось постоянно общаться с разными коллегами из разных подсфер разработки.

С «чисто» разработчиками «головного мозга» становилось довольно быстро скучно, т.к. часто оказывалось, что движение к цели (проекта, ТЗ) является каким-то побочным, а главное — это процесс и нужно, уподобляясь бюрократам, религиозным сектантам и экспертам по багам русского языка — изучать тонкости работы интерпретатора-компилятора и чем больше ты знаешь всякой мусорной хрени, рожденной хаосом, тем круче. Ощущение, что нейроны мозга проросли друг в друга, запутались и отсохли, создав пульсирующее кольцо презрения к красоте и простоте — не покидало.

С «чисто» менеджерами «головного мозга» было тоже не очень весело. Да да, конечно в данном случае основной целью было сделать проект в срок, но возникающие в момент технических и аналитических сложностей и преодоления рисков эмоции и психозы с желанием найти виноватых в багах и подсознательным шантажом, с целью взять на себя ответственность за сроки, навязываемые сверху и откровенным наплевательством на техническое совершенство — приводили к мысли, что настоящие менеджеры все таки должны быть такими же профессионально развитыми, как и разработчики, нередко решающие сложные головоломные задачи, дебажа код и ночами и выходными. Но от менеджера, конечно, требуется гораздо больше именно человеческих качеств: храбрости, ясности, уверенности и умения мотивировать.

Но, к счастью, такие «чистые» случаи довольно редки, а в условиях потока проектов и дедлайна через довольно короткое время в командах остаются настоящие бойцы — и вот именно в коммуникациях с ними и в активной проектной работе таки начали постепенно формироваться правильные ответы на поставленные в начале поста ребром вопросы.

И, как же полезно какое-то время посидеть на поддержке кода… особенно своего! Когда широко открытыми глазами видно, как горе от ума («зачем делать просто если можно сложно?») и попытки разработчика (возможно тебя) слышать только себя и самоутвердиться — рождают кровоточащие в поддержке и развитии чудовища, которые и пристрелить уже нельзя, и кормить — опасно для жизни.

Итак, вот такие ответы на вопросы у меня сформировались и я готов ими поделиться.

Вопрос: какие языки программирования изучать в первую очередь?

Вопрос устарел! :) Если у вас нет цели получать удовольствие от процесса и зарплату за строки кода и троллить реальность, запутывая окружающих в глубине собственных знаний багов компиляторов/интерпретаторов, т.е. если вы не Чудак (лишнюю букву заменить) — то языки уже не нужно прямо сидеть и изучать. Сейчас существует плеяда языков, которые учатся буквально за несколько дней и позволяют быстро решать поставленные бизнес-задачи с хорошим качеством. Для веба тут несомненный лидер — PHP, для machine learning/deep learning тут прекрасно себя показывает лаконичный Python, а для бэкэнд-сервисов можно начать с быстрого решения задачи на том же PHP/Python/Ruby/Go/Node.js, а закончить (по опыту «заканчивать» приходится в 0.1% случаев) на более громоздких и низкоуровневых языках: Java/C#/C++.

Вопрос: какие алгоритмы нужно изучать в первую очередь?

Вы не поверите, но алгоритмы из Computer Science — часто являются контринтуитивными и разрушающими сознание и сколько бы вы их не изучали и не запоминали — вы их забудете после хорошего отпуска, только если вы не гений на пути к нобелевке. Максимум, что нужно знать для начала, так это то, что кроме встроенных в язык функций сортировки, есть еще, как там ее… сортировка «пузырьком» — но про нее нужно сразу забыть, т.к. есть более эффективные методы сортировки, описанные в книгах, которые можно прочитать на пенсии (я честно прочитал не один раз Сэджвика), но гораздо полезнее — знать, как называется библиотечная функция сортировки в языке и использовать ее.


Не нужно знать принципы работы двигателя внутреннего сгорания, чтобы хорошо управлять автомобилем и получать наслаждение от жизни! Не нужно знать тонкости работы виртуальных деструкторов, чтобы эффективно использовать СУБД с HTML-мордой и быстро решать бизнес-задачи с коротким time2market.

Аналогично следует подойти и к поиску и к деревьям и к теории графов и обработке строк. Скорее всего, это все уже реализовано в языке программирования оптимальным образом. А если вы до сих пор не знаете, что регулярные выражения это вершина айсберга теории конечных автоматов — забейте и расслабьтесь и учитесь лучше хорошо пользоваться регулярками. А если ВДРУХХХ нагрузочное тестирование после 10 лет успешной эксплуатации веб-проекта выявит неэффективность алгоритма — тогда и почитаете и заодно разберетесь с основами теории вычислительной сложности.

Гораздо интереснее, если говорить по Science — это покопаться в матстатистике, тервере, линейке чтобы понимать, о чем сейчас говорят в контексте deep learning. Поверьте, это гораздо интереснее, чем бесконечное колупание внутри машины Тьюринга.

Вопрос: стоит углубляться в реляционную алгебру и СУБД?

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

Вопрос: стоит ли копаться в unix и операционной системе?

Если вы нагоФнокодите 50 строк на javascript, то Ктулху этого, скорее всего и не заметит. Но если вы перепутаете фундаментальные сетевые протоколы, как иногда путают IP с TCP — беды не миновать. Я думаю, что на изучение архитектуры операционной системы, bash, системных вызовов и сетевых протоколов и стандартов стоит потратить максимум доступного времени и вы не пожалеете. Язык «С» тоже следует прочувствовать, ну чтобы было понимание, что под капотом происходит у вас. Дело в том, что современные, особенно веб-проекты, требуют очень тесного взаимодействия и понимания тонкостей работы операционки, умения мониторить и понимать процессы, потоки, системные вызовы, знать в деталях TCP/http — это позволит вашему проекту и взлететь быстро, и работать правильно и долго.
Поэтому инвестируйте в изучение unix как можно больше времени — поверьте, это окупиться с лихвой и над вами перестанут смеяться бородатые дядьки, настраивающие nginx/apache/mysql с широко закрытыми глазами.


Не нужно быть геологом, чтобы покорять вершины! Не нужно зазубривать сортировку Шелла, чтобы сортировать данные форм :)

Вопрос: зачем писать модульные и интеграционные тесты к коду?

Вас обманули. Раньше, в эпоху популярных техник разработки на гране садомазохизма, когда языки были дырявыми и программы создавались годами — нужно было все что можно и нельзя покрывать автоматизированными тестами с примесью шизофрении. Сейчас это очень дорого, программы, а особенно веб-проекты, создаются на порядки быстрее, требования постоянно меняются — и единственная возможность чтобы проект работал правильно и долго — это «сразу писать правильно и без ошибок» (С) :-) Я не шучу. Вот как обычно это делают:

• Хорошенько думают, прежде чем писать код;
• Пишут аккуратно, ясно, модульно;
• Пишут на одном из лаконичных динамических языков со встроенными в синтаксис коллекциями и выразительными конструкциями (желательно функциональными), чтобы можно было визуально отследить поток выполнения программы на 99.99% (php, python, ruby, scala).

Но если вы таки, несмотря на предупреждения выше, полезли без особой нужды в низкоуровневые языки типа java и C# (и, упаси Бог, в С/C++) — вам придется писать модульные тесты, ибо вы начнете быстро на третий день запутываться в собственном коде, уложив монитор на пол и ползая по нему с лупой на четвереньках и падать, иногда, на окруживших героя коллег :) Низкоуровневые языки хороши для отдельных сервисов и узких задач и в условиях достаточного количества времени и людей и департамента тестирования — показывают себя с лучшей стороны.

Иногда, правда, в больших и сложных проектах, хорошо помогают функциональные тесты. В Битрикс24, автоматизированном изнутри исключительно на bash/php, у нас несколько сот таких вот тестов и они оправдывают потраченное на них время.

Вопрос: а стоит ли писать ТЗ и углубленно проектировать?

Это философский вопрос :) В веб-проектах его обычно пишут, но требования часто начинают сразу меняться, поэтому совет простой: пусть ТЗ пишут менеджеры и сами его и читают, а разработчикам следует выделить 2-3 дня на пытки с пристрастием экспертов в предметной области со стороны Заказчика. Проектирование в веб-разработке с желанием влезть в голову Клиенту и таки увидеть будущее развитие системы — это ключевой момент, влияющий на успех.

Вопрос: если языки изучать есть смысл только создателям компиляторов, то что же изучать то с пристрастием?

Изучайте стандартные библиотеки языка и возможности веб-технологий (например WebRTC). В PHP можно найти просто море коннекторов к стандартным и очень мощным оперсорсным библиотекам, в Python бонусом идут библиотеки для работы с тензорами и deep learning фреймворками, в java это библиотека коллекций и executor framework и т.п.

Также инвестируйте время в изучение фреймворков. В java есть целая библиотека этого добра — Spring/EE. В php есть ряд интересных и популярных веб-фреймворков. У python появилось несколько прекрасных фреймворков для машинного обучения и т.д.

Вопрос: так увлечение программированием это все таки добро или зло?

Конечно зло! :) Нужно научиться увлекаться эффективным и лаконичным решением задач с помощью имеющегося сейчас в избытке инструментария. Если задачку можно решить на bash — пишите на bash, если сходить в СУБД можно из PHP — берите его и используйте. Если для создания сайта с админкой есть готовые фреймворки — берите их и не страдайте садомазохизмом.

Написанный даже вами код, через 2-3 месяца, вы забудете и как бы вы не старались его хорошо запомнить, мозг будет сопротивляться и вы будете страдать. Поэтому самый простой способ получать удовольствие от разработки — использовать готовые и протестированные библиотеки и решать с их помощью задачи с МИНИМАЛЬНЫМ объемом своего, вылизанного по всем стандартам, кода.

Важно понять, что программировать научиться можно быстро, а вот выражать свои мысли ясно, лаконично и красиво в коде, следуя принципу «дурака работа любит» — очень трудно и именно этому следует учиться большую часть времени. Гораздо полезнее изучать готовые библиотеки от корки до корки и строить свои проекты на базе готовой алгоритмической алгебры, чем писать «все с нуля». А современный тренд по созданию лаконичных и немногословных языков с встроенными в синтаксис коллекциями для выражения собственных мыслей (php, python, kotlin, scala), нередко в функциональном стиле, подавляющих когнитивный шум от тяжеловесных конструкций — еще больше убеждает меня в этом!

Мир движется по пути упрощения, ясности и красоты. Компиляторы победили ассемблер. Лаконичные функциональные языки с многообразием библиотек — побеждают низкоуровневый садомазохизм по работе с памятью и «ООП головного мозга».

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