Лучшие практики кодирования - Best coding practices

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

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

В Правило девяноста девяноста, Тому Каргиллу приписывают объяснение того, почему проекты программирования часто выполняются с опозданием: «Первые 90% кода составляют первые 90% времени разработки. Оставшиеся 10% кода составляют остальные 90% времени. время разработки ". Стоит рассмотреть любое руководство, которое может исправить это отсутствие предвидения.

Размер проекта или программы оказывает значительное влияние на количество ошибок, производительность программистов и объем необходимого управления.[3]

Качество программного обеспечения

Основная статья: Качество программного обеспечения

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

Соммервилл выделил четыре обобщенных атрибута, которые не связаны с тем, что делает программа, а с тем, насколько хорошо программа это делает:[5]

Вайнберг определил четыре цели, которым должна соответствовать хорошая программа:[6]

  • Соответствует ли программа своим Технические характеристики; "правильный вывод для каждого возможного входа"?
  • Выполняется ли программа по графику (и в рамках бюджета)?
  • Насколько адаптируема программа к меняющимся требованиям?
  • Достаточно ли эффективна программа для среды, в которой она используется?

Hoare определил семнадцать целей, связанных с качеством программного обеспечения, в том числе:[7]

  • Четкое определение цели.
  • Простота использования.
  • Надежность (трудно использовать не по назначению, легко допускать ошибки).
  • Ранняя доступность (доставка вовремя при необходимости).
  • Надежность.
  • Расширяемость в свете опыта.
  • Краткость.
  • Эффективность (достаточно быстрая для той цели, для которой она предназначена).
  • Минимальные затраты на разработку.
  • Соответствие любому актуальному стандарты.
  • Ясный, точный и точный пользовательские документы.

Предпосылки

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

От Meek & Heath: «То, что происходит до того, как человек дойдет до стадии кодирования, часто имеет решающее значение для успеха проекта».[8]

Изложенные ниже предварительные условия охватывают такие вопросы, как:

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

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

Жизненный цикл

Основная статья: Методология разработки программного обеспечения

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

Модель водопада - это последовательный подход к разработке; в частности, предполагается, что требования могут быть полностью определены в начале проекта. Однако МакКоннелл цитирует три исследования, которые показывают, что в среднем требования меняются примерно на 25% во время проекта.[9] Все другие упомянутые выше методологии пытаются уменьшить влияние таких изменений требований, часто с помощью какой-либо формы пошагового, инкрементального или итеративного подхода. Для разных сред разработки могут подходить разные методологии.

Требования

Основная статья: Разработка требований

МакКоннелл утверждает: «Первое предварительное условие, которое вы должны выполнить перед началом строительства, - это четкое определение проблемы, которую система должна решить».[10]

Мик и Хит подчеркивают, что ясная, полная, точная и недвусмысленная письменная спецификация - это цель, к которой нужно стремиться.[11] Обратите внимание, что достичь этой цели может быть невозможно, и цель, вероятно, все равно изменится (как упоминалось в предыдущем разделе).

Sommerville различает менее подробные требования пользователя и более подробные системные требования.[12] Он также различает функциональные требования (например, обновление записи) и нефункциональные требования (например, время ответа должно быть менее 1 секунды).

Архитектура

Основная статья: Архитектура программного обеспечения

Хоар отмечает: «Есть два способа создания дизайна программного обеспечения: один - сделать его настолько простым, чтобы очевидно без недостатков; другой способ - сделать его настолько сложным, чтобы не было очевидный недостатки. Первый способ гораздо сложнее."[13]

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

На этом этапе необходимо учитывать любые нефункциональные системные требования (время отклика, надежность, ремонтопригодность и т. Д.).[14]

Архитектура программного обеспечения также представляет интерес для различных заинтересованных сторон (спонсоров, конечных пользователей и т. Д.), Поскольку дает им возможность проверить, могут ли быть выполнены их требования.

Дизайн

Основная статья: Разработка программного обеспечения

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

Выбор языка (ов) программирования

Майер утверждает: «Ни один язык программирования не идеален. Не существует даже единственного лучшего языка; есть только языки, хорошо подходящие или, возможно, плохо подходящие для конкретных целей. Понимание проблемы и связанных с ней требований к программированию необходимо для выбора языка, наиболее подходящего для решение."[15]

От Meek & Heath: «Суть искусства выбора языка состоит в том, чтобы начать с проблемы, решить, каковы ее требования и их относительная важность, поскольку, вероятно, будет невозможно удовлетворить их все одинаково хорошо. Доступные языки должны тогда быть сопоставленным со списком требований и выбрать наиболее подходящий (или наименее неудовлетворительный) ».[16]

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

Даже если нет выбора относительно того, какой язык программирования использовать, МакКоннелл дает несколько советов: «У каждого языка программирования есть свои сильные и слабые стороны. Помните о конкретных сильных и слабых сторонах языка, который вы используете».[17]

Стандарты кодирования

Основная статья: Соглашения о кодировании

Как указывает МакКоннелл, этот раздел также является предварительным условием для программирования: «Установите соглашения о программировании до того, как вы начнете программировать. Практически невозможно изменить код, чтобы он соответствовал им позже».[18]

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

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

Для некоторых примеров плохих соглашений о кодировании Roedy Green предоставляет длинную (иронизирующую) статью о том, как создавать неподдерживаемый код.[19]

Комментирование

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

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

  1. Название модуля
  2. Назначение модуля
  3. Описание модуля
  4. Автор оригинала
  5. Модификации
  6. Авторы, которые изменили код, с описанием того, почему он был изменен.

«Описание модуля» должно быть как можно более кратким, но без ущерба для ясности и полноты.

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

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

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

Соглашения об именах

Смотрите также: Венгерская нотация

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

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

Пример: Переменная для принятия веса в качестве параметра для грузовика может называться TrkWeight или TruckWeightKilograms, причем TruckWeightKilograms является предпочтительным, поскольку его можно мгновенно узнать. Видеть CamelCase именование переменных.

Код должен быть простым

Код, который пишет программист, должен быть простым. Сложная логика для достижения простой цели должна быть сведена к минимуму, поскольку код может быть изменен другим программистом в будущем. Логика, реализованная одним программистом, может не иметь смысла для другого. Так что всегда делайте код максимально простым.[20]

Например, рассмотрим эти эквивалентные строки кода C:

если (часы < 24 && минут < 60 && секунды < 60){    возвращаться истинный;}еще{    возвращаться ложный;}

и

если (часы < 24 && минут < 60 && секунды < 60)    возвращаться истинный;еще    возвращаться ложный;

и

возвращаться часы < 24 && минут < 60 && секунды < 60;

1-й подход, который используется гораздо чаще[сомнительный – обсуждать], значительно больше 3-го. В частности, он занимает в 5 раз больше вертикального пространства экрана (строк) и 97 символов по сравнению с 52 (хотя инструменты редактирования могут уменьшить разницу в фактическом наборе текста). Однако можно спорить, что «проще». Первый имеет явное if / then else с явным возвращаемым значением, очевидно связанным с каждым; даже начинающему программисту это не составит труда понять. Второй просто отбрасывает скобки, сокращая «вертикальный» размер пополам с небольшим изменением концептуальной сложности. В большинстве языков операторы «return» также могут быть добавлены к предыдущим строкам, увеличивая «вертикальный» размер только на одну строку больше, чем в третьей форме.

Третья форма, очевидно, минимизирует размер, но может увеличить сложность: она оставляет неявные значения «истина» и «ложь» и смешивает понятия «условие» и «возвращаемое значение». Для большинства программистов это, вероятно, очевидно, но новичок может не сразу понять, что результат вычисления условия на самом деле является значением (типа Boolean или его эквивалента на любом языке), и, таким образом, им можно управлять или возвращать. В более реалистичных примерах у третьей формы могут быть проблемы из-за приоритет оператора, возможно, возвращая неожиданный тип, когда предыдущие формы на некоторых языках сообщали бы об ошибке. Таким образом, «простота» - это вопрос не просто длины, а логической и концептуальной структуры; сокращение кода может сделать его менее или более сложным.

Для больших, долгоживущих программ использование подробных альтернатив может способствовать раздувание.[сомнительный – обсуждать]

Компактность позволяет кодировщикам просматривать больше кода на странице, сокращая количество жестов прокрутки и нажатий клавиш. Учитывая, сколько раз код может просматриваться в процессе написания и сопровождения, это может дать значительную экономию нажатий клавиш программистом за время существования кода. Это может показаться несущественным для студента, впервые обучающегося программированию, но при создании и сопровождении больших программ сокращение количества строк кода позволяет разместить больше кода на экране, незначительное упрощение кода может повысить производительность.[сомнительный – обсуждать], а также уменьшить напряжение пальцев, запястий и глаз, которые являются обычными проблемами со здоровьем, с которыми сталкиваются производственные кодировщики и информационные работники.[21]

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

Наконец, в очень кратких компоновках лучше использовать современные широкоэкранные компьютерные дисплеи, в зависимости от компоновки и настройки монитора. В прошлом экраны были ограничены 40 или 80 символами (такие ограничения возникли намного раньше: в рукописях, печатных книгах и даже свитках на протяжении тысячелетий использовались довольно короткие строки (см., Например, Библия Гутенберга ). Современные экраны могут легко отображать 200 и более символов, что позволяет создавать очень длинные строки. Большинство современных стилей и стандартов кодирования не занимают всю ширину. Таким образом, при использовании одного окна шириной во весь экран тратится много доступного места. С другой стороны, при использовании нескольких окон или использовании IDE или другого инструмента с различной информацией на боковых панелях доступная ширина кода находится в диапазоне, знакомом по более ранним системам.

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

Портативность

Программный код не должен содержать «жестко закодированных» (буквальных) значений, относящихся к параметрам среды, таким как абсолютные пути к файлам, имена файлов, имена пользователей, имена хостов, IP-адреса, URL-адреса, порты UDP / TCP. В противном случае приложение не будет работать на хосте, дизайн которого отличается от предполагаемого. Внимательный программист может параметризовать такие переменные и настроить их для среды размещения вне самого приложения (например, в файлах свойств, на сервере приложений или даже в базе данных). Сравните мантру «единой точки определения»[22](SPOD).

В качестве расширения ресурсы, такие как файлы XML, также должны содержать переменные, а не буквальные значения, иначе приложение не будет переносимо в другую среду без редактирования файлов XML. Например, для приложений J2EE, работающих на сервере приложений, такие параметры среды могут быть определены в области JVM, и приложение должно получать значения оттуда.

Масштабируемость

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

Возможность повторного использования

Повторное использование - очень важная цель проектирования при разработке программного обеспечения. Повторное использование снижает затраты на разработку, а также сокращает время на разработку, если повторно используемые компоненты или модули уже протестированы. Очень часто программные проекты начинаются с существующей базовой линии, которая содержит проект в его предыдущей версии, и в зависимости от проекта многие из существующих программных модулей и компонентов используются повторно, что сокращает время разработки и тестирования, следовательно, увеличивает вероятность выполнения проекта программного обеспечения в соответствии с графиком. .

Краткое руководство по строительству

Общий обзор всего вышеперечисленного:

  1. Знайте, что должен выполнять блок кода
  2. Придерживайтесь единообразных соглашений об именах.
  3. Укажите краткое описание того, для чего предназначена переменная (ссылка на комментарий)
  4. Исправляйте ошибки по мере их появления.
  5. Держите свой код простым
  6. Разрабатывайте код с учетом масштабируемости и повторного использования.

Разработка кода

Построение кода

Лучшая практика для создания кода включает ежедневные сборки и тестирование, а еще лучше непрерывная интеграция, или даже непрерывная доставка.

Тестирование

Основная статья: Тестирование программного обеспечения

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

Отладка кода и исправление ошибок

Программисты обычно пишут полный код, а затем начинают отладку и проверку на наличие ошибок. Хотя такой подход может сэкономить время в небольших проектах, в более крупных и сложных, как правило, слишком много переменных и функций, требующих внимания. Следовательно, после завершения отладки рекомендуется отлаживать каждый модуль, а не всю программу. Это экономит время в долгосрочной перспективе, так что не нужно тратить много времени на выяснение того, что не так. Модульные тесты для отдельных модулей и / или функциональные тесты за веб-сервисы и веб-приложения могут в этом помочь.

Развертывание

Основная статья: Развертывание программного обеспечения

Развертывание - это заключительный этап выпуска приложения для пользователей. Вот некоторые лучшие практики:[23][24]

  1. Сохраняйте простую структуру установки: количество файлов и каталогов должно быть минимальным. Не устанавливайте ничего, что никогда не будет использоваться.
  2. Сохраняйте только то, что необходимо: действия по управлению конфигурацией программного обеспечения должны обеспечивать соблюдение этого требования. Неиспользуемые ресурсы (старые или неудачные версии файлов, исходный код, интерфейсы и т. Д.) Должны быть заархивированы в другом месте, чтобы новые сборки оставались компактными.
  3. Держите все в курсе: действия по управлению конфигурацией программного обеспечения должны обеспечивать соблюдение этого требования. Для развертываний на основе дельты убедитесь, что версии уже развернутых ресурсов являются самыми последними, прежде чем развертывать дельты. Если не уверены, выполните развертывание с нуля (сначала удалите все, а затем повторно разверните).
  4. Примите многоступенчатую стратегию: в зависимости от размера проекта иногда требуется больше развертываний.[25]
  5. Имейте стратегию отката: должен быть способ отката к предыдущей (рабочей) версии.
  6. Положитесь на автоматизацию для повторяемых процессов: слишком много места для человеческой ошибки, развертывание не должно выполняться вручную. Используйте инструмент, который является родным для каждой операционной системы, или используйте язык сценариев для кросс-платформенных развертываний.[26][27]
  7. Восстановите реальную среду развертывания: учитывайте все (маршрутизаторы, брандмауэры, веб-серверы, веб-браузеры, файловые системы и т. Д.)
  8. Не изменяйте процедуры и сценарии развертывания на лету и документируйте такие изменения: дождитесь новой итерации и соответствующим образом запишите такие изменения.
  9. Настроить развертывание: новые программные продукты, такие как API, микросервисы и т. Д., Требуют особого внимания для успешного развертывания.[28][29][30]
  10. Снижение риска, связанного с другими этапами разработки: если другие действия, такие как тестирование и управление конфигурацией, неверны, развертывание наверняка завершится неудачей.[31][32]
  11. Учитывайте влияние каждой заинтересованной стороны: организационные, социальные, правительственные соображения.[33][34][35]

Смотрите также

Рекомендации

  1. ^ МакКоннелл, Стив (2004). Код завершен (Второе изд.). Microsoft Press. ISBN  0-7356-1967-0.
  2. ^ Соммервилль, Ян (2004). Программная инженерия (Седьмое изд.). Пирсон. п. 38. ISBN  0-321-21026-3.
  3. ^ МакКоннелл, Стив (2004). Код завершен (Второе изд.). Microsoft Press. стр.649–659. ISBN  0-7356-1967-0.
  4. ^ Вайнберг, Джеральд (1998). Психология компьютерного программирования (Серебряная юбилейная ред.). Издательство Дорсет Хаус, Нью-Йорк. С. 128–132. ISBN  978-0-932633-42-2.
  5. ^ Соммервилль, Ян (2004). Программная инженерия (Седьмое изд.). Пирсон. С. 12–13. ISBN  0-321-21026-3.
  6. ^ Вайнберг, Джеральд (1998). Психология компьютерного программирования (Серебряная юбилейная ред.). Издательство Дорсет Хаус, Нью-Йорк. С. 15–25. ISBN  978-0-932633-42-2.
  7. ^ Хоар, C.A.R. (1972). «Качество программного обеспечения». Практика и опыт работы с программным обеспечением. Вайли. 2 (2): 103–105. Дои:10.1002 / spe.4380020202.
  8. ^ Кроткий, Брайан; Хит, Патрисия (1980), Руководство по хорошей практике программирования, Эллис Хорвуд, Wiley, стр. 14
  9. ^ МакКоннелл, Стив (2004). Код завершен (Второе изд.). Microsoft Press. п.40. ISBN  0-7356-1967-0.
  10. ^ МакКоннелл, Стив (2004). Код завершен (Второе изд.). Microsoft Press. п.36. ISBN  0-7356-1967-0.
  11. ^ Кроткий, Брайан; Хит, Патрисия (1980), Руководство по хорошей практике программирования, Эллис Хорвуд, Wiley, стр. 15
  12. ^ Соммервилль, Ян (2004). Программная инженерия (Седьмое изд.). Пирсон. С. 118–123. ISBN  0-321-21026-3.
  13. ^ Хоар, C.A.R (1981). "Старая одежда императора" (PDF). Коммуникации ACM. ACM. 24 (2): 75–83. Дои:10.1145/358549.358561. S2CID  97895. Получено 25 ноя 2019.
  14. ^ Соммервилль, Ян (2004). Программная инженерия (Седьмое изд.). Пирсон. С. 242–243. ISBN  0-321-21026-3.
  15. ^ Майер, Герберт (1989). Расширенное программирование на C на IBM PC. Книги Уиндкреста. п. xii (предисловие). ISBN  0830693637.
  16. ^ Кроткий, Брайан; Хит, Патрисия (1980), Руководство по хорошей практике программирования, Эллис Хорвуд, Wiley, стр. 37
  17. ^ МакКоннелл, Стив (2004). Код завершен (Второе изд.). Microsoft Press. п.70. ISBN  0-7356-1967-0.
  18. ^ МакКоннелл, Стив (2004). Код завершен (Второе изд.). Microsoft Press. п.70. ISBN  0-7356-1967-0.
  19. ^ Роуди Грин. "неподдерживаемый код: глоссарий Java". Получено 2013-11-26.
  20. ^ Множественный (вики). "Лучшие практики". Докфорж. Получено 2012-11-13.
  21. ^ «Повторяющееся растяжение». Получено 30 октября 2016.
  22. ^ См. Например:«Единственная точка определения на примере». Получено 2015-11-30. «Ничего не повторяй. Стремитесь к единой точке определения для каждого аспекта вашего приложения [...] ».
  23. ^ https://dzone.com/articles/7-application-deployment-best
  24. ^ https://lwn.net/Articles/562333/
  25. ^ blog.fortrabbit.com/multi-stage-deployment-for-website-development
  26. ^ https://www.wired.com/insights/2013/04/why-30-of-app-deployments-fail/
  27. ^ http://emphaticsolutions.com/2009/09/06/the-rules-of-software-deployment.html
  28. ^ https://airbrake.io/blog/software-development/speed-up-deployment-match-demand
  29. ^ https://www.linux.com/news/devops-and-art-secure-application-deployment
  30. ^ https://www.awsarchitectureblog.com/2014/05/organizing-software-deployments-to-match-failure-conditions.html
  31. ^ http://www.theserverside.com/news/1364556/Best-Practices-for-Risk-Free-Deployment
  32. ^ http://www.drdobbs.com/effective-software-deployment/184415760
  33. ^ http://searchitoperations.techtarget.com/tip/Enterprise-application-deployment-The-humanity-of-software-implementation
  34. ^ https://18f.gsa.gov/2014/05/14/hacking-bureaucracy-improving-hiring-and-software/
  35. ^ http://www.intact-tech.com/why-a-bad-software-deployment-is-worse-than-doing-nothing/
  36. ^ Дэвис, Алан Марк. (1995). 201 принцип разработки программного обеспечения. Нью-Йорк: Макгроу-Хилл. ISBN  0-07-015840-1. OCLC  31814837.
  37. ^ Джонсон, Понтус; Экстедт, Матиас; Якобсон, Ивар (2012). «Где теория программной инженерии?». Программное обеспечение IEEE. 29 (5): 96. Дои:10.1109 / MS.2012.127. ISSN  0740-7459. S2CID  38239662.
  38. ^ Круг, Стив (2014). Не заставляйте меня думать, еще раз: здравый подход к юзабилити в Интернете. Бейл, Элизабет, Стрейгер, Арен, Матчо, Марк (Третье изд.). [Сан - Франциско, Калифорния]. ISBN  978-0-321-96551-6. OCLC  859556499.
Общий

внешняя ссылка