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