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

Здравствуйте!
Продолжаю серию публикаций по учебному Java Enterprise проекту Topjava (Maven/Spring/Security/JPA(Hibernate)/Rest(Jackson)/ Bootstrap(CSS)/ jQuery+plugin).

Небольшая тема четвертого занятия: улучшаем качество кода

Полезные ссылки:

1. Контрактное программирование, Программирование по контракту
2. Comparison Preconditions in Java
3. QAPlug vs FindBugs
4. QAPlug tutorials
5. Codacy Home

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

Как правило, язык C++ используют там, где требуется высокая скорость работы. Но на C++ без особых усилий можно получить код, работающий медленнее какого-нибудь Python/Ruby. Именно подобным кодом оперируют многочисленные сравнения Any-Lang vs C++.

Вообще, оптимизация бывает трех типов:

1. Оптимизация уже готового, проверенного и работающего кода.
2. Изначально написание оптимального кода.
3. Просто использование оптимальных конструкций.

Специально заниматься оптимизацией готового кода следует только после того, как проект закончен и используется. Как правило, оптимизация потребуется только в небольшой части проекта. Поэтому сначала нужно найти места в коде, которые съедают большую часть процессорного времени. Ведь какой смысл ускорять код, пусть даже на 500%, если он отнимает только 1% машинного времени? И следует помнить, что, как правило, гораздо больший выигрыш в скорости дает оптимизация самих алгоритмов, а не кода. Именно про данный ее вид говорят: «преждевременная оптимизация — зло» (с).

Второй тип оптимизации — это изначальное проектирование кода с учетом требований к производительности. Такое проектирование не является ранней оптимизацией.

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

Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик.
Информация — основа любого приложения или сервиса.



Более 10 лет назад я общался с владельцем покер-рума, и он показал мне страницу, приносившую около 10 000$ в день. Это была совершенно банально оформленная страница. На ней не было ни стилей, ни графики. Сплошной текст, разбитый заголовками, секциями и ссылками. У меня просто не укладывалось в голове — ну как вот это может приносить такие деньги?

Секрет в том, что «вот это» было одним из первых исчерпывающих руководств по игре в покер онлайн. У страницы был PageRank 10/10 (или 9, не суть), и в поисковой выдаче это было первое, на что натыкались.

Цель вашего приложения, какое бы оно ни было — донести (получить, обработать) некоторую информацию до пользователя.





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

Так вот: чем бы вы ни занимались, первичной всегда будет информация. Хорошую, качественную информацию пользователи обязательно найдут и обратятся к вам.

Я расскажу, как организовать работу с информацией так, чтобы это было:
1. Масштабируемо — репликация, шардирование и т.п. настраивается БЕЗ вмешательства в работу приложения.
2. Удобно для пользователей — легко документировать, понятно как использовать.
3. Удобно для ваших разработчиков — быстрое прототипирование, возможности оптимизации только необходимого.

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

Дорогой разработчик!

Я давно хочу с тобой поговорить, но слова не всегда даются легко. Мы отлично проводили время вместе. Я всё ещё помню первый раз, когда я предупредил тебя о мелкой ошибке в коде, и как же ты был рад тому, что я есть в твоей жизни! Ты это помнишь? Ещё я помню, как ты впервые рефакторил меня, чтобы сделать меня более эффективным, и как хорошо написанным я чувствовал себя после этого… ах, замечательные времена!

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

Но потом я стал необъяснимо падать время от времени, безо всякой видимой причины. Что-то немного сломалось во мне. Я продолжал функционировать почти нормально, но ничего не мог поделать с тем, что иногда становился причиной красных сборок, это было просто не в моей власти. Я стал… нестабильным. Моя нестабильность расстроила тебя, и я не злюсь на тебя за это, поскольку меня она тоже расстроила. Я перестал быть надёжным. Я утратил свой смысл. Я должен сказать, что сейчас мне горько вспоминается твоя реакция после нескольких недель моей нестабильности: вместо того, чтобы вложить чуточку любви и потратить пару часов на то, чтобы исправить меня и привести в хорошее состояние, ты пометил меня как @ignore и бросил в огромной пустынной куче кода.

Захотелось мне объективных критериев качества кода и конечно я вспомнил про свои давние наработки (коллекцию нефункциональных тестов, см. тут и тут).
Ещё тогда была идея оформить их не в виде коллекции тестов, а в виде отдельной утилиты, но удалось сделать только теперь, встречаем perlqual (от perl quality).

Всем привет!

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

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

Заранее отвечу на вопрос: мой pull request был принят.

Если кто-то «борется» с программированием или же просто изучает что-то сложное, этот пост может дать ему некого рода надежду.

Я обучался компьютерным наукам и могу программировать на нескольких языках, так почему же, когда люди говорят мне, что я классный разработчик, у меня ощущение, что они неправы? Обычно я отвечаю что-то вроде:

«Я не классный, я просто сижу за этим занятием чуть дольше… вы можете делать так же.»

При решении задач комбинаторики часто возникает необходимость в расчете биномиальных коэффициентов. Бином Ньютона, т.е. разложение также использует биномиальные коэффициенты. Для их расчета можно использовать формулу, выражающую биномиальный коэффициент через факториалы: или использовать рекуррентную формулу: Из бинома Ньютона и рекуррентной формулы ясно, что биномиальные коэффициенты — целые числа.

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

Наличие большого числа библиотек, реализующих Фурье преобразований (во всевозможных вариантах быстрых версий), делает реализацию алгоритмов не очень сложной задачей для программирования.
Реализованные алгоритмы являются частью библиотеки с открытым исходным кодом FFTTools. Интернет-адрес: github.com/dprotopopov/FFTTools

Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик. Я расскажу, как сделать так, чтобы ваш сайт открывался быстро. Очень быстро.

Вашему вниманию предлагается перевод поста о том, как разрабатывался Windows Azure API: о трудностях, удачных и неудачных решениях, сделанных выводах. Далее — текст автора.

После разговора с моим коллегой по работе о REST API мне пришла в голову идея рассказать о своем опыте организации и работы команды, которая создала Windows Azure Service Management API. На написание этого поста меня вдохновили такие великолепные статьи в жанре “чему я научился” как эта за авторством Foursquare и эта от Даниэля Джакобса из Netflix.

Предупреждение: Все рассказанное под катом — мое личное мнение. Я даже не уверен, что остальные участники команды со мной согласны. И я точно знаю, что некоторые из высказанных мыслей довольно противоречивы.

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

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

Мы продолжаем рассказывать интересные зарисовки из жизни колл-центров, телекомов и облачной телефонии. Случалось ли вам отвечать на звонок и слышать “пожалуйста подождите, оператор сейчас свяжется с вами”? Первая мысль, которая приходит в голову обычно нецензурна, вторая — “они что, вконец обнаглели?!?”. Получивший такой звонок пользователь — жертва хитрой технологии “предиктивного обзвона”, которая позволяет колл-центрам экономить сотни часов времени, но иногда приводит к забавным результатам. Под катом я расскажу про эту штуку подробнее и покажу, как она может быть реализована в несколько строк кода на нашей облачной платформе voximplant

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

Итак, первое моё знакомство с языками программирования состоялось в школе, и был это Бэйсик. С тех пор с языками программирования я не пересекался. Прошло больше 20 лет и мне понадобилось изучить один из современных языков программирования. Всем критериям предъявляемым мной языку программирования, которые я смог сформулировать на тот момент, полностью удовлетворял C#. Засучив рукава, я принялся его изучать и у меня появилась возможность оценить насколько изменились языки программирования за это время.

Многое было привычно, если не по внешнему виду, то по концепции: переменные, циклы, операторы ветвления… А что-то было совсем новым: ООП с его классами (полями, методами, свойствами), наследованием и т. д.
Конечно, многое порадовало. Классы теперь позволяют заниматься распределением обязанностей: Так, ты мне принеси «то»; Ты сделай «это»; Ты посчитай мне «это», результат сообщишь. Это очень напоминает наше взаимодействие с окружающей средой. Например, зашли в прачечную, отдали грязное постельное бельё, забрали чистое. Зашли в ателье, отдали ушить брюки, забрали готовый вариант. Зашли в закусочную, сделали заказ, получили завтрак. Очень удобно и наглядно.
Но вернёмся с теме статьи. Я никак не ожидал спустя 20 лет увидеть в языках программирования некоторые вещи:

Представляю вашему вниманию перевод документа "Coding Guidelines for C# 3.0, 4.0 and 5.0".

Целью создания этого списка правил является попытка установить стандарты написания кода на C#, которые были бы удобными и практичными одновременно. Само собой, мы практикуем то, что создали. Эти правила являются одним из тех стандартов, которые лежат в основе нашей ежедневной работы в AvivaSolutions. Не все эти правила имеют четкое обоснование. Некоторые из них просто приняты у нас в качестве стандартов.

Статический анализатор кода VisualStudio (который также известен как FxComp) и StyleCop могут автоматически применять многие из правил кодирования и оформления путем анализа скомпилированных сборок. Вы можете сконфигурировать их таким образом, чтобы анализ производился во время компиляции или был неотъемлемой частью непрерывной или ежедневной сборки. Этот документ просто добавляет дополнительные правила и рекомендации, но его вспомогательный сайт www.csharpcodingguidelines.com предоставляет список правил анализа кода, необходимых в зависимости от того, с какой базой кода вы работаете.

Здравствуйте уважаемые обитатели Хабра. Написать это меня сподвигла статья Программисты не понимают. Это будет крик души одинокого начинающего веб-перфекциониста в уши большинства существующих веб-студий и веб-девелоперов.

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

Владимир Мегре



Статья посвящается Зацепину П.М., выдающемуся инженеру Алтайского государственного университета, под чьим чутким руководством многие студенты, включая автора статьи, постигали магию инженерного творчества.

Введение

Спор о возможности использования в программах оператора GOTO ведётся уже очень давно (официальным его началом признана статья Дейкстры «О вреде оператора GOTO», опубликованная в 1968 году [2]). Через три года мы будем праздновать 50-летний юбилей этого спора. Это хороший повод, чтобы наконец-то «расставить все точки над i» и прекратить спор.

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

Давайте займём в этом споре нейтральную сторону, и беспристрастно во всём разберёмся. Рассмотрим доводы «противников» и «защитников» оператора GOTO и решим, «кто из них прав, а кто виноват».

Привет хабр! Основная речь пойдет про разработку на .Net, то есть с использованием Microsoft Visual Studio, ReSharper, Nuget и пр.
Я думаю, многие из вас разрабатывали большие решения (в msdn — solution), со множеством подпроектов. И в этом случае нередко становилась проблема синхронизации Nuget пакетов, настроек сборки и т.д. Причем, ReSharper здесь поможет слабо, разве что он тоже начнет путаться во множестве используемых библиотек.
Чтобы проверять исходный код, было сделано Open Source решение — SolutionCop, которое бесплатно для использования.
Для начала приведу парочку примеров, когда не помешали бы проверки наших решений.

Пример 1: разные версии Nuget библиотек.

Например, есть три проекта: exe, dll1 и dll2. exe ссылается на обе библиотеки, каждая из них ссылается, например, на RX. Но dll1 использует RX 2.2.0, а dll2 — RX 2.2.5. На деле, далеко не сразу можно получить ошибку, так как сигнатуры функций более-менее совпадают, более того, MsBuild чаще всего собирает проекты в одном и то же порядке. Однако подобная конфигурация может привести к проблемам, которые появятся после deployment'а, когда все модульные тесты пройдут (т.к. они ссылаются только на свою библиотеку), и когда будет готовиться результирующий набор файлов.

Пример 2: проект ссылается на библиотеку напрямую, а не через Nuget.

Опять возьмем три наших проекта: exe, dll1 и dll2. Допустим, мы также используем еще Jetbrains.Annotations, чтобы размечать код NotNull/CanBeNull аттрибутами и получать симпатичный статический анализ. Но вот незадача: для dll1 мы честно скачали пакет версии 9.2.0, а в dll2 мы просто попросили ReSharper добавить ссылку, что он и сделал. В итоге, в packages.config файле dll2 нет пакета с аттрибутами, а значит, если проект будет собираться в порядке dll2 --> dll1 --> exe, то мы получим ошибку, ведь Nuget пакет скачается только при сборе dll1!

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

В комментариях к нашему первому посту на Хабре пользователи активно обсуждали каналы восприятия информации. Мы подумали и решили, что тему «совершенного кода» стоит развить и изложить ещё и письменно — ведь базовые принципы хорошего кода едины для программистов, пишущих на любом языке.

Разработка Parallels Access потребовала создания геораспределенного сервиса, позволяющего безопасно устанавливать связь между компьютерами и мобильными клиентами пользователей в различных точках земного шара. Команда, которая над ним трудится, хочет поделиться полученным опытом в форме цитат, чтобы облегчить участь тем, кто только планирует создание своего клиент/серверного продукта, и погрузить в ностальгию профессионалов, имеющих за спиной дюжину успешных проектов:

Эпичный эпиграф:
«Паттернов можешь ты не знать,
но управленье знать обязан!»

«Большое видится на расстояньи»

Кто знаком с теорией Геделя о неопределенности (которая получила не совсем точное название «о неполноте»), тот понимает: все (достаточно) сложные системы испытывают принципиальные трудности в самопознании и самоописании на определенном уровне глубины и детальности. Сразу уточню: я НЕ утверждаю, что между теорией вышеупомянутого Г. и “вечными” (именно в кавычках!) проблемами ООП имеется прямая связь, нет. Но я, тем не менее, утверждаю, что проблемы «совершенного кода» – объективно не разрешимы. Не вообще никогда, а ровно до того момента, пока мы наконец-то не выйдем за пределы самого ООП – и не посмотрим на него с высоты еще более сложной системы. «Большое ведь видится на расстояньи»!