[Перевод] Управление техническим долгом

Екатерина Сазонова, переводчик-фрилансер и студентка «Нетологии», специально для блога перевела статью Carl Tashian о том, как продакт- и проджект-менеджерам справляться с техническим долгом.

image

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

[recovery mode] Docker-compose: идеальное рабочее окружение


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


В данном посте поговорим про docker-compose, который по моему мнению является панацеей в вопросе организации и оптимизации рабочего процесса разработчика.


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

Читать дальше →

Интеграция CRM и телефонии, уроки разработки сложного продукта


История о том, как разработка интеграции телефонии Sipuni и нескольких CRM стала для нас лабораторией и повлияла не только на технологии, которые мы используем, но и на процессы внутри компании.

Читать дальше →

[Из песочницы] SOLID: принцип единственности ответственности

В этой статье мы попробуем описать один из известных принципов объектно-ориентированного программирования, входящий в аббревиатуру не менее известного понятия SOLID. На английском языке он носит название Single Reponsibility, что в переводе на русский означает Единственность Ответственности.

Этот принцип гласит:

Класс должен иметь только одну причину для изменения

Для начала попробуем определить понятие Ответственность. Любой программный компонент имеет некоторые причины, почему он был написан. Их можно назвать требованиями. Обеспечение следования реализованной логики налагаемым на компонент требованиям назовем ответственностью компонента. Если требования меняются, меняется и логика компонента, а следовательно и его ответственность. Таким образом, первоначальная формулировка принципа эквивалентна тому, что класс должен иметь только одну ответственность, одно назначение. Тогда и причина для его изменения будет одна. Читать дальше →

Реквием по разработке: почему мы обязаны экспериментировать

image

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

Читать дальше →

Реализация Frameworx в телекоммуникационном API

Скорость развития рынка телекоммуникаций вынуждает его участников непрерывно совершенствовать свои бизнес-процессы, снижая себестоимость и максимально сокращая время разработки и вывода новых услуг на рынок. Большой проблемой при этом становится построение правильных бизнес-моделей внутри организации. В процессе реализации услуги YouMagic.Pro мы столкнулись с тем, что каждый продуктолог, который начинал заниматься этим проектом, видел его развитие по-своему. Менялись интерфейсы, формы, мы переписывали код, и все это приводило к ошибкам в работе сервиса. В какой-то момент заявленные требования уже перестали быть совместимыми с изначальной архитектурой и мы решили посмотреть, как реализованы бизнес-процессы в других телеком-компаниях. В результате анализа мы пришли к решению внедрить референтные модели SID Frameworx от ТМ Forum. В этой статье мы расскажем, что же такое референтные модели и с чего нужно начинать разработку телеком-сервисов, которые в дальнейшем будут способны адаптироваться под различные изменения бизнес-требований.

Читать дальше →

Понятие системы и конструкции. Их место в проектировании информационных систем

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

Конструкция

Толковый словарь Ефремовой определяет два разных понятия, которые обозначаются одним термином конструкция:
  1. Состав и взаимное расположение частей какого-либо сооружения, механизма.
  2. Само сооружение или механизм с таким устройством.
Попробуем перевести их на формальный язык. Поскольку состав – это множество, то первое понятие переводится так: конструкция — это множество объектов, связанных между собой связями. При этом, судя по определению, объекты должны быть рукотворным и неживыми. То есть, нельзя представить Землю в виде конструкции, если не предположить, что ее сделали инопланетяне. Нельзя представить ДНК в виде конструкции, если только эта ДНК не создана кем-то. То есть, в определение конструкции надо добавить, что объекты рукотворные. Например, множество объектов: {фюзеляж, крылья, хвост} состоит из рукотворных объектов, и, потому, может называться конструкцией. Конструкцией под названием самолет. Замечу, что в данном контексте самолет – это не объект, а множество объектов {фюзеляж, крылья, хвост}. Можно назвать это множество самолет(к)....Далее...

Архитектура модульных React + Redux приложений 2. Ядро

В первой части я уделил внимание только общей концепции: редюсеры, компоненты и экшны чаще меняются одновременно, а не по отдельности, поэтому и группировать и их целесообразнее по модулям, а не по отдельным папкам actions, components, reducers. Также к модулям были предъявлены требования:
  1. быть независимыми друг от друга
  2. взаимодействовать с приложением через API ядра

В этой части я расскажу о структуре ядра, подходящей для разработки data-driven систем. Читать дальше →

О карте МегаФона — технические подробности, часть 2

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



Читать дальше →

Под капотом среды разработки. Базовые модели

Некоторое время назад мне довелось разрабатывать компоненты сред разработки для Netbeans и JDeveloper. Хм..., на самом деле довольно давно, и надо бы написать статью об этом пока не всё забыл и пока ещё облачные среды не захватили мир окончательно. Так вот, мне посчастливилось заглянуть во внутренности тех продуктов, которые мы используем каждый день, в данной статье я расскажу о некоторых аспектах устройства сред разработки и о принципах проектирования моделей используемых внутри джава IDE. В качестве примеров буду использовать Netbeans, но в других средах всё примерно также, ведь одинаковые проблемы порождают сходные решения. Читать дальше →
  • Новее
  • 1


Последние посты