Сталкивался с проектами с ужасной кодовой базой, огромным и неуправляемым техническим долгом и прочими прелестями от – известных компаний.
Сейчас сам пилю такой же и так же.
Оказывается – “ТЗ сейчас никто не пишет!” ТЗ это ветхое прошлое.
ОК. Википедия, глубже незачем…
Вычеркивается при таком подходе:
Подпроцессы
Процесс разработки состоит из множества подпроцессов, или дисциплин, некоторые из которых:
- Анализ требований → Спецификация программного обеспечения – нафиг оба пункта
- Проектирование программного обеспечения – по ходу слепим
- Программирование – главное таску закрыть и чтобы юнит тесты к ней не падали
- Тестирование программного обеспечения – QA отдел фиксирует баги: отсутствующего кода, который в плане работ через спринт-два
- Системная интеграция (System integration) – девопсы пришли и уже ушли. При этом – на старте их не было, и в конце тоже – придется выбивать, девопс отдел так просто уже их не даст
- Сопровождение программного обеспечения – заключается в прилепливании нового функционала, другими программистами, которые работают по тем же правилам
Еще с википедии:
Барри Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:
- Дефицит специалистов. – не так страшен как отсутствие согласованной работы. Специальные библиотеки, инструменты, написанные специалистами уже обычно есть
- Нереалистичные сроки и бюджет. – потому что эстимейты ставятся от фонаря. По аналогии, которая просто по памяти – потому что программист помнит сколько он подобную таску закрывал – но не помнит сколько времени ушло на заталкивание этого кода в систему.
- Реализация несоответствующей функциональности. – без ТЗ и результат ХЗ: анализ выкинут как немодный
- Разработка неправильного пользовательского интерфейса. – без ТЗ и результат ХЗ: анализ и проектирвоание выкинуты как немодные. А сам UI рисовался веб дизайнером, далеким от разработки (*), со слов представителя заказчика, который самый неосведомленный у заказчика в UX
- Перфекционизм, ненужная оптимизация и оттачивание деталей. – зато на код ревью будет пристально рассматриваться насколько код соответствует “бест практикам”, а QA завернет UI код за 2 пикселя вместо 3ех
- Непрекращающийся поток изменений. – вызван тем что придется постоянно переделывать то что было написано наобум. Напомню: анализ требований → спецификации → проектирование – пропущены как немодные
- Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию. – программисту под видом таски выдается юзер сторя в которой пара предложений. Дальше он додумывает себе в одиночку.
- Недостаточная производительность получаемой системы. – анализа и проектирования не было – соответственно никто и близко не думал об этих проблемах. Которые обычно вызваны получившиейся архитектурой, потоком управления и трансформаций данных
- Разрыв в квалификации специалистов разных областей. – случайно собранные свободные программисты – не команда. Их квалификация становится не важной, потому что писанное ими наобум, без проектирования общей системы – приведет к сборке пазла с неизвестной заранее картинкой и с разных комплектов. И какого качества отдельная пазлинка – неважно
* промышленный дизайн – дизайн учитывающий возможности оборудования, технологий, стоимость ресурсов при серийном выпуске.
в этом главное отличие от просто дизайна как вида изобразительного искусства.
Пример:
Первые цветные ткацкие станки умели работать с 4мя нитями = 4 цвета. Дизайнер узора ткани обязан был учитывать что:
у него есть только 4ре цвета. И такие и таких их оттенков – нити которых распространены и дешевы, если ткань планируется для массового выпуска.
А также должен учитывать разную скорость выцветания цветов, если краска нитей сделана по разным технологиям, чтобы со временем ткань не теряла товарного вида, особенно если данная ткань будет использоваться для выпуска одежды.
Из личного опыта – усредненный веб дизайнер на проектах – совсем не промышленный, а просто художник.
И поэтому:
дизайнера следует приглашать только на последних этапах.
для разукрашивания уже существующего UI – сделанного на основе массового фреймворка.
Идеальный промышленный дизайн для Web UI – не должен требовать переверстки, а тем более переделки логики работы UI или борьбы с выбранным CSS фреймворком.
“Для смены скина – программу не нужно переписывать”