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

• Безопасный вызов метода
• Неиспользуемые переменные
• Превращение в строку
• Запятая в аргументе макроса
• Бесконечный цикл

Заранее предупреждаю: если Вы думаете увидеть под катом что-то крутое, головоломное и сногсшибательное, то ничего такого в статье нет. Статья про светлую сторону макросов.

К добавлению внешнего сервера рано или поздно приходит любой сложный проект. Причины, при этом, бывают совершенно различные. Одни, загружают дополнительные сведения из сети, другие, синхронизируют данные между клиентскими устройствами, третьи- переносят логику выполнения приложения на сторону сервера. Как правило, к последним относятся большинство «деловых» приложений. По мере отхода от парадигмы «песочницы», в которой все действия выполняются только в рамках исходной системы, логика выполнения процессов переплетается, сплетается, завязывается узлами настолько, что становится трудно понять, что является исходной точкой входа в процесс приложения. В этом момент, на первое место выходит уже не функциональные свойства самого приложения, а его архитектура, и, как следствие, возможности к масштабированию.
Заложенный фундамент позволяет либо создать величественный архитектурный ансамбль, либо «накурнож» — избушку на куриных ножках, которая рассыпается от одного толчка «доброго молодца» коих, за время своего существования повидала видимо — невидимо, потому что, глядя на множественные строительные дефекты заказчик склонен менять не исходный проект, а команду строителей.
Планирование — ключ к успеху проекта, но, именно на него выделяется заказчиком минимальный объем времени. Строительные паттерны — туз в рукаве разработчика, который покрывает неблагоприятные комбинации где время — оказывается решающим фактором. Взятые за основу работающие решения позволяют сделать быстрый старт, чтоб перейти к задачам, кажущиеся заказчику наиболее актуальными (как-то покраска дымоходной трубы, на еще не возведенной крыше).
В этой статье я постараюсь изложить принцип построение масштабируемой системы для мобильных устройств, покрывающей 90-95% клиент-серверных приложений, и обеспечивающей максимальное отдаление от сакраментального «накурножа».

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

Дефекты программного кода

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

Белорусские Python’нщики верны своим традициям. Python Meetup состоялся 26 сентября, в последнюю пятницу месяца.
На встрече мы обсуждали извечную головную боль всех программистов – как писать красивый и понятный код без багов. Докладчики подошли к этой проблеме с разных сторон: Павел Кохан рассказал о пяти принципах S.O.L.I.D., которые помогают писать качественный код на любом объектно-ориентированном языке, а Олег Шидловский говорил о том, как ускорить работу хорошего кода.

Недавно в нашем проекте потребовалось настроить мониторинг качества кода. Качество кода — понятие субъективное, однако давным-давно придумали множество метрик, позволяющих провести мало-мальски количественный анализ. К примеру, цикломатическая сложность или индекс поддерживаемости (maintainability index). Измерение подобного рода показателей — обычное дело для языков вроде Java или C++, однако (складывается впечатление) в питоньем сообществе редко когда кто-то об этом задумывается. К счастью, существует замечательный radon с xenon-ом, который быстро и качественно вычисляет упомянутые выше метрики и даже некоторые другие. Конечно, для профессиональных enterprise инструментов маловато, но все необходимое присутствует.

Кроме вычисления метрик, бывает также полезно провести анализ зависимостей. Если в проекте задекларирована архитектура, то между отдельными частями должны существовать определенные связи. Самый частый пример: приложение построено вокруг библиотеки, предоставляющей API, и весьма нежелательно выполнять действия в обход этого API. Другими словами, нехорошо ioctl-ить в ядро когда libc есть. Для питона есть несколько пакетов, строящих граф зависимостей между модулями, и snakefood показался мне самым удачным.

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

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

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

В чём заключается QuickCheck-подход

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

Звучит многообещающе? Вполне.

Опоздал с деплоем на 15 минут

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

Завтра вечером стартуют 45 одинаковых хакатонов за экологию по всему миру. Мы проводим свой российский #hack4good в коворкинге #tceh, потому что круто, праздник и вообще замечательная компания.

Зачем хакатоны – Кирилл Чуваков (наш резидент, участвовал и организовал в over9000 хакатонов)

«Вкратце: первый хакатон мне прям жизнь перевернул – стартапить начал. На каком-то из хакатонов мы сделали прототип проекта, которым занимаемся полгода. Это огромное колличество знакомств. Вообще хакатон это про процесс – тусовка, соревнование, локальные приколы, необычные взгляды на проблемы.»

Сейчас любое крупное приложение состоит из множества сторонних библиотек. Хочется поднять такую тему, как доверие к этим библиотекам. В книгах и статьях можно встретить очень много рассуждений о качестве кода, методах тестирования, методологиях разработки и так далее. Но я не помню, чтобы кто-то рассуждал о качестве кирпичей, из которых строятся приложения. Давайте немного поговорим об этом. Например, есть Medicine Insight Segmentation and Registration Toolkit (ITK). Мне кажется, он написан весьма качественно. По крайней мере, я заметил в коде весьма мало ошибок. Но я не могу сказать, что код используемых библиотек столь же качественен. Тогда вопрос. Насколько мы можем доверять таким системам? Есть повод для размышлений.

На данную статью меня сподвиг следующий пост «Как улучшить свой стиль программирования?» плюс недавний спор среди коллег.

Представьте себе такой диалог:

Админ: Господа, разработчики, ваш код на сервере стал поедать много оперативки. Сервер уже свопиться начинает. Сами понимаете, все может встать колом!
Представитель разработчиков (например, тимлид): Блин, беда. Сейчас займемся проблемой.
Эй, команда, нас тут админы стыдят за неоптимальный код. Нужно срочно все бросить и оптимизировать старый код.
Менеджер проекта: Эй, вы куда? Какая оптимизация? Пусть админы докупят памяти в сервера и проблемы нет. А у вас вон кучу нового функционала нужно разработать. Никакой оптимизации! Сосредоточьтесь на новом функционале. Нам нужно опередить конкурентов с новыми фичами. Потом как-нибудь оптимизируете свой код.

И кто по вашему прав? Что нужно сделать? Сделать апгрейд железа или заняться оптимизацией?
В конце статьи будет голосование.

Исповедь 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 помог в процессе исследования внешней библиотеки»

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

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

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

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