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

Как быть тому, кто работает один? На что ориентироваться, стремясь выстроить чёткий и эффективный рабочий процесс? Каким принципам и правилам следовать? Предлагаем вместе поискать ответы на эти вопросы.

О программистах-одиночках

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

• Разработка опенсорсного проекта, такого, как некий пакет или какая-нибудь библиотека.
• Чей-то личный проект, который может быть как коммерческим, так и бесплатным.
• Фриланс.

Объединяет все эти примеры то, что труд программистов, занимающихся чем-то подобным, обычно не регламентируется неким сводом правил, таких, которые обычно существуют в компаниях.

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

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

?Личные правила и возможная работа в команде

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

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

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

?Правила и профессиональный уровень программиста

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

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

Поговорим о передовых методиках разработки ПО.

Придерживайтесь правил, описывающих особенности рабочего процесса

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

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

Зачем всё это регламентировать, загонять в какие-то рамки, если вполне может показаться, что работа над проектами будет идти гораздо быстрее без некоего определённого рабочего процесса? Не легче ли представить весь «рабочий процесс» в таком виде: «просто пишем код и шлём в ветку master»? На самом деле, по мере роста сложности проекта, оказывается, что наличие чётких правил упрощает определение того, что, в работах по этому проекту, нужно сделать, и, соответственно, без лишних раздумий позволяет на этих делах сосредоточиться. При работе в команде рабочий процесс превращается в нечто вроде конвейера, который улучшает эффективность труда каждого члена команды.

Поговорим теперь о том, как организовать процесс работы над программным продуктом.

?Пользуйтесь трекерами задач

Тут вам пригодятся механизмы платформ, на которых вы размещаете код — GitHub, Gitlab, BitBucket и других. Задачи помогают отслеживать сообщения об ошибках, запросы на добавление в продукт нового функционала, организовывать информацию о важных изменениях проекта. Нужно отметить, что, когда вы вводите заголовок и описание задачи, это заставляет вас чётко формулировать мысли и понятно описывать проблему и возможные пути её решения. Идею, касающуюся использования задач, можно развить, внедрив в свой рабочий процесс инструмент для управления задачами вроде Trello или GitHub Projects.


Задача

?Используйте pull-запросы

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


Сведения о pull-запросе

?Выполняйте обзоры собственного кода

Рекомендация по поводу выполнения обзоров собственного кода может звучать странно, но, несмотря на это, разработчикам следует проводить анализ собственного кода так, будто его написал кто-то другой. Некоторые программисты советуют сделать pull-запрос, на некоторое время отвлечься, а потом, прежде чем включать его в код, его проверить. Выполнение проверок кода, выполняемое за пределами привычной для программиста среды в виде его IDE, позволяет взглянуть на код достаточно свежим взглядом. Это помогает находить ошибки и обнаруживать в коде то, на что в обычных условиях можно не обратить внимания. Обзоры кода, кроме того, заставляют разработчика задавать самому себе различные вопросы: «Почему эта возможность была реализована именно так? Что тут может быть сделано неправильно? Есть ли более эффективный способ решения этой задачи?».

?Поддерживайте осмысленную историю развития проекта в репозитории

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

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

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

Создавайте компоненты и модули, подходящие для повторного использования

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

Пишите документацию

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

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

Следующие идеи помогут вам писать хорошую документацию.

• Поймите то, что ваша документация — это не нечто вроде книги. Документация не должна представлять собой образец высокого литературного искусства. Никто не станет её оценивать с точки зрения её художественных достоинств. Не пытайтесь объяснить в ней абсолютно всё. Стремитесь к тому, чтобы она была чёткой и понятной. Иногда для описания чего-либо достаточно буквально пары предложений.
• Написание документации до написания кода. Документируйте интерфейсы ваших модулей, описывайте порядок их работы с точки зрения внешнего наблюдателя. Подобная документация будет играть роль технических требований к продукту и поможет вам в процессе разработки.
• Написание документации после написания кода. Тут, опять же, стоит придерживаться позиции «стороннего наблюдателя». Что важно в описываемом фрагменте кода? Что нужно знать о том, чтобы пользоваться им (или чтобы внести вклад в его разработку?). Спецификации, задаваемые документацией, созданной до написания кода, в процессе разработки, могут измениться. Поэтому важно проверять подобную документацию на соответствие реальному положению дел после того, как работа завершена.
• Написание документации в процессе написания кода. Этот подход к документированию, в основном, применим к чему-то вроде комментариев, добавляемых в код в процессе разработки. Существует множество материалов на эту тему, поэтому тут я вдаваться в подробности не буду.
• Документация и «модули». Все вышеописанные принципы применимы к модулям. Здесь понятие «модуль» используется в достаточно широком смысле. Это может быть функция, класс, новая возможность, изменение в поведение программы, собственно, некий программный модуль, или весь проект. Если документирование подобных «модулей» кажется вам слишком сложной задачей, попытайтесь разбить их на более мелкие части. Или, если вам легче мыслить более общими категориями, подумайте о том, чтобы писать документацию для более масштабных блоков проекта.

