» » » Организация работы программиста-одиночки

 

Организация работы программиста-одиночки

Автор: admin от 14-01-2019, 12:15, посмотрело: 23

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



Организация работы программиста-одиночки


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

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 часа назад». Хотя точных сведений о времени создания объектов программа теперь не показывала, то, что получилось в итоге, оказалось гораздо более простым и удобным для пользователей этой программы.



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



Итоги



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



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



Организация работы программиста-одиночки

Источник: Хабр / Интересные публикации

Категория: Веб-разработка

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

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *