Software Quality Award, 2015

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

Я являюсь ярым сторонником правил и дисциплины в разработке программного обеспечения; в качестве примера можно посмотреть статью “Вы хакер или дизайнер?”. Кроме того, я являюсь поклонником объектно-ориентированного программирования в его самой чистой форме; например, см. “Семь добродетелей хорошего объекта”. Я также являюсь соучредителем и генеральным директором Zerocracy, компании по разработке программного обеспечения, в которой я воплощаю свою любовь к дисциплине и чистому дизайну на практике.

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

Отправьте мне свой собственный проект для рассмотрения и примите участие в конкурсе.

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

  • Подачи принимаются до 1 сентября 2015 года и больше не принимаются.

  • Заявки необходимо отправлять по электронной почте на адрес me@yegor256.com. Вам достаточно предоставить свой логин GitHub и название репозитория; я проверю историю коммитов, чтобы убедиться, что вы являетесь основным участником проекта.

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

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

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

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

  • Лучшие 8 проектов получат 1-годовые лицензии на открытый исходный код для любых продуктов JetBrains (одна лицензия на проект).

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

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

  • Как минимум 5 000 строк кода.

  • По крайней мере, один год.

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

Лучшие проекты будут иметь (подробнее об этом):

  • “Continuous delivery” - “Непрерывная доставка”.

  • Отслеживаемость изменений.

  • Самодокументирующийся исходный код.

  • Строгие правила форматирования кода.

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

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

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

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

158 проектов было представлено до сих пор (в порядке представления):

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

Я скоро их просмотрю. Победитель будет объявлен 15 октября.

5 октября: Я получил электронное письмо от автора raphw/byte-buddy, просившего пересмотреть моё решение по этому проекту. Я быстро посмотрел, почему проект был отфильтрован, и решил включить его в список финалистов. Кстати, если кто-то из вас считает, что его проект был исключен по ошибке, не стесняйтесь писать мне письма.

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

coala-analyzer/coala (14K строк кода на Python, 160K строк высшего порядка)

  • Есть глобальные функции, например get_language_tool_results и DictUtilities. Это определенно плохая идея в ООП.

  • Класс Constants - ужасная идея.

  • Проверка типов объектов во время выполнения - плохая идея, например, ClangCountVectorCreator.py

  • Что не так с cindex.py? Там почти 3200 строк кода, это слишком много.

  • Статический анализ не является обязательным шагом в процессе сборки и выпуска. Вот почему, я полагаю, форматирование кода не согласовано и иногда довольно некрасиво. Например, pylint сообщает о сотнях проблем. (обновление: используется scrutinizer, но я все равно считаю, что локальное использование pylint серьезно улучшило бы качество кода)

  • Некоторые методы имеют документацию, а другие нет. Я не понимаю логику. Было бы здорово, если бы все методы были задокументированы. Кроме того, не все классы имеют документацию.

  • Score: 5

checkstyle/checkstyle (83K строк кода на Java, 553K строк кода высокого уровня)

  • Есть целый набор утилитарных классов, что, безусловно, является плохой практикой в ООП. Они даже сгруппированы в специальный пакет utils, такая ужасная идея.

  • Сеттеры и геттеры повсюду, вместе с неизменяемыми классами, которые на самом деле не являются объектно-ориентированной концепцией, например DetectorOptions.

  • NULL активно используется во многих местах - это серьезный антипаттерн.

  • Я нашел пять файлов .java с более чем 1000 строк в каждом из них, например, 2500+ в ParseTreeBuilder.java.

  • Есть прямые коммиты в основную ветку, сделанные разными участниками проекта, и некоторые из них не связаны ни с одними тикетами. Невозможно понять, почему они были сделаны. Посмотрите на пример: 7c50922. Были ли обсуждения? Кто принял решение? Совершенно не ясно.

  • Релизы вообще не документированы.

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

  • Score: 3

citiususc/hipster (5K Java LoC, 64K HoC) - citiususc/hipster (5K строк кода на Java, 64K строк кода высшего порядка)

  • Существуют публичные статические методы и даже утилитарные классы, например этот, с забавным названием F

  • NULL активно используется, особенно в итераторах - это плохая идея.

  • Документация JavaDoc не является последовательной, некоторые методы задокументированы, а другие - нет.

  • Не все коммиты связаны с тикетами, вот пример: 8cfa5de.

  • Изменения фиксируются напрямую в ветке master, pull-запросы не используются вовсе.

  • Я не нашел автоматизированной процедуры для выпуска. Я нашел одну для регулярного развертывания снимков в Bintray, а что насчет выпусков? Они выполняются вручную?

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

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

  • Score: 4

