Семь Смертных Грехов Разработки Программного Обеспечения

Они позволяют слишком многое и слишком мало запрещают. Например, Java не помешает вам разместить код всего приложения в одном классе с парой сотен методов.

Технически приложение скомпилируется и запустится.

Но это известный антипаттерн Божественный объект .

Таким образом, антишаблон — это технически приемлемый способ разработать приложение так, чтобы оно было явно некорректным.

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

Их присутствие в вашем проекте похоже на опухоль в живом организме.

Как только оно начинает расти, остановить его уже очень сложно.

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

Стоит ввести парочку антипаттернов, как их количество, как опухоль, будет только расти.

Особенно это касается объектно-ориентированных языков (Java, C++, Ruby, Python), главным образом потому, что они многое наследуют от процедурных языков (C, Fortran, COBOL).

Вот почему разработчики ООП склонны мыслить в процедурном и императивном стиле.

К сожалению.

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

Мой практический совет — читайте и учитесь.

Может быть, эти книги Вам поможет. Всегда скептически относитесь к качеству своего кода и не успокаивайтесь, когда он «просто работает».

Как и в случае с рак , чем раньше вы его диагностируете, тем выше шанс на выживание.

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

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

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

Кратко опишите проблему в заявке.

Используйте тикет-систему для промежуточных мыслей, чтобы потом было понятно, для чего были «те немногие коммиты».

Свяжите заявки и коммиты вместе .

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

Совершать действия без сообщений — это грязная практика, и я даже не буду обсуждать, почему.

Но просто сообщения недостаточно.

Каждое сообщение должно начинаться с номера заявки, с которой вы работаете.

GitHub (я уверен, вы им пользуетесь) автоматически связывает задачи и коммиты, позволяя лучше следить изменения.

Ничего не удаляй .

Git позволяет нам выполнить команду «push --force», которая перезаписывает всю ветку, ранее существовавшую на сервере.

Это лишь один пример того, как можно разрушить историю развития.

Часто я видел, как люди удаляли свои комментарии в обсуждениях GitHub, чтобы их проблемы выглядели чище.

Это просто неправильно.

Никогда ничего не удаляйте; оставьте свою историю, какой бы плохой (или уродливой) вы ее ни считали.

Если это библиотека Java, ее следует упаковать в файл *.

jar и разместить в каком-нибудь репозитории; Если это веб-приложение, то его необходимо развернуть на какой-то платформе и т. д. Независимо от того, насколько велик или мал проект, всегда должны быть стандартные процедуры тестирования, упаковки и развертывания.

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

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

я использую рултор.

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

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

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

Я писал об этом в Строгий контроль качества Java-кода .

я использую qulice.com для Java-проектов и рубокоп для проектов Ruby, но помимо этого существует множество опций для каждого языка.

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

Такой «добровольный» подход не приносит никакой пользы проекту.

Более того, это создает иллюзию качества.

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

Сборка должна завершиться неудачей, если какой-либо статический анализатор укажет на нарушение правил.

Чем выше процент покрытия, тем больше кода выполняется во время тестирования.

Конечно, чем выше процент покрытия, тем лучше.

Однако многие разработчики просто не знают процент покрытия тестами.

Они не измеряют этот показатель.

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

Эта ситуация намного хуже, чем низкий процент охвата, который можно измерить.

Высокий процент покрытия не является гарантией высокого качества.

Очевидно.

Но неизвестный процент покрытия является явным признаком проблем с ремонтопригодностью.

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

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

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

Проект без четкой истории релизов — это неподдерживаемый беспорядок.

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

Используйте их в полной мере.

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

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

Если это веб-приложение, то должны быть веб-страницы, которые будет видеть и использовать конечный пользователь.

Каждый программный продукт имеет интерфейсы, и они должны быть тщательно документированы.

Как и все вышеперечисленное, это касается и ремонтопригодности.

Как новый программист в проекте, я сразу же начну изучать его интерфейсы.

Я должен понять, что он делает, и попытаться использовать его сам.

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

Теоретически я против документации внутри программы.

Я полностью поддерживаю это Agile-манифест — работающий программный продукт гораздо важнее подробной документации.

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

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

Если ваш продукт — это библиотека, то ее конечным пользователем является программист, который будет ее использовать — не разрабатывать, а использовать как «черный ящик».

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