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

Вам когда-нибудь говорили, что вы пишете плохой код? 

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

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

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

Здравствуйте, всем! Хотя это моя первая публикация на Хабре, тему я хочу затронуть важную и далеко не всегда понятную новичкам. Не обращайте внимание на странный заголовок. Считайте, что это – ружье на стене, которое по ходу пьесы обязательно выстрелит.

Материал по этой теме здесь уже имеется, но на мой взгляд, информация там подана не совсем удачно и полно. Рискну внести свою лепту в дело понимания и запоминания такого фундаментального принципа.

В данной статье я постараюсь по максимуму избежать кода. Сделано это в целях повышения универсальности материала, он должен быть интересен всем читателям независимо от их языка программирования. В тех местах, где код неизбежно понадобится, он будет оформлен в синтаксисе Java. Не пугайтесь, все объясню, сложно не будет (во всяком случае, по моим расчетам). Итак, поехали!

Feature-Sliced Design — это архитектурная методология, активно набирающая популярность в последнее время. И не зря: организация разработки по её правилам позволяет упростить процессы, сделать их быстрее и гибче. Больше не нужно будет переживать из-за совместной работы в одном домене и конфликтов кода, долго искать ответ на вопрос «А куда же впилить новую фичу, тут и так намешано…» 

О том, как устроена Feature-sliced Design, чем она отличается от «классической» организации кода, плюсах и минусах от её внедрения — в этой статье.

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

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

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

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

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

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

Всем нам предстоит поддерживать уже существующий код, а также проводить ревью кода коллег.

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

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

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

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

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

Рассмотрим некоторые приемы оптимизации «сверткой» на простейшем примере.

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

Нет-нет, я не собираюсь рассказывать все прибаутки о константах, вроде того, как связано число E и год рождения Льва Толстого. Речь о другом.
Как-то один мой коллега попросил меня «свежим взглядом» посмотреть его программу. Он проводил проверочный расчет, и в итоге должна была получиться единичная матрица. На месте нулевых элементов оказались величины, близкие к нулю – что-то около 10**-17, что можно объяснить погрешностью расчета и исходных данных. Но у трех элементов было значение 10**-7. Вопрос состоял в том, а, собственно, почему так? ведь все формулы «симметричны».

Почему масштабировать вообще сложно?

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

Основная причина тут в том, что как только вы начинаете изменять какую-то большую систему, она начинает разваливаться. Ну, за исключением тех случаев, когда у вас вообще всё на 100% покрыто тестами. Однако, в реальном мире история с покрытием тестами такова, что код современных приложений покрыт (в лучшем случае) примерно на 1%.

Может быть, 100% покрытие тестами — это реальность не только для библиотек, утилит или компиляторов (ведь мы можем формализовать их поведение математически), но и для веб-приложения? Да не, фигня какая-то...

Привет! Меня зовут Сергей, я один из разработчиков продукта «Сервис персонализации» в компании Sportmaster Lab, и в этом посте я расскажу про SonarQube – платформу для непрерывного анализа и измерения качества программного кода, разработанную компанией SonarSource.

Сейчас SonarQube является чем-то вроде отраслевого стандарта. В частности, это стандарт центра компетенций Sportmaster Lab. В своей работе SonarQube использует статический анализ кода: реальное его выполнение не требуется, так как анализируются именно «исходники». Предмет анализа этого инструмента — потенциальные ошибки и уязвимости, стандарты оформления кода, наличие тестов и уровень покрытия ими, а также дублирование кода и его поддерживаемость. SonarQube поддерживает большое количество языков программирования, его можно встраивать в конвейер CI/CD и в вашу среду разработки. А еще — файлы отчетов сторонних инструментов (Eslint, Stylelint, OWASP Dependency Check и многие другие).

В этой статье вы узнаете:

• как работать с SonarQube;

• как он может помочь вам в работе и сделать ваш код лучше.

Эта статья — мой сугубо личный опыт работы с SonarQube в качестве пользователя, поэтому я не буду останавливаться на таких «административных» моментах, как развертывание SonarQube, создание в нем нового проекта и настройка его интеграции с GitLab.

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

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

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

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

Всем привет.

Давно читаю хабр, давно и регулярно читаю статьи про правильное программирование.

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

TLDR: забейте на читабельность и выразительность. Стремитесь сделать ваш код хорошо работающим..

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