Семь смертных грехов программного проекта

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

Антишаблоны

К сожалению, языки программирования, которые мы используем, слишком гибкие. Они позволяют слишком много и запрещают слишком мало. Например, Java не имеет ничего против того, чтобы вы разместили приложение целиком в одном «классе» несколькими тысячами методов. Технически приложение будет компилироваться и запускаться. Но это хорошо известный анти-паттерн, который называется объектом Бога.

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

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

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

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

Мое единственное практическое предложение здесь - читать и учиться. А, также, всегда старайтесь скептически относиться к качеству своего программного обеспечения и не расслабляйтесь, когда оно «просто работает». Как и при раке, чем раньше вы его диагностируете, тем больше шанс выжить.

Неизменяемые изменения

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

Всегда использовать tickets. Независимо от того, насколько мал проект или его команда, даже если это только вы сами, создайте билеты (проблемы GitHub) для каждой проблемы, которую вы решаете. Кратко объясните проблему в билете и запишите там свои размышления. Используйте билет как временное хранилище для всей информации, связанной с проблемой. Опубликуйте все, что может иметь какой-либо смысл в будущем, когда кто-то другой попытается понять, о чем были эти «немногие странные коммиты».

Ссылочные билеты в Commits. Излишне говорить, что каждая фиксация должна иметь сообщение. Фиксации без сообщений - очень грязная практика; Я даже не буду обсуждать почему. Но одного сообщения недостаточно. Каждое сообщение должно начинаться с номера ticket, с которым вы работаете. GitHub (я уверен, вы его используете) будет автоматически связывать фиксации и билеты, увеличивая отслеживаемость изменений.

Не удаляйте ничего. Git позволяет нам сделать «принудительный» push, который перезаписывает всю ветку, которая ранее существовала на сервере. Это всего лишь один пример того, как вы можете разрушить историю развития. Много раз я также видел, как люди удаляли свои комментарии в обсуждениях GitHub, чтобы сделать билеты более «чистыми». Это просто неправильно. Никогда ничего не удаляйте; Пусть ваша история останется с вами, независимо от того, насколько плохо (или грязно) она может выглядеть для вас сейчас.

Специальные выпуски

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

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

$ ./release.sh
...
DONE (98,7 с)

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

Здесь я могу дать только один практический совет: автоматизировать его. Для этого я использую rultor.com, но вы можете использовать любые инструменты, которые вам нравятся. Важно то, что вся процедура полностью автоматизирована и может быть выполнена из командной строки.

Статический анализ

Статический анализ делает наш код лучше. И, сделав его лучше, мы неизбежно заставляем его работать лучше. Но это происходит только тогда, когда вся команда вынуждена (!) Следовать правилам, продиктованным статическим анализатором (ами). Я написал об этом в строгом контроле качества Java-кода. Я использую qulice.com в проектах Java и rubocop в Ruby, но есть много похожих инструментов почти для каждого языка.

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

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

Неизвестное тестовое покрытие

Проще говоря, тестовое покрытие - это степень, в которой программное обеспечение было протестировано модулем или интеграционными тестами. Чем выше охват, тем больше «количество» кода выполнялось во время выполнения тестов. Очевидно, что более высокий охват - это хорошо.

Тем не менее, многие разработчики проектов просто не знают их охвата. Они просто не измеряют эту метрику. У них могут быть некоторые тесты, но никто не знает, насколько глубоко они проникают в программное обеспечение и какие части его не тестируются вообще. Эта ситуация намного хуже, чем низкий охват тестирования, который измеряется и сообщается всем.

Высокий охват не является гарантией высокого качества. Это очевидно. Но неизвестный охват является явным индикатором проблем ремонтопригодности. Когда новый разработчик входит в проект, он или она должны иметь возможность вносить некоторые изменения и видеть, как покрытие влияет на них. В идеале, тестовое покрытие должно проверяться так же, как и статический анализ, и сборка должна выходить из строя, если она выходит ниже определенного заранее определенного порога (обычно где-то около 80 процентов).

Непрерывное развитие

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

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

Когда я смотрю в исходный код и его историю фиксации и релиза, я должен быть в состоянии сказать, каково намерение его автора (ов), что проект делал год назад, куда он идет сейчас, какова его дорожная карта Is и т.д. Вся эта информация должна быть в исходном коде и, что более важно, в истории Git.

Теги Git и примечания к выпуску GitHub - два мощных инструмента, которые предоставляют мне такую ​​информацию. Используйте их в полной мере. Кроме того, не забывайте, что каждая двоичная версия продукта должна быть доступна для немедленной загрузки. Я должен иметь возможность скачать версию 0.1.3 и протестировать ее прямо сейчас, даже если проект сейчас работает на 3.4.

Недокументированные интерфейсы

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

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

Я говорю здесь о документации для пользователей, а не для разработчиков. В общем, я против документации внутри программного обеспечения. Здесь я полностью согласен с программным обеспечением Agile Manifesto, гораздо более важным, чем полная документация. Но это не относится к «внешней» документации, которая должна быть прочитана пользователями, а не разработчиками.

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

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