Pull to refresh
  • by relevance
  • by date
  • by rating

Организация процессов производства информационных систем. Часть 2. Формирование проектного решения

System Analysis and Design *IT Infrastructure *Industrial Programming *Development Management *Business Models

V Разработка плана-графика проектных работ

Чтобы выполнить большой и важный труд, необходимы две вещи:
ясный план и ограниченное время.
Элберт Хаббард
И вот заказчик и исполнитель ударили по рукам, решив, что именно они будут производить, определив примерные сроки и стоимость. Начинается второй этап производства программного продукта.

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

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

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


Читать дальше →
Total votes 7: ↑7 and ↓0 +7
Views 6.9K
Comments 4

Организация процессов производства информационных систем. Часть 3. Реализация проектного решения

System Analysis and Design *IT Infrastructure *Industrial Programming *Development Management *Business Models

VII Разработка плана реализации и внедрения проектного решения


Блестящим планам везет на проектировщиков.
Скверным планам везет на исполнителей.
Веслав Брудзинский.

На этом этапе процесс вновь начинает крутиться вокруг руководителя проекта. Снова оценка трудоемкости, определение сроков, согласование объемов, утверждение порядка исполнения и т.п.

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

Для решения этих задач чаще всего разрабатывают план-график, позволяющий организовать и упорядочить взаимодействие команд и отдельных исполнителей в рамках всего проекта.
Читать дальше →
Total votes 10: ↑9 and ↓1 +8
Views 4.1K
Comments 0

Организация процессов производства информационных систем. Часть 4. Внедрение информационной системы

System Analysis and Design *IT Infrastructure *Industrial Programming *Development Management *Business Models

IX Внедрение информационной системы


Нет ничего труднее, опаснее и неопределённее, чем руководить введением нового порядка вещей, потому что у каждого нововведения есть ярые враги, которым хорошо жилось по старому, и вялые сторонники, которые не уверены, смогут ли они жить по новому.
Н. Макиавелли

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

Для начала реализованный продукт необходимо развернуть на оборудовании, уготовленном для организации его опытной эксплуатации.
Читать дальше →
Total votes 7: ↑6 and ↓1 +5
Views 9.8K
Comments 1

Как восемь человек масштабируют highload-проект. Опыт Unsplash

Badoo corporate blog High performance *Website development *Programming *Designing and refactoring *
Translation

Фото: Alex Smith | Unsplash

Добрый день!

Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести.


Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

В обычный день наш API обрабатывает больше 10 млн. запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. обновлений, и мы обслуживаем 60 млн. изображений.

В то же время наша команда сравнительно мала: два дизайнера, три человека, работающих с фронтендом, два — с бекендом и один дата-инженер. У нас нет отдельного DevOps-инженера, и каждый член команды тратит бОльшую часть своего времени на эксперименты и разработку новых фич для обеспечения дальнейшего развития продукта.
Читать дальше →
Total votes 48: ↑47 and ↓1 +46
Views 10K
Comments 3

Как подружить PHPstorm, xDebug и удаленные ветки, собранные через Docker? Слишком просто…

PHP *Debugging *Studying in IT DevOps *
Tutorial
Доброго времени суток, Хабр!

Еще год назад мой процесс отладки кода в PHP заключался в двух строчках:

var_dump($variable);
die();

Периодически, конечно, приходилось использовать более «сложные» конструкции:

console.log(data);

echo json_encode($variable, JSON_UNESCAPED_UNICODE);
exit();

Нет, что вы! Я знал — в наше время не подобает культурному программисту заниматься этим

древним ремеслом
шутка про другое древнейшее ремесло

Но, честно говоря, я всегда боялся того, что не понимаю. В том числе и принтеров xDebug, в особенности, как все это дело настроить. В один прекрасный день у меня получилось это сделать на своей машине и в локальном проекте — радости не было предела. Спустя много месяцев я столкнулся с новой проблемой, как заниматься отладкой в PHPstorm через xDebug, если проект собирается удаленно докером через CI.

Если Вы так же, как и я, испытываете трудности с настройкой разных штук, добро пожаловать под кат, я расскажу о своем опыте настройки окружения отладки с такими страшными словами, как Docker, xDebug, CI.
Читать дальше →
Total votes 23: ↑21 and ↓2 +19
Views 16K
Comments 19

Трансформация процессов разработки и доставки для унаследованного приложения

Development Management *DevOps *

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


Пора было переходить от слов к делу — менять процессы.


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

Читать дальше →
Total votes 6: ↑6 and ↓0 +6
Views 1.8K
Comments 3

Деплоим код напрямую в docker-контейнер. Или как не прокрастинировать после каждого коммита

Website development *Studying in IT DevOps *
Tutorial
Пришла задача WEB-12982
Создаешь ветку web-12982 в репозитории
Пока ветка собирается, читаешь тз и пьешь кофе
Приступаешь непосредственно к разработке

git commit, git push
Пока ветка пересобирается листаешь хабр
git commit, git push
Пока ветка пересобирается листаешь твиттер
git commit, git push

Сдаешь на ревью ветку с 50 коммитами

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


Знакома ситуация? В моей компании инфраструктура разработки организована таким образом:


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

Но, медленно... Если тебе близка эта ситуация, добро пожаловать под кат.

Читать дальше →
Total votes 14: ↑11 and ↓3 +8
Views 8.3K
Comments 15

Как подружить дизайнера, верстальщика и «Фигму» с помощью дизайн-системы, ломика и какой-то матери™

Web design *Website development *Interfaces *Usability *Design
Tutorial


Привет, Хабр. Недавно я выпендрился в комментариях и пообещал подробно ответить на вопрос о том, как дизайн-система упрощает взаимоотношения и нейтрализует конфликты между дизайнерами и верстальщиками (разработчиками). Плюс рассказать о некоторых вариантах стандартизации именования слоёв. Вот и отвечаю. Подробно. Про сетки. Про компоненты. Про иконки. Про язык. Про БЭМ. Про «фигмин» слэш и её же плагины. Про артборды и вьюпорты. Про типографику. Про стили и палитры. Про эффекты. Про экспорт растра. Про «мультиплеер». Про распределение обязанностей. Ну и немножко «о жизни, вселенной и вообще». Осторожно, трафик: внутри много картинок, есть gif-анимации. А ещё много, действительно много нудного текста. Я предупредил.
Читать дальше →
Total votes 43: ↑42 and ↓1 +41
Views 54K
Comments 36

Как команда разработчиков может зарабатывать больше делая трафиковые сайты [Руководство к внедрению]

Website development *Development for e-commerce *Internet marketing Search engine optimization Branding
Согласитесь, что отстройка от конкурентов может быть фактором роста для вашей IT компании. Правильно подавая свои сильные стороны, вы сможете увеличить конверсию из лидов в продажи, получать больше рекомендаций от довольных клиентов.

Одним из таких преимуществ может быть создание сайтов оптимизированных под поисковые системы и получение трафика из них (соответствие рекомендациям для вебмастеров Google и Яндекс; простота получения поискового трафика после запуска проекта).
В данной статье речь пойдет о том, как преподнести SEO-friendly сайт клиенту в виде уникального торгового предложения при продаже ваших услуг.

Также вы узнаете:

  • Кто нужен вашей команде;
  • Как изменить процессы;
  • Какие основные ошибки встречаются в процессе разработки;
  • На что вы можете влиять.

Что такое SEO-friendly разработка сайта?


Существуют базовые особенности для любого сайта, которые прямо или косвенно влияют на получение поискового трафика:

  • логичная структура;
  • корректная верстка;
  • быстрая загрузка;
  • отсутствие технических проблем.

Для каждого из пунктов оптимизатор может выдать необходимые рекомендации еще в момент разработки проекта.

Кстати!
Посредством разработки SEO-friendly проектов вы сможете не только дать дополнительный сервис, но также сможете увеличить объем работы в каждом проекте.

Начнем с того, кто нужен команде.

Кто нужен в команду?


Вам в команду нужен специалист по оптимизации сайтов под требования поисковых систем (aka SEO-специалист).
Читать дальше →
Total votes 10: ↑0 and ↓10 -10
Views 3.7K
Comments 6

Программист-защитник сильнее энтропии

FUNCORP corporate blog High performance *Programming *Perfect code *Designing and refactoring *
© Dragon Ball. Goku.

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

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

