К добавлению внешнего сервера рано или поздно приходит любой сложный проект. Причины, при этом, бывают совершенно различные. Одни, загружают дополнительные сведения из сети, другие, синхронизируют данные между клиентскими устройствами, третьи- переносят логику выполнения приложения на сторону сервера. Как правило, к последним относятся большинство «деловых» приложений. По мере отхода от парадигмы «песочницы», в которой все действия выполняются только в рамках исходной системы, логика выполнения процессов переплетается, сплетается, завязывается узлами настолько, что становится трудно понять, что является исходной точкой входа в процесс приложения. В этом момент, на первое место выходит уже не функциональные свойства самого приложения, а его архитектура, и, как следствие, возможности к масштабированию.
Заложенный фундамент позволяет либо создать величественный архитектурный ансамбль, либо «накурнож» — избушку на куриных ножках, которая рассыпается от одного толчка «доброго молодца» коих, за время своего существования повидала видимо — невидимо, потому что, глядя на множественные строительные дефекты заказчик склонен менять не исходный проект, а команду строителей.
Планирование — ключ к успеху проекта, но, именно на него выделяется заказчиком минимальный объем времени. Строительные паттерны — туз в рукаве разработчика, который покрывает неблагоприятные комбинации где время — оказывается решающим фактором. Взятые за основу работающие решения позволяют сделать быстрый старт, чтоб перейти к задачам, кажущиеся заказчику наиболее актуальными (как-то покраска дымоходной трубы, на еще не возведенной крыше).
В этой статье я постараюсь изложить принцип построение масштабируемой системы для мобильных устройств, покрывающей 90-95% клиент-серверных приложений, и обеспечивающей максимальное отдаление от сакраментального «накурножа».
Читать полностью »
Рубрика «Совершенный код» - 45
Архитектура мобильного клиент-серверного приложения
2014-12-26 в 18:18, admin, рубрики: ios development, iOS разработка, mobile development, архитектура приложений, Программирование, Проектирование и рефакторинг, разработка под iOS, Совершенный кодПрактические советы для эффективного инспектирования кода. Часть 2
2014-10-27 в 16:48, admin, рубрики: code review, инспектирование кода, Программирование, разработка, Совершенный код Первая часть практических советов для эффективного инспектирования кода была написана более двух лет назад, но актуальность не потеряла. В данной статье содержатся ещё несколько советов, которые позволяют повысить эффективность этой сложной и ответственной практики. Если коротко, то инспекции надо проводить быстро, рассказывать о них, визуализировать и не пытаться объять необъятное.
Читать полностью »
Python Meetup 26.09.14: cовершенствуем код и ускоряем Python
2014-10-22 в 13:47, admin, рубрики: meetup, python, s.o.l.i.d., анонс, Блог компании Wargaming, минск, Совершенный код Белорусские Python’нщики верны своим традициям. Python Meetup состоялся 26 сентября, в последнюю пятницу месяца.
На встрече мы обсуждали извечную головную боль всех программистов – как писать красивый и понятный код без багов. Докладчики подошли к этой проблеме с разных сторон: Павел Кохан рассказал о пяти принципах S.O.L.I.D., которые помогают писать качественный код на любом объектно-ориентированном языке, а Олег Шидловский говорил о том, как ускорить работу хорошего кода.
Визуализация клонов в проекте на Python
2014-10-21 в 15:36, admin, рубрики: clonedigger, matplotlib, python, radon, scipy, snakefood, кластерный анализ, копипастинг, Совершенный код 
Недавно в нашем проекте потребовалось настроить мониторинг качества кода. Качество кода — понятие субъективное, однако давным-давно придумали множество метрик, позволяющих провести мало-мальски количественный анализ. К примеру, цикломатическая сложность или индекс поддерживаемости (maintainability index). Измерение подобного рода показателей — обычное дело для языков вроде Java или C++, однако (складывается впечатление) в питоньем сообществе редко когда кто-то об этом задумывается. К счастью, существует замечательный radon с xenon-ом, который быстро и качественно вычисляет упомянутые выше метрики и даже некоторые другие. Конечно, для профессиональных enterprise инструментов маловато, но все необходимое присутствует.
Кроме вычисления метрик, бывает также полезно провести анализ зависимостей. Если в проекте задекларирована архитектура, то между отдельными частями должны существовать определенные связи. Самый частый пример: приложение построено вокруг библиотеки, предоставляющей API, и весьма нежелательно выполнять действия в обход этого API. Другими словами, нехорошо ioctl-ить в ядро когда libc есть. Для питона есть несколько пакетов, строящих граф зависимостей между модулями, и snakefood показался мне самым удачным.
Помимо анализа зависимостей, не менее полезно определять копипасту, особенно, если в проекте задействованы джуниоры или другие люди, любящие «срезать углы болгаркой». Об этом собственно и пойдет речь в статье.
Читать полностью »
Старая псина учит новые трюки: Code Kata с использованием QuickCheck
2014-10-18 в 14:24, admin, рубрики: java, junit, kata, quickcheck, tdd, Совершенный кодКогда я агитирую коллег-программистов создавать больше различных автотестов на их код, они часто жалуются, что это сложная и унылая работа. И в чём-то они правы. При использовании классических юнит-тестов, действительно, нередко приходится писать уйму кода, чтобы проверить каждый отдельный случай поведения. Да и к качеству тестирования порой возникают вопросы, особенно в сложных системах, когда тривиальные сценарии использования проходят на ура, но на каких-то более сложных сценариях, на которые никто не подумал писать тесты, возникают неприятные проблемы.
Я уже давно слышал про способ тестирования, который используется в QuickCheck, но всё никак не хватало финального толчка, чтобы им заняться вплотную. Этим толчком стала эта презентация от Джона Хьюза, автора этой замечательной библиотеки.
В чём заключается QuickCheck-подход
Описать суть подхода можно довольно просто: мы не создаём тесты-примеры, а вместо этого задаём правила, которые определяют поведение системы на произвольных входных данных. Библиотека сама генерирует большое количество случайных входных данных и проверяет, соответствует ли поведение кода установленным правилам. Если это не так, то она показывает нам, на каком примере происходит падение теста.
Звучит многообещающе? Вполне.
Как ходить на хакатоны, если у вас проблемы с алкоголем, лишним весом, общением и, вообще, если вы айтишник
2014-09-11 в 5:55, admin, рубрики: Блог компании #tceh, Карьера в IT-индустрии, коворкинг, пиши код, Совершенный код, хакатон 
Опоздал с деплоем на 15 минут
Кто не знает, хакатон – это офигенный способ поработать ещё и на выходных. Только один 48-часовой день, только работа, один проект и один результат, море нового опыта и куча новых связей, плюс знания-знания-знания.
Завтра вечером стартуют 45 одинаковых хакатонов за экологию по всему миру. Мы проводим свой российский #hack4good в коворкинге #tceh, потому что круто, праздник и вообще замечательная компания.
Зачем хакатоны – Кирилл Чуваков (наш резидент, участвовал и организовал в over9000 хакатонов)
«Вкратце: первый хакатон мне прям жизнь перевернул – стартапить начал. На каком-то из хакатонов мы сделали прототип проекта, которым занимаемся полгода. Это огромное колличество знакомств. Вообще хакатон это про процесс – тусовка, соревнование, локальные приколы, необычные взгляды на проблемы.»
Можем ли мы доверять используемым библиотекам?
2014-08-11 в 6:14, admin, рубрики: c++, ITK, pvs-studio, static code analysis, Блог компании PVS-Studio, качество кода, Си, Совершенный код, статический анализ кода 
Сейчас любое крупное приложение состоит из множества сторонних библиотек. Хочется поднять такую тему, как доверие к этим библиотекам. В книгах и статьях можно встретить очень много рассуждений о качестве кода, методах тестирования, методологиях разработки и так далее. Но я не помню, чтобы кто-то рассуждал о качестве кирпичей, из которых строятся приложения. Давайте немного поговорим об этом. Например, есть Medicine Insight Segmentation and Registration Toolkit (ITK). Мне кажется, он написан весьма качественно. По крайней мере, я заметил в коде весьма мало шибок. Но я не могу сказать, что код используемых библиотек столь же качественен. Тогда вопрос. Насколько мы можем доверять таким системам? Есть повод для размышлений.
Читать полностью »
Что дешевле: новое железо или труд разработчиков?
2014-08-04 в 19:30, admin, рубрики: менеджмент проектов, Программирование, программисты, Совершенный код, управление проектами На данную статью меня сподвиг следующий пост “Как улучшить свой стиль программирования?” плюс недавний спор среди коллег.
Представьте себе такой диалог:
Админ: Господа, разработчики, ваш код на сервере стал поедать много оперативки. Сервер уже свопиться начинает. Сами понимаете, все может встать колом!
Представитель разработчиков (например, тимлид): Блин, беда. Сейчас займемся проблемой.
Эй, команда, нас тут админы стыдят за неоптимальный код. Нужно срочно все бросить и оптимизировать старый код.
Менеджер проекта: Эй, вы куда? Какая оптимизация? Пусть админы докупят памяти в сервера и проблемы нет. А у вас вон кучу нового функционала нужно разработать. Никакой оптимизации! Сосредоточьтесь на новом функционале. Нам нужно опередить конкурентов с новыми фичами. Потом как-нибудь оптимизируете свой код.
И кто по вашему прав? Что нужно сделать? Сделать апгрейд железа или заняться оптимизацией?
В конце статьи будет голосование.
Читать полностью »
Будь мужиком, пиши хороший код, б***ть
2014-07-23 в 5:54, admin, рубрики: Программирование, разработка, Совершенный код 
Как вы знаете производительности хорошего программиста и плохого отличается в 28 раз. Чтобы стать хорошим программистом нужно как минимум следовать указанным ниже пунктам.
Читать полностью »
Как улучшить свой стиль программирования?
2014-07-22 в 9:13, admin, рубрики: как не надо делать, Программирование, программисты, разработка, Совершенный кодИсповедь 1
Я — разработчик. От своих работодателей я постоянно слышу, что работаю медленно и часто всё усложняю без веской причины. И что мне пора бы что-то с этим сделать. Во избежание.
Весь мой опыт программирования складывается из университетских работ и пары лет пребывания в различных компаниях. Критикующие меня люди неоднократно говорили мне, что в целом я разбираюсь в теме, так что я далеко не клинический случай, как можно было подумать. Однако, очевидно, я выработал совсем не те программистские привычки (как минимум, на взгляд работодателя) и мне нужно срочно изменить их. Везде, где бы я ни работал, мои решения, использующие иерархии мелких классов с делегированием поведения, признавались плохими. Говорят, будто так и надо писать, но это не так. Потому что всё это «как надо» может стоить мне работы.
Читать полностью »