Качество кода *

В данной статье последовательно рассматриваются различные аспекты улучшения производительности приложений на примере мной разработанного поисковика приложений для мобильной операционной системы Андроид. Если сам поисковик может пригодиться различным пользователям с большим количеством программ, то статья будет интересна в первую очередь разработчикам (не только андроид-разработчикам). И для всех читателей, независимо от платформы, в конце прикреплён опрос "Что для меня в первую очередь важно в мобильном приложении?"


Приветствую Вас, читатели хабра,

начну с небольшой предыстории — с описания проблемы, а далее продолжу тем, как я проблему решал.

Я, как гордый обладатель андроид-телефона, очень рад открытости системы и возможности ставить туда множество приложений как из разных маркетов, так и скачанных откуда-то. В среднем на моём старом добром Galaxy Note около 150 приложений, большинством из которых я периодически пользуюсь.

С чувством, что чем больше коров приложений, тем больше молока пользы от моего телефона, я заметил, что кучу времени я провожу в листаниях от экрана к экрану в поисках иконки нужного приложения. Когда коров программ мало, тогда их легче найти. Их можно поставить на домашний экран или разнести по папочкам. Всё это хорошо и удобно, если используются 20-30 приложений.
Но раз уж я отношусь к категории хэви-юзеров, то начал искать быстрый метод поиска приложений.

Требования к решению проблемы довольно просты:
поиск должен быть быстрым и ресурсосберегающим (процессор, батарея), а также всё должно происходить автоматически — я не хочу ничего сам устанавливать, сортировать или распихивать по папкам.

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

В какой-то момент после апдейта на андроид 4.1 на смену поиску пришёл Google Now, который вдруг перестал работать без соединения с интернетом (возможно только у меня?), жутко начал грызть батарею и предлагать мне поездки, куда я вовсе ехать и не хочу. Только вот искать программы совсем перестал.

С мыслью: «Ээх, гугл, что ж с тобой стало — менеджеры по сбору личных данных заменили разработчиков» стал искать другие программы, но окромя сплошных лаунчеров, которые надо самому настраивать, ничего не нашёл (возможно не по тем словам искал).

Ну раз ничего нет, что же делать, я и сам копать траншею по клавишам в IDE бить умею, думаю, там делов-то на день, сделаю сам себе удобную прогу — как говорится: «Лучше день потерять, а потом за час долететь».

Главное условие: нахождение результата должно происходить быстро.

Вот об этом и поговорю в этой статье (чтоб не скучно было, текст будет периодически сопровождаться кодом)
Всё, что написано не ново, а скорее является подборкой того, на что нужно обращать внимание для улучшения быстродействия программ.
В качестве наглядного примера приведена конкретная программа, написанная в Java для ОС Андроид, но приведённые аспекты распространяются и на другие среды.

В качестве реакции на мой предыдущий пост о защитном программировании, один из моих читателей прислал мне такой вопрос:

[Один] очень известный сценарий защитного программирования встречается, когда входным параметром является

IEnumerable




public class Publisher
{
    public Publisher(IEnumerable<Subscriber> subscribers)
    {
        // defensive copy -> good or bad?
        this.subscribers = subscribers.ToArray();
    }
    //  …
}

Один из моих читателей, Барри Гайлз, недавно написал мне и задал достаточно интересный вопрос, который, по моему мнению, достоен обсуждения:

«Недавно я столкнулся с одной интересной ситуацией на работе: я производил ревью кода и вставил защитные проверки – одну для проверки аргумента конструктора на null, одну для проверки на null значения, возвращаемого из свойства. У меня также имелись утверждения для закрытых методов, которые я использовал для того, чтобы явно указать мои предположения.
«Похоже, что преобладающей практикой среди моих коллег по команде является опускание проверок и допущение падений. Если быть честным, я борюсь с этой концепцией, так как я уже привык разрабатывать посредством защитного программирования и считал это хорошей практикой. Я практически уверен, что дело обстоит так же в большей части руководств и записей в блогах.
«Вы не могли бы дать совет относительно того, почему лучше программировать в защитном стиле, вместо того, чтобы позволить коду провалиться и затем проверять трассировку стека?»

JavaScript, the winning style

Код написанный в одном стиле, имеет много преимуществ: меньше мелких ошибок, многие ошибки легко обнаружить почти сразу, другие же можно легко отладить еще на стадии разработки. Новым же программистам не придется тратить лишнее время на изучение вашего кода (это не значит что им не придется разбираться в самом коде, а значит лишь что его легче будет читать) и им будет проще влиться в проект.

Качество кода станет только лучше, если вся команда будет придерживаться заранее определенного стиля. Это безусловно стоит того, чтобы потрать немного времени на выработку общих правил.

В отличие от Питона у которого есть единый свод правил «Style Guide for Python Code», у языка JavaScript такого нет. Однако на выбор есть целых 6 популярных гайдов:

• Google JavaScript Style Guide
• npm’s coding style
• Felix’s Node.js Style Guide
• Idiomatic JavaScript
• jQuery JavaScript Style Guide
• Douglas Crockford’s JavaScript coding style

Помимо гайдов, не стоит так же забывать об автоматических анализаторах кода, таких, например, как JSLint и JSHint. И в них уже заложены свои настройки. Вопрос в том, какой же все-таки максимально правильный способ писать код на JavaScript, который был бы актуален и максимально соответствовал бы большинству рекомендаций? Давайте попробуем объединить большинство рекомендаций в этой статье и подумаем как можно оптимизировать процесс проверки качества кода.

(Картинка без намека, просто уж очень хотелось котика в статью добавить! Ведь это основной залог популярности в интернетах, правда? :))

У меня очень неоднозначное отношение к книгам Роберта Мартина… В них довольно много здравых и интересных мыслей, но иногда они выражаются столь категорично, что неокрепшим программерским мозгом они могут восприниматься неправильно. Если же мозг читателя достаточно окреп, чтобы воспринимать советы прагматично, то есть все шансы, что ничего нового из этих советов он (мозг или программист) не вынесет.

На хабре каждую неделю загораются споры о том, как должен выглядеть идеальный код, нужно ли его комментировать, как правильно именовать переменные. А что насчет самой высокой формы любого языка — поэзии?

Если грубо считать качество в наработке на отказ, то понятно, что бюджеты под разные критерии разные. Как в айти, так и в нормальном производстве.

Если сковородка может сломаться через полгода, можно взять дешёвую сталь, простое покрытие и китайских рабочих. Если нужен срок жизни в десять лет, то придётся брать хорошие материалы, дорогие технологии и made in Germany.

Если мы можем игнорировать, что от сайта отваливается один пользователь из тысячи, можно быстро сварганить что-то простое. Если потеря одной финансовой транцакции грозит штрафом на полмиллиона, придётся подробно продумывать архитектуру, выбирать надёжные библиотеки и серьёзно заниматься тестированием.

Но при этом «быстро и просто» не значат «плохо».

Если сайт сделан так, что от него отваливается каждый десятый, то мы поимеем головную боль, постоянные авралы и бездонную дыру, куда проваливается бюджет. И хвастаться, сколько сэкономили на быстрой и простой разработке и отсутствии анализа, тоже не получится.

И вот тут я хочу напомнить почему-то забываемый всеми момент.

Авралы, расходы и головную боль мы поимеем только тогда, когда система закрыта. Если она открыта, все эти радости достанутся кому-нибудь другому.

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

Но, увы, всё это великолепие разбивается о суровую действительность и реальные проекты. Если мы говорим о продакшн-проекте, то пользователей не волнует, насколько красив ваш код и насколько хороша архитектура, их волнует, чтобы проект хорошо работал. Но я всё равно считаю, что в любом случае нужно стремиться писать правильно, просто при этом фанатизма быть не должно. После чтения различных холиваров на тему правильных подходов к написанию кода мне в глаза бросилась одна тенденция: каждый пытается применить означенные подходы не в целом к программированию, а только к своему опыту разработки, к своим проектам. Многие не осознают, что хорошие практики — это не абсолютные правила, которые должны строго соблюдаться в 100% сценариев, это лишь советы о том, как следовало бы поступать в большинстве ситуаций. На каждую хорошую практику всегда можно придумать несколько дюжин примеров, в которых она работать не будет. Но это вовсе не означает, что хорошая практика не такая уж и хорошая, просто её применили не к месту.

По-настоящему хороший комментарий — тот,
без которого вам удалось обойтись.
Дядюшка Боб

В последнее время меня стали очень утомлять оживлённые дебаты о том, нужно ли комментировать код. Как правило, по одну сторону баррикад — самоуверенные джуниоры, имеющие непререкаемую позицию вида «А как же его не комментировать, ведь без комментариев непонятно будет!». По другую — умудрённые опытом сеньоры. Они понимают, что если возможно обойтись без комментариев, то «Лучше бы, чёрт возьми, так и сделать!». Наверное, у многих жажда комментировать идёт со студенческой скамьи, когда товарищи преподаватели заставляли комментировать каждую строчку, «чтобы студент лучше разобрался». В реальном проекте не должно быть кучи комментариев, которые только и делают, что засоряют код. Впрочем, я не агитирую вообще не писать комментарии, но если вам удалось написать такой код, который не требует пояснений, то расценивайте это, как свою маленькую победу. Сразу хотелось бы сослаться на нескольких очень умных книжек, на основе которых формировалась моя позиция. Я люблю и уважаю авторов этих работ, полностью разделяя их мнение.

• С. Макконнелл, «Совершенный код. Мастер-класс»
• Р. Мартин, «Чистый код. Создание, анализ и рефакторинг»
• Д. Босуэлл, Т. Фаучер, «Читаемый код, или Программирование как искусство»

Доброго времени суток. Вот и пришло время для публикации второй части так понравившегося многим хабровчанам перевода стайл гайда для языка Python от компании Google, (первая часть бережно хранится хабром). Теперь мы коснемся напрямую форматирования исходного кода на языке программирования Python. Как известно, чистота — залог здоровья, а чистота программного кода — залог уважения коллег и (в идеале) поощрения от кого-нибудь свыше. Вообще, Python сам по себе является хорошо читаемым языком, и даже синтаксис данного языка призывает к порядку в коде (и, как следствие — в голове). Но каждый из нас сам себе документатор и сам себе творец оформления. А как уже говорилось однажды — ко мнению авторитетных товарищей нельзя не прислушиваться. Итак, вторая часть Google Python Style Guide — Python Style Rules ждет Вас под катом. И pdf тут как тут.

Хай, Хабр!
Сегодня я хочу представить, дорогому хабрасообществу свой первый хабраперевод. Программировать на языке Python — подобно песне. Но еще лучше, когда Ваш код читаем и понятен, а значит чуть более поэтичен, чем обычно бывает производстве. У каждого свои правила и свои стереотипы относительно написания и оформления исходного кода, на каком бы языке он ни был написан. Множество копий сломано о щиты на форумах, но, как ни крути, нельзя не считаться с мнением авторитетных товарищей. Так что сейчас будет представлен перевод первой части стайл-гайда для языка Python от Google. Коснется он именно постулатов написания кода (вторая часть тоже скоро появится, а посвящена она будет форматированию исходного кода). Сразу предупреждаю: тут много (если не большая часть) прописных истин, которые все знают уже давно. Но я искренне надеюсь, что Вы сможете найти тут что-то новое или хотя бы вспомнить старое. Приступим под катом. И pdf тут как тут.

Каждый знает, что бывают «десятикратные» программисты, которые в 10 раз более производительны, чем программист обыкновенный. Мы не можем измерить производительность, поэтому и не знаем, правда ли это. Но на самом деле людей необыкновенно производительных существует немало, достаточно, чтобы доказать существование «десятикратного программиста».

Как же они этого добиваются?

Часто считают, что десятикратная производительность вытекает из десятикратных способностей или десятикратных знаний. Я так не думаю. Не хочу сказать, что способности или знания бесполезны. Но за много лет я заметил, что самое главное тут — десятикратная разборчивость. Фокус в том, чтобы постоянно уклоняться от паршивой работенки.

Начало Код с душком
Техника: Составление методов

В продолжении, техника рефакторинга по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.

От переводчика: я сейчас по крупицам собираю литературу по проектированию кросс-платформенного ПО. Этот небольшой текст — самое интересное, что я пока нашёл.

Кодеру для реализации конкретной фичи достаточно гугла, но ведь есть особые требования к проектированию? Скажем, ветвление #ifdef в методах — единственное средство выделения platform-specific частей проекта? (Не много ли макарон?) Есть ли более высокоуровневые подходы, шаблоны, «надстройки» над #ifdef? Надеюсь, этот пост послужит пищей для дальнейшего обсуждения.

Привет, хабр!
С удивлением обнаружил отсутствие на хабре развернутой статьи о сабже, что немедленно сподвигло меня исправить эту вопиющую несправедливость.

В условиях когда клиентская часть веб-приложений становится все более толстой, бизнес-логика неумолимо переползает на клиент, а на суверенитет серверных технологий все более смело посягает node.js нельзя не задуматься о приемах проектирования архитектуры на javaScript. И в этом деле нам несомненно должны помочь паттерны проектирования — шаблонные приемы решения часто встречающихся задач. Паттерны помогают построить архитектуру, которая потребует от вас наименьших усилий при необходимости внести изменения. Но не стоит воспринимать их как панацею, т.е., грубо говоря, если качество кода «не фонтан», он кишит хардкодом и жесткой связью между логически независимыми модулями, то никакие паттерны его не спасут. Но если стоит задача спроектировать масштабируемую архитектуру, то паттерны могут стать хорошим подспорьем.
Но впрочем эта статья не о паттернах проектирования как таковых, а о их применении в javaScript. В первой части этой статьи я напишу о применении порождающих паттернах.

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

Обычно, первое, что человек делает, встретив плохой код — ищет виноватого. Это сразу становится личной или племенной вендеттой:

«Как можно быть таким идиотом?»
«Кто виноват в том, что мой мозг взорвался от всей этой бессвязности и богохульства?»
«Кто оскорбляет <Название Компании>!?»

Это неправильно. Не надо начинать с этого. Прежде, чем найти беднягу-автора кода и обрушить на него свой гнев, лучше поймите сам код.

Начало Код с душком (рефакторинг М. Фаулера) .
В продолжении, техника рефакторинга по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.

Синтаксис будет на C#, но главное понимать идею, а её можно использовать в любом другом языке программирования.

От переводчика. Искал в интернете простой и легко применимый гайдлайн по написанию программ на C++. Мне понравился один из вариантов, и я решил его перевести и опубликовать. Если хабрапользователи хорошо встретят этот топик, могу перевести и другие связанные документы, а также гайдлайны по написанию кода от других компаний.

1 Введение

Настоящий документ содержит рекомендации по написанию программ на языке C++.

Рекомендации основаны на установившихся стандартах, собранных из различных источников, личного опыта, частных требований и потребностей определённых проектов, а также почерпнутых из источников (см. ниже).

Но для появления ещё одного списка рекомендаций, помимо указанных источников, есть несколько причин. Основная причина — их излишняя обобщённость, поскольку зачастую требуется задать частные правила (в особенности правила именования). Данный документ содержит комментарии, что делает его более удобным в использовании при проведении ревизий кода, чем другие уже существующие документы. К тому же, рекомендации по программированию обычно вперемешку содержат описания проблем стиля и технических проблем, что не совсем удобно. Этот документ не содержит каких-либо технических рекомендаций по C++, делая упор на вопросах стиля.

Всем привет.

Небольшая шпаргалка для новичков, и всех остальных кто забыл, по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.

После очередного спора внутри нашей компании решили вынести холивар на хабр.

Собственно, какой из вариантов форматирования кода предпочитаете использовать?

Выравниваю код

foo       = 'bar'
habrahabr = 'Hello, world!'

Не выравниваю код

foo = 'bar'
habrahabr = 'Hello, world!'

В примере фигурирует присваивание значений, но тоже самое относится к ассоциативным массивам, словарям и т.п.