среда, 18 сентября 2013 г.

Качество кода (или взгляд по-русски)


Сподвиг к написанию твит http://zeroturnaround.com/rebellabs/there-is-more-to-code-quality-than-just-pretty-vs-ugly/?utm_content=buffer1b258&utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer#!/
и желание уже наконец-то расшифровать (может кому-то поможет?) на понятном русском языке буржуйские загадочные термины и слова касательно характеристик кода и программного продукта в целом. Постараюсь привязать инструменты и методы, которые помогают улучшить тот или иной параметр качества. Примеры кода будут позже. Сейчас же на скорую руку написал свои первые мысли на сей счет. Между прочим, указанную статью я еще не читал, а потому может включу сюда, если увижу там что-то чего я смог упустить.

Fitness
~~~~~~~
Это типа отсутствие жирка. Жирок конечно необходим в экстремальных условиях, но для спортсмена требуется поддерживать себя в форме, чтобы показывать стабильно хорошие результаты. Так и здесь, в коде, требуется убирать излишества, которые затрудняют понимание кода и отдаляют нас от начальных целей и основопологающих идей. Более того, тестировать универсальные вещи сложнее, так как нужно специально выдумывать искуственные сценарии для тестирования. В противоположность этому, task centric-код полагается на уже имеющиеся сценариии использования кода для решения конкретной задачи и, потому, не требуется выдумывать тесты, так как они уже под рукой.
Безусловно, возникает вопрос по библиотекам, универсальным фреймуоркам, но у них тоже есть свои клиенты, свое сообщество пользователей, а потому придумать сценарии использования не так уже сложно, если известно для чего будут использоваться библиотеки и фреймуорки.
Жирок убрать сложно, если плохо определено назначение кода. Возникает желание сделать кода максимально готовым ко всему. Это и есть причина такого жирного и универсального кода.
Буржуи любят термин “high cohesion”, т.е. дословно “высокая зацепленность кода” или более понятно это означает, что код должен фокусироваться на выполнении конкретной задачи, а не заниматься посторонними вещами. Типа специалиазация и еще раз специализация.
Поможет в этом частично TDD. Сначала тесты, а затем код.

Correctness
~~~~~~~~~~
Все просто, в коде не место ошибкам, код должен правильно решать задачи. Поможет только тест, т.е. формализуем в тесте постановку задачи и сверяем с ответом. Погружаем наше решение в тест и смотрим результат проверки решения. Погружаем вновь и вновь пока не получим на выходе “Тест пройден”. Правда между последовательными погружениям не забываем исправлять код, а иначе войдем в бесконечность или, что более точно, пока компьютер не перегорит.
Для поиска логической ошибки в коде потребуется посидеть с отладчиком изучая, возможно, используемые сторонние библиотеки.

Performance
~~~~~~~~~~
Код должен выполняться за приемлемое время. Если меня кто-то неожиданно делегирует представлять страну в Олимпийских играх в дисциплине Марафон, то это будет очень странным решением, так как выбрали очевидно не того человека, так как даже если сильно захотеть, то гены у меня не те, чтобы соревноваться не то что с Абебе Бикила, а даже с обычным рядовым бегуном, например, с Бочариком.
Короче, дело к ночи, точнее к работе, а потому кратко скажу, что надо выбирать соответствующие задаче алгоритмы и структуры данных. Сперва лучше не гнаться за супер-пупер алгоритмами дающими менее порядка величины улучшения по сравнению с простыми, но не супер-пуперскими алгоритмами и структурами. Ниже, в разделе о сопровождении ПО, поясняется почему нежелательно изощряться без лишней необходимости.
Инструментов для распознавания правильно используемых алгоритмов и структур, увы, нет. Тут только экспертиза поможет.
Есть правда нефункциональные требования к продукту. Выдавать веб-страницу на экран пользователя через максимум секунду, а лучше через пол-секунды, после его желания увидеть произведение дизайнера. Желание обычно формируется через нажатие ссылки, кнопки или ввода адреса в адресной строке браузера. Или, например, сделать закрытие операционного дня за 2 часа, чтобы бухгалтеры смогли вернуться домой вовремя, чтобы утром встать выспавшимися и бодрыми для повышения экономических показателей банка и, соответственно, для улучшения аппетита у акционеров этого банка при виде роста котировок акций банка.
Вообщем, очень хорошо, когда есть нефункциональные требования. Это есть источник того, что может позволить верифицировать код по метрикам группы Производительность системы.
Для замеров существует масса инструментов типа JMeter, а также любых самописных инструментов и системных утилит. У юниксоидов, как мне кажется, выбор лучше и проще.
Да, забыл совсем. Есть еще очень хорошие инструменты FindBugs, PMD, которые позволяют найти широко распространенные ошибки в коде, в т.ч. касающиеся многопоточного кода.

