Начинающие программисты тратят много времени, набирая знания, необходимые для прохождения интервью. Они решают задачи и улучшают свои резюме. Но самое интересное начинается после того, как программист получает вожделенную должность — в каком-нибудь стартапе, в Google, в Amazon или где-нибудь ещё. Нередко оказывается так, что те знания и навыки, которые помогли человеку найти работу, не соответствуют тому, что надо знать и уметь для выполнения его повседневных задач.
Автор статьи, перевод которой мы сегодня публикуем, говорит, что команда, в которой он трудится, воодушевилась рассказом TechLead’a о 7 привычках высокоэффективных программистов. Члены команды решили высказать собственные мысли по этому вопросу. Здесь, в форме советов, приведён разбор 7 навыков эффективных программистов.
1. Учитесь читать чужой код
Все кроме вас пишут ужасный код. Именно поэтому способность программиста работать с чужим кодом — это ценный навык. Этот навык даёт тому, кто им обладает, много хорошего.
Программисту необходимо уметь разбираться в чужом коде. В конце концов, это — его работа. При этом неважно то, насколько запутанным выглядит подобный код, или то, как плохо он написан. «Чужим кодом», кстати, может быть то, что было написано самим программистом, скажем, год назад.
Этот навык положительно влияет на программиста двумя способами. Во-первых, способность к чтению чужого кода даёт возможность понять то, как устроен некачественный код. Просматривая чужие работы, можно узнать о том, какие приёмы являются рабочими, а какие — нет. Во-вторых, что более важно, это помогает выявить особенности восприятия чужого кода другими людьми, выяснить, какой код воспринимается легко, а какой — тяжело.
Если вы читаете чужой код и встречаете в нём что-то такое, что вам не нравится, постарайтесь не молчать об этом. Это поднимет ваш авторитет в глазах сослуживцев.
Обращайте внимание тех, с кем вы работаете, на то, как важно писать код, который легко поддерживать, на то, как важны хорошие комментарии. Это ещё сильнее упрочит ваш статус в команде.
Ваш собственный код должен быть спроектирован настолько качественно, чтобы он был бы понятным и без документации. На самом деле, у хороших программистов не возникает нужды в документировании кода. Это — пустая трата времени, того времени, которое лучше было бы потратить на программирование и на проведение совещаний.
Способность понимать некачественный код, кроме прочего, помогает во внесении изменений в подобный код. Иногда это означает редактирование кода, в котором некто разбирается не очень хорошо. Например, однажды нам попался скрипт, в ходе работы которого были задействованы такие технологии, как PowerShell, Python и Perl. В Perl мы разбирались не очень хорошо. Однако нам удалось достаточно глубоко разобраться в проекте, удалось понять сущность происходящего и внести в код необходимые изменения. Это стало возможным благодаря тому, что мы поняли тот код, который нам нужно было изменить, включая и код Perl-скриптов.
Умение разбираться в чужом коде повышает ценность программиста из-за того, что он может понимать то, как устроены даже переусложнённые системы, такие, при взгляде на которые у кого-нибудь другого попросту опускаются руки.
2. Развивайте в себе чутьё на неудачные проекты
Существует множество навыков, на овладение которыми нужно время. Один из них, который, мы уверены, стоит освоить, заключается в том, чтобы развить в себе понимание того, какими проектами заниматься не стоит, и того, какие проекты с высокой долей вероятности могут вылиться в «гонку на выживание».
В больших компаниях всегда имеется множество проектов, над которыми трудятся программисты. Но далеко не все эти проекты будут завершены. Далеко не все из них принесут пользу. Среди них могут быть и такие, которые не имеют коммерческого смысла (по крайней мере — для программиста). Некоторые проекты, в целом — перспективные, могут страдать от недостатков управленческого характера. Это не значит, что вы должны отказываться от неких идей сразу же после того, как поняли, что вы не согласны с теми, кто их предлагает. Однако если автор идеи не может внятно объяснить то, какую пользу компании может принести проект после его завершения, тогда, возможно, такой проект не стоит и начинать.
Кроме того, некоторые проекты могут быть чрезмерно ориентированы на технологии, а не на решение некоей проблемы. Это иногда, ещё в самом начале работы, позволяет понять, что завершение подобного проекта не принесёт особенной пользы.
Для того чтобы научиться с первого взгляда распознавать бесперспективные проекты, нужно принять участие во множестве подобных проектов. Поэтому, если вы находитесь на начальном этапе карьеры программиста — не тратьте слишком много времени на попытки оценки перспективы всех достающихся вам проектов. Со временем у вас выработается внутреннее чутьё, руководствуясь которым вы сможете быстро распознавать проекты, обречённые на неудачу.
3. Избегайте совещаний
Кем бы вы ни работали, без совещаний вам не обойтись. Это касается абсолютно всех. Дело в том, что вам нужно находить общий язык с менеджерами проектов, пользователями, клиентами. Однако у совещаний есть одна неприятная особенность: иногда они внезапно занимают едва ли не весь рабочий день. Именно поэтому очень важно научиться избегать ненужных совещаний. Пожалуй, лучше будет не «избегать совещаний», а стремиться к тому, чтобы «контролировать время, которое уходит на совещания». Цель этого заключается в том, чтобы тратить время только на те совещания, которые действительно необходимы, на такие, которые способствуют развитию проектов.
Самый распространённый метод управления временем, которое уходит на совещания, заключается в том, что ежедневно выделяется двухчасовой блок, который превращается в непрерывное совещание. Многие назначают повторяющиеся совещания на время, которое они считают наиболее подходящим. Эти совещания используются для обсуждения рабочих вопросов.
Ещё один способ управления временем — приходить на работу раньше других для того, чтобы успеть справиться со своими делами. Мы, например, предпочитаем поступать именно так. И, кстати, если в офис прийти пораньше — работать там будет гораздо спокойнее чем обычно. Большинство людей, приходящих пораньше, похожи друг на друга. Они это делают для того, чтобы успеть справиться со своей работой. Поэтому они не мешают работать другим.
В нашем случае это важно для отдельных членов команды. Дело в том, что наша работа требует времени на то, чтобы полностью сосредоточиться на некоей задаче. В это время мы ни с кем не общаемся. Конечно, бывают ситуации, когда для решения задачи нужно с кем-то её обсудить, поработать совместно. Но после того как все вопросы разрешены, разработчику нужно лишь писать код. В общем-то, речь идёт о попадании в некую зону комфорта, в которой программист может постоянно держать в голове всё то, что связано с решаемой им задачей. Если его постоянно прерывают, у него могут возникнуть сложности с быстрым возвратом к тому, на чём его отвлекли.
4. Освойте GitHub
Когда смотришь на некоторых высококлассных программистов, то возникает ощущение, что они начали пользоваться GitHub в первый же день своей жизни. Они понимают смысл каждой команды и параметра, они без труда справляются со своими делами.
А вот другие впервые сталкиваются с GitHub на первой работе. Для них GitHub — это настоящий ад, построенный из непонятных команд и таинственных процессов. Они никогда не уверены полностью в правильности того, что делают. Именно поэтому весьма популярны всяческие «шпаргалки» по GitHub.
Вышесказанное справедливо для любой системы контроля версий. Если ей пользоваться правильно — она оказывает весьма полезной. Если пользоваться ей неправильно — она страшно мешает работать. Простой PR или коммит легко может превратиться в кошмар, который отнимет у программиста несколько часов. Это время уйдёт на распутывание хитросплетений веток и форков. Кроме того, если регулярно забывать о загрузке на свою машину самой свежей версии репозитория, можно постоянно заниматься решением конфликтов слияния. Ничего хорошего в этом нет.
Если вам нужна «шпаргалка» по GitHub — сделайте её.
Научитесь продуктивно работать с GitHub. При этом неважно то, как именно вы этого добьётесь.
5. Пишите простой код, который легко поддерживать
Некоторые начинающие программисты имеют следующую черту: они пытаются, в одном проекте, реализовать всё, что знают. Дело тут в том, что они стремятся использовать в каждом фрагменте создаваемого ими кода свои знания об объектно-ориентированном программировании, о структурах данных, о паттернах проектирования и о новых технологиях. Это неоправданно усложняет код из-за того, что при таком подходе на решаемую программистом задачу легко могут повлиять, например, те паттерны проектирования, которые он уже реализовывал на практике.
Существует баланс между слишком сложными структурами проектов и простым кодом. Паттерны проектирования и объектно-ориентированное программирование нацелены на то, чтобы упрощать код в крупномасштабных проектах. Однако чем больше мы прибегаем к абстрагированию и инкапсуляции, чем больше в наших решениях «чёрных ящиков» — тем сложнее отлаживать код таких решений.
6. Научитесь говорить «нет» и расставлять приоритеты
Эту рекомендацию, на самом деле, можно дать кому угодно — хоть финансовому аналитику, хоть программисту. Но можно отметить, что возникает такое ощущение, что все хотят чего-то особенного именно от технических специалистов. Например, если вы — инженер по анализу данных, то вам, возможно, предлагают задачи, которые оказываются гораздо шире того, чем, как предполагается, вы должны заниматься. Одним командам нужны какие-то выборки из данных, другим нужны сводные данные, третьим — новые конвейеры.
Надо отметить, что способность расставлять приоритеты и умение говорить «нет», на самом деле, может представлять собой два отдельных навыка. Однако эти навыки очень близко друг с другом связаны. Там, где возникает необходимость в одном из них, обычно нужен и второй. Расстановка приоритетов — это когда время тратят только на то, что оказывает серьёзное влияние на компанию. А умение говорить «нет» — это отказ от выполнения работы, которую должен выполнять кто-то другой.
Научиться тому, о чём мы говорим, может быть непросто, так как люди часто стремятся к тому, чтобы решить каждую задачу, которую перед ними ставят. Особенно это характерно для тех, кто только что отучился и получил свою первую работу. Раньше, на учёбе, им давали задания, с которыми они вполне справлялись. Теперь же, на работе, они ожидают того же и стремятся к тому, чтобы никого не разочаровать.
Тут надо понимать, что в больших компаниях существует бесконечное количество задач. Самое важное — это браться только за те задачи, которые можно решить.
Существует множество навыков, на владение которыми не тестируют на собеседовании. Их редко можно получить на учёбе. Часто такая ситуация складывается лишь из-за особенностей учебной среды, а не из-за того, что кто-то не хочет показывать учащимся настоящие задачи, с которыми они могут столкнуться в реальности.
7. Научитесь думать о том, как именно будет использоваться ваша разработка
Есть один навык, на владение которым сложно организовать проверку в ходе собеседования. Ситуации, в которых он нужен, тяжело воспроизвести во время учёбы. Речь идёт об умении видеть ошибки, которые может совершить конечный пользователь программной системы. Мы обычно называем это «продумыванием сценариев использования программы».
На самом деле, это «продумывание сценариев» — лишь достаточно мягкое название того, что называется «защитой от дурака».
Например, так как большая часть работы программиста заключается в поддержке кода, ему часто приходится менять код, который тесно связан с чем-то другим. Даже простое изменение чего-либо требует поиска всех тех мест, где это используется. Например, меняться может объект, метод, API некоей системы. Если внести в систему непродуманное изменение — это может «поломать» работу совершенно неожиданных частей программы. Причём, речь идёт об изменениях любого масштаба — даже о чём-то вроде смены типа в базе данных.
Этот навык также включает в себя умение находить и анализировать пограничные ситуации, которые могут возникнуть при работе с системой. Сюда же идёт и способность осмысления высокоуровневой схемы решения на этапе проектирования.
Это относится и к разработке более крупных частей систем, таких, как модули или микросервисы. Приступая к решению подобных задач нужно подумать о том, как именно будут использоваться сущности, которые планируется создать. Нужно поразмыслить о сценариях их неправильного использования, о различных вариантах их использования, и о том, что тем, что вы создаёте, возможно, будут пользоваться совершенно неочевидными на первый взгляд способами.
Сам процесс написания кода — это лишь часть работы по решению некоей задачи. Нетрудно создать программу, которая хорошо работает на вашем компьютере. Но код, с которым работает кто-то другой, легко может вести себя совсем не так, как изначально ожидалось. Как код, который вы пишете, будет использоваться в продакшне? С какими системами ему придётся взаимодействовать? Частью каких процессов он может стать? Не покажется ли он слишком примитивным и ограниченным программисту, которому придётся поддерживать его через несколько лет? Это — очень непростые вопросы.
Итоги
В этом материале мы представили вашему вниманию обзор 7 навыков, которые характерны для высокоэффективных программистов. Надеемся, вы нашли среди них те, которые вам захочется развить и у себя.
Уважаемые читатели! Что вы посоветовали бы освоить тому, кто стремится к профессионализму в программировании?
Автор: ru_vds
