{"id":14292,"url":"\/distributions\/14292\/click?bit=1&hash=23aed192f809013ec1c0769a11eb00fbed4dd7038bbe5f8e3db447db2e792dcd","title":"\u0421 \u043d\u0430\u0447\u0430\u043b\u0430 \u0433\u043e\u0434\u0430 \u043a\u0430\u0440\u0442\u043e\u0439 \u00ab\u0425\u0430\u043b\u0432\u0430\u00bb \u043e\u043f\u043b\u0430\u0442\u0438\u043b\u0438 40 \u043c\u043b\u043d \u043f\u043e\u043a\u0443\u043f\u043e\u043a","buttonText":"","imageUuid":""}

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

Отрывок из книги «От джуна до сеньора: как стать востребованным разработчиком» Владимира Швеца, выпущенной издательством «Альпина Паблишер».

Код ради кода

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

Если вы с энтузиазмом познаете новое, с удовольствием разбираетесь в подходах к разработке или обожаете писать свои pet projects, будьте осторожны: так можно перепутать работу и игру. Нет ничего лучше, чем любовь к своей работе, и ваша тяга к новым знаниям — это прекрасно (я бы вас даже обнял, но руки заняты набором этого текста).

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

Вам может захотеться встроить в проект Lua-интерпретатор или написать микросервис на Scala, но до конца ли вы уверены, что это решение — результат анализа потребностей проекта? Может, вам просто хочется испробовать новый язык или технологию?

Действительно ли эта новая библиотека, которую так хочется использовать, нужна проекту, или вам просто любопытно, как она работает?

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

Ваша работа — не супермаркет игрушек, поэтому вы должны ответственно подходить к тому, что и как использовать. Никто не станет сдвигать рассчитанные ETA, чтобы вы могли узнать, а так ли продуктивен Go в действительности. Никто не будет мириться со штрафами от клиентов, пока вы проверяете, подходит ли Rust в качестве альтернативы языку программирования проекта (разве что вам поставили такую задачу, если это так — я очень за вас рад).

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

Задание

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

История из жизни

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

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

Кадр из фильма «Франкенштейн» Джеймса Уэйла, 1931 год

Оптимизация

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

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

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

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

В вопросах оптимизации необходимо идти от обратного: не от отсутствия кода к его появлению, а от существующего кода к его упрощению и ускорению.

Второе правило оптимизации: убедитесь в том, что вы оптимизируете нужный код. Прежде чем приступать к любой оптимизации, следует как минимум сделать профилирование кода. Необходимо знать все медленные места проекта, все бутылочные горлышки (bottlenecks, да, ознакомьтесь с этим). Чем больше вы получите информации о проекте, тем лучше сможете проанализировать и спланировать дальнейшую оптимизацию.

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

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

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

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

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

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

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

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

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

Задание

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

История из жизни

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

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

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

Удалить несколько строк кода и получить немедленный прирост скорости — не об этом ли мечтает каждый разработчик?

Кадр из сериала «Остановись и гори», 2014-2017 

Десять раз спроси, один — напиши

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

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

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

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

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

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

Задание

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

История из жизни

Один раз я взял небольшой (и потенциально быстрый) заказ на разработку сайта с астрологическими прогнозами. Сказать, что я задолбал заказчика вопросами о том, как устроены гороскопы и от чего будет зависеть выдача пользователям, значит не сказать ничего.

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

Кадр из сериала «Офис», 2005-2013

Винтик в механизме

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

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

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

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

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

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

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

Вы занимаетесь веб-разработкой? Научитесь писать на ассемблере. Создаете мобильные приложения? Попробуйте написать свою мини-игру под Linux.

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

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

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

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

Задание

Попробуйте честно ответить себе на вопрос: вы чувствуете, что на текущем месте работы получаете новые знания и опыт? Не ощущаете ли вы себя в западне рутинной, повторяющейся работы? Если понимаете, что начали буксовать в профессиональном развитии, попробуйте изучить что-то новое: язык программирования, подход к разработке — что угодно, что вызывает у вас интерес.

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