Clarity
~~~~~~~~
Типа ясность и прозрачность кода для чела впервые увидевшего оный или для того кто настрогал этот код а теперь вернулся его почитать, чтобы понять логику работы.
Нет ничего очевиднее, что простота и ясность важна. “Говорите яснее”, “короткое и лаконичное описание” - часто слышим, но редко этому следуем. Собственно, изъясняться на правильном русском тоже талант, который, к сожалению и ах, ныне редко встретишь ИТ-специалистов и не только ИТ. Код, собственно, в этом отношении ничем не должен отличаться от требования изъясняться “по-русски”.
Частично здесь может помочь checkstyle и разные метрики типа cyclomatic code complexity. Конвенция о стиле кода (соглашение по кодированию) - это субкультура. Не может быть единой для всех. Появляется с согласия основателей и пионеров кода, которые привыкли к определенному стилю.

Maintainablity
~~~~~~~~~~~
Дословно - способность поддерживаться (кем-л. или чем-л). Ну а на нашем великом языке синонимом этому словосочетанию является издревле испокон века - простота. Да, да, простота. Простота во всем! Так как простота позволяют любому с улицы. Ладно, ладно, не с совсем уж с улицы, а сразу из университета. Да-к вот, любой студент пришедший в компанию может легко и без красных глаз разобраться в коде. Сложный критерий качества продукта, согласен. Ведь всем всегда очень хочется задействовать весь арсенал современных инструментов, которые только-только вышли на рынок.
Потому стандарты важны. Потому важно обучение стандартам в вузах.
Регулируется простота процессом контроля за используемыми инструментами и библиотеками. Никаких самописных аналогов допускать не следует прежде чем не найдется веских оснований для этого. А если сильно хочется что-то самописное, то следует изучить лучшие практики созданию подобных продуктов, а потом садиться за комп. Желательно свой шедевр выставить на всеобщее обозрение, чтобы сообщество разработчиков всего мира смогли вылить на вас все о чем они думают после знакомства с вашим изобретением. Возможно после всего этого мнение об использовании своей писанины изменится в сторону использования популярной и аналогичной тулзы.
“Простота - залог здоровье, а здоровье прежде всего”.

Beauty
~~~~~~~
“Красота спасет мир!”. Это ясно. А еще не помню кто из физиков сказал такое, но было сказано следующее близкое по смыслу. “Если я вижу красивое уравнение, то сразу склонен верить, что истина где-то рядом”.
Сложно измерить красоту. Красота в коде доставляет удовольствие заниматься с этим произведением искуства. Начинаешь чувствовать свое величие и возможность прикоснуться к прекрасному.
Очень хорошо помогает улучшать эстетику кода - вынос его на всеобщее обозрение под любой подходящей публичной лицензией.
Как мне кажется, весь синтетический сахар появляющийся сейчас способствует формированию вкуса и красоты у разработчиков. Код становится лаконичным и более функциональным. Объектно-ориентированная парадигма была в моде, а сейчас больше движение в сторону функционального подхода. Это движение в свою очередь появилось, по моему пониманию, из-за все более дешевой памяти и доступности многопроцессорных архитектур.
Красота - это радость для глаз! :)

Извините за бесчисленные грамматические ошибки и свое несовпадающее с вами видении данной темы. Буду рад замечаниям и дополнениям.
А если вспомнить еще про Майера с его терминами reliability, scalability, robustness и т.д., то данные обрывки мысли можно обогатить и структурировать в отдельную статью.

Комментариев нет: