[Программирование, Софт] Понятность ПО: самый важный показатель, который вы не отслеживаете (перевод)

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
24-Ноя-2020 16:34

Цитировать

Привет, Хабр! В OTUS открыт набор на новый поток курса "Software Architect", в связи с этим приглашаем всех желающих на онлайн день открытых дверей, в рамках которого наши эксперты подробно расскажут о программе обучения, а также ответят на ваши вопросы.

Основные идеи

Все течет, все меняется. Программирование как нельзя лучше подтверждает правильность этого изречения: разработчики ежедневно модифицируют, адаптируют, дорабатывают и даже перерабатывают свои системы.
Приложения становятся все сложнее, над ними трудятся все больше разработчиков, и поддерживать понятность программного обеспечения становится нелегко. Сложный код труднее понять и при необходимости изменить.
Понятность системы — это то ее свойство, благодаря которому инженеру не составит труда в ней разобраться. Чем понятнее система, тем проще инженерам вносить в нее изменения, которые будут вести себя предсказуемо и не сделают систему уязвимой.
Система является понятной, если она отвечает следующим критериям: завершенность, компактность, открытость и структурированность.
Со свойством понятности связано свойство наблюдаемости, однако основными характеристиками наблюдаемости являются: 1) способность предупреждать о неправильном функционировании системы и помогать выявлять причины ошибки, чтобы восстановить нормальную работу системы, и 2) способность помогать выявлять факторы, ограничивающие производительность системы, чтобы задействовать дополнительные ресурсы или сообщить о проблеме ответственным лицам.

2500 лет назад Гераклит сказал: «Все течет, все меняется». Программирование как нельзя лучше подтверждает правильность этого изречения: разработчики ежедневно модифицируют, адаптируют, дорабатывают и даже перерабатывают свои системы. Еще один аспект, который отличает разработку программного обеспечения ото всех остальных направлений деятельности, — большая свобода действий, ограниченная лишь техническими возможностями информационных систем.Однако часто на нашем пути к реализации этого мощнейшего потенциала возникает неожиданное препятствие — ограничены наши знания о собственных разработках. Приложения становятся все сложнее, над ними трудятся все больше разработчиков, и поддерживать понятность программного обеспечения становится нелегко. В результате проекты рушатся, как Вавилонская башня.ПримерБольшинство коммерческих проектов по разработке программного обеспечения начинается не с чистого листа. Как правило, уже существует какое-то приложение, написанное на определенном языке (или языках) программирования для одной или нескольких операционных систем, в котором используется набор фреймворков и библиотек.

Самый быстрый и надежный способ выпуска приложений. Развертывание, подключение, защита и эксплуатация приложений в мультиоблачных средах и на периферии. Начните бесплатно.

Мы (или наша команда) изменяем это приложение таким образом, чтобы оно соответствовало некоторым требованиям, например разрабатываем новую возможность, устраняем существующий баг и так далее. При этом мы обязаны соблюдать все действующие (не только задокументированные) требования и, насколько это возможно, не менять существующее поведение программы.Устроившись на работу, любой начинающий разработчик осознает, что написать фрагмент кода для решения простой задачи по информатике (или найти ответ на StackOverflow) — это совсем не то же самое, что встроить такой фрагмент в большую сложную систему.Что такое понятность?Посмотрим, как толкуют понятность финансисты, и на основе этого определения дадим свое: «Понятность системы — это то ее свойство, благодаря которому инженеру не составит труда в ней разобраться». Чем понятнее система, тем проще инженерам вносить в нее изменения, которые будут вести себя предсказуемо и не сделают систему уязвимой.Опираясь на эту аналогию, можно сказать, что система является понятной, если она отвечает следующим критериям.

Завершенность. Система должна поставляться с определенным набором исходной информации (исходный код, документация и т. д.). У инженера должна быть вся важная информация о системе.
Компактность. Исходный код не должен содержать слишком много ненужной информации, в которой пользователь может захлебнуться. Здесь в дело вступают принципы разделения ответственности и абстракции, которые позволяют инженеру сосредоточиться на своей задаче.
Открытость. Это такой метод представления программы, который позволяет человеку понять ее в результате чтения кода. Огромное значение здесь имеют согласованность, соглашения о кодировании, форматирование исходного кода, комментарии к коду и подсветка синтаксиса.
Структурированность. В структурированной системе должны присутствовать перекрестные ссылки, чтобы инженеру не составляло труда найти нужную информацию. Ориентироваться в системе программистам позволяет модульность кода, документация на программное обеспечение, средства навигации по исходному коду и инструменты управления исходным кодом.

Понятность среды выполненияС распространением модели «программное обеспечение как услуга» (SaaS) и других моделей поставки приложений многие организации предпочитают самостоятельно реализовывать полный жизненный цикл программного обеспечения.В таких организациях понятность кода играет еще более важную роль: разработчикам необходимо отслеживать, как работает приложение и как его используют клиенты.Поэтому у специалистов, которые занимаются этой задачей, должен быть доступ к информации о закономерностях использования системы, реальным примерам входных и выходных данных, сведениям о фактической производительности и доступности приложения.Наблюдаемость и понятность — не одно и то жеСейчас вы, возможно, подумали, что для этого нужно обеспечить наблюдаемость приложения и использовать средства мониторинга. К сожалению, это не так. Средства мониторинга предназначены для решения более традиционных задач в ИТ:

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

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

Подробнее о курсе "Software Architect". Посмотреть открытый урок по теме "Мониторинг и Алертинг" можно здесь.

Читать ещё:

===========
Источник:
habr.com
===========
===========
Автор оригинала: Liran Haimovitch
===========Похожие новости:

Теги для поиска: #_programmirovanie (Программирование), #_soft (Софт), #_razrabotka_po (разработка по), #_programmnoe_obespechenie (программное обеспечение), #_arhitektura_prilozhenij (архитектура приложений), #_blog_kompanii_otus._onlajnobrazovanie (
Блог компании OTUS. Онлайн-образование
), #_programmirovanie (
Программирование
), #_soft (
Софт
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 14:10
Часовой пояс: UTC + 5