История из жизни

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

Когда мне начинало казаться, что я просто занимаю определенное место в скучном, большом механизме, я начинал писать для себя, по вечерам, после работы, ночью. И это всегда помогало. Я старался никогда не позволять себе быть узником собственных мыслей.

Кадр из сериала «Кремниевая долина», 2014-2019
0
26 комментариев
Написать комментарий...
Агент К

В целом все вроде ок написано, но вот от этого стало и смешно и тошно одновременно:

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

Не надо только вот этой лабуды. Люди разные и нет никаких "настоящих" и "ненастоящих" разработчиков.

Да, есть (во всех областях) люди, которым в целом наплевать на "мотивацию", потому что эта мотивация у них в голове в таком количестве, что хлебом не корми. Но это буквально единицы и не каждый человек, зная таких людей, будет им особо завидывать.

Но в большистве случаев на работу приходят обычные люди, для которых материальные блага такая же необходимость как и для всех остальных. Более того - разработчики, спасибо зарплатам, еще и из тех кто может себя побаловать и желание это никуда не девается со временем как минимум. Пойдите найдите мне сеньора, который будет не за 300к рублей (условно), а за 50к работать, но за охуенную идею - вы не найдете, либо это будет те самые 1-2 человека, которые готовы жизнь на эту идею положить.

Открою и я секрет: тоже самое и в любой другой профессии. От хирурга до столяра (говорю как сеньор разработчик и столяр жалкого 3го разряда)

Ответить
Развернуть ветку
Ivan Ganev

Вы видимо никогда не слышали про опенсорс.

Ответить
Развернуть ветку
Дмитрий Перепёлкин

В opensource есть две категории людей.
Те кто состоялся в ИТ, достаточно зарабатывает и имеет время делать серьёзные коммиты или ревью в большие проекты. Вторая категория — те кто пытается там развиться, чтобы наработать резюме. Иначе говоря, в первом случае материальный вопрос решён, во втором он решается в перспективе.

Есть ещё третья очень малочисленная группа, которые получают инвестиции и донаты под проекты с открытым кодом, чем обеспечивают себе основное место работы. Различные гранты от Mozilla и т.д.

Ответить
Развернуть ветку
Ivan Ganev

Просто автор комментария выше:

а за 50к работать, но за охуенную идею - вы не найдете, либо это будет те самые 1-2 человека, которые готовы жизнь на эту идею положить.

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

Ответить
Развернуть ветку
Дмитрий Перепёлкин
считает что это что-то невероятно исключительное что бы за какие-то там 50к сениор работал

Да вполне адекватная история, если напрягают несколько раз в неделю по серьёзным вопросам и таких проектов несколько. Причём работодатель прекрасно знает, что на него работа эксклюзивно не ведётся. А то в ковид были случаи, где на испытательный человек устраивался на 20 работ, хапал миллион и балдел )
Либо же тоже адекватная ситуация, когда свежий проект, инвестиций нет, ангелы закидывают, чтобы хоть что-то было, но есть перспективы, тоже 50к как манна небесная.

Но ситуация при которой разработчики пишут код за так это не что-то исключительное, это вполне обычное явление.

Да, конечно! Совершенно не исключено. Есть и те, кто пишут код просто как развлечение и хобби, а когда начинают монетизировать, сильно разочаровываются в том что делают ))) Кодить для себя вполне нормальная идея.

Ответить
Развернуть ветку
Апрель Обормотов

А что вы имеете ввиду под "за так"?

Ответить
Развернуть ветку
Ivan Ganev

бесплатно

Ответить
Развернуть ветку
Агент К

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

Ответить
Развернуть ветку
Nan Nan

Времена Торвальдсов и Страуструпов прошли, практически весь опенсорс имеет некую финансовую подоплёку

Ответить
Развернуть ветку
Ivan Ganev

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

