Проектирование и рефакторинг *

Вы пишете лишнюю документацию для вашего проекта? Нет? Тогда вам ее, скорее всего, недостаточно.

Угадать для каждого конкретного проекта необходимый объем технической документации крайне сложно и важно. Важно — потому, что от этого зависит скорость процесса, качество и стоимость. Сложно — потому что сам процесс может меняться со временем, могут меняться исполнители, да и для заданного состояния процесса не так просто подобрать нужный набор и объем документации.

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

Введение

Недавно довелось столкнуться с проектом по доработке когда-то написанной CRM. Цель доработки была в том, чтобы увеличить быстродействие системы при взаимодействии с пользователем и добавить немного нового функционала, а также победить обнаруженные предыдущими разработчиками и так и не побеждённые утечки памяти в JavaScript'е, на котором и был реализован весь пользовательский интерфейс.
Начав заниматься проектом, покопавшись в недрах огромного количества используемых и не очень дружно взаимодействующих между собой библиотек и framework'ов, проведя ряд экспериментов, мы пришли к неожиданному для себя выводу о том, что виной всему… SPA-архитектура.

Hello C++ World!

В прошлую пятницу вышел релиз Visual Studio 2015 Preview, в котором были представлены новые возможности увеличения продуктивности разработки, в том числе рефакторинг кода на С++. В значительной мере на реализацию этого функционала повлияли отзывы комьюнити, которые были получены в ходе тестирования Visual Studio «14» CTPs, так что спасибо всем поучаствовавшим.

В этой статье мы рассмотрим такие возможности Visual Studio 2015 Preview по работе над С++ кодом, как:

• Переименование (Rename)
• Извлечение функции (Extract Function)
• Генерация заглушек чисто виртуальных методов (Implement Pure Virtuals)
• Генерация объявлений/заглушек методов (Create Declaration/Definition)
• Перемещение объявлений функций (Move Function Definition)
• Преобразование в Raw-String (Convert to Raw-String Literal)

Введение

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

Что бы стало еще понятнее, добавлю, что речь пойдет о том же, о чем писал «классик» — Patterns of enterprise application architecture by M. Fowler.

Часть 1.
Часть 2.
Часть 3.

Сегодня дописал пост о том, как мы решили написать свой GUIRunner для FireMonkey. В комментарии к посту в одной из соцсетей Алексей Тимохин обратил мое внимание на другой известный фреймворк для тестирования — DUnitX.
Я пытался найти альтернативу, использовать консольный вариант, но Александр был неумолим. Когда же зайдя в репозиторий я увидел готовый GUIRunner под FireMonkey, совсем поник.

Однако.

Часть 1.
Часть 2.

Здравствуйте.

В этой статье я хочу познакомить читателей с процессом переноса VCL кода в FireMonkey. В стандартной поставке Delphi, начиная по-моему с версии 2009, проект DUnit идёт из коробки.

Однако писался он в далекие времена VCL. И хотя и позволяет тестировать код написанный для FireMonkey (Благодаря консольному выводу), но у него нет «няшного» GUIRunner'a, к которому многие из нас привыкли, ведь в нём очень быстро и легко можно «убрать» те тесты которые мы не хотим запускать «именно сейчас».

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

Для чего выдумывать все эти паттерны проектирования, принципы и методики? Разве не было бы проще обойтись без всего этого, а просто научить разработчиков хорошему дизайну? Или почему бы не формализовать этот процесс и ввести четкие количественные метрики, которые бы говорили, что одно решение однозначно лучше другого?

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

Со временем и молодой разработчик, и молодой менеджер придут к пониманию того, что это невозможно. Невозможно найти идеальный абстрактный дизайн, поскольку слова «идеальный» и «абстрактный» противоречат друг другу. Дизайн – это постоянный поиск компромисса между противоречивыми требованиями: производительностью и читабельностью, простотой и расширяемостью, тестируемостью и цельностью решения.

Доброго времени чтения, уважаемые участники habrahabr.ru

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



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

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



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

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

Возьмем за условие задачи e-commerce проект (интернет-магазин или другой b2c интернет-сервис). Наделим этот магазин классной командой: внятным руководством, скорыми на честные решения маркетологами, гибкой разработкой (готовой быстро реагировать на изменяющиеся требования). Дадим ему некоторый уровень количественной успешности (пусть будет от 1000 заказов в сутки). Предположим что проект этот — пока еще стартап (или недавно им был). И он когда-нибудь обязательно захватит мир. Но пока что не сподобился внедрить систему разряда ERP/CRM для работы с большими объемами заказов/клиентов.

Что обычно происходит в активной стадии развития такого бизнеса? Маркетинг всеми силами изыскивает способы:

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

И вычитывает и выдумывает другие мирозахватнические бизнес-модели.

Часть 1.

Здравствуйте.

В этой статье я продолжу рассказ о том, как мы пишем под FireMonkey. Будет добавлено 2 интересных объекта. Оба напомнят нам о векторной алгебре и тригонометрии. Также в посте будут показаны приемы из ООП, которыми мы пользуемся.

Компания Oracle серьёзно взялась за разработку JDK9 и опубликовала первый список «предложений на улучшение» (JEP), в которых описаны новые функции Java 9. Список невелик и консервативен, но его наверняка дополнят в предстоящие почти два года до выпуска Java 9.

Программные интерфейсы

Представлены три новых программных интерфейса.

• Обновление Process API для лучшего взаимодействия с не-Java процессами операционной системы (сейчас разработчики часто вынуждены использовать нативный код).
• Новый HTTP-клиент с поддержкой HTTP 2.0, веб-сокетов и заменой устаревшему HttpURLConnection.
• Облегчённый JSON API для обработки и генерации JSON-документов и потоков данных.

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

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.

Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.

До Agile и XP вся ответственность за работу с рисками ложилась на менеджеров. В гибких методологиях разработчики гораздо больше вовлечены в процесс и делят ответственность с менеджерами. Однако, принципы XP и Agile – больше методологические, чем технологические. Я думаю, что с рисками эффективнее работать комплексно на всех уровнях, в том числе на самом низком уровне, т.е. во время проектирования и написания кода.

Почему об этом следует думать разработчику, если есть менеджер?

1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.

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

Процесс написания приложения мы договорились подробно описывать на Хабре.

В статьях будет показано на практике использования различных техник, таких как: Dependency Injection, фабричный метод, использование контекстов, использование контроллеров и т.д. В ближайшем будущем планируется прикрутить туда тесты Dunit. DUnit’a в данный момент нет для FMX, так что придётся что-то придумывать самим.

Начнем мы с рабочего прототипа который к моменту окончания статьи приобретет такой вид:

Всем привет. Однажды мы узнали о том, что нам предстоит сделать True Image для Mac OS. Как это обычно бывает, сделать надо быстро и качественно, ага. Сразу возник резонный вопрос, почему бы просто не скомпилировать True Image для Windows под Мак, ведь большинство кода уже кроссплатформенно, в том числе интерфейс, написанный на Qt? Но нам тут же были обозначены рамки:

Интерфейс решено было сделать абсолютно новый, в разы проще чем у большого брата. Также в качестве GUI-фреймворка опытные в Маковых делах ребята из Parallels посоветовали использовать именно нативный Сocoa вместо Qt, а люди из еще одной известной компании подтвердили правильность этого решения. Решили не ставить под сомнение их опыт.

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

Domain-Driven Design: Tackling Complexity in the Heart of Software Эванса — лучшая книга о проектировании действительно больших enterprise-приложений, что я читал. Видимо это мнение разделяют многие другие разработчики и проектировщики, потому что Entity и ValueObject, Repository и Specification встречаются почти в каждой большой кодовой базе. Но вот незадача, Ubiquitous Language (единый язык) и Bounded Context (контекст предметной области) в чужом коде я не видел ни разу. И здесь зарыта очень большая собака.

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

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

В данном крохотном посте речь пойдет об одной из глав, книги «Принципы, паттерны и методики гибкой разработки на языке C#», с названием «Рефакторинг». Глава полностью посвящена рефакторингу. На примере одного большого метода, автор последовательно модифицирует код, попутно объясняя почему он делает те или иные модификации. После каждого этапа, код прогоняется через тесты.

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

Статья не преследует цели дискредитации автора, просто показалось интересным выложить свои наблюдения и услышать мнение сообщества по этому поводу.

Привет, читатель! Я хочу поговорить с тобой о паттернах проектирования. Знаешь, это такая старая штука, о которой модно было писать в конце прошлого века, и некоторые изверги о них еще иногда спрашивают на собеседованиях. У меня возникла мысль, что пришла пора снова вспомнить о них, но на этот раз рассмотреть их в современных реалиях. А разве есть более подходящий способ это сделать, кроме как взять… и написать об этом книгу?