# БИБЛИОТЕКА Статистика Redmine Системная инженерия Стейкхолдеры Управление Критическая цепь Linux Информация Социальные связи Саморазвитие Логика, интеллект Политэкономия Сумма технологии АНАЛИТИКА Ресурсы ПО для аналитики Требования Спецификации Трассировка Нотации Архитектура РАЗРАБОТКА Ресурсы Цикл разработки ПО Continuous Integration OOP - базис Frontend HTTP/REST Apache web-server Регулярные выражения git Javascript Perl Полезности в Windows ТЕСТИРОВАНИЕ Книги и ссылки QA и QC Цикл тестирования 1 Тест-анализ 2 Тест план 3 Тест-дизайн и покрытие Уровни тестирования Виды тестирования Баг-репорт Шаблоны документов XPATH Безопасность Нагрузочное Android Автоматизация Selenium WebDriver Генератор ИНН БАЗЫ ДАННЫХ SQL MongoDB
Эта страница:
- Почерпнуть мудрость - Жизненный цикл разработки ПО (SDLC) - Непрерывная интеграция (CI) - Модные процессы разработки - OOP - базис - Распространённые ошибки - Пару слов о мотивации
Ещё в этом разделе:
РАЗРАБОТКА Фронтенд HTTP/REST основы Apache web-server Регулярные выражения git Javascript Perl Python Ruby Rust Полезности в Windows
Другие разделы:
# АНАЛИТИКА MONGO DB SQL РАЗРАБОТКА БИБЛИОТЕКА ТЕСТИРОВАНИЕ
Кратко о разработке
Все рассказы о введении KPI для программистов неизменно заканчивались тем, что программисты переставали работать и вместо этого прокачивали KPI.
Зарплата зависит от числа закоммиченных строк кода? --пишем к каждой функции комментарий длиннее тела функции.
Зависит от числа закрытых тикетов? --заводим по десять тикетов на все аспекты каждой проблемы, а потом все закрываем одним патчем. Ну и так далее.
Почерпнуть мудрость

Разное

Интерфейсы

JAVA

Жизненный цикл разработки ПО (SDLC)
Что почитать на тему:

Для IT-продуктов мы можем построить расширенную V-модель:

Если мы работаем по Agile, то все эти этапы выполняются внутри каждой пользовательской истории (user story). Если у нас более длинные итерации, то по этим фазам проходит сразу целая очередь или подсистема.
На V-модели видно сколько проектирования должно быть выполнено до старта нашего проекта. С другой стороны, видно, какие действия будут совершены для окончательной валидации нашего предмета поставки.
Соответственно, результаты предшествующего проектирования должны поступить нам на вход (причем, не всегда "самотёком"), а действия по валидации будут вызывать запросы на изменения, поддержку или дефекты, выявленные после поставки.

ЖЦ производства информационной системы в общем виде являет собой следующую развёртку во времени:

(скачать схему в XML)

Реализация программного продукта (Процесс 10 из схемы выше) в общем виде выглядит так:

Waterfall или Agile? Этот вопрос поднимается почти у каждого заказчика.

Водопад

software development lifecycle

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

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

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

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

Гибкий/итеративный подход ("Agile") базируется на т.н. "agile-манифесте":

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

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

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

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

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

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

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

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

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

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

Модные процессы разработки

Domain Driven Design - Разработчик сначала слушает не требования Клиента, но те слова, которые он употребляет. Тем самым определяя онтологию (предметную область) того что хочет Клиент. И её начинает реализовывать на самом нижнем уровне, добавляя те сущности, названия которых употреблял Клиент. А затем, уже когда Клиент более-менее сам начинает понимать что он хочет - просто перекомпоновывает и дорабатывает.

Test Driven Design - сначала тест, потом разработка. У исповедующих этот способ разработки есть большие экзистенциальные трудности. Например, большая проблема для составления тестов идущих от логического НЕ. Трудно, скажем, написать тест на "система не должна взрываться", потому что непонятно как это проверить. Разработчик идёт от верификации, а валидация, которой в конечном счёте заинтересуется Клиент при приёмке - отсутствует.

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

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

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