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

Научитесь выявлять их. Выработайте привычки избегать их.

От переводчика

Анонсируем новый линтер (статический анализатор) для Go, который одновременно является песочницей для прототипирования ваших задумок в мире статического анализа.

go-critic построен вокруг следующих наблюдений:

• Лучше иметь “good enough” реализацию проверки, чем не иметь её вовсе
• Если проверка спорная, это ещё не значит, что она не может быть полезна. Помечаем как “opinionated” и вливаем
• Писать линтер с нуля, как правило, сложнее, чем добавлять новую проверку в существующий каркас, если сам фреймворк прост для понимания

В этом посте мы рассмотрим использование и архитектуру go-critic, некоторые реализованные в нём проверки, а также опишем основные шаги добавления своей функции-анализатора в него.

1. Попарно сравниваются элементы массива
2. Если элемент слева^* больше элемента справа, то элементы меняются местами
3. Повторяем пункты 1-2 до тех пор, пока массив не отсортируется

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

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

Разумеется, статья вызвала большое количество вопросов, которые необходимо осветить отдельно: отличие от существующих решений и сравнительный анализ производительности и планов построения запросов к базе данных. А также ответить на вопрос: что это вообще такое и зачем?

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

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

•         Зачем, что и когда мы пытаемся достичь при ревью кода
  
•         Подготовка кода к ревью
  
•         Выполнение ревью кода
  
•         Примеры ревью кода
  

Привет, Хабр. Меня зовут Сергей Рудаченко, я техлид в компании Roistat. Последние два года наша команда переводит различные части проекта в микросервисы на Go. Они разрабатываются несколькими командами, поэтому нам понадобилось задать жесткую планку качества кода. Для этого мы используем несколько инструментов, в этой статье речь пойдет об одном из них — о статическом анализе.

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

В статьях по этой теме часто встречается термин «линтер». Для нас это удобное название простых инструментов для статического анализа. Задача линтера — поиск простых ошибок и некорректного оформления.

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

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

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

В декабре прошлого года мы участвовали в хакатоне со своей платформой прототипирования. За отведенные два дня мы замахнулись с нуля разобраться с онлайн-кассой и её облачной экосистемой, а также сделать прототип сервиса — Маркетплейс. Как и ожидалось, мы потратили 80% времени на интеграцию с незнакомым устройством, а за оставшиеся 20% хорошо развлеклись и сделали всё остальное.

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

В этой статье я покажу как за 2-3 часа был сделан веб-сервис, интегрированный с облачными кассами и пригодный для обкатки на фокусной группе клиентов. Сам проект доступен для ознакомления и клонирования в виде исходников в github и онлайн версии.

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

Дольше всего приходится вычитывать не хитрые алгоритмы, и не решения с алгебраическими типами данных и монадами, а огромные куски простого кода: методы на 500 строк, скрипты на 1000 строк, классы на 1500 строк. Все они доставляют индустрии проблем не меньше, чем печально известное NullPointerException.