Software Quality Award, 2016

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

Это второй год Software Quality Award. Приз остаётся таким же - $4,096. Правила немного изменились. Читайте далее. Кстати, наступил 2015 год.

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

  • Предложения принимаются до 1 сентября 2016 года.

  • Я проверю историю коммитов, чтобы убедиться, что вы являетесь основным участником проекта.

  • Я оставляю за собой право отклонить любое предложение без объяснения.

  • Все представления будут опубликованы на этой странице (включая отклоненные).

  • Результаты будут объявлены 15 октября 2016 года на этой странице и по электронной почте.

  • Лучший проект получит $4,096.

  • Окончательные решения будут приниматься мной и не подлежат обсуждению (хотя я могу пригласить других людей помочь мне принять правильное решение).

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

Каждый проект должен быть:

  • Не меньше 10 000 строк кода.

  • Возраст не менее одного года.

  • Объектно-ориентированный (это единственное, что я понимаю).

Лучший проект выбирается на основании этих критериев.

Что не имеет значения:

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

  • Гул и тренды. Даже если ваш проект - это всего лишь еще один парсер аргументов командной строки, он все равно подходит для получения награды. Мне не важна ваша маркетинговая позиция; все дело в качестве.

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

На данный момент подано 60 проектов (в случайном порядке):

15 октября 2016 года: Я попросил одного из наших Java-разработчиков провести предварительный анализ всех проектов. Вот отчет, который он прислал мне сегодня: award-2016.txt (вы можете найти свой проект там). Я добавил свои комментарии к его плюсам и минусам (вы можете увидеть их прямо в этом текстовом файле). Исходя из его мнения и предварительного анализа, я выбрал несколько финалистов.

  • “NullVoxPopuli/aeonvera (Ruby)” - “NullVoxPopuli/aeonvera (Ruby)”

  • “SimonKagstrom/kcov (C++)” - “SimonKagstrom/kcov (C++)”

  • “skinny-framework/skinny-framework (Scala)” - “skinny-framework/skinny-framework (Scala)”

  • “paypal/squbs (Scala)” - “paypal/squbs (Scala)”

  • “ben-manes/caffeine (Java)” - “ben-manes/caffeine (Java)”

  • coala/coala (Python) - coala/coala (Python)

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

18 окт 2016: Это мой анализ семи финалистов. Я пытался уделить максимальное внимание каждому проекту (они все довольно хорошие).

pholser/junit-quickcheck (19K LoC, 80K HoC)

  • Релизы GitHub находятся здесь, но я не нашел, как именно они создаются, где находится процедура релиза? Кроме того, они не задокументированы, нет никаких заметок о релизе.

  • Есть некоторые утилитарные классы, например Lists, Items и Sequences.

  • Есть некоторые классы -ER, например Shrinker и SampleSizer (который имеет конструктор с кодом).

  • Дизайн “генераторов” на самом деле не является объектно-ориентированным, по-моему. Все они являются поставщиками процедур, а не настоящими “объектами” в терминах ООП.

  • Score: 5

NullVoxPopuli/aeonvera (46K LoC, 835K HoC) - NullVoxPopuli/aeonvera (46 тыс. строк кода, 835 тыс. символов кода).

  • Это Ruby on Rails, который использует архитектуру MVC, но не является настоящим ООП. Кроме того, также имеется ORM с анемичной моделью (в директории models/). За исключением этого, “сериализаторы”, “сервисы”, “валидаторы” и т. д. - также не настоящее ООП.

  • Я не нашел никаких выпусков на GitHub.

  • В репозитории отсутствует официальная процедура выпуска. Я просто не могу понять, как этот продукт попадает в производство, процесс неавтоматизирован (или скрипт отсутствует в репозитории). Это серьезная проблема для веб-приложения.

  • Кроме того, приложение определенно является более чистым, чем многие другие подобные веб-приложения на RoR. Хорошая работа.

  • Score: 4

SimonKagstrom/kcov (15K LoC, 50K HoC) - SimonKagstrom/kcov (15 тыс. строк кода, 50 тыс. строк комментариев).

  • Некоторые фрагменты кода - это слишком сложные методы, например, в ptrace.cc, elf-parser.cc или html-writer.cc.

  • Есть некоторые классы, оканчивающиеся на -ER, такие как “writers” (писатели), “verifiers” (проверяющие) и “parsers” (анализаторы), например: AddressVerifier или DwarfParser.

  • Интерфейсы имеют префикс I, что является плохой практикой в ООП, см. reporter.hh.

  • Есть некоторые “utils”, которые я бы заменил на классы (большинство из них): utils.hh.

  • Score: 4

skinny-framework/skinny-framework (44K LoC, 191K HoC) - skinny-framework/skinny-framework (44 тыс. строк кода, 191 тыс. строк кода с комментариями).

  • Я не нашёл статического анализа.

  • Я не нашел контроля покрытия кода, хотя есть много модульных тестов.

  • Есть утилитарные классы, например StringUtil, DateTimeUtil.

  • Это MVC, что является анти-паттерном в ООП.

  • Есть ORM, которая также является анти-паттерном.

  • Сложность кода иногда очень высока, например вот этот файл: AssociationsFeature.scala

  • Score: 2

paypal/squbs (28K LoC, 163K HoC) - paypal/squbs (28 тыс. строк кода, 163 тыс. строк комментариев)

  • Поглощение исключений кажется распространенной практикой здесь, например: здесь, здесь, здесь и т. д.

  • Есть утилитарные классы, например ConfigUtil.

  • Общее впечатление состоит в том, что сложность довольно высока, например эти файлы действительно сложны в понимании: ServiceRegistry.scala или UnicomplexBoot.scala.

  • Оценка: 3 (в основном из-за сложности)

ben-manes/caffeine (47K строк кода, 191K строк комментариев)

  • Есть некоторые классы -ER, например, Weigher можно легко переименовать в Weight. То же самое относится к “loaders” и “writers”.

  • Score: 4

coala/coala (15K LoC, 274K HoC) - coala/coala (15 тыс. строк кода, 274 тыс. строк кода с комментариями).

  • Есть некоторые классы -ER, такие как “parsers”, “collectors”, “importers”.

  • Я все еще не вижу последовательного форматирования кода, довольно странно видеть так много пробелов перед некоторыми строками, размещенных там без какой-либо логики (по крайней мере, я не вижу этой логики, например, здесь).

  • Некоторый код является полностью глобальным, без каких-либо классов, как в Processing.py и в Collectors.py (возможно, это неизбежно, но все же выглядит странно).

  • Некоторые файлы достаточно длинные, например, Lynter.py или ConsoleInteraction.py.

  • Score: 5

Я не могу найти сильного одиночного лидера… Позвольте мне подумать об этом.

23 октября 2016 года: В этом году я не нашел одного лидера, и приз достается двум проектам: pholser/junit-quickcheck и coala/coala ($2,048 каждому).

Поздравляю @pholser и @sils, победителей!

Вот ваши значки:

Поместите этот код в GitHub README (замените ??? на ваше имя пользователя GitHub в URL).

Спасибо всем за участие! Увидимся в следующем году.

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 05:15

sixnines availability badge  GitHub stars