Из Википедии, свободной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

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

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

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

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

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

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

Хоар определил семнадцать целей, связанных с качеством программного обеспечения, в том числе: [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 ) {  return  true ; } else {  вернуть  ложь ; }

и

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

и

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

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

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

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

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

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

Наконец, в очень кратких компоновках лучше использовать современные широкоэкранные компьютерные дисплеи, в зависимости от компоновки и настройки монитора. В прошлом экраны были ограничены 40 или 80 символами (такие ограничения возникли гораздо раньше: в рукописях, печатных книгах и даже свитках на протяжении тысячелетий использовались довольно короткие строки (см., Например, Библию Гутенберга ). Современные экраны могут легко отображать 200 или больше символов, что позволяет использовать очень длинные строки. Большинство современных стилей и стандартов кодирования не занимают всю ширину. Таким образом, при использовании одного окна, равного ширине экрана, много доступного пространства тратится впустую. Windows или использование 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]

См. Также [ править ]

  • Лучшая практика
  • Список инструментов для статического анализа кода
  • Ассоциация надежности программного обеспечения автомобильной промышленности (MISRA)
  • Software Assurance
  • Качество программного обеспечения
  • Список философий разработки программного обеспечения
  • The Cathedral and the Bazaar - книга, сравнивающая нисходящее и восходящее программное обеспечение с открытым исходным кодом
  • Дэвис 201 Принципы разработки программного обеспечения [36]
  • Где теория программной инженерии? [37]
  • Не заставляйте меня думать (Принципы интуитивной навигации и информационного дизайна) [38]

Ссылки [ править ]

  1. ^ МакКоннелл, Стив (2004). Код завершен (второе изд.). Microsoft Press. ISBN 0-7356-1967-0.
  2. Перейти ↑ Sommerville, Ian (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. Перейти ↑ Sommerville, Ian (2004). Программная инженерия (седьмое изд.). Пирсон. С. 12–13. ISBN 0-321-21026-3.
  6. ^ Вайнберг, Джеральд (1998). Психология компьютерного программирования (Серебряный юбилейный ред.). Издательство Дорсет Хаус, Нью-Йорк. С. 15–25. ISBN 978-0-932633-42-2.
  7. Перейти ↑ Hoare, CAR (1972). «Качество программного обеспечения» . Практика и опыт работы с программным обеспечением . Вайли. 2 (2): 103–105. DOI : 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. Перейти ↑ Sommerville, Ian (2004). Программная инженерия (седьмое изд.). Пирсон. С. 118–123. ISBN 0-321-21026-3.
  13. Перейти ↑ Hoare, CAR (1981). «Старая одежда императора» (PDF) . Коммуникации ACM . ACM. 24 (2): 75–83. DOI : 10.1145 / 358549.358561 . S2CID 97895 . Проверено 25 ноя 2019 .  
  14. Перейти ↑ Sommerville, Ian (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» . Проверено 26 ноября 2013 .
  20. ^ Несколько (вики). «Лучшие практики» . Докфорж . Проверено 13 ноября 2012 .
  21. ^ "Повторяющиеся травмы напряжения" . Проверено 30 октября 2016 года .
  22. ^ См., Например: «Единственная точка определения на примере» . Проверено 30 ноября 2015 . «Ничего не повторяй. Стремитесь к единой точке определения для каждого аспекта вашего приложения [...] ».
  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. DOI : 10,1109 / MS.2012.127 . ISSN 0740-7459 . S2CID 38239662 .  
  38. ^ Круг, Стив (2014). Не заставляйте меня думать, повторюсь: здравый подход к юзабилити в Интернете . Бейл, Элизабет, Стрейгер, Арен, Матчо, Марк (Третье изд.). [Сан - Франциско, Калифорния]. ISBN 978-0-321-96551-6. OCLC  859556499 .
Общий
  • Harbison, Samuel P .; Стил, Гай Л. (2002). C - Справочное руководство . ISBN 978-0-13-089592-9.
  • Расширение жизненного цикла разработки до программного обеспечения для обеспечения безопасности продукта, версия 2.0, октябрь 2008 г. описывает принципы и методы безопасности, которые разработчики программного обеспечения, тестировщики и интеграторы могут применять для достижения двойной цели - создания более безопасных программно-интенсивных систем и проверки безопасности. программного обеспечения, которое они производят.
  • Датта, Шив; Крюк, Гэри (26 июня 2003 г.). «Лучшие практики программирования на C» . developerWorks . IBM . Архивировано из оригинального 13 июля 2009 года . Проверено 21 января 2010 года .

Внешние ссылки [ править ]

  • Пол Бёрден, соавтор стандартов кодирования MISRA C и представитель PRQA в рабочей группе MISRA C более 10 лет, обсуждает распространенную ошибку стандарта кодирования: «нам не нужен стандарт кодирования !, нам просто нужно отлавливать ошибки. ! "