Вероятно, в любой команде рано или поздно возникает вопрос создания и утверждения стандартов кодирования. На первый взгляд, задача вполне тривиальная. Но лишь в том случае, когда решается на раннем этапе развития проекта. Тогда разработчикам необходимо лишь выбрать и применить один из популярных стандартов, и чаще всего этот выбор за них делает фреймворк, который они используют.
В нашем случае всё не так просто. Проект, над которым мы работаем, начал свою жизнь ещё до того, как различным стандартам и описаниям лучших практик в среде разработки стали уделять большое внимание. В том числе, задолго до появления столь популярных ныне PSR стандартов для PHP. По этим причинам задача стандартизации кода не ставилась на более ранних этапах, а теперь – предстала нашей команде в качестве вызова.
В этой публикации мы расскажем о том, как пришли к пониманию необходимости единого code style, и выработали методы его постепенного внедрения в масштабный проект. Этот опыт может быть интересен тем, кто пока не использует стандартизацию, но уже ощущает в этом потребность.
PVS-Studio supports analyzing projects developed in C, C++, C#, and Java. You can use the analyzer under Windows, Linux, and macOS. This small article will tell you the basics of analyzing C and C++ code in Linux environment.PVS-Studio поддерживает анализ проектов на языках C, C++, C# и Java. Использовать анализатор можно под системами Windows, Linux и macOS. В этой заметке речь пойдет об анализе кода, написанного на C и C++ в среде Linux.
SonarQube — отличный инструмент для внедрения статического анализа кода в процесс разработки ПО. Он поддерживает как используемую у нас в компании Java, так и большое количество других языков программирования.
На данный момент этот инструмент плотно вошёл в нашу жизнь, следя за единым стилем кода и уберегая от самых разных видов ошибок. Поиск ошибок происходит при сборке на CI или перед принятием pull request в версионное хранилище. Все найденные ошибки отображаются в Web-интерфейсе, где можно изучать их и управлять ими.
Однако беда в том, что удобный Web-интерфейс не означает удобство по устранению найденных замечаний в коде проекта. Для того, чтобы внести исправление, приходится сначала смотреть, в каком именно файле это замечание обнаружено, потом открывать этот файл и только затем вносить исправление. Также это приводит к тому, что разработчик узнает о проблеме с очень большим отставанием (иногда анализ в SonarQube может занимать десятки минут), что не способствует поддержанию чистоты кода.
Для того, чтобы облегчить жизнь разработчикам нашей компании, использующим IntelliJ IDEA, я составил инструкцию. А в дальнейшем понял, что она может быть полезной более широкому кругу специалистов, и решил выложить её в публичный доступ.
В данном руководстве хочу изложить пошаговую настройку по развёртыванию платформы для непрерывного анализа и измерения качества кода. Подобных статей в сети достаточно много, но я хочу выделить лишь главное, чтобы все новички с первого раза смогли с ней разобраться. Ставить будем SonarQube 7.9 с PostgreSQL 10.
Привет, Хабр!
Меня зовут Артём Добровинский, я работаю Android-разработчиком в компании FINCH.
Однажды, за парой пинт с коллегой из компании, которая занимается размещением объявлений по продаже комиссованных МИГ'ов и комаров по имени Игорь, мы начали обсуждать статические анализаторы кода в CI (а что еще обсуждать). Прозвучала мысль о том, что их круто использовать — но только после того, как появится уверенность в логической надежности кода. Другими словами, о кодстайле можно думать только после того, как все тесты написаны.
Решил прислушаться к коллеге и задумался о том, как подсчитать масштаб бедствия для подручных приложений. Взгляд пал на Sonarqube и Jacoco. Процесс их подключения для hello-world проектов элементарен. Подключить их в Android-проект, разбитый на модули — уже сложнее. С целью помочь интересующимся и была написана эта статья.
фото с Unsplash по запросу "pipeline"
Привет! Я начинаю серию постов о пайплайнах в разработке и не только, которые помогают удостовериться в качестве разрабатываемых мобильных приложений. Главная идея в том, чтобы осветить все подходы к мобильной разработке, актуальные сейчас: нативную разработку для Android и iOS, React Native, Xamarin и Flutter. Я начну с Android, но сначала хотел бы дать общее представление, о чём это всё.
Имейте в виду, что это общий обзор инструментов и практик, способных пригодиться вам в процессе разработки Android-приложений, а не туториал по настройке этих инструментов.
Уязвимости в своём коде хочется находить как можно быстрее, а значит нужно автоматизировать этот процесс. Как именно автоматизировать поиск уязвимостей? Существует динамическое тестирование безопасности, существует статическое — и у обоих свои преимущества и недостатки. Сегодня подробно разберёмся со статическим на опыте его применения в Одноклассниках.
По каким принципам можно выбирать инструмент для статического тестирования? С какими сложностями сталкиваешься, когда уже выбрал? Как писать собственные правила анализа, расширяющие стандартную функциональность? Я занималась всеми этими вопросами — и теперь делюсь с Хабром тем, что узнала.
Речь пойдёт о Java, веб-приложениях, SonarQube и Find Security Bugs, но рассказанное применимо также для других языков и технологий.