Ответить
Развернуть ветку
Nan Nan

Для разработчика это неплохая строчка в резюме - "сделал мерж реквест в сам %project_name%!".

Ну и человек выше в общем то верно написал - зарплаты в ИТ пока ещё остаются высокими, поэтому человек может позволить себе в свободное время пописать для опенсорса: "Вообще-то я тимлид в faang, а опенсорс - для души!"

Ответить
Развернуть ветку
Дмитрий Перепёлкин

В faang уже вряд ли, конечно. Там многих сократили, а на оставшихся свалилось много работы )
Но, да. На определённый набор навыков зарплаты ещё не скоро упадут. Можно в том же банке сидеть и практически ничего не делать на высокой позиции, т.к. всё уже отлажено, а цифровых трансформаторов в коллективе не завелось. Платят по сути за знания, и не важно, что применяются они не часто. Чтобы чем-то себя занять можно коммитить в opensource, ответы на SO писать и т.д., при этом получать зарплату и изредка что-то серьёзное решать.

Ответить
Развернуть ветку
Ivan Ganev

Это одна из мотиваций, но не единственная.

Ответить
Развернуть ветку
Ilya Shalyapin

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

Ответить
Развернуть ветку
Nan Nan

Ну мы же говорим про серьёзные проекты, а не про "как я написал hello world на 42х языках программирования".

Ответить
Развернуть ветку
Ilya Shalyapin

Мне знакомы проекты с более 10к звезд на гитхабе которые держались на энтузиазме много лет, но в итоге не продержались. Например gorilla и sqlx. На них работает куча больших коммерческих сервисов. Есть множество других подобных проектов, которые сейчас держатся на энтузиазме.

Ответить
Развернуть ветку
Konstantin Safonov

Большая часть серьёзного опенсорса пишется людьми на зарплате в рабочее время. Тот же Linux пишут в Red Hat, IBM(технически, они и red hat владеют, но коммитили в ядро ещё до покупки), Intel и даже Microsoft.

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

Ответить
Развернуть ветку
Агент К

Да куда уж мне.

Ответить
Развернуть ветку
Andrey Barkov

в общем и целом...

Ответить
Развернуть ветку
Ilya Shalyapin

А где тогда играть с кодом если не на работе? Поработаешь так 10 лет в одном месте, а потом кажется что Delphi уже умер. После работы, не всегда есть время и силы, есть другие интересы, плюс какой-то небольшой пет проект не прокатит как коммерческий опыт от года, который везде требуется.

Ответить
Развернуть ветку
Nan Nan

Приходил домой после работы (на которой писал код), садился за компьютер (за которым сидел 8 часов на работе) и начинал писать код вечером и ночью.

Ага, а потом расскажите мне, что "в ит не бывает выгораний"

Ответить
Развернуть ветку
ochepurnaja

и долго в таком режиме работы нон-стоп реально продержаться нормальному человеку?

Ответить
Развернуть ветку
Robastik: веб-парсер Excel
нормальному человеку

Зачем нормальному такой режим?

Ответить
Развернуть ветку
Вадим Д.

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

Ответить
Развернуть ветку
Леонид Калмыков

это справедливо, но не по отношению ко всем отраслям

Ответить
Развернуть ветку
SL Potapenko

все это верно в пределах нескольких (десятков, сотен) итераций, пока развивается текущая версия мажорного релиза, и в рамках какого-то одного субъективного компонента программного комплекса.
Если смотреть шире, то сложное ПО редко имеет гомогенную структуру - обычно это крутой замес технологий у компонентов, например, после нескольких генераций команды разработки, а во времени сильно меняющийся АPI или даже архитектуру взаимодействия между компонентами.
Есть такое понятие, как "технический долг". Его только профилированием и последующей оптимизацией не вернуть. Почти всегда требуются более радикальные изменения. Соответственно, прототипирование (или "игра в код") для этих новых изменений неизбежно.

Ответить
Развернуть ветку
23 комментария
Раскрывать всегда