Пять качеств хорошего менеджера

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

  1. умение формулировать чёткие цели;
  2. последовательность;
  3. ответственность;
  4. заинтересованность проектом;
  5. компетентность;

Continue reading

Поделиться
Posted in Management, Programming | Tagged , , , | Leave a comment

Больше, чем спорт

В большом спорте есть много примеров человеческой доблести. Возможно, поэтому спортивные соревнования являются одним из самых популярных способов проведения досуга. В мире спорта каждый может найти занятие для себя: подвижные игры и силовые упражнения, командные и индивидуальные соревнования, — а можно быть просто сочувствующим болельщиком. И в любом случае найдутся единомышленники, которые могут объединиться в клубы. По прошествии времени спорт из увлечения вырастает в нечто большее и становится неотъемлемой частью жизни. Люди, занимаясь физическим развитием, совершенствуют свой дух и поднимают мораль. Continue reading

Поделиться
Posted in Society, Sport | Tagged , , , , | Leave a comment

Язык не имеет значения…

Довольно расхожая фраза в IT кругах, смысл которой часто остаётся не понятым. Я думаю, многие в начале карьеры программиста слышали о том, что конкретный язык и технология — это лишь реализация более фундаментальных идей. И качество программиста оценивается не столько количеством библиотек, которые он использовал в работе, сколько знанием и пониманием общих знаний, таких как: структуры данных, алгоритмы, структура информационных систем и т.д. Continue reading

Поделиться
Posted in Programming, Society | Tagged , , , | Leave a comment

Жизнь в консервной банке

Однажды, гуляя по летнему городу, я любовался видами канала Грибоедова. Я никуда не торопился и мог полностью насладиться чудесным солнечным днём. Тогда я увидел много интересных мелочей, которые оставались для меня незаметными в потоке будничных событий. Это было удивительно и одновременно обидно: как я не замечал всего этого великолепия раньше?

Continue reading

Поделиться
Posted in Society | 2 Comments

Сначала код?

Золотая лихорадка программного обеспечения, о которой я писал в предыдущей статье, зачастую приводит к такому широко распространённому мнению, что, в первую очередь, важно выпустить продукт, а потом его можно будет улучшить. Не могу не отметить, что такая точка зрения в корне не верна: обычно «потом» не наступает никогда и тому есть несколько причин. Continue reading

Поделиться
Posted in Management, Programming | Tagged , , , , , , | Leave a comment

Золотая лихорадка

Во все времена желание быстро и легко разбогатеть бередило воображение людей. Множество отчаянных безумцев всегда были готовы броситься в бурлящий водоворот жизни в надежде выловить выигрышный лотерейный билет: кто-то отправлялся в опасные неизведанные дали за диковинными товарами; кто-то шёл на Аляску в поисках золотоносной жилы; другие закладывали своё имение, вкладывая последние деньги в рискованные предприятия. Когда ты сидишь в офисе в уютном кресле, почитывая в социальных сетях как твои друзья хорошо развлекаются в безопасных он-лайн играх, такие истории кажутся чем-то неправдоподобным, а люди, пускающиеся в такие авантюры ,- не в себе. Но стоит вспомнить исторические примеры и становится ясно, что человечество никогда не отказывалось от жажды «легкой» наживы, как ни высока была бы конечная цена. И даже сейчас многие среди нас действуют подобным образом, гоняясь за мнимыми богатствами, ставя под угрозу своё будущее и не только. Continue reading

Поделиться
Posted in Films, Management, Society | Tagged , | Leave a comment

Как не надо делать REST

Данная статья является вольным переводом статьи REST Anti-Patterns by Stefan Tilkov. 

Начнем, пожалуй, с краткого списка типичных ошибок при разработке RESTful API:

  1. Передача всего через GET запрос
  2. Передача всего через POST запрос
  3. Отсутствие кэширования
  4. Неиспользование кодов ответа сервера
  5. Злоупотребление cookies
  6. Отстутствие гипермедиа
  7. Игнорирование MIME типов
  8. Нарушение самодокументации

Давайте остановимся на каждом пункте более подробно.

Передача всего через GET запрос

Для многих людей REST просто означает использование HTTP для предоставления доступа к некоторым функциям приложения. Фундаментальной и самой важной операцией (стого говоря, слово «глагол» или «метод» подошло бы лучше) является метод HTTP GET. GET запрос должен получать представление некоего ресурса, определённого по URI, однако во множестве библиотек и API легко увидеть как URI используется не как идентификатор ресурса, а в качестве простого и удобного способа передачи параметров. В результате появляются URI похожие на этот: http://example.com/some-api?method=deleteCustomer&id=1234 Подобная последовательность символов, составленная в URI, ничего нам не говорит о том, соответствует ли система REST, но в этом конкретном случае мы можем догадываться о том, что метод GET не будет «безопасным»: вызывающий будет нести ответственность за результат (удаление пользователя), хотя спецификация говорит, что неверно использовать метод GET в таких случаях. Единственное, что говорит в пользу такого подхода это простота реализации и тестирования с помощью браузера: всего-то вам нужно вставить URI в адресную строку, подправить пару параметров и готово. Однако есть и сложности при таком подходе:

  1. URI не является идентификатором ресурса; скорее URI используется для передачи операций и их параметров;
  2. HTTP метод не всегда семантически верен;
  3. Подобные ссылки обычно не предназначены для добавления в закладки
  4. Есть риски, что поисковые краулеры, такие как Google, могут привести к неожиданным побочным эффектам

Заметим, что API, реализующие этот антишаблон, могут быть «случайно RESTful». Например: http://example.com/some-api?method=findCustomer&id=1234 Определяет ли этот URI операцию и её параметры или же он идентифицирует ресурс? Аргументировать можно обе точки зрения: это может быть валидный URI, который можно добавить в закладки; обращение к этому URI через GET может быть вполне «безопасно»; сервис может прислать ответ в разных форматах в зависимости от заголовка Accept и может поддерживать кэширование. Во многих случая такой результат будет непреднамеренным. Часто API начинают писать с реализации интерфейса вывода, но когда разработчики начинают добавлять функции для ввода данных, ваши иллюзии рассеиваются (маловероятно, что обновление пользователей будет происходить через PUT запрос к этому URI; скорее всего разработчики добавят новый).

Передача всего через POST запрос

Этот антишаблон очень похож на предыдущий, только теперь используется POST HTTP метод. POST имеет помимо URI еще и тело запроса. Типичный сценарий использует единый URI для обращения к нему через POST и разнообразные сообщения для выражения различных намерений. Это практически реализация SOAP 1.1 web-сервисов, с использованием HTTP в качестве «транспортного протокола» и SOAP сообщений, возможно с заголовками адресации web-служб, которые определяют, что должно произойти. Можно утверждать, что передача всего через POST запрос имеет все те же недостатки, что и вариант с GET запросом. Просто это немного сложнее использовать, а также нельзя использовать ни кэширование (даже случайно), ни поддержку закладок. В конце концов, это не то, чтобы нарушает принципы REST, а, скорее, просто их игнорирует.

Отсутствие кэширования

Даже если вы используете методы так, как и должно было быть, всё же вы можете легко потерять возможность использовать кэширование. Самый простой способ так сделать это просто добавить следующий  HTTP-заголовок в ответ:

Cache-control: no-cache 

Подобного рода действие просто предотвратит сохранение чего бы то ни было в кэш. Конечно, возможно именно этого вы и добивались, но чаще это не так. Скорее всего, это настройка по умолчанию вашей платформы. В любом случае, поддержка эффективных кэширования и обновлений — одно из ключевых преимуществ использования RESTful HTTP. Сэм Руби (Sam Ruby) предполагает, что ключевым вопросом при определении степени RESTful сервиса является: «Поддерживаются ли ETags»? (ETags — механизм, появившийся в HTTP 1.1, который позволяет клиенту проверять является ли закэшированное состояние всё еще актуальным с помощью криптографической контрольной суммы). Самый простой способ генерировать корректные заголовки — это возложить эту задачу на ту часть инфраструктуры, которая «знает», как это правильно делать. Например, генерировать файл в директории под управлением web-сервера, такого как Apache HTTPD. Конечно, это можно сделать и на клиентской стороне тоже: когда вы реализуете программного клиента к RESTful сервису, в ваших же интересах использовать доступные возможности кэширования и совсем необязательно получать каждый раз новое состояние. Например, сервер может послать некоторую информацию, чьё представление будет «свежим» в течение следующий 600 секунд после получения (возможно, система обновляется только каждые 30 минут). Тогда нет совершенно никакого смысла в том, чтобы постоянно запрашивать ту же информацию в более короткий промежуток времени.  Аналогично серверному решению, использование кэширующего прокси, такого как Squid, на клиентской стороне может быть лучшим выбором, чем реализация логики собственными силами. Кэширование в HTTP  протоколе — очень мощный и сложный механизм; за более подробным разбором советуем обратиться к статье Марка Ноттингема Cache Tutorial.

Неиспользование кодов ответа сервера

Многие web-разработчики не знают, но HTTP имеет великое множество кодов состояния уровня приложений для обработки различных сценариев. Большинство из нас знакомы с 200 («OK»), 404 («Not found»), и 500 («Internal server error»). Но есть еще и много других, и правильное их использование позволяет клиентам и серверам общаться на более богатом сематически уровне. Например, код ответа 201 («Created») сигнализирует, что был создан новый ресурс, URI которого может быть получен из заголовка ответа Location. Код ответа 409 («Conflict») информирует клиента о том, что есть конфликт, другими словами, возможно PUT использует данные старой версии ресурса. Код 412 («Precondition Failed«) говорит о том, что состояние сервера не соответствует ожиданиям клиента. Другой аспект правильного использования кодов состояния затрагивает клиента: предполагается что коды разных классов (т.е. весь 2хх диапазон, весь 5хх диапазон) будут трактоваться согласно общим подходам — то есть, клиент должен трактовать все коды 2хх как индикатор успешной работы, даже если не было написано обработчика конкретного вернувшегося кода. Много приложений с претензией быть RESTful возвращают только 200 или 500, или даже только 200 (с текстом ошибки в теле ответа — снова, посмотрите SOAP). Если вам угодно, вы можете назвать это «передача ошибок с кодом 200», но, как не назови, всё же верным определением ситуации будет: если вы не используете богатство семантики кодов HTTP, вы теряете возможность для увеличения шансов повторного использования, лучшей совместимости и меньшего связывания.

Злоупотребление cookies

Использование cookies для передачи ключа состояния серверной сессии является другим антишаблоном REST. Cookies — точный признак того, что что-то не RESTful. Правильно? Нет, не обязательно. Одним из основополагающих принципов REST является отсутствие состояний — не в том смысле, что сервер не может хранить никакие данные: это нормально, если хранятся состояния ресурса или клиента. А вот состояние сессии недопустимо хранить в силу ограничений, накладываемых на  масштабируемость, надёжность и связанность. Чаще всего cookies используют для хранения ключа, который является ссылкой на некую серверную структуру данных, хранящуюся в памяти. Это означает, что cookie, которые браузер посылает с каждым запросом, используются для обеспечения диалогового (сессионного) состояния. Если cookie используется для хранения некоторой информации, например авторизационной метки, которую сервер может проверить, не опираясь на состояние сессии, — это идеально RESTful с одним исключением: cookies не должны использоваться для кодирования информации, которую можно передать более стандартными способами (например, в URI, в некоторых стандартных заголовках или (в редких случаях) в теле запроса). Например, предпочтительнее использовать HTTP авторизацию с точки зрения RESTful HTTP.

Отсутствие гипермедиа

Первой идеей REST, которую трудно принять, является стандартный набор методов. Теория не определяет, какие методы входят в стандартный набор, а лишь только говорит, что должно быть ограниченное множество, применимое ко всем ресурсам. HTTP определяет их как GET, PUT, POST и DELETE (основные, как минимум), и приведение всей семантики вашего приложения к этим четырём глаголам потребует некоторой сноровки. Но как только получается сделать это, люди начинают использовать лишь часть того, что позволяет REST — вариант web-ориентированной CRUD (Create (Создать), Read (Прочесть), Update (Обновить), Delete (Удалить)) архитектуры. Приложения, которые использую такой подход, нельзя назвать “не RESTful”, они просто не используют другую базовую концепцию REST: гипермедиа в качестве механизма состояния приложения.

Гипермедиа — концепция связывания вещей вместе — то, что делает web сетью, соединённым множеством ресурсов, где смена состояний приложения происходит посредством перехода по ссылкам. Возможно, это звучит несколько эзотерично, но есть некоторые обоснованные причины для следования этому принципу.

Первым индикатором антишаблона «Отсутствие гипермедиа» является отсутствие ссылок в представлениях. Очень часто URI создаётся на стороне клиента по некоторым правилам, но при этом клиент практически никогда не преходит по ссылкам, присылаемых сервером. Чуть лучший вариант — использовать смесь создания URI и переходов по ссылкам, которые обычно представляют взаимосвязи между моделями данных, лежащих в основе приложения. Но в идеале, клиент должен знать единственный URI; всё остальное: индивидуальные URI, равно как и правила создания (например, список параметров), — должно быть передано через гипермедиа, в виде ссылок в представлении ресурсов. Отличным примером является протокол AtomPub с его нотацией  документов, который предоставляет именованные элементы для каждой коллекции в описываемом домене. Наконец, возможные переходы состояний, через которые может пройти приложение, должны быть получены динамически, а клиент должен иметь возможность переходить по этим ссылкам с минимально возможными предварительными знаниями о них. Хорошим примером такого подхода является HTML, который содержит достаточное количество информации для браузера для предоставления полностью динамического интерфейса пользователю.

Я рассматривал добавление «человекопонятного URI» в качестве ещё одного признака антишаблона. Но я не стал этого делать, потому что я люблю читаемые и «хачные» URI как никто другой. Но когда кто-то только начинает работать с REST, он часто тратит впустую бесконечно много времени в дискуссиях о «правильных» URI, но абсолютно забывает об аспекте гипермедиа. Так что моим советом будет ограничить себя во времени поиска идеальных URI (в конце концов, это только строки) и направить эту энергию на поиск хороших мест для вставки ссылок в представления.

Игнорирование MIME типов

Нотация HTTP для согласования содержания позволяет клиенту получать разные представления ресурса в зависимости от его нужд. Например, ресурс может иметь представления в разных форматах, таких как: XML, JSON или YAML, — для разных клиентов, реализованных на Java, JavaScript и Ruby соответственно. Или может быть «машинный» формат, такой как XML, в дополнение к версиям PDF или JPEG для людей. Или он может поддерживать обе (v1.1 и v1.2) версии какого-то особого формата. В любом случае, хоть и есть много здравых доводов в пользу поддержку единственного формата, но такой подход будет означать лишь ещё одну упущенную возможность.

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

Нарушение самодокументации

Этот антишаблон настолько распространён, что его можно встретить почти в каждом REST приложении, даже в тех, что были созданы теми, кто называет себя «RESTафарианами», включая меня: нарушение ограничения самодокументации (которая является идеалом, имеющим не так много общего с научной фантастикой об ИИ, как может показаться на первый взгляд). В идеале, сообщение – HTTP запрос или HTTP ответ, включая заголовки и тело, — должно содержать достаточно информации для любого шаблонного клиента, сервера или посредника, чтобы обработать его. Например, когда ваш браузер получает защищённое представление ресурса в виде PDF, вы можете увидеть все существующие соглашения в рамках стандартов: есть какая-то авторизация через HTTP; скорее всего есть некие механизмы кэширования и проверки кэша; заголовок content-type, посланный сервером (application/pdf), запускает просмотрщик PDF, зарегистрированный в системе; и, наконец, вы можете прочесть PDF на вашем экране. Любой пользователь на планете может использовать свою собственную инфраструктуру для выполнения того же запроса. Если серверные разработчики добавят ещё один тип содержимого, клиентам нужно будет только удостоверится, что установлен нужный просмотрщик.

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

Выводы

Даже после того, как “Банда четырёх” опубликовала свою книгу, которая дала старт продвижению шаблонов, множество людей не понимают их и пытаются использовать как можно больше шаблонов — явление, которое так долго высмеивается. Шаблоны должны применяться тогда и только тогда, когда подходят для решения задачи. Аналогично, одни могут с религиозным рвением избегать всех перечисленных антишаблонов. Во многих случаях, есть обоснованные причины нарушения правил, или в терминологии REST — обхода ограничений. Это нормально. Но также полезно опасаться таких действий и принимать более взвешенные решения.

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

P.S. Если у вас при прочтении статьи возникли вопросы, я с радостью постараюсь на них ответить.

 

Поделиться
Posted in Programming, Web | Tagged , , , , | 3 Comments

Профессионализм

Однажды на собеседовании меня спросили, что я вкладываю в понятие «профессионал»? Этот вопрос заставил меня немного задуматься: действительно, чем отличается профессионал от любителя или дилетанта? Ведь все они способны сделать продукт: для художников это будет картина, для программистов — программа. Однако есть разительные отличия между произведением мастера и любителя. Иногда эти различия видны невооруженным глазом обывателя, иногда требуются специальные знания для того, чтобы найти разницу, но она всё равно есть.

Если немного поразмыслить, то определённо приходишь к выводу: чтобы овладеть экспертными знаниями в определённой области необходим опыт. Как же приобритается этот драгоценный опыт? Широко распространено мнение, что объём полученных знаний прямо пропорционален времени, потраченному на изучение материала: так часто сотрудник получает расширение полномочий и повышение в должности за выслугу лет, при условии, конечно, что за время работы он не допускал значительных (ведь все мы ошибаемся) ошибок. Однако, при таком подходе происходит подмена понятий и человек вознаграждается за терпение, а не за полученные знания. Представьте, что когда-нибудь в поликлинике уколы, а ещё хуже операцию, вам будет делать уборщица, которая проработала много лет на одном месте и пристально следила за другими врачами. Скорее всего, вы усомнитесь в её квалификации как врача, хотя, возможно, и найдёте возможным прислушаться к её советам.

Таким образом мы приходим к проблеме определения самих понятий «опыт» и «знание». На мой взгляд, и тут я буду рад услышать другие мнения, знания определяются системой взаимосвязей между различными объектами тематики. Также важным критерием является возможность находить новые взаимосвязи. Это означает, что поставить на конвеер производство сайтов на какой-то платформе не значит стать профессиональным программистом. Равно как и тысяча вырванных зубов не будет свидетельством профессионализма стоматолога. Эксперт, решая конкретную задачу, должен видеть весь комплекс связанных проблем (вот для чего нужны взаимосвязи), чтобы после удаления зуба не было воспалительного процесса. Всё-таки конечная цель — это не избавление от зуба, а избавление от боли. Так и написание сайта или программы не есть самоцель и профессиональному разработчику должна быть видна проблема, которую он решает.

Поделиться
Posted in Management, Society | 5 Comments

Как управлять требованиями

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

  1. требования к продукту зафиксированы в базе знаний (корпоративная wiki, система управления задачами, документация разработчика, система контроля версий и т.п.) до начала работы над продуктом, что позволяет следить за историей изменений и непротиворечивостью требований;
  2. любой член команды имеет доступ к полным требованиям. Это решит проблему коммуникации и обеспечит целостное видение проекта.
  3. требования оформлены единообразным способом понятным для каждого участника команды. Это условие в сочетании со вторым позволяет определить форму и вместе с тем необходимый минимум информации для описания требований.

Ниже мы рассмотрим какими способами можно обеспечить такой процесс.

Устное общение

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

Пользовательские истории

Пользовательская история — это отнюдь не байка о том, как несчастный пользователь не смог зарегистрироваться в системе в силу недостаточно высокого IQ для прохождения препятствия в виде регистрационной формы. Пользовательская история — это что-то, что представляет ценность для проекта. Что формирует стоимость продукта. В конце концов, это то, что пользователь может сделать в системе. Таким образом, пользовательские сценарии описывают требования к проекту с точки зрения владельца и в какой-то степени функциональность ПО. Способов реализации пользовательских историй, как обычно, огромное множество (сколько людей — столько и мнений). Однако, есть ключевые вещи в каждом сценарии (как в повестях есть завязка, кульминация, развязка, главный герой, мораль и т.д.):

  • Роль пользователя в системе. Например, администратор;
  • Действие, которое пользователь может совершить;
  • Цель, которую достигает пользователь.

Дополнительными могут быть такие параметры, как:

  • Приоритет;
  • Сложность;
  • Ограничения, накладываемые системой;
  • Нефункциональные требования. Например, работа веб-приложения оффлайн.
  • и другие…

Примером пользовательской истории может служить следующее высказывание:

Администратор рекламного агентства может управлять медиапланами рекламной кампании для повышения её, кампании, эффективности.

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

Администратор рекламного агентства может создать медиаплан для управления расходами на рекламную кампанию.

Администратор рекламного агентства может редактировать медиаплан для изменения параметров расходов на текущую рекламную кампанию.

Администратор рекламного агентства может удалить медиаплан рекламной кампании для прекращения рекламной кампании.

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

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

Проектирование. UML диаграммы

UML (англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, согласно wikipedia. Исходя из названия, очевидно, что эта нотация, разработанная консорциумом OMG, предназначена для описания моделей, по большей части програмного обеспечения. Для разных типов моделей в UML предусмотрены разные графические представления (диаграммы). Рассмотрим диаграммы, которые помогут нам описать информационную систему на этапе постановки задач.

Диаграмма прецедентов (Use case diagram)

Начнём с уже известных нам пользовательских историй. Для их изображения в нотации UML используется диаграмма прецедентов. Ниже изображена диаграмма прецедентов для последнего примера из раздела Пользовательские истории. На этой диаграмме мы видим два элемента: актёр (actor, действующее лицо) — пользователь системы; и прецедент (use case, вариант использования) — действие, которое пользователь может выполнить в системе. На самом деле, на ней есть ещё и третий элемент, который позволяет ассоциировать действующее лицо с доступными ему вариантами использования. Реальные диаграммы вариантов использования могут выглядеть сложнее, так как позволяют:

  • показать несколько ролей;
  • объединять прецеденты в подсистемы
  • показывать взаимодействия между прецедентами (обобщение, включение, расширение)
Ниже приведен пример диаграммы прецедентов, спроектированной для системы учёта платежей:

Диаграмма классов (Class diagram)

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

Диаграмма деятельности (Activity diagram)

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

Выводы

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

  • Диаграмма состояний (State machine diagram). Она используется для описания переходов состояний объекта (например, статус платежа)
  • Диаграмма последовательности (Sequence diagram). Используется для описания последовательных взаимодействий в реальном времени.
  • Диаграмма коммуникации (Communication Diagram). Используется для описания взаимодействия между разными системами, частями системы или действующими лицами посредством сообщений.
Также я хочу отметить, что графическое представление требований и моделей значительно легче для восприятия, чем текстовое. А значит использования диаграм сократит время коммуникаций, которое тратится на уточнения задач. Однако, и этот подход не гарантирует однозначную трактовку поставленных условий, хотя и сужает область возможных отклонений.

Test driven development

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

Модульное тестирование

Модульное тестирование призвано помочь разработчикам в поиске ошибок в логике выполнения программы. Выполнение модульных тестов означает, что каждая часть системы ведёт себя ожидаемым образом и, как следствие, что система не сможет прийти в противоречивое состояние. Значит для написания модульных тестов необходимо выделить части системы, взаимодействие которых вызывает опасения, и определить «ожидаемое поведение».  Обычно в качестве «частей системы» выступают публичные методы классов. Их тестируют как «чёрный ящик» на определённом наборе данных, который и описывает «ожидаемое поведение». Как правило набор данных состоит из пограничных значений; значений, которые приводят к исключениям; и несколькими значениям из области допустимых.

Приёмочное тестирование

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

Выводы

Мы рассмотрели разные возможности для описания требований к программному продукту, однако, не стоит предполагать, что они являются взаимоисключающими. Каждый из них позволяет взглянуть на задачу под другим углом зрения и применения комплекса методик позволит получит более полную картину разрабатываемого проекта, а значит и лучше контролировать разработку. Сдругой стороны не стоит думать, что применение всех приёмов сразу прояснит все неясности и решит все проблемы. Или что, для всеобъемлющего понимания необходимо написать все пользовательские сценарии, несколько диаграмм и обязательно сделать 100%-ное покрытие тестами. К постановке задач необходимо подходить с умом и выбирать наиболее эффективные решения, как и в любом другом деле.

P.S. Как говорил Фейнман в своих лекциях по физике, «мы понимаем явление, если находим ему несколько различных объяснений».

Поделиться
Posted in Management, Programming | Tagged , , , , | 1 Comment

Россия — страна возможностей или покинь страну до полуночи

Россия, во истину, — страна возможностей. В силу идиотского стечения обстоятельств, равно как и идиотского исполнения своих обязанностей инспектором УФМС, мне вместо запланнированной поездки в Великий Новгород представилась уникальная возможность — раздобыть билеты, чтобы вылететь заграницу в течение 6 часов, не имея никакой визы в паспорте (хочу сказать, что в противном случае мне грозила депортация из России на срок до трех лет). Что бы Вы делали, если Вам необходимо поехать туда-не-знаю-куда, но как можно скорее?

Вот и я в состоянии растерянности, истерии и некоторого страха отправился в аэропорт пытать своё счастье. Не прошло и полутора часов, как я оказался в аэропорту. Нужно отметить, что счастье оказалось крепким орешком (кокосовым, наверное) и отказалось сразу перейти на мою сторону: замечательный рейс в Стамбул через Швейцарию, найденный в интернете на сайте Озона, купить в офисе Swiss Airlines не удалось, а покупать на сайте было страшно, уже имея проблемы с заказом в этой системе. Однако девушка-оператор любезно (в отличие от инспектора УФМС; да и в обличие ей тоже) предложила попробовать поинтересоваться в кассах: мол у авиакомпании «Россия» всегда много рейсов — может и сейчас что-нибудь есть подходящее. Стрелки часов подползали к восьми, и с каждой минутой ощущение обреченности во мне крепло все сильнее. Как будто вот-вот стукнет полночь, и моя карета превратиться в тыкву, а я сам — в золушку.

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

Продолжением истории послужило нахождения каких-то странных касс на втором этаже Пулково 2. Оператор со скучающим видом спросила, чем она может мне помочь? Я опять изложил свои пожелания: в страну с безвизовым въездом и как можно быстрее. Я понимал, что о странах с безвизовым въездом я могу знать больше кассиров. Но я не ожидал, что выборка рейсов, которые вылетают в следующие 5 часов, станет для этой девушки таким сложным делом: она была готова выписать билет в любое место и на любое время, если бы я ей их сказал, как это делает большинство пассажиров, но я не мог. А она сполна воспользовалась возможностью ничего не делать на рабочем месте, предоставляемую гражданам РФ за вознаграждение, называемое «зряплатой», и продолжила мирно дремать в свое уютном кресле. Оказалось, что работающие кассы находились на первом этаже. Так что я оставил попытки реанимировать девушку на втором этаже и спустился на первый.

К моему счастью и некоторому удивлению обнаружилась касса без очереди и очень любезным оператором, от которой я в течение трех минут узнал, что осталось всего три рейса, чтобы успеть покинуть страну вовремя. На выбор били следующие направления: Рига, Алма-Ата и Сеул. В Риге не нашлось пересадок в страны, которые я бы мог посетить без визы; поездка в Алма-Ату таила в себе угрозу попутешевствовать в рамках границ союзных государств, таких как, например, Беларусь, где не фиксируется факт пересечения границы РФ. Перебирая возможные варианты, я часто ловил на себе удивленный взгляд оператора: возможно, она впервые в жизни видела человека, который настоятельно искал возможность не преступить закон любой ценой. В конце концов оставался лишь рейс в Сеул с наиболее удобным продолжением в Бангкок. Таким образом моё желание просто съездить в Великий Новгород лёгким движением руки (на самом деле от инспектора, который стал инициатором всей суматохи, и этого не потребовалось) превратилось в захватывающее путешествие в Тайланд. Россия, во истину, — страна возможностей.

Поделиться
Posted in Uncategorized | 3 Comments