Честно говоря, вы похоже не участвовали в реальной разработке в реальных компаниях )) Сразу прошу у вас прощения, за такой переход на личности.
Совершенно верно. Но переход на личности приветствую. Сейчас это очень нужно.
... Да, а что вас удивляет? иначе программисты были бы не нужны, весь код бы генерировался из шаблонов.
Для меня вопрос в том, что именно идёт в дело, что именно превращается в код. Придумать несколько решений можно, но почему-то Петя делает одно, а Вася — другое. Кто-то же даёт отмашку? Или каждый поработал самостоятельно и принёс решение?
Бесконечное количество. И кстати - они ВСЕ будут формально соответствовать исходным требованиям.
Мне трудно иметь дело с отвлечёнными примерами. Всё-таки, кажется, что на практике в Ваших тикетах встречаются более конкретные указания.
Манифест agile с вами несогласен)
Скорее всего, это так и есть. Но я не стремлюсь специально вступать с чем-то в противоречие. Я просто рассуждаю. Могу войти и в противоречие.
Сегодня вы пилите утвержденную фичу, а завтра изменилась ситуация на рынке, и фича стала не актуальна, или должна быть видоизменена.
А вот это уже очень интересно. Допустим, произошли изменения. Какие-то. Весь вопрос в том, что с эти делать. Как Вы будете "выпиливать" фичу из готового продукта? И какие варианты видоизменения могут считаться допустимыми? Как быть. если эти изменения потребуют видоизменения архитектуры самого приложения? Там, ещё, зависимости разные...
т.е. после каждой выполненной задачи сразу стирать весь бэклог? на которые с вашим подходом убиты тысячи часов, чтобы декомпозировать и расписать и оценить всё до мелочей?
Подождите! В Вашем примере "Вася пилил фичу до рефакторинга всей подсистемы". Зачем же пришёл Петя уже после рефаторинга и снова стал пилить ту же фичу? Давайте уточним условия задачи.
Простите, но мир так устроен.
Да он устроен так, как устроен. Вы правильно это описываете. Даже я это понимаю, хотя опыта соприкосновения с этим миром не имею. (Когда-то давно соприкоснулся, но... один раз не считается.)
Меня же, например, интересует, почему положительный опыт не тиражируеся. И что было бы, если бы, например, agile не было бы? Что было бы вместо agile? Старый-добрый каскад? Всё крутится вокруг того, если способ сделать мир немного проще.
Представим себе, что в нашем ведении находится разработка форума, вроде того, где мы сейчас сидим. Текущий способ редактирования сообщений представляется не очень удобным (нужно куда-то бегать мышкой, "скроллить" и ловить всплывающие меню). Хочется как-то модернизировать. Но как?
Ключевой вопрос — это вопрос о том, что является (должно быть) единицей обработки. Традиционно считается, что единицей обработки является отдельное сообщение (пост). Мы можем вручную вырезать нужный фрагмент и оформить цитату. Но удобнее сразу иметь возможность прокомментировать конкретный фрагмент, неправда ли? Для этого надо, чтобы единицей обработки было отдельное предложение. Тогда каждый пост можно будет развернуть в виде набора атомарных постов, и реализовать наборы типовых операций над отдельными предложениями или их наборами. В результате, Вы получаете обратно Ваш текст, но уже размеченный Вашим собеседником. И так — для каждого Вашего собеседника. Да и в пользовательском интерфейсе не надо будет решать проблему линейного/иерархического отображения реплик, а пользователь сам будет определять, в каком виде реплики будут отображаться (автоматически).
Выбор единицы обработки определяет архитектуру системы.
Или, другой например. Вот, когда мы смотрим ленту Хабра и переходим на новую страницу, что происходит? К БД посылается запрос, получить соответствующий набор статей на момент совершения запроса. Это означает, что, пока Вы сидите на одной странице, проходит время, за которой на Хабре появились новые статьи, происходит сдвиг. В результате, Вы снова получаете ряд уже виденных Вами на предыдущей странице статей. Спрашивается, это что: "баг" или "фича". Нужно ли это исправлять? Например, можно было бы запомнить самую последнюю статью на момент захода пользователя на Хабр, а все новые статьи отображать на отдельной странице ("новые"). И тогда не будет никаких сдвигов, всё будет логично и понятно. Разве не так?
Но! Кто-то сделал то, что сейчас работает? Интересно, как этот разработчик объяснял себе странное поведение ленты? И что будет делать этот разработчик, если дать ему новый тикет, попросив его переделать отображение ленты?
В обычной ситуации, скорее всего, невозможно. Но мы с Вами тут сидим и рассуждаем, что-то себе представляем. то есть — находимся в необычной ситуации.
Реальный проект - это десятки тысяч тикетов, каждый из которых может содержать скрытые подзадачи.
Разве процесс проектирования не заключается в том, чтобы сделать все задачи явными?
Почти не бывает идеально описанных тикетов, всегда есть подразумевающийся контекст, допущения, упрощения, просто ошибки, и "устные договоренности", возникшие во время разработки, и нигде не зафиксированные.
Да, конечно. Но разве процесс проектирование не направлен на то, чтобы (в пределе) формализовать все "устные договорённости"?
Берете два с виду одинаковых тикета. Но один делал Вася, а другой - Петя.
Это у Вас есть какой-то тикет. Но, представьте, что нужно что-то сделать, так надо, сначала, назвать, что именно. Мы должны указать место, где должны быть произведены изменения, и описаны сами требуемые изменения. Как только это место найдено в спецификации (и на языке спецификации), Вася или Петя делают одно и то же и закрывают тикет. Ведь, тикет явно указывает, что нужно сделать, что и в какую сторону изменить. Разве не так?
И они выбрали разные пути решения.
Почему? Неужели задача, связанная с обрабатываемым тикетом, столь велика, что допускает множество решений? Надо же понимать, что различные пути решения затрагивают различные аспекты уже существующей архитектуры, а какие-то требуют её изменения. Не все решения оказываются, таким образом, допустимыми.
И Вася был после кранча/болезни, а Петя после отпуска.
формализация процесса разработки ПО (на мой непросвещённый взгляд) должна гарантировать независимость разработки от такого рода привходящих обстоятельств, поскольку, при необходимости что-то сделать, каждый будет заглядывать в одни и те же места спецификации, руководствоваться одними и теми же положениями общих для всех документов.
И кто-то внешний, менеджер на приемке, тестировщик на тесте, лид/коллега на ревью указал им на разные недостатки.
Вполне естественно, что, если Вася и Петя пойдут разными путями, то они получат и разные результаты. Вопрос в том, что должно происходить в тот момент, когда каждый из них принимает какое-то решение и собирается его реализовать. Вот тут и нужно провозгласить, что именно планируется сделать, и выяснить потенциальные недостатки, не дожидаясь конечного результата. Как можно пытаться кодировать то, что может быть забраковано? Пускать в реализацию, кажется, можно только то, что принято и утверждено.
И Вася пилил фичу до рефакторинга всей подсистемы, а Петя - после.
Страшное дело! А зачем Петя пилил? Система прошла рефаторинг? Отменить все старые тикеты!
А ешё за это время поменялся контракт взаимодействия с внешним сервисом.
Кранты! Снизу постучали. Опять.
И оказалось что когда Петя закончит фичу - девопсы сломали тестовый стенд, и Петя потратит лишние пару часов на поиск причины.
Простите, а почему у Вас один и тот же стенд для старой и для новой системы?
Всё это и многое другое не будет учтено при оценке (и в гипотетической общей табличке оценок)
Если общая таблица оценок существует (построена), то варианты разработки выбираются из неё и только из неё. Если имеются неучтённые факторы, то нужно строить новую таблицу оценок. Всё, о чём я говорю, это вопросы целостности (непротиворечивости) описания. Чрезвычайно сложно действовать в раздробленном мире, где ТЗ меняется на ходу, и никто ничего не может спланировать наперёд.
В общем, на мой взгляд эти противоречия абсолютно неразрешимы ...
Самое главное противоречие — это противоречие между глубокой практичностью программистов на деле, и совершенной абстрактностью тех же программистов на словах. Почему, когда программист хочет поделиться какой-то проблемой, он произносит только общие слова? Почему программист не приводит конкретных примеров? Можно было бы посмотреть реальный проект, оценить способы и сроки исполнения, попробовать сделать то же самое при помощи других подходов, сравнить результаты, сформулировать выводы. Разве не так?
Противоречие: бизнесу абсолютно необходимо оценивать качество и скорость работы программиста, но это абсолютно невозможно сделать объективно.
Учёные давно занимают вопросами построения всевозможных систем. И всё, что подлежит оценке, оценивается (включая и временные затраты). Только никто этим не пользуется при разработке ПО.
В этом смысле, было бы крайне любопытно посмотреть на руководителя какой-нибудь конторы, который возьмёт только что сделанную и сданную заказчику успешно функционирующую систему, разложит по полочкам её составные части, выявит все зависимости, выделит смысловое ядро и построит движок, на котором могла бы "крутиться" такая система. А потом сравнит реальные произведённые затраты и те затраты, которые могли бы быть потрачены, если бы вот эта самая постфактум-разработка была бы проделана в реальности. "Движок" — это и есть то, что фактически нужно сделать. Вы продаёте заказчику "движок". Меняется ТЗ — меняется и "движок". Хотите ещё большей гибкости — создавайте "дижок" "движков". И, заметьте, это всё предельно очевидно. Разве не так?
С другой стороны, разработка порою в душе не е... вообще не знает, сколько надо времени, особенно если
новая функциональность нетипична
есть зависимости на другие команды
будет задействована новая технология
ТЗ надо сильно уточнять
надо разобраться в логике легаси-кода
Сразу возникает вопрос. Почему функциональность какой-то фичи может оказаться нетипичной? Разве набор фич не может быть ограниченным? Возьмите какую-нибудь задачу. Попробуйте расписать разного рода сценарии. Разве их не будет весьма ограниченное количество? Вот и надо один раз закодировать каждый сценарий (в виде рабочего компонента) и потом брать из готового каталога. Разве не так?
А команды? Кто распределял нагрузку между командами, что бы были такие патологические зависимости? Зачем же существует модульное проектирование? Неужели фича размывает границы между модулями? Если это так, то надо. вообще, новую систему делать. Разве не так?
Новая технология? Стоп. Когда что-то разрабатывается, то, разве, не утверждается список используемых технологий? Каждая новая технология содержит свой уникальный набор собственных внутренних нетипичных фич (см. п.1), которые будут размывать изначальную модульность (см. п.2).
Уточнение ТЗ представляется (лично мне) признаком ошибочности его составления. Например. (Я немного утрирую.) Сначала создавалась система, которая не предполагала никакого участия пользователей в редактировании материалов некоторого сайта. Затем, захотелось добавить новую "фичу" — редактирование. Но это же — совершенно другая система, другая идеология! При этом, заранее можно сеть и просчитать каждый вариант системы, для каждого варианта предложить свою архитектуру и разговаривать с заказчиком на уровне архитектуры, не на уровне фич. Разве не так?
А ещё пресловутое "легаси"... Все привыкли к тому, что берётся и правится уже существующий действующий код. Только зачем так делают? Меняется, ведь, спецификация системы. Значит, нужно повторить те же шаги. что и были раньше сделаны, но уже с новыми вводными данными. Тут ещё проблема в том, что всё делают в рамках одного языка программирования. А система должна описываться (проектироваться) на одном языке, а реализовываться при помощи генерации программного кода на другом языке. И править нужно первичное описание, а не конечную реализацию. Разве не так?
С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно — ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве.
Если бы всё фичи были бы заранее известны, пронумерованы, поименованы и закодированы, то не надо было бы ничего заранее разрабатывать. Неразрешимое противоречие заключается, скорее всего, в том, что все всегда начинают с чистого листа (как будь-то до нас ничего не было и даже мы сами ничего ещё не делали, хотя... нет! делали! есть же "легаси"!), но никто не хочет пронумеровать, поименовать и закодировать.
А так было бы здорово иметь каталог фич (типа Периодической таблицы химических элементов) и знать заранее все характеристики.
Ну, знаете, до того, чтобы дойти до прикладной инженерии (как Вы и говорите), нужно пройти путь фундаментальных исследований. Наука — это есть то, чему научились, что смогли осознать, обобщить привести в систему, обосновать и изложить в виде технологий, то есть — алгоритмов и спецификаций.
Фундаментальные исследования — это исследования в области реляционной алгебры и, например, в области динамических отношений.
Фундаментальные исследования — это исследования в области построения онтологий. Например, можно ли обобщить различные онтологии.
Фундаментальные исследования — это исследования в области представлений данных и в области построения вычислительных систем (то есть — архитектур, способов спецификации программных систем).
Фундаментальные исследования — это исследования в области построения компиляторов и, вообще, в области автоматической генерации программного кода и доказательного программирования.
Я вижу проблему в том, что наука никак не пополнятся новыми данными, что не идёт никакое обобщение. Если бы оно было, то предлагались бы новые архитектуры, новые подходы к организации вычислений, новые способы построения интерфейсов (включая и пользовательских). Пользуемся всем старым.
За предыдущее десятилетие отрасль разработки ПО перешла от каскадной модели к agile. В каскадной модели чётко задаётся желаемое до того, как написано код, а agile обеспечивает достаточную гибкость для внесения изменений по ходу движения.
Придётся немного "зацепиться"...
Предположим, нужно создать некую систему, решающую определённую задачу. Это новая задача? Её никто не решал до Вас? Это новая система? Такую систему уже делали до Вас? Если в прошлом уже что-то было, то где результаты этой работы? Где выводы? Где код? Где уже законченная спецификация системы? Ведь, если такая спецификация уже есть, то её надо брать готовенькую и автоматически строить код. (Вопросы авторского права я оставляю за скобками. Я говорю о возможностях.)
Концептуальная причина сложившегося положения вещей — это отсутствие науки. Если бы была наука, то можно было бы что-то системное предложить. Можно было бы что-то поменять в существующих протоколах. Оптимизировать. Ввести какие-то новые уровни. Может быть, даже, модернизировать бухгалтерский учёт. Создать что-то принципиально новое. Всё, чем мы пользуемся, в своей основе, создано задолго до нас. А, вот, создать что-то принципиально новое, человечество пасует. А ещё очень трудно жить в мире, где очень мало самого контроля (и, поэтому, часто, происходит всё, что угодно), но, зато, очень много контролирующих. Отсюда и обилие протоколов, систем и стандартов. Отсюда и "легаси".
Все описанные неудобства и сложности имеют относительно понятные и простые технические решения.
Отказ от "легаси" — это тяжёлый психологический барьер. Трудно отказаться от того, во что вложены многие человеко-часы. Хотя, впрочем, история информационных технологий — это история постоянного отказа от старого кода в пользу более современных библиотек и инструментов, решающих те же задачи. Но, спрашивается, зачем выкидывать старый код, если он работает?
Всегда есть "закон парето". И главный "закон парето" — это фундаментальное противоречие между потребностями бизнеса (извлечение прибыли) и потребностями потребителей (потреблять потребляемое, желательно, с наименьшими затратами). Все хотят уменьшить затраты. В свою пользу.
Понятный процент брака и понятная схема замены этого брака отлично работают в большинстве сфер.
Лично для меня более понятная схема работа такая: если у меня выходит из строя принтер, то, либо мне полностью заменяют принтер (можно насчитать амортизацию), либо ... изначально встраивают в принтер модульность (СНПЧ, барабан, головка и т.д., и т.п.) + отдельная продажа комплектующих. Для этого надо поддерживать в рабочем состоянии заводы, производящие старые модели, и ограничивать аппетиты производителей, которые так и норовят заработать на расходниках. И, кстати, я бы не отказался бы ещё от такой возможности, как гарантийное обслуживание, когда моё оборудование (компьютер, переферия и переходники) находятся на гарантийном обслуживании определённой конторы. Если у конторы есть на гарантийном обслуживании определённый парк оборудования, то ясно, что нужно ещё производить, к чему ещё нужны комплектующие. Но... это только лично мне. Хотя... человечество могло бы воспользоваться. Ведь, что мы имеем? Что-то перестают производить. А оно ещё у кого-то в ходу. Как поддерживать? Значит, нельзя было прекращать производить. Значит, этим должен кто-то заниматься. Например, ОС Windows XP. Вроде бы была неплохая ОС. Значит, надо отдать поддержку этой ОС в надёжные руки. Пусть Microsoft зарабатывает на новых продуктах. Но и пусть, чтобы кто-то зарабатывал на старых, проверенных продуктах.
Подобные рассуждения всегда односторонние. Попробуйте продолжить цепочку. Например, Вы. Вам тоже можно было бы работать медленнее. Если бы все работал бы медленнее, то дело было бы более качественным, а деньги крутились бы быстрее.
Я говорю о той ситуации, когда я делаю заказ вчера и надеюсь на то, что мне его полностью привезут. Но, на деле, его начинают собирать только сегодня, и из того, что есть на складе сегодня. А хотелось бы, чтобы мой заказ увидели уже вчера, и всё требуемое подвезли заранее. Неужели это так трудно?
Зачем конечному потребителю прослеживать всю цепочку?
Конечному потребителю важно знать, покупает ли он требуемый товар или нет. Возьмите, например, масло, чай, кофе, соль. Где произведено? Как определить подделку? Это произведено на том заводе, как это указано на упаковке? Определённый чай (или кофе) растёт в определённом месте. Другое место не подходит. Оборудование. Произведено где? В Китае? В Чехии? В Германии? И гарантийное обслуживание. К кому обращаться? В магазин по чеку? Или, всё-таки, к производителю?
Банку или тем более иному эмитенту не положено знать, что вы купили по карте. Но да, он может вести учёт в разрезе MCC (Merchant Category Code), чтобы устанавливать разные лимиты и другие условия для разных видов покупок.
В целом, всё, что Вы говорите (не только про банки), понятно и возражений не вызывает. Но я хочу остановиться на одном моменте.
Предположим, речь идёт об оплате ЖКХ. Разве не было бы очень удобно централизованно платить за ЖКХ прямо интернет-банке? Так, чтобы прямо туда приходили квитанции. Чтобы все перечисления были хорошо атрибутированы. Чтобы это всё было — в одном месте, а не раскидано по различным личным кабинетам. Чтобы и показания счётчиков вводить. Чтобы видеть всю историю платежей (это была бы простая выписка, возможно, даже, по специальному счёту).
А ещё есть такое понятие как "акция". Хочешь купить товар по "акционной" цене, но не всегда удаётся. В магазине любят менять ценники. Например, "акция" уже закончилась (и касса про это знает), а "акционный" ценник ещё висит. Или обратная ситуация, когда касса ничего не знает про "акцию". (Вряд ли такое возможно.)
А если заказ делается в интернет-магазине, например, на завтра. Ведь заказ тоже начинает собирать в день исполнения. Вчера товар ещё был, а утром его уже нет. Если бы об этом знать заранее! Тогда и не должно быть кнопочки "Положить в корзину". Тут и нужно иметь хотя бы примерную оценку количества требуемого товара.
Плюс, ещё, такая возможность завести к утру (к моменту выполнения заказа) на выбранный склад всего недостающего. Почему-то никто так не делает.
Тут ещё вопрос в том, что ошибки бывают двух видов: нет дырки или контакта, где они должны быть, или есть дырка или контакт, где они не должны быть. Надо договориться, что делать в каждом случае.
... безошибочную систему построить практически нельзя (очень дорого).
Большинство, наверное, так и думает. Но я хотел бы спросить: почему нельзя, почему дорого? Тут, наверное, вопрос приоритетов: важнее побыстрее и побольше выдать продукции, не особо заморачиваясь с качеством, или, всё-таки, пытаться это самое качество как-то обеспечивать (за счёт сокращения объёмов продукции и увеличении времени выполнения заказов).
Совершенно верно. Но переход на личности приветствую. Сейчас это очень нужно.
Для меня вопрос в том, что именно идёт в дело, что именно превращается в код. Придумать несколько решений можно, но почему-то Петя делает одно, а Вася — другое. Кто-то же даёт отмашку? Или каждый поработал самостоятельно и принёс решение?
Мне трудно иметь дело с отвлечёнными примерами. Всё-таки, кажется, что на практике в Ваших тикетах встречаются более конкретные указания.
Скорее всего, это так и есть. Но я не стремлюсь специально вступать с чем-то в противоречие. Я просто рассуждаю. Могу войти и в противоречие.
А вот это уже очень интересно. Допустим, произошли изменения. Какие-то. Весь вопрос в том, что с эти делать. Как Вы будете "выпиливать" фичу из готового продукта? И какие варианты видоизменения могут считаться допустимыми? Как быть. если эти изменения потребуют видоизменения архитектуры самого приложения? Там, ещё, зависимости разные...
Подождите! В Вашем примере "Вася пилил фичу до рефакторинга всей подсистемы". Зачем же пришёл Петя уже после рефаторинга и снова стал пилить ту же фичу? Давайте уточним условия задачи.
Да он устроен так, как устроен. Вы правильно это описываете. Даже я это понимаю, хотя опыта соприкосновения с этим миром не имею. (Когда-то давно соприкоснулся, но... один раз не считается.)
Меня же, например, интересует, почему положительный опыт не тиражируеся. И что было бы, если бы, например, agile не было бы? Что было бы вместо agile? Старый-добрый каскад? Всё крутится вокруг того, если способ сделать мир немного проще.
И ещё. Давайте не будем ходить далеко.
Представим себе, что в нашем ведении находится разработка форума, вроде того, где мы сейчас сидим. Текущий способ редактирования сообщений представляется не очень удобным (нужно куда-то бегать мышкой, "скроллить" и ловить всплывающие меню). Хочется как-то модернизировать. Но как?
Ключевой вопрос — это вопрос о том, что является (должно быть) единицей обработки. Традиционно считается, что единицей обработки является отдельное сообщение (пост). Мы можем вручную вырезать нужный фрагмент и оформить цитату. Но удобнее сразу иметь возможность прокомментировать конкретный фрагмент, неправда ли? Для этого надо, чтобы единицей обработки было отдельное предложение. Тогда каждый пост можно будет развернуть в виде набора атомарных постов, и реализовать наборы типовых операций над отдельными предложениями или их наборами. В результате, Вы получаете обратно Ваш текст, но уже размеченный Вашим собеседником. И так — для каждого Вашего собеседника. Да и в пользовательском интерфейсе не надо будет решать проблему линейного/иерархического отображения реплик, а пользователь сам будет определять, в каком виде реплики будут отображаться (автоматически).
Выбор единицы обработки определяет архитектуру системы.
Или, другой например. Вот, когда мы смотрим ленту Хабра и переходим на новую страницу, что происходит? К БД посылается запрос, получить соответствующий набор статей на момент совершения запроса. Это означает, что, пока Вы сидите на одной странице, проходит время, за которой на Хабре появились новые статьи, происходит сдвиг. В результате, Вы снова получаете ряд уже виденных Вами на предыдущей странице статей. Спрашивается, это что: "баг" или "фича". Нужно ли это исправлять? Например, можно было бы запомнить самую последнюю статью на момент захода пользователя на Хабр, а все новые статьи отображать на отдельной странице ("новые"). И тогда не будет никаких сдвигов, всё будет логично и понятно. Разве не так?
Но! Кто-то сделал то, что сейчас работает? Интересно, как этот разработчик объяснял себе странное поведение ленты? И что будет делать этот разработчик, если дать ему новый тикет, попросив его переделать отображение ленты?
В обычной ситуации, скорее всего, невозможно. Но мы с Вами тут сидим и рассуждаем, что-то себе представляем. то есть — находимся в необычной ситуации.
Разве процесс проектирования не заключается в том, чтобы сделать все задачи явными?
Да, конечно. Но разве процесс проектирование не направлен на то, чтобы (в пределе) формализовать все "устные договорённости"?
Это у Вас есть какой-то тикет. Но, представьте, что нужно что-то сделать, так надо, сначала, назвать, что именно. Мы должны указать место, где должны быть произведены изменения, и описаны сами требуемые изменения. Как только это место найдено в спецификации (и на языке спецификации), Вася или Петя делают одно и то же и закрывают тикет. Ведь, тикет явно указывает, что нужно сделать, что и в какую сторону изменить. Разве не так?
Почему? Неужели задача, связанная с обрабатываемым тикетом, столь велика, что допускает множество решений? Надо же понимать, что различные пути решения затрагивают различные аспекты уже существующей архитектуры, а какие-то требуют её изменения. Не все решения оказываются, таким образом, допустимыми.
формализация процесса разработки ПО (на мой непросвещённый взгляд) должна гарантировать независимость разработки от такого рода привходящих обстоятельств, поскольку, при необходимости что-то сделать, каждый будет заглядывать в одни и те же места спецификации, руководствоваться одними и теми же положениями общих для всех документов.
Вполне естественно, что, если Вася и Петя пойдут разными путями, то они получат и разные результаты. Вопрос в том, что должно происходить в тот момент, когда каждый из них принимает какое-то решение и собирается его реализовать. Вот тут и нужно провозгласить, что именно планируется сделать, и выяснить потенциальные недостатки, не дожидаясь конечного результата. Как можно пытаться кодировать то, что может быть забраковано? Пускать в реализацию, кажется, можно только то, что принято и утверждено.
Страшное дело! А зачем Петя пилил? Система прошла рефаторинг? Отменить все старые тикеты!
Кранты! Снизу постучали. Опять.
Простите, а почему у Вас один и тот же стенд для старой и для новой системы?
Если общая таблица оценок существует (построена), то варианты разработки выбираются из неё и только из неё. Если имеются неучтённые факторы, то нужно строить новую таблицу оценок. Всё, о чём я говорю, это вопросы целостности (непротиворечивости) описания. Чрезвычайно сложно действовать в раздробленном мире, где ТЗ меняется на ходу, и никто ничего не может спланировать наперёд.
Самое главное противоречие — это противоречие между глубокой практичностью программистов на деле, и совершенной абстрактностью тех же программистов на словах. Почему, когда программист хочет поделиться какой-то проблемой, он произносит только общие слова? Почему программист не приводит конкретных примеров? Можно было бы посмотреть реальный проект, оценить способы и сроки исполнения, попробовать сделать то же самое при помощи других подходов, сравнить результаты, сформулировать выводы. Разве не так?
Учёные давно занимают вопросами построения всевозможных систем. И всё, что подлежит оценке, оценивается (включая и временные затраты). Только никто этим не пользуется при разработке ПО.
В этом смысле, было бы крайне любопытно посмотреть на руководителя какой-нибудь конторы, который возьмёт только что сделанную и сданную заказчику успешно функционирующую систему, разложит по полочкам её составные части, выявит все зависимости, выделит смысловое ядро и построит движок, на котором могла бы "крутиться" такая система. А потом сравнит реальные произведённые затраты и те затраты, которые могли бы быть потрачены, если бы вот эта самая постфактум-разработка была бы проделана в реальности. "Движок" — это и есть то, что фактически нужно сделать. Вы продаёте заказчику "движок". Меняется ТЗ — меняется и "движок". Хотите ещё большей гибкости — создавайте "дижок" "движков". И, заметьте, это всё предельно очевидно. Разве не так?
новая функциональность нетипична
есть зависимости на другие команды
будет задействована новая технология
ТЗ надо сильно уточнять
надо разобраться в логике легаси-кода
Сразу возникает вопрос. Почему функциональность какой-то фичи может оказаться нетипичной? Разве набор фич не может быть ограниченным? Возьмите какую-нибудь задачу. Попробуйте расписать разного рода сценарии. Разве их не будет весьма ограниченное количество? Вот и надо один раз закодировать каждый сценарий (в виде рабочего компонента) и потом брать из готового каталога. Разве не так?
А команды? Кто распределял нагрузку между командами, что бы были такие патологические зависимости? Зачем же существует модульное проектирование? Неужели фича размывает границы между модулями? Если это так, то надо. вообще, новую систему делать. Разве не так?
Новая технология? Стоп. Когда что-то разрабатывается, то, разве, не утверждается список используемых технологий? Каждая новая технология содержит свой уникальный набор собственных внутренних нетипичных фич (см. п.1), которые будут размывать изначальную модульность (см. п.2).
Уточнение ТЗ представляется (лично мне) признаком ошибочности его составления. Например. (Я немного утрирую.) Сначала создавалась система, которая не предполагала никакого участия пользователей в редактировании материалов некоторого сайта. Затем, захотелось добавить новую "фичу" — редактирование. Но это же — совершенно другая система, другая идеология! При этом, заранее можно сеть и просчитать каждый вариант системы, для каждого варианта предложить свою архитектуру и разговаривать с заказчиком на уровне архитектуры, не на уровне фич. Разве не так?
А ещё пресловутое "легаси"... Все привыкли к тому, что берётся и правится уже существующий действующий код. Только зачем так делают? Меняется, ведь, спецификация системы. Значит, нужно повторить те же шаги. что и были раньше сделаны, но уже с новыми вводными данными. Тут ещё проблема в том, что всё делают в рамках одного языка программирования. А система должна описываться (проектироваться) на одном языке, а реализовываться при помощи генерации программного кода на другом языке. И править нужно первичное описание, а не конечную реализацию. Разве не так?
Если бы всё фичи были бы заранее известны, пронумерованы, поименованы и закодированы, то не надо было бы ничего заранее разрабатывать. Неразрешимое противоречие заключается, скорее всего, в том, что все всегда начинают с чистого листа (как будь-то до нас ничего не было и даже мы сами ничего ещё не делали, хотя... нет! делали! есть же "легаси"!), но никто не хочет пронумеровать, поименовать и закодировать.
А так было бы здорово иметь каталог фич (типа Периодической таблицы химических элементов) и знать заранее все характеристики.
Ну, знаете, до того, чтобы дойти до прикладной инженерии (как Вы и говорите), нужно пройти путь фундаментальных исследований. Наука — это есть то, чему научились, что смогли осознать, обобщить привести в систему, обосновать и изложить в виде технологий, то есть — алгоритмов и спецификаций.
Фундаментальные исследования — это исследования в области реляционной алгебры и, например, в области динамических отношений.
Фундаментальные исследования — это исследования в области построения онтологий. Например, можно ли обобщить различные онтологии.
Фундаментальные исследования — это исследования в области представлений данных и в области построения вычислительных систем (то есть — архитектур, способов спецификации программных систем).
Фундаментальные исследования — это исследования в области построения компиляторов и, вообще, в области автоматической генерации программного кода и доказательного программирования.
Я вижу проблему в том, что наука никак не пополнятся новыми данными, что не идёт никакое обобщение. Если бы оно было, то предлагались бы новые архитектуры, новые подходы к организации вычислений, новые способы построения интерфейсов (включая и пользовательских). Пользуемся всем старым.
Придётся немного "зацепиться"...
Предположим, нужно создать некую систему, решающую определённую задачу. Это новая задача? Её никто не решал до Вас? Это новая система? Такую систему уже делали до Вас? Если в прошлом уже что-то было, то где результаты этой работы? Где выводы? Где код? Где уже законченная спецификация системы? Ведь, если такая спецификация уже есть, то её надо брать готовенькую и автоматически строить код. (Вопросы авторского права я оставляю за скобками. Я говорю о возможностях.)
У кого-то есть работающий Matlab...
Концептуальная причина сложившегося положения вещей — это отсутствие науки. Если бы была наука, то можно было бы что-то системное предложить. Можно было бы что-то поменять в существующих протоколах. Оптимизировать. Ввести какие-то новые уровни. Может быть, даже, модернизировать бухгалтерский учёт. Создать что-то принципиально новое. Всё, чем мы пользуемся, в своей основе, создано задолго до нас. А, вот, создать что-то принципиально новое, человечество пасует. А ещё очень трудно жить в мире, где очень мало самого контроля (и, поэтому, часто, происходит всё, что угодно), но, зато, очень много контролирующих. Отсюда и обилие протоколов, систем и стандартов. Отсюда и "легаси".
Отказ от "легаси" — это тяжёлый психологический барьер. Трудно отказаться от того, во что вложены многие человеко-часы. Хотя, впрочем, история информационных технологий — это история постоянного отказа от старого кода в пользу более современных библиотек и инструментов, решающих те же задачи. Но, спрашивается, зачем выкидывать старый код, если он работает?
А наука здесь нужна, чтобы упорядочить опыт...
Всегда есть "закон парето". И главный "закон парето" — это фундаментальное противоречие между потребностями бизнеса (извлечение прибыли) и потребностями потребителей (потреблять потребляемое, желательно, с наименьшими затратами). Все хотят уменьшить затраты. В свою пользу.
Лично для меня более понятная схема работа такая: если у меня выходит из строя принтер, то, либо мне полностью заменяют принтер (можно насчитать амортизацию), либо ... изначально встраивают в принтер модульность (СНПЧ, барабан, головка и т.д., и т.п.) + отдельная продажа комплектующих. Для этого надо поддерживать в рабочем состоянии заводы, производящие старые модели, и ограничивать аппетиты производителей, которые так и норовят заработать на расходниках. И, кстати, я бы не отказался бы ещё от такой возможности, как гарантийное обслуживание, когда моё оборудование (компьютер, переферия и переходники) находятся на гарантийном обслуживании определённой конторы. Если у конторы есть на гарантийном обслуживании определённый парк оборудования, то ясно, что нужно ещё производить, к чему ещё нужны комплектующие. Но... это только лично мне. Хотя... человечество могло бы воспользоваться. Ведь, что мы имеем? Что-то перестают производить. А оно ещё у кого-то в ходу. Как поддерживать? Значит, нельзя было прекращать производить. Значит, этим должен кто-то заниматься. Например, ОС Windows XP. Вроде бы была неплохая ОС. Значит, надо отдать поддержку этой ОС в надёжные руки. Пусть Microsoft зарабатывает на новых продуктах. Но и пусть, чтобы кто-то зарабатывал на старых, проверенных продуктах.
Подобные рассуждения всегда односторонние. Попробуйте продолжить цепочку. Например, Вы. Вам тоже можно было бы работать медленнее. Если бы все работал бы медленнее, то дело было бы более качественным, а деньги крутились бы быстрее.
Я говорю о той ситуации, когда я делаю заказ вчера и надеюсь на то, что мне его полностью привезут. Но, на деле, его начинают собирать только сегодня, и из того, что есть на складе сегодня. А хотелось бы, чтобы мой заказ увидели уже вчера, и всё требуемое подвезли заранее. Неужели это так трудно?
Есть на складе? Дайте две! ;-)
Конечному потребителю важно знать, покупает ли он требуемый товар или нет. Возьмите, например, масло, чай, кофе, соль. Где произведено? Как определить подделку? Это произведено на том заводе, как это указано на упаковке? Определённый чай (или кофе) растёт в определённом месте. Другое место не подходит. Оборудование. Произведено где? В Китае? В Чехии? В Германии? И гарантийное обслуживание. К кому обращаться? В магазин по чеку? Или, всё-таки, к производителю?
В целом, всё, что Вы говорите (не только про банки), понятно и возражений не вызывает. Но я хочу остановиться на одном моменте.
Предположим, речь идёт об оплате ЖКХ. Разве не было бы очень удобно централизованно платить за ЖКХ прямо интернет-банке? Так, чтобы прямо туда приходили квитанции. Чтобы все перечисления были хорошо атрибутированы. Чтобы это всё было — в одном месте, а не раскидано по различным личным кабинетам. Чтобы и показания счётчиков вводить. Чтобы видеть всю историю платежей (это была бы простая выписка, возможно, даже, по специальному счёту).
А ещё есть такое понятие как "акция". Хочешь купить товар по "акционной" цене, но не всегда удаётся. В магазине любят менять ценники. Например, "акция" уже закончилась (и касса про это знает), а "акционный" ценник ещё висит. Или обратная ситуация, когда касса ничего не знает про "акцию". (Вряд ли такое возможно.)
А если заказ делается в интернет-магазине, например, на завтра. Ведь заказ тоже начинает собирать в день исполнения. Вчера товар ещё был, а утром его уже нет. Если бы об этом знать заранее! Тогда и не должно быть кнопочки "Положить в корзину". Тут и нужно иметь хотя бы примерную оценку количества требуемого товара.
Плюс, ещё, такая возможность завести к утру (к моменту выполнения заказа) на выбранный склад всего недостающего. Почему-то никто так не делает.
Тут ещё вопрос в том, что ошибки бывают двух видов: нет дырки или контакта, где они должны быть, или есть дырка или контакт, где они не должны быть. Надо договориться, что делать в каждом случае.
Большинство, наверное, так и думает. Но я хотел бы спросить: почему нельзя, почему дорого? Тут, наверное, вопрос приоритетов: важнее побыстрее и побольше выдать продукции, не особо заморачиваясь с качеством, или, всё-таки, пытаться это самое качество как-то обеспечивать (за счёт сокращения объёмов продукции и увеличении времени выполнения заказов).