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

в 12:20, , рубрики: аналитика, Блог компании Acronis, Inc, практическая разработка, Программирование, Проектирование и рефакторинг, разработка, требования к по, метки:

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

КДПВ (эта картинка актуальности не потеряет, наверно, никогда):

Стадии рождения новой функциональности в программном продукте - 1

Disclaimer: всё нижеприведенное описание процессов основано на личном опыте автора, полученного в конкретной компании и могут не иметь ничего общего с объективной реальностью читателя. Информация о каждой стадии разработки подана в сжатом виде и призвана раскрыть только основные моменты процесса в рамках одной статьи.
Читать полностью »

в 8:35, , рубрики: django, supl.biz, архитектура, Блог компании Supl.biz, Веб-разработка, инфраструктура, проектирование, Проектирование и рефакторинг, пятница, разработка, стартап, торговая площадка, метки: ,

Добрый день. Меня зовут Алексей Красноперов и я являюсь основателем и техническим директором проекта Supl.biz — торговой площадки для малого и среднего бизнеса. Хочу рассказать, как устроен проект изнутри.

Общая архитектура проекта

Техническая сторона Supl.biz
Читать полностью »

в 17:45, , рубрики: KISS, принципы проектирования, Программирование, Проектирование и рефакторинг

Постараюсь объяснить сущность принципа проектирования KISS просто и одновременно очень подробно. KISS – это очень общий и абстрактный принцип проектирования, который содержит в себе практически все остальные принципы проектирования. Принципы проектирования описывают как писать «хороший» код. Однако что значит хороший код? Некоторые считают, что это код, который выполняется максимально быстро, некоторые – что это код, в котором задействовано как можно больше паттернов проектирования… Но верный ответ лежит на поверхности. Код – это информация в чистом виде. А основные критерии ценности информации – это 1)достоверность 2)доступность 3)понятность. То, почему важны достоверностью и доступность – очевидно. От кода нет проку, если он работает с ошибками или если сервер с приложением «лежит». Почему же важна понятность кода? В понятном коде проще искать ошибки, проще его изменять, дорабатывать и сопровождать. Итак, понятность – основная ценность, к которой должен стремиться программист. Однако тут есть одна неувязочка. Дело в том, что понятность – вещь сугубо субъективная. Читать полностью »

в 7:03, , рубрики: .net, ASP.NET, hstore, postgresql, никто не читает теги, Программирование, проектирование, Проектирование и рефакторинг

Картинка для привлечения внимания Так сложилось, что к тридцати годам я менял работу лишь единожды и не имел возможности на собственном опыте изучить, как в различных компаниях устроены веб-проекты, расчитанные на высокую скорость отклика и большое количество пользователей. <irony> Так что, дорогой читатель, попавший в поле моего зрения в оффлайне, увидев меня, лучше беги, пока я не начал докучать тебе вопросами на тему обработки ошибок, логирования и процесса обновления на рабочих серверах&lt/irony&gt. Мне интересен не столько набор используемых технологий, сколько принципы, на которых построена кодовая база. Как код разбит на классы, как классы распределены по слоям, как бизнес-логика взаимодействует с инфраструктурой, каковы критерии по которым оценивается качество кода и как организован процесс разработки нового функционала. К сожалению, подобную информацию найти непросто, в лучшем случае всё ограничивается перечислением технологий и кратким описанием разработанных велосипедов, а хочется, конечно, более детализированной картинки. В этом топике я попытаюсь как можно более подробно описать, как устроен код в компании, где работаю я.
Читать полностью »

в 8:57, , рубрики: c++, dependency injection, Блог компании Инфопульс Украина, Проектирование и рефакторинг

«Не звони нам. Мы позвоним тебе сами.» — принцип Голливуда

Внедрение зависимости (Dependency Injection — DI) означает передачу (внедрение) одной или более зависимости какому-либо объекту (клиенту, компоненту) таким образом, что после внедрения эта зависимость становится частью состояния объекта. Это немного напоминает паттерн проектирования Стратегия, с той лишь разницей, что стратегия задаётся лишь однажды — в конструкторе. DI позволяет создавать более слабо-связанную архитектуру приложения, которая лучше поддаётся поддержке и тестированию.

Итак, ещё раз плюсы:

  • Уменьшает связность компонент (отделяет бизнес-логику от создания объекта)
  • Позволяет писать более поддерживаемый код (в одни и те же объекты мы легко можем внедрять разные зависимости)
  • Позволяет писать более тестируемый код (мы можем легче использовать стабы и моки)
Без внедрения зависимости С внедрением зависимости 
class example {                         
public:  
    example()                           
        : logic_(new logic{})           
        , logger_(                      
            logger_factory::create()    
          )                             
    { }  
         
    int run() const;                    
         
private: 
    shared_ptr<ilogic> logic_;          
    shared_ptr<ilogger> logger_;        
};                             


 class example {
 public:
     example(shared_ptr<ilogic> logic
           , shared_ptr<ilogger> logger)
       : logic_(logic), logger_(logger)
     { }

     int run() const;

 private:
     shared_ptr<ilogic> logic_;
     shared_ptr<ilogger> logger_;
 };

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

в 10:36, , рубрики: clean code, java, java named parameters, refactoring, Проектирование и рефакторинг

В некоторых языках программирования (например, в Scala) есть именованные параметры. Именованные параметры позволяют контролировать присвоение значений, дополнительным бонусом выступает возможность использовать свой порядок указания параметров, нежели описано в сигнатуре функции. В рамках цикла статей BadDesign, предложу урезанный механизм именованных параметров для Java.
Читать полностью »

в 7:25, , рубрики: .net, dependency injection, Блог компании СКБ Контур, ооп, Проектирование и рефакторинг

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

Во-первых, он может просто образоваться сам собой! Мы в Эльбе довольно долго использовали этот контейнер, и некоторые из описываемых в статье идей (Factory Injection, Generics Inferring, Configurators) изначально были реализованы поверх него через публичное API.

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

В-третьих, DI-контейнер — относительно простая штука. Он очень хорошо поддается разработке в режиме TDD, за счет чего делать его становится весело и приятно.

Эта статья — не введение в DI. На эту тему есть много других прекрасных публикаций, в том числе и на Хабре. Скорее здесь собран набор рецептов приготовления DI так, чтобы получившееся блюдо было вкусным, но не острым. Если у вас DI-контейнер в продакшене или вы написали свой собственный самый лучший контейнер, то здесь отличное место для холиваров о том, чей контейнер круче!
Читать полностью »

в 20:54, , рубрики: красивый код, ненормальное программирование, Проектирование и рефакторинг, разработка, рефакторинг

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

Рассмотрим «игрушечный» пример на Python с использованием именованных аргументов:

#вычислим объем параллелепипеда
#если значение стороны не указано, то считаем что оно равно единице
def volume(length=1, width=1, height=1): 
  return length * width * height; 
print(volume())                            # V = 1 
print(volume(length=2))                    # V = 2 
print(volume(length=2, width=3))           # V = 6 
print(volume(length=2, width=3, height=4)) # V = 24

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

Ниже я покажу, как можно сымитировать использование именованных аргументов в C.
Читать полностью »

в 14:11, , рубрики: Анализ и проектирование систем, асинхронность, личный опыт, масштабируемость, отказоустойчивость, очередь сообщений, проектирование, Проектирование и рефакторинг, разработка

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

Как мы строим систему обработки сообщений - 1

По каналам связи устройства присылают сообщения на наш шлюз (gateway) – входную точку приложения. Задача приложения – разобраться, что именно пришло, произвести необходимые действия и сохранить информацию в базе данных для дальнейшего анализа. Базу мы будем рассматривать как конечную точку обработки. Звучит просто, но с ростом количества и разнообразия сообщений появляется несколько нюансов, которые я и хочу обсудить.
Читать полностью »

в 19:37, , рубрики: Delphi, FireMonkey, mobile development, open source, tdd, testing, ооп, Проектирование и рефакторинг

Часть 1.
Часть 2.
Часть 3. DUnit + FireMonkey
Часть 3.1. По мотивам GUIRunner
Часть 4. Serialization

Здравствуйте, дорогиее.

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

Сейчас наш проект выглядит так:

MindStream. Как мы пишем ПО под FireMonkey. Часть 5. Тестирование - 1
Читать полностью »

1...1020...575859...70...76
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js