Давайте разберёмся подробнее, что входит в понятие «падать изящно».

  • Падать быстро. В случае непредвиденной ошибки все операции должны завершаться сразу же, особенно если последующие вычисления тяжёлые или могут привести к порче данных.
  • Падать аккуратно. Если возникла ошибка, программа должна освободить все ресурсы, снять локи, удалить временные и наполовину записанные файлы, закрыть соединения. Дождаться завершения критических операций, прерывание которых может привести к непредсказуемым результатам. Либо безопасным способом аварийно завершить эти операции.
  • Падать явно и красиво. Если что-то сломалось, сообщение об ошибке должно быть простым, лаконичным и содержать важные детали из того контекста системы, где возникла ошибка. Это поможет команде, которая отвечает за систему, максимально быстро разобраться в проблеме и исправить её.
Читать дальше →
Total votes 31: ↑31 and ↓0 +31
Views 7.8K
Comments 6

Еще раз про усложненность архитектуры и порог входа

Development of mobile applications *Designing and refactoring *Development for Android *
Sandbox

В данной статье я коснусь вопроса порога входа в проект с устоявшейся архитектурой и дам несколько вариантов ответа на очень часто возникающий вопрос: почему так сложно?


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

Читать дальше →
Total votes 8: ↑5 and ↓3 +2
Views 7.6K
Comments 13

Framework vs Platform: в чём разница?

Development Management *
Translation

Привет, Хабр! Представляю вашему вниманию перевод статьи "Framework Vs. Platform What’s The Difference?" автора G. Harris.


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


Разница между почти правильным словом и правильным словом действительно много значит. Это разница между светлячком (lightning bug) и молнией (lightning).

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


Я хотел бы предложить одно из возможных определений по аналогии.

Читать дальше →
Total votes 12: ↑10 and ↓2 +8
Views 4.7K
Comments 3

Code review — улучшаем процесс

Programming *Perfect code *Git *Debugging *Development Management *
Sandbox
image

Представим команду, где не проводится Code review. Разработчики пишут код, и без проверок вносят все изменения в основную ветку. Спустя время расширяется функционал или находятся баги, они возвращаются к исходному коду, а там все переменные названы одной буквой, нет следования архитектуре, да и качество не самое лучшее. Этот некачественный код будет копиться и однажды наступит момент, когда, при любом мало-мальском нововведении, проект начнёт разваливаться: в лучшем случае – увеличится время разработки, в худшем – поддержка проекта станет невозможной. И это при том, что когда-то давно задача была выполнена и все хорошо работало.

Как этого можно избежать?
Читать дальше →
Total votes 12: ↑12 and ↓0 +12
Views 10K
Comments 10

Требования к ПО на пальцах

System Analysis and Design *
Sandbox
Пост про основы разработки требований — без сложных схем, терминов и таблиц, зато с гифками.

image

Если коротко, то основные этапы разработки требований — это:

  1. Зачем нам что-то делать? (нужно больше золота)
  2. Что мы будем делать? (все как у людей, но дешевле)
  3. Как мы это сделаем? (с блокчейном и датасаентистами, естественно)
  4. Когда мы это сделаем? (вчера, а отрефакторим «потом»)

А теперь подробнее.
Читать дальше →
Total votes 16: ↑16 and ↓0 +16
Views 26K
Comments 12

Методика проектирования архитектурных слоев на основе анемичной модели и DDD

Programming *System Analysis and Design *Designing and refactoring *Development Management *
Tutorial
В результате выполнения методики будут выделены архитектурные слои с максимальной специализацией по уровням прикладных задач и разделением ответственности по SRP.

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

Как следствие, это выражается:

  • в непредсказуемости сроков разработки
  • большим временем локализации ошибок
  • увеличением требования к квалификации разработчиков и сложной заменяемости

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

Если сравнивать архитектуру систем с архитектурой зданий, то на определённом этапе, переполненную хрущёвку надо превратить в небоскрёб. Методика описывает то, КАК это сделать.

image
Читать дальше →
Total votes 5: ↑3 and ↓2 +1
Views 8.8K
Comments 15

Архитектурный слой (в корпоративной разработке). Понятие, определение, представление

Programming *System Analysis and Design *Designing and refactoring *Development Management *
Сейчас сложно найти короткое и понятное определение таких понятий как «слой приложения» и «уровень абстракции». Это влечёт различия в понимании одного и того же либо непонимания данного понятия среди разработчиков. А недопонимания ведут к разногласиям.

Цель этой статьи: совместно выработать определённость, создать у всех единое представление и выработать короткое, ясное и практичное определение для понятия Архитектурный слой в области корпоративных приложений. Всё что приводится в статье вы можете обсудить и дополнить в комментариях, а я актуализирую материал в статье в соответствии с замечаниями.

Разделение архитектуры корпоративного приложения на слои позволяет
  • лучше выполнять декомпозицию задачи
  • проще ориентироваться внутри проекта
  • разработчики приобретают возможность внесения изменений в какой-то определённый слой, вместо того, чтобы перерабатывать всё приложение целиком
  • помогает структурировать приложения разложением на группы подзадач, находящихся на определенных архитектурных слоях
  • в зависимости от уровня сложности слоя, к опыту разработчиков могут быть разные требования, что позволяет распределять разработчиков по слоям в зависимости от опыта

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


В чём сейчас заключается путаница при работе с многослойной архитектурой:
  • принято считать, что слоёв должно быть 3: данные, бизнес-логика, интерфейса — но на самом деле слоёв может быть любое необходимое количество
  • нет критериев, по которым те или иные задачи относятся к тому или иному слою, что часто приводит, к созданию одного большого прикладного слоя, либо один какой либо из слоёв дорабатывается под задачи, не характерные для него
  • нет конкретного короткого определения
  • есть пересечения между понятиями слоя (layer), уровня и яруса (tier), к которым так же нет точных определений. По Фаулеру уровни относятся, подразумевая физическое разделение, а на практике такой определённости нет
Читать дальше →
Total votes 8: ↑6 and ↓2 +4
Views 4.5K
Comments 24

ООП: Кто взял Измаил? Вопрос принадлежности методов объекту

Programming *System Analysis and Design *Designing and refactoring *ООP *
Данная статья посвящена разбору вопроса о том, какому именно объекту ООП должен принадлежать метод, осуществляющий взаимодейстие между несколькими сущностями.

Это распространённая тема для холиваров. Например:
Не используйте ООП. Никогда. Это ошибка.

На эту тему есть много материалов, к примеру: www.youtube.com/watch?v=QM1iUe6IofM

Если ООП все еще кажется вам хорошей идеей, то решите простую задачку.

Есть три объекта: кошка, кормушка и человек. Вам необходимо написать метод, который бы позволял человеку покормить кошку, воспользовавшись кормушкой.

Вопрос: методом какого класса будет являться метод.покормить()?

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

Теперь сравните это с функциональной реализацией: у вас есть функция покормитьКошку() принимающая в качестве аргумента ссылку на кошку и кормушку.
Цитата из холивара

Как ответить на данный вопрос?
Читать дальше →
Total votes 37: ↑21 and ↓16 +5
Views 9.2K
Comments 398

Момент, когда проектная документация нужна

МойСклад corporate blog System Analysis and Design *Technical Writing *
Время идет, планета крутится, системы растут и развиваются, а я продолжаю слышать в кругах аналитиков сожаление: «Эх, пришел на проект, а тут никакой документации, смотрим в код».

Но это ерунда. Хуже, когда заказчик говорит: «Создали два разработчика. Уволить не могу, хотя почти ничего не делают, только по мелочи донастраивают. А с этой системой у нас уже и бухгалтерия интегрирована, и … Документация? Нет ее. А надо?.. Спасите-помогите»!

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


Читать дальше →
Total votes 1: ↑1 and ↓0 +1
Views 4K
Comments 20

Почему инженеры не могут оценить время разработки

VDSina.ru corporate blog Development Management *Project management *
Translation

Статистический подход к объяснению ошибочных дедлайнов в инженерных проектах



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

Эта проблема особенно актуальна в проектировании ПО, но и другие инженерные дисциплины страдают от того же. Поэтому хотя в этой статье говорится о проектировании ПО, она в некоторой степени относится и к другим дисциплинам.
Читать дальше →
Total votes 56: ↑55 and ↓1 +54
Views 29K
Comments 78

Экономим ресурсы и успеваем в срок: зачем подключать QA-инженера в начале работы над фичей

Kolesa Group corporate blog Web services testing *Development Management *IT career
Sandbox

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

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

Так зачем переделывать задачу и факапить сроки, если можно предотвратить большинство ошибок? Есть один вариант: QA-инженер. Специалист который будет влиять на качество процессов и продуктов на каждом этапе работы над фичей и служить связующим звеном между всеми этапами и подразделениями. В итоге вы получите качественный результат. 

Читать далее
Total votes 3: ↑3 and ↓0 +3
Views 2.3K
Comments 0