gulpjs/gulp (700 JS LoC) - gulpjs/gulp (700 строк JS кода)

  • Score: 0

kaitoy/pcap4j (42K строк кода, 122K строк комментариев).

  • NULL используется в изменяемых объектах, например в AbstractPcapAddress; это плохая идея.

  • Слишком много static методов и переменных. Они буквально повсюду. Есть даже модуль, называемый pcap4j-packetfactory-static, полный “классов” с статическими методами.

  • Документация JavaDoc не является последовательной и иногда просто неполной, проверьте, например, здесь.

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

  • Процедура выпуска не автоматизирована, релизы не документированы.

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

  • Score: 3

raphw/byte-buddy (84K LoC, 503K HoC) - Репозиторий raphw/byte-buddy (84K LoC, 503K HoC).

  • Есть много public static методов и свойств. Я понимаю, что, возможно, это единственный способ работать с областью проблем в Java, но всё же…

  • instanceof используется очень часто, и это плохая практика в ООП. Опять же, я понимаю, что иногда это может понадобиться в контексте конкретной проблемной области, но всё же…

  • Большинство коммитов выполняется непосредственно в ветке master, без создания pull-запросов или тикетов, поэтому их прослеживаемость нарушена.

  • Процедура выпуска не автоматизирована (я не нашел скрипт).

  • Score: 5

subchen/snack-string (1K LoC, 2K HoC) - subchen/snack-string (1K строк кода, 2K строк дочернего кода)

  • Score: 0

gvlasov/inflectible (5K LoC, 36K HoC) translates to: gvlasov/inflectible (5 тыс. строк кода, 36 тыс. строк документации)

  • Score: 10

testinfected/molecule (10K LoC, 43K HoC) - testinfected/molecule (10 тыс. строк кода, 43 тыс. строк кода, содержащих только комментарии).

  • В некоторых классах есть методы установки и получения, хотя они имеют другую соглашенную нотацию, например Request и Response.

  • Большинство файлов .java не содержат блоков Javadoc, и они выглядят последовательными, но внезапно некоторые файлы имеют документацию, например WebServer.

  • Есть не так много проблем, и большинство коммитов нельзя проследить до какой-либо из них, например b4143a0 - зачем он был сделан? Неясно. Кроме того, почти нет pull request. Похоже, автор просто коммитит в master.

  • Процедура выпуска не задокументирована/автоматизирована. Я не нашел ее. Кроме того, релизы вообще не задокументированы.

  • Статический анализ отсутствует.

  • Score: 6

trautonen/coveralls-maven-plugin (4.5K LoC) - переведите на русский язык

  • Score: 0

wbotelhos/raty (8.7K LoC, 63K HoC) - wbotelhos/raty (8,7 тыс. строк кода, 63 тыс. символов)

  • Есть глобальные функции, например в helper.js

  • jasmine.js имеет 2400 строк кода, что является слишком большим количеством.

  • Я не понимал, почему файлы .html находятся вместе с файлами .js в одном каталоге, например run.html

  • Не все изменения могут быть прослежены до проблемы, например 0a233e8. В проекте нет так много проблем и всего несколько запросов на слияние.

  • Процедура выпуска не автоматизирована (по крайней мере я не нашел никакой документации об этом).

  • “Отсутствует статический анализ”

  • “Нет модульных тестов”

  • Score: 2

xvik/guice-persist-orient (17K строк кода, 54K строк кода, содержащихся в других модулях)

  • В данном проекте активно используется инъекция зависимостей, что, по моему мнению, является не лучшей идеей в ООП в целом. Но в данном случае, я понимаю, что это требуется предметной областью проблемы. В любом случае…

  • Есть всего несколько проблем и практически нет запросов на объединение изменений (pull requests), и коммиты нельзя проследить обратно к проблемам, например, к этому: e9c8f79

  • Не существует статического анализа (статический анализ присутствует, с набором проверок Checkstyle, PMD и FindBugs).

  • Score: 5

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

15 октября: Таким образом, у нас есть эти лучшие проекты из 158, представленных на конкурс:

  1. testinfected/molecule –> testinfected/molecule

  2. coala-analyzer/coala - переведите на русский язык

  3. xvik/guice-persist-orient

  4. raphw/byte-buddy

  5. citiususc/hipster

  6. checkstyle/checkstyle

  7. kaitoy/pcap4j

Поздравляем @gvlasov, победителя! Вот ваш значок:

Положите этот код в README на GitHub:

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

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

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-05 at 22:09

sixnines availability badge   GitHub stars