Уважаемый Читатель!
Чтобы лучше понять содержание этого поста, Вам необходимо прочитать предыдущий пост на эту тему: Разработка Программ == Материализация Идей (http://smartenesse-ru.sirotin.eu/разработка-программ-материализация)
Но сначала небольшое отступление. В стародавние времена в философских трактатах авторы нередко применяли такой прием, как диалоги с оппонентами или скептиками. Воспользуемся этим приёмом и мы. Оставшаяся часть текста содержит разговор автора со Скептиком. Кто это скептик? Представим себе, что он или она имеет за плечами уже немало лет работы кодировщиком, тестером, архитектором и менаджером программных систем. Он или она знает проблемы отрасли изнутри. Он или она уже пережил(а) первоначальный энтузиазм и последуещее разочарование Экстремальным Программированием, Cleanroom Software Engineering, Scrum и их некоторыми вариациями. И этот опыт обьясняет его или её скептицизм.
Скептик (далее С): Спору нет, тезис о материализации идей звучит круто. Только вот вопрос: зачем это нужно? Нам что, не хватает красивых и громких заявлений про Scrum, TDD и т.д.?
Автор (далее А): Отрасль создания software за свою недолгую историю пережила много больших и малых смен парадим. Они касались Методологии разработки (XP, Scrum, FDD, TDD и т.д.), Модели организации процесса разработки (каскадная, итеративная, спиральная и т.д.), улучшения отдельных фаз процесса (Domain Driven Design, Unit Test, Непрерывная Интеграция) и т.д. Часто это были прорывы, реально улучшившие тот или иной аспект этого сложного процесса. Но мне кажется, все они фокусируются на отдельных частях. И тем самым суть и смысл процесса разработки software ускользает от внимания.
С: Ну хорошо. Тезис охватывает весь процесс. Но что он дает конкретно на каждом шаге процесса?
А: Ну например, может выясниться, что вы думаете, что завершили определённую фазу, а на самом деле не сделали что-то из необходимого или делается что-то лишнее, ненужное.
С: А вот с этого места пожалуйста поподробнее. И как же мы это выясним?
А: Во первых, Вы наверняка переживали сами ситуацию, когда Вам казалось, что система готова. Еще день или два и можно сдавать заказчику. Но открываются новые и новые недоделки. Потом Заказчик начинает активно работать с системой и открываются новые бреши. А когда Вы сдали систему в production Вы вспоминаете, что в процессе разработки совсем ничего не думали о защите системы.
С: да. Так бывает практически всегда. Но это недоработка коллег, занимающихся требованиями. Они просто не вытянули необходимую информацию из заказчика или забыли её записать в нужный документ.
А: Нет, все не так просто. Они вам расскажут о многочисленных совещаниях с заказчиками, применении современных методик опроса и т.д. и т.п. Они спрашивали, они регистрировали. А в конце заказчик захотел, чтобы была ещё одна фича как в конкурирующей системе Х. И часто он прав.
С: Как это?
А: Отрасли пора привыкнуть к мысли, что времена открытия новых просторов и построения новых систем на пустом месте прошли. Для любой важной проблемы уже давно существуют многочисленные альтернативные решения. И Ваше решение должно быть в каком-то смысле не хуже. Иначе заказчик вас не поймет. И Заказчик или Пользователь ожидают от Вашей системы общепринятый уровень комфорта, надежности, защищенности. Заказчик не должен их специально заказывать, как это ожидается в рамках популярного сейчас агильного подхода. Когда программист покупает автомобиль, он даже не думает о том, открывается ли у автомобиля багажник. В своей же работе он ожидает, что Заказчик специально сформулирует ему подобного уровня требования.
С: Получается, агильный подход плох?
А: Он был и остается полезен. Но это временное и вынужденное решение. С профессионализацией отрасли он отойдет на второй план.
С: И на его место придет материализация идей?
А: Наверное будут появляться новые улучшения в том или ином аспекте, которые принесут новые buzzeords.
Материализация идей как таковая в софтверной отрасли была на самом деле с первого дня. Просто чем дальше, тем отчетливее будет кристализоваться понимание этого факта, как мне кажется. Софтверная отрасль по методам работы будет все больше походить на машиностроение или строительство.
С: Но ведь в софтверная отрасль отличается от них по двум фундаментальными факторам:
- в ней нет копирования одного изделия много раз (как например в автомобилемтроении)
- в ней нет износа и необходимости замены деталей (профилактики)
А: Крупносерийное производство сложных изделий становится все большей редкостью. Покупатель сегодня может сам сконфигурировать автомобиль и тем самым выбрать один из миллионов возможных вариантов. Немецкий производитель Audi поэтому решил отказаться от традиционного конвейера. Самолеты и корабли выпускаются под заказчика, очень мелкими сериями. И замена блоков на тех же самолетах часто производится не только из-за износа, но и в рамках модернизации. Это когда работающий (не износившийся) блок заменяют на более эффективный.
Но дело не в производстве в этих отраслях. Нас интересует процесс проектирования этих изделий. Там проколы, когда фаза проекта завершена, а что-то не сделано, а разработчики “не видят” этого, бывают намного реже.
Что же касается профилактикии профилактики и модернизации …
С: Но программы не изнашиваются. Какая тут может быть профилактика?
А: Аналог профилактики можно найти и при эксплатации программных систем. Банки данных и кэши надо иногда чистиь от мусора, разгребать застрявшие в пробках процессы, переносить систему на новое железо.
А поддержка и модернизация требует в жижненном цикле современных систем, по моей оценке, примерно столько же денег и времени, сколько первоначальная разработка. И в этой части ситуация в нашей отрасли по сравнению с традиционными отраслями удручающая.
С: Мне кажется, вы сгущаете краски. ИТ и её софтверная подотрасль развиваются немыслемыми для других отраслей темпами. Что Вы имеете в виду под “удручающей ситуацией”?
А: Я поясню это на примере из своей недавней практики. Однажды я получил очень маленький проект. Надо было срочно изменить один из процессов в некой системе. Изменения ожидались небольшие, но простирались они начиная от интерфейса с внешней системой через банк данных, несколько веб-сервисов и должны были в конце концов отображены на веб-формулярах пользователей и службы поддержки.
С: Ситуация обычная. А исходные коды были?
А: Были сохраненные в системе версионирования исходники на четырех языках программирования, схемы банка данных и Maven – сборщик. И в команде были специалисты с суммарным знанием необходимым для понимания кода на всех языках. Проблема состояла в том, что мы не очень понимали, с чего начать, а сроки как всегда были даны минимальные.
С: Это действительно проблема. Я бы начал с грубого анализа кода. По именам в namespace попытался бы понять какие модули нам интересны, а потом попытылся поймать релевантные места в дебагере или на худой коней навставлять в код печатей и пересобрать систему, погонять данные по процессу. И так, повторяя этот процесс, шаг за шагом стал бы приближаться к цели.
А: Тут мы едины. Размышляя о плане реализации примерно такого подхода я шел утром на работу. Недалеко от здания фирмы я увидел, как за несколько десятков метров передо мной остановился автомобиль городской водопроводной службы. Из него вышли два человека в комбинзонах и оглядевшись кругом, уверрено двинулись к водопроводному люку. Пока а подошел, они открыли крышку люка и один спустился вниз.
“Какой номер? Спросил оставшийся наверху. Спустившийся вниз ответил ему. Спрашивавший развернул в руках какой-то план и удолетворенно сказал: “То что надо. Здесь и надо …”.
Я не расслышал, что они собрались делать в этом месте, поскольку уже удалился от них. Но меня охватил прямо-таки стыд за нашу отрасль в этот момент. Я подумал: Если бы городское водоснабжение работало теми же методами как мы, то для поиска модернизируемого агрегата они должны были бы начать у точки водозабора и выкапывать трубы до тех пор, пока не встретиться искомый агрегат. Но они подумали об этом заранее и составили чертежи. С этими чертежами умеют работать их специалисты, в том числе не самой высокой квалификации.
А мы каждый раз начинаем заново ворошить оставшийся от разработчиков программный код.
С: Не скрою, аналогия убедительная. Получается, чертежи или их аналог -ключевой элемент в тезисе о материализации идей?
А: Во-первых: не чертежи, а правильные модели. А во вторых: не центральное, но очень важное.
Чертеж в руках техника водопроводной службы -это материализованные специальным образом идеи разработчиков труб, агрегатов и самого водопровода. Возможно, он содержит какую-то информацию и от строителей.
Наша отрасль требует тоже нечто подобное. Идеи в начале проекта и программный код в конце – этого недостаточно. Нужны промежуточные модели. Вопрос – какие.
Именно это я попытаюсь осветить в последующих постах в этой категории моего блога.
С: Ну что-же, спасибо за интересную дискуссию. Буду ждать новых постов.