Хабрахабр

[Перевод] 7 привычек высокоэффективных программистов

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

Члены команды решили высказать собственные мысли по этому вопросу. Автор статьи, перевод которой мы сегодня публикуем, говорит, что команда, в которой он трудится, воодушевилась рассказом TechLead’a о 7 привычках высокоэффективных программистов. Здесь, в форме советов, приведён разбор 7 навыков эффективных программистов.

1. Учитесь читать чужой код

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

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

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

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

Это ещё сильнее упрочит ваш статус в команде. Обращайте внимание тех, с кем вы работаете, на то, как важно писать код, который легко поддерживать, на то, как важны хорошие комментарии.

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

Иногда это означает редактирование кода, в котором некто разбирается не очень хорошо. Способность понимать некачественный код, кроме прочего, помогает во внесении изменений в подобный код. В Perl мы разбирались не очень хорошо. Например, однажды нам попался скрипт, в ходе работы которого были задействованы такие технологии, как PowerShell, Python и Perl. Это стало возможным благодаря тому, что мы поняли тот код, который нам нужно было изменить, включая и код Perl-скриптов. Однако нам удалось достаточно глубоко разобраться в проекте, удалось понять сущность происходящего и внести в код необходимые изменения.

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

2. Развивайте в себе чутьё на неудачные проекты

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

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

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

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

3. Избегайте совещаний

Кем бы вы ни работали, без совещаний вам не обойтись. Это касается абсолютно всех. Дело в том, что вам нужно находить общий язык с менеджерами проектов, пользователями, клиентами. Однако у совещаний есть одна неприятная особенность: иногда они внезапно занимают едва ли не весь рабочий день. Именно поэтому очень важно научиться избегать ненужных совещаний. Пожалуй, лучше будет не «избегать совещаний», а стремиться к тому, чтобы «контролировать время, которое уходит на совещания». Цель этого заключается в том, чтобы тратить время только на те совещания, которые действительно необходимы, на такие, которые способствуют развитию проектов.

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

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

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

4. Освойте GitHub

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

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

Если ей пользоваться правильно — она оказывает весьма полезной. Вышесказанное справедливо для любой системы контроля версий. Простой PR или коммит легко может превратиться в кошмар, который отнимет у программиста несколько часов. Если пользоваться ей неправильно — она страшно мешает работать. Кроме того, если регулярно забывать о загрузке на свою машину самой свежей версии репозитория, можно постоянно заниматься решением конфликтов слияния. Это время уйдёт на распутывание хитросплетений веток и форков. Ничего хорошего в этом нет.

Если вам нужна «шпаргалка» по GitHub — сделайте её.

При этом неважно то, как именно вы этого добьётесь. Научитесь продуктивно работать с GitHub.

5. Пишите простой код, который легко поддерживать

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

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

6. Научитесь говорить «нет» и расставлять приоритеты

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

Однако эти навыки очень близко друг с другом связаны. Надо отметить, что способность расставлять приоритеты и умение говорить «нет», на самом деле, может представлять собой два отдельных навыка. Расстановка приоритетов — это когда время тратят только на то, что оказывает серьёзное влияние на компанию. Там, где возникает необходимость в одном из них, обычно нужен и второй. А умение говорить «нет» — это отказ от выполнения работы, которую должен выполнять кто-то другой.

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

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

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

7. Научитесь думать о том, как именно будет использоваться ваша разработка

Есть один навык, на владение которым сложно организовать проверку в ходе собеседования. Ситуации, в которых он нужен, тяжело воспроизвести во время учёбы. Речь идёт об умении видеть ошибки, которые может совершить конечный пользователь программной системы. Мы обычно называем это «продумыванием сценариев использования программы».

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

Даже простое изменение чего-либо требует поиска всех тех мест, где это используется. Например, так как большая часть работы программиста заключается в поддержке кода, ему часто приходится менять код, который тесно связан с чем-то другим. Если внести в систему непродуманное изменение — это может «поломать» работу совершенно неожиданных частей программы. Например, меняться может объект, метод, API некоей системы. Причём, речь идёт об изменениях любого масштаба — даже о чём-то вроде смены типа в базе данных.

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

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

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

Итоги

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

Уважаемые читатели! Что вы посоветовали бы освоить тому, кто стремится к профессионализму в программировании?

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть