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

Исповедь 1

Я — разработчик. От своих работодателей я постоянно слышу, что работаю медленно и часто всё усложняю без веской причины. И что мне пора бы что-то с этим сделать. Во избежание.

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

Приветствую. Поговорим о вертикальном выравнивании кода?

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

Работает это в любом редакторе и с любым текстом. Как-то так:



Сразу забрать приложение можно тут: sourceforge.net/projects/tnice/files
(выделяем текст, жмем Ctrl+Shift+D, пишем символы выравнивания, жмем Ctrl+Enter)
А подробный мануал и принцип работы под катом.

В предыдущей статье «Конструирование типов» была описана идея, как можно сконструировать типы, похожие на классы. Это даёт возможность отделить хранимые данные от метаинформации и сделать акцент на представлении самих свойств сущностей. Однако описанный подход оказывается довольно сложным из-за использования типа HList. В ходе развития этого подхода пришло понимание, что для многих практических задач линейная упорядоченная последовательность свойств, как и полнота набора свойств, не является обязательной. Если ослабить это требование, то конструируемые типы значительно упрощаются и становятся весьма удобны для использования.

В обновлённом варианте библиотеки synapse-frames исключительно просто описываются иерархические структуры данных и представляются любые подмножества таких структур.

Доброго времени суток.

Среди способов повышения читаемости кода, связанных с визуальным восприятием текста, можно выделить следующие:

• Подсветка синтаксиса
• Использование отступов
• Вертикальное выравнивание

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

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

Если вы хоть немного разделяете мои ощущения, то нам есть о чём поговорить. Дело в том, что со временем что-то внутри меня начало подсказывать, что рефакторить всё подряд, везде и всё время — не самая лучшая идея. Поймите меня правильно, код должен быть хорошим (а лучше бы ему быть идеальным), но в условиях суровой реальности не всегда разумно постоянно заниматься улучшением кода. Я вывел для себя несколько правил о своевременности рефакторинга. Если у меня начинают чесаться руки что-нибудь улучшить, то я оглядываюсь на эти правила и начинаю думать: «А действительно ли сейчас тот момент, когда нужно нарефакторить?». Давайте порассуждаем о том, в каких же случаях рефакторинг уместен, а в каких — не очень.

Много статей написано о том, как правильно реализовывать на Java шаблон проектирования Singleton.

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

Лично я считаю единственным корректным способом реализации синглтона на Java так называемый Synchronized Accessor:

public class Singleton {
    private static Singleton instance;
    
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

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

Однако, пытаясь освежить в памяти возможности Java concurrency, я почитал старые статьи о вариантах синглтонов и удивился, что не нахожу описания еще одного способа, который я называю Function Pointer.

Довольно давно я делился проблемой тестирования кода в финализаторе и недавно жаловался на падение теста (Как тестировать код финализатора (c#) и Как тестировать код финализатора (c#). Послесловие: тест все-таки упал).
В ходе обсуждения комрадом withkittens была высказана идея:

Финализатор (при правильной реализации IDisposable pattern) должен (should) вызывать Dispose(false). Этот факт можно тестировать статическим анализом. Соответственно, если Dispose(false) вызывает удаление файла (вы же написали тест?), то можно быть уверенным, что и финализатор тоже вызовет удаление файла, unit-тест излишен.

Мне эта идея показалась очень здравой, кроме того, иногда хочется контролировать исходный код более кастомно, чем дает встроенный анализ кода или решарпер.
Опыт реализации кастомных правил анализа кода под катом + «как ozcode помог в процессе исследования внешней библиотеки»

Избавляемся от недостатков классического ООП и пишем на С++ в модульном стиле.

Я изучил множество ошибок, возникающих в результате копирования кода. И утверждаю, что чаще всего ошибки допускают в последнем фрагменте однотипного кода. Ранее я не встречал в книгах описания этого феномена, поэтому и решил о нём написать. Я назвал его «эффектом последней строки».

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

Ладно. Введение это очень весело, но вы его все равно не читаете, так что кому интересно — добро пожаловать под кат!

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

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

При построении многослойных («enterprise») систем часто оказывается, что создаются ValueObject'ы (или case class'ы), в которых хранится информация о каком-либо экземпляре сущности, обрабатываемом системой. Например, класс

case class Person(name: String, address: Address)

Такой способ представления данных в системе обладает как положительными свойствами:

• строго типизированный доступ к данным,
• возможность привязки метаинформации к свойствам с помощью аннотаций,

так и некоторыми недостатками:

• если сущностей много, то таких классов также становится довольно много, а их обработка требует много однотипного кода (copy-paste);
• потребности отдельных слоёв системы в метаинформации могут быть представлены аннотациями к свойствам этого объекта, но возможности аннотаций ограничены и требуют использования reflection'а;
• если требуется представить данные не обо всех свойствах объекта сразу, то созданные классы использовать затруднительно;
• затруднительно также представить изменение значения свойства (delta).

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

• возможность описывать отдельные свойства сущностей (с указанием типа данных в этом свойстве и любой метаинформации, необходимой приложению, в форме, подходящей именно для этого приложения);
• возможность оперировать со свойствами экземпляров строго типизированным образом (с проверкой типов на этапе компиляции);
• представлять частичную/неполную информацию о значениях свойств экземпляра сущности, пользуясь объявленными свойствами;
• создавать тип объекта, содержащего частичную информацию о свойствах экземпляра сущности. И использовать этот тип наравне с другими типами (классами, примитивными типами и др.).

Сколько было сломано копий при обсуждении вопроса «Возможно ли сделать eval безопасным?» — невозможно сосчитать. Всегда находится кто-то, кто утверждает, что нашёл способ оградиться от всех возможных последствий выполнения этой функции.
Когда мне понадобилось найти развёрнутый ответ на этот вопрос, я наткнулся на один пост. Меня приятно удивила глубина исследования, так что я решил, что это стоит перевести.

Коротко о проблеме

В Python есть встроенная функция eval(), которая выполняет строку с кодом и возвращает результат выполнения:

assert eval("2 + 3 * len('hello')") == 17

Это очень мощная, но в то же время и очень опасная инструкция, особенно если строки, которые вы передаёте в eval, получены не из доверенного источника. Что будет, если строкой, которую мы решим скормить eval'у, окажется os.system('rm -rf /')? Интерпретатор честно запустит процесс удаления всех данных с компьютера, и хорошо ещё, если он будет выполняться от имени наименее привилегированного пользователя (в последующих примерах я буду использовать clear (cls, если вы используете Windows) вместо rm -rf /, чтобы никто из читателей случайно не выстрелил себе в ногу).

“А что это вы тут делаете?”

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

<div data-role="header">
    <a href="#" class="ui-btn-left ui-btn ui-btn-inline ui-mini ui-corner-all ui-btn-icon-left ui-icon-delete">Cancel</a>
<h1>My App</h1>
    <button class="ui-btn-right ui-btn ui-btn-b ui-btn-inline ui-mini ui-corner-all ui-btn-icon-right ui-icon-check">Save
</button></div>

Этот пример создает кнопки Cancel и Save. Для поклонников фреймворков, например, популярного в последние пару лет Bootstrap, данный код выглядит нормально. Для меня же это выглядит адом и вот почему.

EditorConfig это конфигурационный файл и набор расширений, к большому количеству редакторов кода и IDE (Далее просто IDE).

Его задача — создать единый формат настроек, и, раз и навсегда, решить вопросы вроде “табы или пробелы” для всех IDE и всех языков программирования. Такой файл может храниться в системе контроля версий проекта, что позволит всем его разработчикам использовать одну и ту же конфигурацию.

Файлы .editorconfig можно найти в таких проектах, как jQuery, Ruby, WordPress, и многих других.

Плагины доступны для большого количество IDE




Давайте разберемся, как это работает.

Не так давно, я заинтересовался трудами идеологов программирования, таких как Кент Бэк, Роберт Мартин, Мартин Фаулер, Пол Дюваль.

Их книги произвели на меня впечатление и воодушивили попробовать некоторые описанные практики. Refactoring, TDD, XP, и, наконец, Continuous Integration, это то, что в последнее время интересует меня в процессе разработки программного обеспечения.

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

Теория

Continuous Integration (далее CI) — это практика разработки программного обеспечения, в которой члены команды проводят интеграцию не реже чем раз в день. Результаты интеграции проверяются автоматически, используя автотесты и статический анализ кода.

Использование CI позволяет вовремя отслеживать ошибки интеграции, сделать систему и процесс разработки более «прозрачными» для всех участников команды, также, CI избавляет от рутинных операция по сборке продукта, повышает качество продукта, включает в себя профит от написания тестов, который, я думаю, для всех хаброюзеров очевиден.

Фактически, CI позволяет избавиться от предположений, при процессе разработки ПО. Менеджер предполагает, что продукт готов и стабилен, программист — что в коде нет ошибок и т. д. Избавиться от вопросов, таких как: «стабильна ли последняя сборка, какие фичи готовы, соответствует ли код стандартам компании» и т.д.

Всех, кому интересна тема CI прошу под кат.

От переводчика: Это перевод статьи авторства Джоэля Спольски (Joel Spolsky). Через 2 года эта статья уже сможет получить автомобильные права в США, а еще через два — и не только там. Да, ей 14 лет (а точнее 14 лет и 11 дней), но актуальности она не потеряла ни грамма. Я регулярно вижу, как программисты (да и я сам, временами) порываются наступить на эти грабли. Тот факт, что я не нашел ее перевода на Хабре, вполне может свидетельствовать о том, что я плохо искал. Об ошибках перевода прошу сообщать в ЛС

UPD: Оказывается перевод статей Джоэля, в т. ч и этой, есть еще в бумажном издании «Джоэл о программировании»

Наконец выходит первая публичная бета-версия Netscape 6.0. Версии 5.0 не существует. Предыдущий мажорный релиз — версия 4.0 — был выпущен почти три года назад. Три года — это невероятно большой срок в мире интернета. Все это время в Netscape сидели и беспомощно наблюдали за тем, как уменьшается их доля рынка.

Это немного подло с моей стороны критиковать их за столь долгое ожидание между релизами. Они ведь не специально это сделали, правда?

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

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

27 февраля в Стэнфорде состоялся второй по счету конкурс поэтов, пишущих стихи на различных языках программирования — Code Poetry Slam 1.1. В отличии от стихотворений, упоминавшихся в прошлой заметке, конкурс не зацикливается на стихах в общепринятом смысле этого слова, во главу угла ставится само выступление автора, то, как он преподносит свою историю.

Добрый день, хабражители! Обнаружил, что на сайте нет статьи о том, как можно организовать процесс создания документации для Ruby on Rails проектов. Исправим эту проблему.

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