- PVSM.RU - https://www.pvsm.ru -
Автор материала, перевод которого мы публикуем сегодня, говорит, что большинство программистов работает в командах. Однако на определённом этапе карьеры разработчику может понадобиться трудиться в одиночку. Основной объём подходов к организации работы над программными продуктами рассчитан именно на применение в командах. Эти подходы выражаются в правилах, принимаемых в организациях. Такие правила упорядочивают работу, помогают программистам качественно и быстро делать своё дело. Нечто подобное было бы весьма полезно и тем программистам, которые работают сами по себе.
Как быть тому, кто работает один? На что ориентироваться, стремясь выстроить чёткий и эффективный рабочий процесс? Каким принципам и правилам следовать? Предлагаем вместе поискать ответы на эти вопросы.
Здесь я, говоря о «программистах-одиночках», подразумеваю всех тех, кто работает в неофициальной, неструктурированной среде. Это может быть как отдельно взятый программист, так и небольшая группа людей, занятых, скажем, в свободное время, каким-то проектом. Вот несколько примеров:
Объединяет все эти примеры то, что труд программистов, занимающихся чем-то подобным, обычно не регламентируется неким сводом правил, таких, которые обычно существуют в компаниях.
Правила, в применении их к самостоятельной работе программистов над некими проектами, важны по нескольким причинам. Рассмотрим их.
Программист, самостоятельная работа которого хорошо организована, вполне может присоединиться к некоей команде. В таком случае весьма высоки шансы того, что он станет ценным членом такой команды. А именно, речь идёт о следующем:
В результате программист-одиночка, рационально организующий свой труд, в любом случае оказывается в выигрыше.
Разработка программного обеспечения — это не только процесс написания кода. Здесь присутствуют множество деталей, ответственных за то, чтобы превратить идею в готовый проект, а затем поддерживать его в работоспособном состоянии. Внедрение в личный рабочий процесс передовых методик разработки ПО поможет программисту-одиночке уверенно следовать к цели, ради которой создаётся проект, и избежать ситуаций, когда кажется, что всё оказалось настолько запутанным, что непонятно — куда двигаться дальше.
Если вы, как и я, любите программировать, у вас всегда будет соблазн, начиная новый проект, сразу же, без оглядки, броситься в пучину написания кода. Но опыт подсказывает мне, что, если у меня есть некий высокоуровневый план работ, то это, не вредя гибкости, которой отличается индивидуальная разработка, помогает избежать множества неприятностей разного масштаба.
Поговорим о передовых методиках разработки ПО.
«Рабочий процесс» — это последовательность шагов, которые нужно пройти в процессе преобразования идеи в готовый продукт. Вот несколько вопросов, ответы на которые должны давать правила, регламентирующие процесс работы над программным продуктом:
Зачем всё это регламентировать, загонять в какие-то рамки, если вполне может показаться, что работа над проектами будет идти гораздо быстрее без некоего определённого рабочего процесса? Не легче ли представить весь «рабочий процесс» в таком виде: «просто пишем код и шлём в ветку master»? На самом деле, по мере роста сложности проекта, оказывается, что наличие чётких правил упрощает определение того, что, в работах по этому проекту, нужно сделать, и, соответственно, без лишних раздумий позволяет на этих делах сосредоточиться. При работе в команде рабочий процесс превращается в нечто вроде конвейера, который улучшает эффективность труда каждого члена команды.
Поговорим теперь о том, как организовать процесс работы над программным продуктом.
Тут вам пригодятся механизмы платформ, на которых вы размещаете код — GitHub, Gitlab, BitBucket и других. Задачи помогают отслеживать сообщения об ошибках, запросы на добавление в продукт нового функционала, организовывать информацию о важных изменениях проекта. Нужно отметить, что, когда вы вводите заголовок и описание задачи, это заставляет вас чётко формулировать мысли и понятно описывать проблему и возможные пути её решения. Идею, касающуюся использования задач, можно развить, внедрив в свой рабочий процесс инструмент для управления задачами вроде Trello или GitHub Projects.
Задача
Многие разработчики предпочитают отправлять изменения, с помощью push-запросов, прямо в главную ветку своего проекта, которая называется master. Однако у подхода к внесению изменений в код проектов с использованием pull-запросов, есть некоторые важные преимущества. Во-первых, такие запросы облегчают анализ изменений, касающихся внедрения в проект некоей новой возможности или исправления ошибки, и того, как они, после слияния с основной кодовой базой, на неё повлияют. Кроме того, если pull-запросы связаны с задачами из трекера задач, их использование облегчает понимание того, как именно развивается проект, избавляя от необходимости выяснения этого в процессе чтения кода.
Сведения о pull-запросе
Рекомендация по поводу выполнения обзоров собственного кода может звучать странно, но, несмотря на это, разработчикам следует проводить анализ собственного кода так, будто его написал кто-то другой. Некоторые программисты советуют сделать pull-запрос, на некоторое время отвлечься, а потом, прежде чем включать его в код, его проверить. Выполнение проверок кода, выполняемое за пределами привычной для программиста среды в виде его IDE, позволяет взглянуть на код достаточно свежим взглядом. Это помогает находить ошибки и обнаруживать в коде то, на что в обычных условиях можно не обратить внимания. Обзоры кода, кроме того, заставляют разработчика задавать самому себе различные вопросы: «Почему эта возможность была реализована именно так? Что тут может быть сделано неправильно? Есть ли более эффективный способ решения этой задачи?».
Постарайтесь делать коммиты так, будто вы работаете в команде. А именно — избегайте слишком больших коммитов, старайтесь, чтобы сообщения коммитов чётко и понятно описывали бы их смысл. Так же, как и в случае с обзорами кода, написание качественных сообщений коммитов заставляет разработчика тщательно обдумывать свои действия, задавая себе вопросы наподобие следующих: «Чего я пытаюсь добиться этим коммитом? Как я пытаюсь этого добиться?».
Возможны ситуации, в которых вы можете позволить себе отступить от правил. Например, вы можете решить, что, для того, чтобы не замедлять работу из-за пустяков, вы, при внесении в код весьма незначительных изменений (наподобие исправления опечаток), можете, без лишних движений, отправить push-запрос прямо в ветку master.
Независимо от того, какие правила будут лежать в основе вашего рабочего процесса, самое важное, чтобы всё, что вы делаете, делалось бы намеренно, а не по случайному стечению обстоятельств. Успешные проекты не возникают сами по себе: их создают с любовью и заботой. Действия, выполняемые намеренно, подразумевают некие периоды анализа ситуации, разбора сложных случаев и размышлений о том, как, например — с помощью каких инструментов, с ними можно справиться.
Внедряйте в работу принципы DRY [1], SOLID [2] и FIRST [3]. Создавайте программы из маленьких, инкапсулированных, атомарных компонентов, подходящих для повторного использования. Поддерживайте такие компоненты в актуальном состоянии, собирайте их в коллекции с использованием соответствующих платформ, наподобие Bit [4]. Всё это поможет вам повысить скорость и качество работы.
Документация… Для многих это — больной вопрос. О том, что программные проекты нуждаются в документации, знают очень многие. Тех, кто пишет хорошую документацию, уже гораздо меньше, и ещё меньше тех, кому нравится этим заниматься. После того, как завершился очередной увлекательный этап написания кода, необходимость его документирования часто становится задачей, о которой хочется просто забыть. Как, в виде обычных текстов, выразить все хитросплетения программного кода?
И, кстати, тут уместно задаться вопросом о том, зачем всё это нужно. Дело в том, что людям свойственно ошибаться. Мы можем о чём-то забывать. У нас бывают неудачные дни. Или, работая над неким проектом, мы можем просто перейти к работе над чем-то другим. Документирование позволяет зафиксировать знания о коде, которые, в противном случае, будут привязаны к некоему человеку. Документирование кода, кроме того, помогает разработчикам видеть код в более общих чертах, чем это доступно при его написании, и яснее понимать цели проектов.
Следующие идеи помогут вам писать хорошую документацию.
Тут то, что мы называем «общением», применимо, в основном, к ситуациям, когда некий проект разрабатывают силами небольшой команды или делают его на заказ.
Зачем это нужно? Дело в том, что прозрачность работы ведёт к повышению ответственности её исполнителей. Когда вы знаете, что вы должны что-то кому-то сообщить (члену команды или представителю заказчика), это способствует тому, что вы внимательнее относитесь к тому, что делаете. Именно поэтому во многих компаниях практикуют проведение коротких совещаний, на которых сотрудники отчитываются о проделанной работе.
Кроме того, часто некий член команды сталкивается с проблемой, для него сложной, которую легко можно решить, просто обсудив её с клиентом или с другим членом команды. Я уже сбился со счёта, вспоминая случаи, когда я прямо-таки опускал руки, пытаясь понять, почему то, что я написал, не работает. А причиной подобного было то, что другой член команды внёс в проект изменения, которые мешали работе моего кода. Для того, чтобы в этом разобраться, достаточно было вынести проблему на всеобщее обсуждение.
Вот несколько рекомендаций по поводу общения с клиентами и с членами команд программистов.
В целом можно отметить, что вам следует постараться, чтобы взаимодействие между всеми заинтересованными лицами было бы организовано удобно и просто, чтобы, так сказать, «цикл обратной связи», работал бы без задержек. Это помогает организовать здоровую и продуктивную рабочую среду.
Мониторинг в сфере разработки ПО — это очень важный вопрос. Компьютеры подвержены сбоям. В ходе развёртывания проектов происходят ошибки. Оплошности разработчиков приводят к тому, что программы, вроде бы прошедшие все возможные проверки и успешно введённые в строй, падают с исключениями. Именно поэтому разработчику и нужно позаботиться о системе мониторинга программ. Это облегчит решение проблем, которые могут возникать на разных стадиях жизненного цикла продукта. Данные мониторинга программ — это одна из частей вышеупомянутого «цикла обратной связи». Мониторинг даёт программисту связь с реальностью, с той средой, в которой работают его программы.
Вот несколько рекомендаций по поводу организации наблюдения за поведением программ:
Мониторинг активности приложений и отслеживание показателей их производительности способны принимать разные формы. В самом простом виде это может быть вывод данных о работе программы с помощью команды console.log(), сохранение этих сведений в текстовых файлах и ручной анализ таких файлов. Мониторинг может представлять собой и довольно продвинутую систему, в которую входят специализированные инструменты вроде Sentry, Bugsnag и Elastic APM. Главное — выбрать то, что вам подходит, и последовательно этим пользоваться.
Вы смотрите, но не наблюдаете, а это большая разница.
Артур Конан Дойль, «Скандал в Богемии»
То, о чём пойдёт речь в этом разделе, можно считать и самостоятельной рекомендацией, и подходом к использованию других приведённых здесь рекомендаций. Дело в том, что не существует универсальной формулы организации работы над программным продуктом. Разные люди по-разному занимаются разработкой программ, используют разные методы мониторинга, по-разному документируют код, и так далее. Именно поэтому, какими бы ни были правила работы над программами, которые выбрали вы, важно всегда стремиться к тому, чтобы за проектом было бы организовано наблюдение, чтобы из результатов наблюдения делались бы выводы, и чтобы в итоге всё это приводило бы к улучшениям программ.
Наблюдение за программой подразумевает критический анализ её поведения, или, скажем, показателей её производительности. Наблюдая за программой, вы строите связи того, что вы видите, с тем, что вы знаете о системе, приходя в итоге к логическим выводам о происходящем. Тот, кто работает в одиночку, обычно лишён тех возможностей по анализу программ, которые используются в организациях (вроде A/B-тестов или исследований целевой аудитории). В результате ему приходится собирать подсказки о жизни его программы из «неформальных» источников — таких, как комментарии пользователей, сообщения о проблемах в трекерах задач и логи приложения.
После завершения очередного этапа наблюдения за программой приходит время делать выводы и совершенствовать её на основе этих выводов. Потом следует очередной этап наблюдений, за которым идёт очередная итерация анализа собранных данных и улучшения программы. Но работа над программой — это нечто большее, нежели «наблюдение — анализ — улучшение».
Рассмотрим условный пример. Предположим, у меня есть программа, выводящая список неких объектов и время их создания. Правда, моя программа использует UTC-время. В результате многие её пользователи видят сведения о времени, кажущиеся им неправильными.
Для того чтобы это исправить, я решил добавить к выводимой отметке времени пояснение в виде строки UTC. В результате, например, то, что раньше выглядело как 5:30 pm, теперь будет выглядеть как 5:30 pm UTC. Такой подход сработал, пользователям стало удобнее. Но я в итоге понял, что пользователи всё равно будут переводить это время во время своего часового пояса. Зачем нагружать их лишней работой? Эти размышления привели к тому, что я добавил в программу функцию по автоматической конверсии времени. Так работать с ней стало гораздо удобнее.
Позже, пообщавшись с пользователями, я понял, что для них самое главное — это примерно понимать возраст объектов, а не знать точное время их создания. Сделав это наблюдение, я обновил программу таким образом, чтобы она показывала бы возраст объектов, а не время их создания. Теперь отметки времени выглядели как «5 минут назад» или «2 часа назад». Хотя точных сведений о времени создания объектов программа теперь не показывала, то, что получилось в итоге, оказалось гораздо более простым и удобным для пользователей этой программы.
Тот же подход применим и к любым другим программным проектам. При этом надо отметить, что здесь мы не говорим о неких жёстких и обязательных для исполнения правилах. Выбирая для себя те или иные подходы к упорядочению процесса работы над программами, вы сами оцениваете их работоспособность, после чего используете лишь те из них, которые вам подходят, в той форме, которая вас устраивает. Как видите, тут мы тоже видим итеративный процесс, о котором только что говорили в применении к разработке программ.
В идеале, если говорить о структурированной среде разработки программного обеспечения, в такой среде можно выделить несколько важных ролей — от заказчика продукта, до его разработчика. Люди (или группы людей), играющие эти роли, взаимодействуют, что и приводит к появлению готового продукта. Но, работая в одиночку, вы совмещаете множество подобных ролей (не исключено, что речь идёт и обо всех таких ролях), что даёт вам свободу организовать работу именно так, как вам того хочется. Лучше всего будет употребить эту свободу для того, чтобы создать структуру, которая позволит вам трудиться более эффективно. Для создания такой структуры вам, вполне возможно, придётся приложить совсем немного усилий, и я вам гарантирую то, что результаты её создания и использования вам понравятся.
Уважаемые читатели! Как вы организуете свой труд в ситуациях, когда вам приходится играть роль «программиста-одиночки»?
Автор: ru_vds
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/305172
Ссылки в тексте:
[1] DRY: https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
[2] SOLID: https://blog.bitsrc.io/solid-principles-every-developer-should-know-b3bfa96bb688
[3] FIRST: https://addyosmani.com/first/
[4] Bit: https://bitsrc.io/
[5] Источник: https://habr.com/post/436008/?utm_campaign=436008
Нажмите здесь для печати.