Рубрика «Проектирование и рефакторинг» - 56

В компании Mutual Mobile тестирование является частью создания отличного программного обеспечения. Однако тестирование не всегда было ключевой частью при создании приложений под iOS. Когда мы начали искать способы, чтобы улучшить тестирование наших приложений, то обнаружили, что написание тестов для приложений это довольно сложно. И решили, что если мы собираемся улучшить способ тестирования программного обеспечение, то мы должны сначала придумать лучший способ спроектировать приложения, и это решение мы назвали VIPER.

Традиционным способом проектирования приложения под iOS является использование шаблона MVC (модель-представление-контроллер). Использование MVC для архитектуры приложения, может натолкнуть Вас на мысль, что каждый класс представляет собой или модель, или представление, или контроллер. Поскольку значительная часть логики приложения не входит в модель или представление, она обычно оказывается в контроллере. Это приводит к проблеме, известной как Massive View Controllers, где контроллеры в конечном итоге делают слишком много. Если вся логика встроена в контроллер представления, это приводит к тестированию логики через UI, в свою очередь это является неправильным способом проектированиям логики. Также проще совмещать бизнес-логику и UI код в том же методе. Когда Вам будет нужно добавить новые функциональные возможности или исправить ошибку, то будет трудно определить, где внести изменение и при этом быть уверенным, что не будет непредсказуемых последствий в другом месте.

Введение в VIPER - 1
Читать полностью »

По итогам Rambler.iOS V - 1

Во вторник состоялся Rambler.iOS V, который мы анонсировали на Хабре ранее. Эксперимент с разбитием одной очень крупной темы на восемь связанных между собой докладов отлично состоялся — благодаря такой гранулированности докладчики смогли сосредоточиться именно на своем аспекте VIPER и подготовить действительно мощные выступления.
Читать полностью »

Статья «Как справиться с проблемами в унаследованном проекте после 3 других команд» рассказывает, через что пришлось пройти команде разработчиков, чтобы через полтора года получить достаточно стабильный программный продукт.
Здесь мы хотим рассказать, чем занималась команда тестирования, чтобы эффективно проверять все изменения, сделанные разработчиками, и гарантировать, что продукт соответствует ожиданиям заказчиков и конечных пользователей.Читать полностью »

Организация «чистого» завершения приложений на Go - 1

Здравствуйте, в данной заметке будет затронута тема организации «чистого» завершения для приложений, написанных на языке Go.
Чистым выходом я называю наличие гарантий того, что в момент завершения процесса (по сигналу или по любым иным причинам кроме system failure), будут выполнены определённые процедуры и выход будет отложен до окончания их выполнения. Далее я приведу несколько типичных примеров, расскажу о стандартном подходе, а также продемонстрирую свой пакет для упрощённого применения этого подхода в ваших программах и сервисах.

TL;DR: github.com/xlab/closer GoDoc
Читать полностью »

Вот вам анекдот из конца 90-ых. Я (Dave Baggett) был одним из двух программистов (вместе с Andy Gavin), разрабатывающих Crash Bandicoot для PlayStation 1.

Ретроспектива разработки Crash Bandicoot, или как разработчики упаковывали целые игры в 2MB RAM - 1

Оперативная память была главной проблемой даже в те времена. У PS1 было всего 2MB RAM, и нам приходилось совершать безумные вещи, чтобы уместить в них игру. У нас были уровни, содержащие более 10MB чистых данных, и эти 10 мегабайт должны были постранично загружаться и выгружаться в память динамически, без каких-либо видимых задержек для игрока, при фреймрейте в 30 кадров в секунду.
Читать полностью »

Есть шутка о типичной карьере разработчика:

  1. Не использует фреймворки
  2. Обнаруживает фреймворки
  3. Пишет свои фреймворки
  4. Не использует фреймворки

Пункт 4, конечно же, ссылается на новоприобретенные способности использовать Composer для построения собственных фреймворков, создавая их из различных компонентов третьих сторон.

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

Webiny

Он называется Webiny, и, будучи упакованным до краев усовершенствованиями и изменениями, которые они считают необходимыми, фреймворк имеет некоторые действительно интересные компоненты, на которые стоит взглянуть. В этой вводной статье мы не будем обращать внимание на структуру в целом, но осветим самые основные ее компоненты — StdLib.
Читать полностью »

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

Это востребовано довольно часто по разным причинам: защита публикации от недоступности к прочтению на одном-двух ресурсах (из-за поломки сервера, бана администрацией или периода модерации), для повышения популярности своей публикации за счёт массовости (спама, но, конечно, добросовестно-дилетантского; о недобросовестном — чуть ниже), для экономии времени публикации, для сбора своих статей на каком-либо одном авторском ресурсе. Большой плюс будет и в том, что базу исходных образцов статей легко будет хранить в виде архива в копиях и восстановить при необходимости прочтения или повторных публикаций, даже если исчезли все другие прежние копии.

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

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

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

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

В публикации рассматриваются следующие темы:

  • Наследование VS компоненты
  • Сложные иерархии классов юнитов, предметов и прочего
  • Машины состояний, деревья поведений
  • Абстракции игровых объектов
  • Упрощение доступа к другим компонентам в объекте, сцене
  • Сложные составные игровые объекты
  • Характеристики объектов в игре
  • Модификаторы (баффы/дебаффы)
  • Сериализация данных

Читать полностью »

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

Однако, за перенос настроек в базу данных пришлось расплачиваться. Об архитектуре, позволяющий кэшировать редко меняющиеся Linq to SQL сущности, смотрите под катом.
image
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js