Существует две фундаментальные стратегии: обработка исправимых ошибок (исключения, коды возврата по ошибке, функции-обработчики) и неисправимых (assert(), abort()). В каких случаях какую стратегию лучше использовать?
Читать полностью »
Рубрика «Проектирование и рефакторинг» - 42
Выбор правильной стратегии обработки ошибок (части 1 и 2)
2017-02-27 в 10:55, admin, рубрики: c++, Анализ и проектирование систем, Блог компании Mail.Ru Group, никто не читает теги, обработка ошибок, Проектирование и рефакторинг, Совершенный кодИстория об ужасах стандартов кодирования
2017-02-22 в 13:58, admin, рубрики: IT-стандарты, Анализ и проектирование систем, Блог компании Инфопульс Украина, Программирование, Проектирование и рефакторинг, стандартыНа моём первом месте работы я работал на парня по имени Марк. Марк был очень умным и целеустремлённым программистом, и я научился многому у него. Но мы с ним постоянно бодались по поводу стандартов и стилей кодирования.
Мы тогда писали под DEC VAX на VAX Basic. Чтобы вся эта история имела какой-то смысл, вы должны понимать, что VAX Basic не был тем классическим Basic, о котором вы думаете. Разработчики компилятора из DEC начали с синтаксиса Basic и понемногу добавили всё хорошее из FORTRAN, Modula II и Pascal. Например, ещё в начале 1980-ых в языке уже были исключения.
Также нужно помнить, что в 1980-ых ещё не существовало полноценных IDE с богатыми редакторами кода (вроде Visual Studio). Мы использовали нечто, называемое TPU (Text Processing Utility). Эта программа была несколько мощнее, чем Notepad, но значительно уступала современным редакторам. Тогда она соревновалась с Emacs и vi. В результате, каждый разработчик был сам ответственен за свой стиль кода, а текстовый редактор в это дело совершенно не вмешивался.
Марк определил строгий набор правил и стандартов написания кода. Его приверженность этим стандартам была близка к фанатизму. К примеру, он мог приконнектиться к рабочему компьютеру ночью из дому (а в тот момент это означало использование модема со скоростью около 1200 бод) ради ревью кода. На следующее утро меня ждало совещание с Марком, где он построчно комментировал мой код, указывая на ошибки в стиле и требуя, чтобы я сегодня же их исправил.
Читать полностью »
Union Type, TPT, DDD, ORM и RDBMS
2017-02-20 в 6:05, admin, рубрики: .net, C#, entityframework, tpt, union type, Проектирование и рефакторинг, Разработка веб-сайтов, метки: entityframework, tpt, union type
Объединения и pattern-matching широко используются в функциональном программировании для повышения надежности и выразительности программ.
Классический пример удачного использования объединений для моделирования бизнес-процессов – корзина и состояние заказа. Пользователь в праве добавлять и убирать товары, пока не оплатил заказ. Но сама операция модификации оплаченного заказа лишена смысла. Также лишена смысла операция Remove для пустой корзины. Тогда логично вместо общего класса Cart определить интерфейс ICartState и объявить по одной реализации для каждого состояния. Более подробно данный подход изложен текстом здесь и в видео-формате вот тут.
Недавно у нас возникла задача спроектировать структуру БД для специализированной CRM/ERP. Первый подход к моделированию договоров оказался не удачным, из-за того что сторонами договоров могут выступать как физические и так и юридические лица из России и других стран мира. ИНН необходим продавцу, чтобы получить оплату, но не всегда нужен полкупателю (для идентификации личности чаще используются паспортные данные). Формат реквизитов отечественных и зарубежных юр.лиц не совпадает. Не помогало делу и то, что ИП являются физическими лицами, но «прикидываются» юридическими.
На ретроспективе мы разобрали ошибки первоначального дизайна и наметили направление рефакторинга. Всех, заинтересовавшихся нашей историей, прошу под кат.
Читать полностью »
Проблемы, возникающие при разработке андроид приложений
2017-02-17 в 17:28, admin, рубрики: Google API, java, Программирование, Проектирование и рефакторинг, Разработка под androidВведение
Доброго времени суток.В этой статье вы узнаете о том, какие проблемы могут возникнуть при разработке android приложений. На написание этой статьи меня побудили комментарии из прошлой статьи, кстати вот она:
Моя первая статья
Спасибо за советы! Ну пора начинать…
Читать полностью »
Создаём развивающее приложение при помощи Android Studio
2017-02-16 в 14:54, admin, рубрики: java, Проектирование и рефакторинг, разработка мобильных приложений, Разработка под androidВведение
Добрый день, господа! Я ученик 11 класса и разработкой занимаюсь только от того, что не хочу готовиться к ЕГЭ. Хочется отметить, что статья не предназначена для новичков в программировании. Идею приложения можно описать тремя словами — увидел, запомнил, повторил. Перед игроком появляется квадратное поле с определённым число закрашенных элементов. Через некоторое время поле очищается. Надо выбрать какие элементы были закрашены. По мере прохождения уровней игры поле становится всё больше и запоминать приходится всё больше.
Читать полностью »
Ответ на введение в проектирование сущностей, проблемы создания объектов
2017-02-16 в 6:50, admin, рубрики: DDD, design patterns, domain-driven design, php, ооп, Проектирование и рефакторингПосле прочтения статьи Введение в проектирование сущностей, проблемы создания объектов на хабре, я решил написать развернутый комментарий о примерах использования Domain-driven design (DDD), но, как водится, комментарий оказался слишком большим и я посчитал правильным написать полноценную статью, тем более что вопросу DDD, на хабре и не только, удаляется мало внимания.
Рекомендую прочитать статью о которой я буду здесь говорить.
Если вкратце, то автор предлагает использовать билдеры для контроля за консистентностью данных в сущности при использовании DDD подхода. Я же хочу предложить использование Data Transfer Object (DTO) для этих целей.
Умер ли MVC для фронтенда?
2017-02-15 в 7:12, admin, рубрики: architecture, components, javascript, mvc, React, redux, Анализ и проектирование систем, Блог компании Туту.ру, Проектирование и рефакторинг, Совершенный код
В этой статье хочу поделиться переводом интересных размышлений на тему прошлого и настоящего в архитектуре фронтенда.
В то время как все больше и больше фронтенд-разработчиков перенимают подходы с однонаправленной архитектурой, возникает вопрос — есть ли будущее у классического MVC? Чтобы понять, как мы дошли до такого вопроса, давайте немного проанализируем эволюцию архитектуры фронтенда.
Читать полностью »
Рефакторинг платежного процесса Я.Денег — пробуждение силы
2017-02-14 в 14:11, admin, рубрики: javascript, node.js, Блог компании Яндекс.Деньги, Клиентская оптимизация, платежная система, Программирование, Проектирование и рефакторинг, рефакторинг, стандарты
Для любого проекта с длинной историей однажды наступает момент, когда код начинает жить своей жизнью — просто не остается тех, кто хорошо ориентируется в логике и связях. Добавление новых функций порой похоже на выстрел наугад: может попасть в цель, а может — в зрителей.
И тогда приходит он, рефакторинг платежного процесса. Но мы решили сделать процесс еще интереснее, добавив к рефакторингу идеи IDEF-0.Читать полностью »
Почему VIPER это хороший выбор для вашего следующего приложения
2017-02-11 в 16:05, admin, рубрики: iOS, viper, Анализ и проектирование систем, архитектура приложений, паттерны головного мозга, Проектирование и рефакторинг, разработка мобильных приложений, разработка под iOS, чистая архитектураКогда я прочитал статью, в которой автор рассказал про то, что архитектура VIPER полна проблем, это вызвало у меня несколько негативные эмоции, после чего я сразу решил написать статью в поддержку архитектуры.
Читать полностью »
Почему VIPER это плохой выбор для вашего следующего приложения
2017-02-09 в 13:49, admin, рубрики: iOS, ios development, viper, архитектура приложений, Проектирование и рефакторинг, разработка мобильных приложений, разработка под iOSЭтот пост является вольным переводом статьи Why VIPER is a bad choice for your next application by Sergey Petrov
За последний год о VIPER писали все кому не лень. Эта архитектура реально вдохновляет разработчиков. Но большинство статей, на самом деле, довольно предвзяты. Они лишь показывают крутизну этого архитектурного паттерна, умалчивая о его негативных сторонах. А ведь проблем у него вовсе не меньше (а может даже и больше) чем у других. И в этой статье я постараюсь объяснить, почему VIPER вовсе не так хорош как о нем говорят, и почему он не подойдет для большинства ваших приложений.