# БИБЛИОТЕКА Статистика Требования в проектах Redmine Управление Стейкхолдеры Информация Саморазвитие Логика, интеллект Социальные связи Экономика и общество ТЕСТИРОВАНИЕ Книги и ссылки QA и QC Этапы тестирования Тест план Тестовые случаи Баг-репорт Метрики Уровни тестирования Виды тестирования Шаблоны документов XPATH Безопасность Нагрузочное Android Автоматизация Selenium WebDriver Генератор ИНН и т.п. РАЗРАБОТКА Ресурсы Цикл разработки ПО Continuous Integration OOP - базис Frontend HTTP/REST основы Apache web-server Регулярные выражения git Javascript Perl Python Ruby Rust Полезности в Windows LINUX Ресурсы права, юзеры и группы crontab IP tables SSH консоль (терминал) tips & tricks useful apps БАЗЫ ДАННЫХ SQL MongoDB
Эта страница:
- Почерпнуть мудрость - Жизненный цикл разработки ПО (Software Development Life Cycle) - Непрерывная интеграция (Continuous Integration) - OOP - базис - Самые распространённые ошибки - Пару слов о мотивации
Этот раздел:
РАЗРАБОТКА Фронтенд HTTP/REST основы Apache web-server Регулярные выражения git Javascript Perl Python Ruby Rust Полезности в Windows
Разделы:
# MONGO DB SQL РАЗРАБОТКА БИБЛИОТЕКА LINUX ТЕСТИРОВАНИЕ
Кратко о разработке
— Что надо сделать для того чтобы спутники успешно выходили на орбиту?
— Отправлять их туда вместе с их разработчиками.
Почерпнуть мудрость
Жизненный цикл разработки ПО (Software Development Life Cycle)
Waterfall или Agile? Этот вопрос поднимается почти у каждого заказчика.

Проектный подход

software development lifecycle

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

Выбирают Waterfall, если заказчик(у):

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

Гибкий/итеративный подход

Гибкий/итеративный подход ("Agile") нацелен на минимизацию рисков путём сведения разработки к серии коротких циклов(итераций), которые обычно длятся 2-3 недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. Методология подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим "авралам" с массовым рефакторингом и переделками практически на каждой очередной итерации. В итеративном подходе предполагается очень плотное участие заказчика в процессе, он буквально должен жить с командой разработки, а в случае срыва сроков делить с ней риски.

Вот схематическое изображение жизненного цикла одного из самых распространённых методов гибкой работы, SCRUM: scrum

В этой диаграмме бросается в глаза её нелинейная форма, в которой выделяются наличие циклов ежедневной работы и месячных "спринтов".
Суть диаграммы в том, чтобы показать, откуда берутся выполняемые работы. Если бы речь шла о чистом управлении работами, на диаграмме не было бы слов "выбор требований", "демонстрация заказчикам", а просто обсуждались бы безымянные работы: менеджерские практики не работают с содержанием работ, они работают только с оптимизацией выполнения множества работ в рамках имеющихся ресурсов. Содержание работ при этом затрагивается управлением жизненным циклом. Гибкие методы -- это про управление жизненным циклом прежде всего, в них нужно обсуждать организацию инженерной работы, а не просто вопросы планирования и контроля исполнения работ.

Выбирают Agile, если заказчик:

  • готов отдать 80%-100% своего времени проекту с полным погружением;
  • обладает достаточной компетенцией и готов погружаться в разработку вместе с технарями;
  • готов разделить риски за срыв сроков или за невысокое качество работы подрядчика;
  • как и разработчик, отлично понимают, что на данный момент нормально требования не собрать, потому что они еще не выдуманы до конца, а работать начинать надо, потому что рынок, бизнес, и все такое.

Почерпнуть мудрость:

Непрерывная интеграция (Continuous Integration)

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

Типовая экосистема разработчика ПО при непрерывной интеграции: Типовая экосистема разработчика ПО при непрерывной интеграции На рисунке мы видим следующие сущности:

  • IDE
    Разработчик. Пишет код и в какой-то момент коммитит его в репозиторий исходных кодов.
  • Репозиторий
    Хранилище исходного кода и различных метаданных о нем. Отсюда система непрерывной интеграции загружает код в процессе сборки.
  • Система непрерывной интеграции
    Позволяет автоматизировать процессы сборки исходных кодов, публикации собранных приложений, либо информации о выявленных проблемах. Наша основная цель.
  • Стенд (на рисунке выглядит как сервер)
    В данном случае сервер, на который загружается приложение после успешной сборки.
  • Трекер ошибок
    Система контроля и отслеживания ошибок в работе или сборке приложения. Именно сюда система непрерывной интеграции может записать отчет в случае невозможности успешно завершить сборку приложения.

Примерная последовательность действий, выполняемая в процессе сборки приложения: Примерная последовательность действий, выполняемая в процессе сборки приложения Рассмотрим рисунок на примере типичного спринта: разработчик пишет код и загружает(1) его в репозиторий. Далее, по какому-либо событию, в дело вступает система непрерывной интеграции. Она загружает из репозитория необходимые исходные коды(2-3) и запускает процесс их сборки(4). В случае успеха, собранное приложение может быть загружено(5-1) на стенд. В случае неудачи, система может создать(5-2) задачу в багтрекере.

OOP - базис

Объектно-ориентиированное программирование (ООП) — методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования/

Инкапсуляция — свойство системы, позволяющее объединить данные и методы, работающие с ними, в классе. Некоторые языки (например, С++) отождествляют инкапсуляцию с Сокрытием, но большинство (Smalltalk, Eiffel, OCaml) различают эти понятия.
Инкапсуляция обеспечивается следующими средствами:

  • Контроль доступа. Поскольку методы класса могут быть как чисто внутренними, обеспечивающими логику функционирования объекта, так и внешними, с помощью которых взаимодействуют объекты, необходимо обеспечить скрытость первых при доступности извне вторых. Для этого в языки вводятся специальные синтаксические конструкции, явно задающие область видимости каждого члена класса. Традиционно это модификаторы public, protected и private, обозначающие, соответственно, открытые члены класса, члены класса, доступные внутри класса и из классов-потомков, и скрытые, доступные только внутри класса. Конкретная номенклатура модификаторов и их точный смысл различаются в разных языках.
  • Методы доступа. Поля класса в общем случае не должны быть доступны извне, поскольку такой доступ позволил бы произвольным образом менять внутреннее состояние объектов. Поэтому поля обычно объявляются скрытыми (либо язык в принципе не позволяет обращаться к полям класса извне), а для доступа к находящимся в полях данным используются специальные методы, называемые методами доступа. Такие методы либо возвращают значение того или иного поля, либо производят запись в это поле нового значения. При записи метод доступа может проконтролировать допустимость записываемого значения и, при необходимости, произвести другие манипуляции с данными объекта, чтобы они остались корректными (внутренне согласованными). Методы доступа называют ещё аксессорами (от англ. access — доступ), а по отдельности — геттерами (англ. get — чтение) и сеттерами (англ. set — запись)

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

Полиморфизм подтипов (иногда просто - "полиморфизм") — свойство системы, позволяющее использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.

Класс - универсальный, комплексный (составной) тип данных, состоящий из тематически единого набора:

  • "полей" - переменных более элементарных типов;
  • "методов" - процедуров и функций, связанных с классом, для работы с его полями. Они определяют действия, которые можно выполнять над объектом такого типа, и которые сам объект может выполнять. То есть он является моделью информационной сущности с внутренним и внешним интерфейсами для оперирования своим содержимым (значениями полей).

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

Самые распространённые ошибки
  1. неосмысленные имена переменных;
  2. проверка наиболее возможной ситуации находится в конце списка проверок;
  3. отсутствие проверки “если ничего из указанного”;
  4. отсутствие валидации параметров метода в самом начале метода;
  5. отсутствие валидации данных до выполнения операции с данными в БД типа update/insert (не отлавливаются пустые значения);
  6. обращение в БД с запросами вида “select * from A” (возвращает очень много данных);
  7. неоправданное и неаргументированное время жизни при использовании кэшей;
  8. ошибки с правами доступа (пароли лежат где-то в открытом виде);
  9. глобальные константы в коде классов;
  10. куча одинаковых(очень похожих) кусков кода не вынесены в функции;
  11. использование функции, когда не полностью известно(понятно) её предназначение и принцип работы (например, использование функции округления, не интересуясь в какую сторону она округлит);
  12. отсутствие комментариев на сложных участках;
  13. подключать/использовать библиотеки/функции дублирующие функционал друг друга, когда можно было бы обойтись чем-то одним из арсенала;
  14. оставлять в коммите код, использовавшийся для дебага (может тормозить систему, заполняет логи лишней информацией);
  15. размещение сложных условий в одну строку (нечитабельно, например t = y && p &&!q&&(!!l)?k?m:n :0);
    Никогда не пишите длинных if-ов
  16. при переборе массивов, особенно двумерных, каждый раз использовать обращение к элементу массива, а не присвоить его значение какой-нибудь переменной и работать с ней в пределах, даёт существенный прирост скорости в часто выполняемых операциях в том числе с клиентской стороны при обхода DOM-дерева, иначе каждый раз у элемента верхнего будет искаться наследник и так далее.
Пару слов о мотивации
Источник: комментарий к какой-то из статей на habrahabr.ru

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

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