Общайтесь с заказчиками, и с теми, кто вместе с вами участвует в разработке продукта

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

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

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

Вот несколько рекомендаций по поводу общения с клиентами и с членами команд программистов.

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

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

Организуйте систему мониторинга

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

Вот несколько рекомендаций по поводу организации наблюдения за поведением программ:

• Сохраняйте логи и результаты автоматического анализа работы кода. Не стесняйтесь применять console.log() там, где это нужно Лучше залогировать слишком много информации чем слишком мало. Однако постарайтесь найти «золотую середину», чтобы логи ваших программ не содержали бы ненужных подробностей об их работе. Это упростит поиск в журналах важных сведений.
• Выясните, куда попадают логи ваших приложений, и настройте механизмы, которые позволяют удобно с ними работать. В роли вышеупомянутых «механизмов» может выступать всё что угодно — от входа на на сервер с использованием SSH и просмотра свежих событий, записанных в журнал, до чего-то вроде использования ELK-стека. Самое важное — это знать о том, где лежат логи приложения, формируемые командами console.log() или любыми другими средствами.
• Не игнорируйте исключения. Хотя любой разработчик должен стремиться к тому, чтобы его приложение было бы устойчивым, то есть, могло бы восстановить работоспособность в случае возникновения ошибки, «избавляться» от неожиданных исключений, просто «запирая» их в некоем блоке catch, будет неправильно. Гораздо лучше будет логировать сведения о неожиданных исключениях. Например, если вы обращается к какому-то API для загрузки неких данных, созданных пользователем (скажем — твитов), вы должны быть готовы к обработке ошибки 404. А вот те ошибки, которые вы не обрабатываете, нужно логировать. Я бывал в ситуации, когда, не логируя сведения о неожиданных ошибках, я попросту не знал, что исчерпал лимит обращений к одной системе. Это привело к тому, что доступ к соответствующему API моей программе закрыли.
• Проверяйте журналы. Проверку журналов, сформированных по результатам работы приложений, можно организовать либо вручную, либо воспользовавшись некими средствами для их автоматического анализа. Однажды я, не особенно заботясь о контроле логов, исправил в программе небольшую проблему и продолжил спокойно заниматься своими делами. Как оказалось позже, моё исправление было нерабочим. С тех пор я внимательно отношусь к проверке логов приложений после их развёртывания, что позволяет мне проверять правильность их работы.

Мониторинг активности приложений и отслеживание показателей их производительности способны принимать разные формы. В самом простом виде это может быть вывод данных о работе программы с помощью команды console.log(), сохранение этих сведений в текстовых файлах и ручной анализ таких файлов. Мониторинг может представлять собой и довольно продвинутую систему, в которую входят специализированные инструменты вроде Sentry, Bugsnag и Elastic APM. Главное — выбрать то, что вам подходит, и последовательно этим пользоваться.

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

Вы смотрите, но не наблюдаете, а это большая разница.
Артур Конан Дойль, «Скандал в Богемии»

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

Наблюдение за программой подразумевает критический анализ её поведения, или, скажем, показателей её производительности. Наблюдая за программой, вы строите связи того, что вы видите, с тем, что вы знаете о системе, приходя в итоге к логическим выводам о происходящем. Тот, кто работает в одиночку, обычно лишён тех возможностей по анализу программ, которые используются в организациях (вроде A/B-тестов или исследований целевой аудитории). В результате ему приходится собирать подсказки о жизни его программы из «неформальных» источников — таких, как комментарии пользователей, сообщения о проблемах в трекерах задач и логи приложения.

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

Рассмотрим условный пример. Предположим, у меня есть программа, выводящая список неких объектов и время их создания. Правда, моя программа использует UTC-время. В результате многие её пользователи видят сведения о времени, кажущиеся им неправильными.

Для того чтобы это исправить, я решил добавить к выводимой отметке времени пояснение в виде строки UTC. В результате, например, то, что раньше выглядело как 5:30 pm, теперь будет выглядеть как 5:30 pm UTC. Такой подход сработал, пользователям стало удобнее. Но я в итоге понял, что пользователи всё равно будут переводить это время во время своего часового пояса. Зачем нагружать их лишней работой? Эти размышления привели к тому, что я добавил в программу функцию по автоматической конверсии времени. Так работать с ней стало гораздо удобнее.

Позже, пообщавшись с пользователями, я понял, что для них самое главное — это примерно понимать возраст объектов, а не знать точное время их создания. Сделав это наблюдение, я обновил программу таким образом, чтобы она показывала бы возраст объектов, а не время их создания. Теперь отметки времени выглядели как «5 минут назад» или «2 часа назад». Хотя точных сведений о времени создания объектов программа теперь не показывала, то, что получилось в итоге, оказалось гораздо более простым и удобным для пользователей этой программы.

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

Итоги

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

Уважаемые читатели! Как вы организуете свой труд в ситуациях, когда вам приходится играть роль «программиста-одиночки»?