Комментарии 7
Отсюда вывод, что понятность — это ключевой показатель, который необходимо отслеживать и которым надо управлять.
Окей, я соглашусь, звучит здраво — понятный код лучше непонятного, потому что чтобы работать с кодом надо его понимать (а так же понимать, что от этого кода нужно — собственно в этом и состоит задача программиста).
А дальше то что? Статья о том, что понятное лучше? Простите за каламбур, но это и так понятно)
Как измерить понятность? Ладно, это слишком круто. Как, хотя бы, ввести аналог отношения предпочтения по «понятности»?
Иными словами, вот два файла из исходного кода телеграмма:
1. ChangeNameActivity
2. ChangePhoneActivity
Какой из них понятнее? 1 или 2? Каким образом вы это узнали? Как сравнить их по понятности с другими файлами в том же репозитории телеграмма? Как я уже сказал, мне даже цифр не надо — можно просто рассказать о том, как узнать что один код понятнее другого?)
Или вот еще один пример: провели мы рефакторинг. Как узнать код в результате стал более понятным или меннее понятным? Соцопрос в команде провести? В результате выяснится, что тем кто проводит рефакторинг — все понятно, а тем кто им не занимается — не понятно и нужны пояснения (тут вносит огромный вклад куча когнитивных искажений).
Ну и последний вопрос: как вообще проверить, что человек что-то понял?)
Это я все к чему. Прежде чем предлагать отслеживать показатель — может расскажете как он определяется и как его измерять?)
Как измерить понятность?
Пока видимо только субъективно. У нас на проекте мы тоже начали думать о понятности кода, стараемся сделать обсуждения понятности частью культуры разработки, поэтому часть обсуждений в код ревью проходит именно про «понятность» названий классов, методов, переменных, текстов сообщений в логах и на UI. Тут главное начать, и со временем команда вырабатывает субъективный взгляд на «понятность». Также помогает взгляд извне, например «понятность сообщений об ошибках» — тут могут помочь конечные пользователи.
Можно пофантазировать о том, что такой размеченный набор «понятного кода» в будущем можно скормить лингвистической нейросети как обучающий, и тогда она сможет сама анализировать новый код на предмет «понятности».
Эту тему хорошо рассмотрел Рич Хикки и назвал simple made easy.
Для себя это понимаю как комбинаторную сложность, что весьма формализуемо.
Рассматривая систему стремимся к тому что бы каждый её компонент был максимально однозначным — т.е. был понятен его граф переходов, и кол-во таких компонентов было минимальным. Так поступаем на каждом уровне: пакет, модуль, функция.
Например односрочные выражения они более компактные но при этом нет одназначности что они делают и в голове у разработчика вырисовывается множество путей по которым может работать алгоритм — т.е. это комбинаторно сложно, т.к. растет кол-во комбинаций которы нужно проанализировать. Другой пример открываю код который на уровне функци понятный он каждый минимальный элемент вынесен в отдельную фукнцию, в там случае разработчику сложно уместить в голове все элементы/функции и понять что же в итоге делает код.
Для себя это понимаю как комбинаторную сложность, что весьма формализуемо.
А как ты формализуешь семантику? Например, назвали бизнес-метод transform, а сам класс — Transformer. Эти названия слишком абстрактны и не проясняют смысл бизнес-операции. Получается, что код непонятен, хотя его непонятность здесь лежит именно в разделе смысла, а не топологических свойств кода. Поэтому для семантического анализа «понятности» нужны методы лингвистического анализа и нейросети (а может и ещё какие-нибудь средства ИИ).
Мне кажется, надо вводить понятие "долг перед пользователем" (в смысле 'user debt'). Так же как технический долг он копится и осложняет жизнь пользователям при попытке использовать проект.
Понятность сильно зависит от предварительного обучения. Смотри нотную запись или просто умение читать. Т.е. кто-то сумел объяснить каким либо способом (желательно письменным), как все это устроено и что все это значит — это одно. А если человек сам разбирается — это совсем другое.
Понятность ПО: самый важный показатель, который вы не отслеживаете