Основной тезис этой статьи: Разработку программного обеспечения следует рассматривать как материализацию идей посредством трансформации ментальных моделей в программный код.
В статье описывается парадигма материализации идей в программной инженерии (engl.: RPSE: Reification as Paradigm of Software Engineering).
Английский вариант статьи: RPSE: Reification as Paradigm of Software Engineering. Сокращение RPSE используется далее в тексте для обозначения описываемой парадигмы.
Основные определения
Перед тем как перейти к обсуждению основных тезисов этой статьи, необходимо договориться о значении базовых терминов, используемых в ней.
Программная инженерия
Под программной инженерией мы будем понимать классическое определение дисциплины Software Engineering из словаря IEEE [1]: Программная инженерия — это «The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software».
Парадигма
Используемый в этой статье термин парадигма, опирается на ставшее классическим определение парадигмы Томаса Куна [2]: Парадигма — это круг проблем, набор понятий, общепризнанных правил и законов, приёмов решения задач в некоторой области науки.
Под парадигмами я подразумеваю признанные всеми научные достижения, которые в течение определенного времени дают научному сообществу модель постановки проблем и их решений…
Вводя этот термин, я имел в виду, что некоторые общепринятые примеры фактической практики научных исследований — примеры, которые включают закон, теорию, их практическое применение и необходимое оборудование, — все в совокупности дают нам модели, из которых возникают конкретные традиции научного исследования.
Дуализм этого понятия заключается в том, что парадигма с одной стороны характеризуется через сообщество признающих её специалистов. Именно специалисты определённой области определяют, создают и развивают её части. С другой стороны, признание определённой парадигмы означает для специалиста присоединение к такому сообществу.
Томас Кун рассматривал в своей книге научные парадигмы. Однако очень скоро после выхода первого издания книги проявилась полезность использования этого понятия в технике и различных областях социальной жизни. В связи с этим в специальной и популярной литературе стали появляться многочисленные публикации о парадигмах и их смене в автомобилестроении, градостроительстве, лечении определённых болезней и т.д.
Программная инженерия и особенно её важная составная часть — программирование, не стали исключением. На данный момент существует много конкурирующих парадигм программирования. Их перечислению посвящена отдельная статья в Википедии[3], а также такие интересные обзоры как [4].
Описанная в этой статье парадигма, напротив, применима к самым разным предметным областям и фазам создания программного обеспечения.
Предлагаемая в данной статье парадигма тоже пока не обладает собственной развитой теоретической базой, однако уже сегодня видны пути её развития.
Материализация идей
Используемый в этой статье термин материализация идей (engl: reification) является расширением классического определения reification в информатике: “Reification is the process by which an abstract idea about a computer program is turned into an explicit data model or other object created in a programming language” [6].
Уже в самых ранних из дошедших до нас философских трактах было принято противопоставлять Идеальноe (мир идей) Материальному (миру вещей).
Идеальное мы можем в лучшем случае ощущать (или думать, что мы это ощущаем). Индикатором такого ощущения Идеального может быть изменение настроения или хода мыслей после прослушанного музыкального произведения, прочитанного фрагмента книги и т.д. Разумеется, я имею в виду опосредованное воздействие, например музыки, на наше сознание, а не примитивное физиологическое подчинение организма грохоту рок-концерта или ритму дискотеки.
Попытки сформулировать наше ощущение Идеального как правило не приводят к успеху.
Об этом замечательно сказал великий русский поэт Федор Иванович Тютчев:
Как сердцу высказать себя?Даже практические идеи типа мелкого ремонта по дому или приготовления новой вариации знакомого блюда вначале трудно сформулировать. И только после обдумывания либо попытки объяснить другому, идея приобретает всё более чёткие «очертания».
Другому как понять тебя?
Поймёт ли он чем ты живёшь?
Мысль изречённая есть ложь...[7]
Перейдём теперь от рассмотрения понятия Идеального к рассмотрению Материального. Мы можем ощущать и регистрировать материальные объекты вокруг нас, различать качественно их свойства. Свойства многих объектов можно объективно измерять. Мы можем также объективно выделять иерархии и иные структуры материальных объектов.
Чтобы оценивать или измерять (получать количественные характеристики) не обязательно иметь предмет. Достаточно иметь его модель. Более того, во многих практически интересных ситуациях модель можно использовать и без предмета. Модели можно обсуждать с другими. О моделях можно договариваться. Модели можно стандартизировать (формализовать).
В некоторых областях человеческой деятельности стандартизация моделей зашла так далеко, что изготовленные на основе стандартизованной модели (например — чертежа) разными людьми или автоматами детали (например болты с резьбой) с технологической точки зрения и визуально будут неотличимы друг от друга.
Отдавая себе отчёт об относительной неточности предлагаемого определения, далее в этой статье я буду разделять мир феноменов нашего внутреннего и внешнего мира U на две части:
U = M + I
где множество М состоит их феноменов, которые можно объективно регистрировать или измерять (материальный мир) и I — всё остальное.
Применима ли эта формула к абсолютно всем феноменам окружающего мира — это открытый философский вопрос. Далее в этой статье мы сузим область применения этой формулы на мир феноменов из мира программной инженерии.
Или, сформулировав в виде тезиса: Всё множество относящихся к программной инженерии феноменов можно разделить на подмножество идеальных и подмножество материальных. При этом материальный феномены регистрируемы либо измеряемы на основе их моделей.
Процесс создания или изменения программной системы заканчивается в большинстве случаев созданием того или иного кода, который с помощью компьютера отображается в физический процесс (феномен реального мира).
Начинается же этот процесс возникновением неких идей о будущей системе в головах заказчиков или разработчиков. Эти идеи и представления мы будем именовать ментальной моделью.
Материализация идей в соседних с Программной Инженерией областях
Понятно, что приведённое выше определение не является радикально новым и широко применяется (осознанно или неосознанно) в соседних программированию областях интеллектуального труда. Рассмотрим для примера две таких области — машиностроение и математику.
Эти две области используют материализацию идей давно и эффективно. Программированию у них есть в этом отношении чему поучиться.
В машиностроении мы видим полный цикл материализации идей — от возникновения идеи в голове конструктора через её продумывание, детализацию, отображение в модель и наконец — изготовление из определённого материала.
По-другому обстоит дело в математике
«Конечным продуктом» математики являются формальные модели со строго доказанными свойствами.
С этой точки зрения программирование лежит посредине. Графически это можно изобразить следующим образом:
Таким образом, математика использует большее количество более абстрактных моделей и практически совсем не касается области предельно конкретных моделей типа машиностроительных чертежей.
Машиностроение же наоборот, использует относительно мало абстрактных моделей, но много конкретных. Например таких, по которым однозначно могут быть изготовлены физические объекты.
С этой точки зрения программирование лежит посередине.
Мультимодельность мира
За несколько тысяч лет своего развития математика научилась описывать одни и те же феномены реального или воображаемого мира в очень разных терминах. Древние греки научились чисто словесные описания задач подменять геометрическими фигурами и с их помощью решать практически важные задачи. Позже появилось понимание о взаимозаменяемости отрезков на плоскости и чисел. Затем кристаллизовалось понятие алгебраической переменной и сведения геометрических задач к системам алгебраических уравнений.
Сегодня уже школьники старших классов знают, что одну и ту же задачу можно решить разными способами (например — геометрически или алгебраически) и что одна и та же математическая модель, например — алгебраическое уравнение, описывает много самых разных физических, химических и т.д. явлений.
Морфизм моделей и согласованность понятий и нотаций
Математика хорошо научилась не только описывать одни и те же реальные или воображаемые объекты и процессы с помощью моделей самой разной математической природы. Важным достижении математики является умение определять степень подобия моделей из разных разделов математики а также умение трансформировать их друг в друга. Многие прорывные решения важнейших математических проблем последних лет являются по сути цепочками отдельных доказательств, каждое из которых использует специализированных аппарат из специального раздела математики. В местах соединения этих узкоспециализированных доказательств математики умело трансформирует модели одного раздела математики в модели другого раздела. В программировании нечто подобное происходит уже сейчас при компилировании исходного кода программы и при генерации кода из DSL (Domain Specific Language) или метаданных. Но культура работы с моделями в области программного инжиниринга далеко отстаёт от математической.
Модели в машиностроении
А чему программная инженерия может поучиться в плане материализации у машиностроения?
Во многих отраслях и даже внутри крупных концернов существуют цепочки согласованных формальных и семи-формальных моделей. Эти цепочки заканчиваются моделями, на основании которых изготавливаются и монтируются физические объекты — приборы и машины. Как правило, на большинство типов промежуточных моделей существуют формальные методы проверки их корректности (технические нормы). Модели являются основным языком коммуникации специалистов разного профиля в процессе проектирования и изготовления машиностроительных изделий.
На этом фоне ситуации в ИТ выглядит намного хуже. Только внутри очень крупных ИТ концернов в последние годы делались попытки построения сопоставимых наборов моделей и процессов. Мелкие фирмы и ИТ-стартапы, как правило, не только не имеют развитых формальных моделей и процессов, но даже не подозревают об их существовании. Такое положение определяется в настоящий момент следующими факторами:
- Недостаточной эффективностью существующих моделей и процессов
- Недостаточной известностью этих моделей за пределами больших концернов
- Недостатками образования разработчиков и особенно менеджеров
- Отставанием университетского образования от реальных потребностей программной инженерии.
Определение и контуры парадигмы материализации идей (RPSE)
Мы определили все необходимые понятия, чтобы дать основное определение предлагаемой парадигмы. Вот оно:
Разработка программного обеспечения — это материализация идей посредством трансформации ментальных моделей в код, выполняемый на компьютерах.
В рамках предлагаемой парадигмы:
- Все основные процессы разработки программного обеспечения являются конкретными вариантами (реализациями) процесса построения цепочек ментальных и материальных моделей. Последней наиболее конкретной моделью в этой цепочке является, как правило, программный код.
- Суть разработки программного обеспечения заключается в создании таких цепочек.
- Все основные вопросы оптимизации разработки, снижения её стоимости и повышения её качества могут быть сведены к оптимизации построения соответствующей цепочки моделей.
Приведённое выше определение имеет свои особенности и вариации в разных областях программной инженерии. Только в очень небольшом количестве случаев бывает так, что в голове программиста сначала полностью вызревает ясное представление о способе решения стоящей перед ним задачи, которое он после этого за небольшое время отображает в код на языке программирования. В большинстве реальных проектов процессы поиска решения и его реализация сосуществуют, развиваются параллельно и взаимодействуют друг с другом. Т.е. ментальные модели, код и зачастую промежуточные модели (в виде теста, изображений, формальных моделей типа UML) растут и изменяются параллельно, оказывая влияние друг на друга.
Нередко код на некотором языке программирования фактически отсутствует, поскольку создание нового решения сводится к управлению масками конфигураторов или генераторов, как например при работе с инструментами разработки в системах типа SAP или WebSphere.
Варианты превращения вручную написанного или автоматически сгенерированного кода в исполняемый код в наше время стали также очень многообразны.
И наконец, само понятие процессора, на котором исполняется код, также значительно расширилось в последние годы. Если раньше это были процессоры, которые находились на платах, которые в свою очередь были вставлены в корпуса десктопов, ноутбуков и серверных стоек, то теперь это множество расширилось различными чипами самого разного размера, которые встроены в мобильные телефоны, игровые приставки, видеокамеры наблюдения, «умные» домашние приборы и т.д. Не говоря уже о квантовых компьютерах.
И тем не менее, RPSE, в силу её общности, применимо ко всем перечисленным выше областям.
Что ещё можно сказать об определённой парадигме сегодня, можно ли как то очертить её контуры поточнее?
Следующим шагом к уточнению парадигмы после попытки дать её основное определение является попытка перечислить основные категории феноменов, которые она затрагивает. Вспоминая определение Куна, нам надо попытаться перечислить типы моделей, которые вводит и использует RPSE.
Модели RPSE можно разделить на три основные категории:
- Ментальные модели
- Код на языках программирования или его эквиваленты как модели исполняемого кода.
- Промежуточные модели.
Наименее исследованными в этой триаде являются ментальные модели. Что конкретно понимается под ними?
Ментальные модели — это термин для обозначения идей, которые существует в голове заказчиков, программистов и других участников процесса и на основании которых возникает в конце концов исполняемый код. Наличие таких моделей бесспорно и может быть на психическом уровне зарегистрировано, например — самим программистом. На современном уровне развития техники эти модели не могут быть достоверно измерены приборами.
Одним из хорошо работающих способов фиксации и измерения таких моделей является интевьюирование носителя идеи. Очевидно, что процесс интервьюирования или схожие с ним резко влияют на саму ментальную модель. Каждый из нас наверняка не раз переживал ситуацию, когда одна только попытка сформулировать проблему с целью посоветоваться с коллегой приводила к «озарению», а часто и к решению проблемы.
Интервьюирование позволяет на основании правильно сформулированных вопросов относительно объективно построить модели различной сложности. Наиболее употребительными являются:
Структурные модели:
- Списки с бинарными, перечислительными (enumeration), числовыми, строковыми и иными значениями.
- Графовые и сетевые структуры данных
Модели описания поведения:
- Семи-формальные модели определения поведения
- Формальные модели определения поведения (например — конечные автоматы)
Зачем программной инженерии нужна «сквозная» парадигма?
Наличие «сквозной» парадигмы открывает перед участниками использующего эту парадигму процесса создания, модификации и использования программного обеспечения следующие возможности:
- Возможность всем участникам процесса использовать одинаковую терминологию.
- Возможность строить сквозной процесс создания нового ПО.
- Возможность оценивать его параметры процесса, его промежуточные результаты и управлять им.
Основные задачи по развитию парадигмы
Теоретические задачи
Как уже неоднократно отмечалось, в том числе и в книге Куна[2], в большинстве случаев учёные занимаются решением потенциально решаемых задач, и реже берутся за такие, к которым не очень понятно как подойти. Но именно таковы наши задачи. Вот основные из них:
- Конструктивное определение понятия ментальной модели.
- Нахождение конструктивных критериев оценки степени абстрактности/идеальности vs. конкретности/материальности моделей.
- Нахождение критериев для отбора кандидатов на роль промежуточных и дополнительных моделей.
- Отбор и разработка критериев и методов сравнения моделей различных типов, включая их прямую и обратную трассировку.
- Разработка методов автоматизированной и автоматической трансформации моделей.
Практические задачи
Наряду с теоретическими задачами для развития и внедрения описываемой парадигмы в практику программной инженерии необходимо решить как минимум следующие практические задачи:
- Создание инструментов для: а) Экстрагирования и фиксации ментальных моделей. б) Автоматизированной и автоматической трансформации ментальных моделей в промежуточные. в) Трассировки и оценки изменения содержания трансформируемых моделей
- Создание необходимой технической и обучающей литературы и иного медиального обучающего материала.
- Организация форумов и конференций на эту тему
Заключение
В этой статье сделана попытка определить парадигму программной инженерии как материализации идей. Слово определить (а не открыть) употреблено здесь не случайно. Фактически участники ИТ-проектов давно занимаются созданием, трансформацией и использованием моделей, может не отдавая себе в том отчета.
В строгом смысле определения Куна описанный подход пока не может претендовать на право именоваться парадигмой, а только кандидатом в парадигмы, поскольку не обладает обширным сообществом поддерживающих его людей а также развитой системой взаимосвязанных моделей. Однако, хочется верить, что недостатки будут уже в скором времени преодолены.
Это первая статья из запланированной серии статей. В следующих статьях я собираюсь рассказать о ментальных и промежуточных моделях.
Литература
1. IEEE Standard Glossary of Software Engineering Terminology, IEEE std 610.12-1990, 1990.
2. Kuhn, Thomas S. The Structure of Scientific Revolutions. 3rd ed. Chicago, IL: University of Chicago Press, 1996.
3. Programming paradigm: en.wikipedia.org/wiki/Programming_paradigm (state — 27.08.2018)
4. Peter A. Henning, Holger Vogelsang Taschenbuch Programmiersprachen. Carl Hanser Verlag GmbH & Co. KG; Auflage: 2., neu bearbeitete (5. September 2007). ISBN-13: 978-3446407442.
5. Software Engineering Paradigms And Models Information Technology Essay
www.uniassignment.com/essay-samples/information-technology/software-engineering-paradigms-and-models-information-technology-essay.php (state — 27.08.2018)
6. Reification (computer science) en.wikipedia.org/wiki/Reification_(computer_science) (state — 27.08.2018)
7. Федор Иванович Тютчев. Silentium! (Молчание (лат.), 1829 г.
8. Borovik, Alexandre. Mathematics under the microscope: notes on cognitive aspects of mathematical practice. American Mathematical Society. ISBN-13: 978-0821847619.
Иллюстрация: geralt
Комментарии (28)
visirok Автор
08.10.2018 14:39Хотите верьте, хотите — нет. Но это продумано и написано исключительно в свободное от работы время. Да и с Софизмом в смысле определения Википедии пересечений я не вижу.
maslyaev
08.10.2018 18:15+1Ну почему так всех прёт с моделирования? Мне кажется, намного продуктивнее пользоваться не моделирующей, а инструментальной парадигмой. Молоток не обязан моделировать процесс забивания гвоздя, кастрюля не обязана моделировать варку борща, так почему программа обязательно должна что-то там моделировать?
Есть, конечно, чрезвычайно узкий круг программ, которые реально что-то моделируют. Но среди терабайтов разнородных исходников их ещё поискать. Подавляющее большинство того, с чем реально приходится иметь дело (и со стороны разработчика, и со стороны пользователя) вообще ничего не моделирует. Ну не моделирует Ворд листок бумаги с карандашом. Электронная почта не моделирует доставку корреспонденции почтальоном. Бухгалтерская программка не моделирует гроссбух. Метафора чистого листа бумаги или гроссбуха может использоваться (пользователям так понятнее), но никаких моделей там нет и в помине.
Установка «программа должна моделировать реальный мир» — чрезвычайно деструктивный психовирус. Двигаясь по этой парадигме, мы гонимся за миражом программы, которая будет отражать реальный мир. Но реальный мир обладает недискретной сложностью, а у нас в руках дискретные инструменты. У множеств R и Q разная мощность, и тужиться свести первое ко второму — только зря гневить дух старика Кантора.
Впрочем, претензия совсем не к Вам. У почти всех мозги пожраны психовирусом моделирования.Ermit
09.10.2018 14:21Всех прёт с моделирование потому, что мышление — это, по сути, моделирование. То есть моделирование — это «забивание гвоздей» мозгом. :-)
visirok Автор
09.10.2018 16:10Рискую показаться занудой, но со знаком равенства между моделированием и мышлением я не согласен.
Ermit
09.10.2018 17:58А какой-нибудь аргумент можно попросить, что-то нибудь такое, что было бы в мышлении и интеллекте, но не было бы в моделировании. В механизмах, в элементах.
Пожалуйста.visirok Автор
09.10.2018 18:40Достаточно сравнить определения обоих понятий в Википедии. У понятий есть пересечение, но они далеко не тождественны.
Компьютерное моделирование не является частью мышления.
Отнюдь не всякая идея есть модель (в строгом определении этого понятия).Ermit
09.10.2018 18:47-1Определения? В Википедии? У, как строго и аргументированно.
Тогда — конечно.visirok Автор
09.10.2018 19:00Не все статьи в Википедии одинакового качества. Но с этими двумя я во многом согласен и считаю, что их вполне можно взять за основу.
Вы можете предложить свои определения. Но будет трудно по этим вопросам оспорить или превзойти Википедию.
Хотя я назвал два конкретных примера различия элементов. Чем они плохи?Ermit
09.10.2018 19:02Они ничем не плохи, просто я задавал Вам один вопрос, а Вы отвечали на другой. Плюс к этому, приписали мне то, что никогда не утверждал.
А статьи ничем не плохи, наверное.visirok Автор
09.10.2018 19:10Вы говорите, что две категории на самом деле тождественны. Я называю два элемента, каждый из которых принадлежит к одной категории и не принадлежит к другой. Либо мои примеры плохи и доказательство неверно, либо это всё же две разных категории. Разве это не опровергает Ваше утверждение о том, что мышление это моделирование? Или вы считаете что мышление это часть моделирования?
Ermit
09.10.2018 19:23-1Я вообще ничего не говорил про категории, это раз. Я говорил, что суть феноменального ПРОЦЕССА мышления является моделирование. Вы не говорили ни про какие элементы, Вы НЕПРАВИЛЬНО приписали мне какое-то компьютерное моделирование и стали говорить о каких-то идеях. И еще про СТРОГОЕ (??!?!) определение. Даю справку: определение может быть строгим только в рамках какого-нибудь исчисления.
Давайте, забудем и разойдемся, Ваш уровень в этом вопросе я осознал, не думаю, что какие-то Ваши мысли об этом мне могли быть интересными.visirok Автор
09.10.2018 19:58Категории — это про упомянутое Вами Мышление и Моделирование. Это я их для удобства так охарактеризовал.
Компьютерное моделирование — состовная часть понятия Моделирования согласно определению Википедии и не только.
Философы тоже претендуют на строгость определений, вне рамок каких-либо исчислений.
Идеи — продукт мышления, опять таки согласно определению Мышления в Википедии.
Ваше сведение процесса мышления к моделированию я принять не могу. Ваши мысли, доказывающие этот тезис были бы мне и читателям Хабра наверняка интересны. Но если Вы настаиваете, разойдёмся.
Спасибо, что Вы нашли время прочитать статью.
maslyaev
09.10.2018 20:28+1В мышлении есть ещё до чёртиков всего кроме моделирования. Например, такая чрезвычайно интересная тема, как целеполагание. Во фразе «люблю пельмени» эти самые пельмени, если поднатужиться, можно за уши притянуть к моделированию (видимо, их же, пельменей), но «люблю» никаким боком в концепцию моделирования не упихивается.
Когда дело доходит до дела, подход «мышление = моделирование» и «информация = модель» в подавляющем большинстве случаев будет как чемодан без ручки. Например:
— Вот этот мой коммент — что он что моделирует?
— Конкретный HTTP-заголовок конкретной HTTP-посылки
— Просьба передать за проезд
— Страшно сказать: Конституция РФ
Чего это за модели и что они моделируют?
Упёртость в модели, мне кажется, является одним из печальных следствий чрезвычайно тупой и бестолковой философской традиции считать, что наше сознание только тем и занимается, что отражает реальный мир. Пусть господа философы сходят в нейрохирургию и спросят врачей, находили ли они в мозгах пациентов зеркала. Может быть и находили. Несчастные случаи разные бывают.
Даже умница Кант в своё время застрял в рассмотрении познающего субъекта :(
Правильный вопрос в том, что же такое оплодотворяет смыслом все эти познания, отражения и моделирования? Ну не может ведь быть так, чтобы деятельность была, а смысла и цели в ней не было, разве нет? Может быть, пора уже устать выносить смысл за скобки?visirok Автор
09.10.2018 21:18Ну не может ведь быть так, чтобы деятельность была, а смысла и цели в ней не было, разве нет?
Если верить Томасу Куну, Дарвина критиковали в основном за то, что он предположил, что эволюция происходит естественным путём а не по плану, начертонному Создателем.
visirok Автор
08.10.2018 18:46Или я плохо объяснил, или Вы невнимательно читали.
Я не ратую писать программы, что-то моделирующие.
Я предлагаю подумать о модели (моделях) будующей программы (системы) перед тем, как начинать её программировать. Нужны ли модели, если да — какие — это отдельный вопрос.
Предлагается понимать процесс программирование как построение таких цепочек.
В простейшем случае в цепочке только два звена: ментальная модель и код программы.
HenT
09.10.2018 11:40+1На мой субъективный взгляд, проблема современной разработки ПО заключается не в сложности/сроках перевода Идеи в Готовый Продукт, а в том, что не смотря на развитие технологий семимильными шагами, введения невероятного числа (и уровня) асбтракций, у нас до сих пор Инструмент формирует Сознание. Мы думаем о том, ЧЕМ Идея будет реализована в Продукт. В этой «могиле» лежат триллиарды долларов и тысячелетия затраченного времени, но до сих пор всё зависит на 99% от коньюнктурно меняющегося инструментария.
В начале нулевых некий сферический бухгалтер в вакуумной конторе средней руки боялся «ойтишника» как огня: «Сейчас они придут, поставят 1С и меня уволят!1111». Он делал свою «ценную рбаоту», разбирался в «сложных вопросах» и был «незаменим». Сейчас «ойтишники» стали теми самыми бухгалтерами, только 1С еще не появился… пока не появился.
visirok Автор
09.10.2018 11:55Я согласен с Вашим тезисом о том, что Инструмент формирует Сознание. Иногда он его даже деформирует.
Очевидны преимущества эксковатора перед лопатой при прокладывнии каналов и автомагистралей. И преимущества IDE по сравнению с простым текстовым редактором в большом проекте тоже очевидны. А вот с инструментами управления проектами что-то не так.
Я не раз замечал, что они ориентируют их пользователей на мелочи, усугубляют их т.н. клиповое мышление. Как в музыкальных клипах — отдельные фрагменты вроде хорошо сделаны, а общего смысла нет.
Я не хочу сказать, что Jira, Polarion и их собратья совсем плохи или вредны. Но в них не хватает важных возможностей, либо мне не повезло эти возможности наблюдать в деле.
Важнейшие вопросы — сколько процентов уже сделано? Когда закончим? Они решаются за пределами этих инструментов.
Или я не прав?HenT
09.10.2018 12:51в данном случае проблема шире. Сколько всего сделано за последние годы для «улучшения жизни», языки, фреймворки, утилиты, виртуализаторы и оркестраторы, а в сторону фронта вообще нельзя смотреть без боли там же ад кромешный!
У Вадима Шефнера есть замечательный рассказ «Скромный гений», один из его персонажей предлагает построить «Завод по открыванию консервных банок.» Мне кажется сегодня потребители IT продукции просто не понимают за какие чудовищные заводы им приходиться платить бешенные деньги, ради того, чтобы открыть консервную банку.visirok Автор
09.10.2018 13:07Признаться я не понял ни первой ни второй части.
Вы можете коротко сформулировать суть проблемы? Как Вы её видите?
В буквальном смысле потребители ИТ продукции платят не так уж много и получают взамен не очень тривиальные продукты и сервисы. Не раскроете свою мысль про открывание банок поподробнее?
HenT
09.10.2018 13:41Жил был Кролик, покупал морковку в магазине на 100р в год. Подумал: «Зачем так много платить? Нужно экономить! посажу Морковку у себя в огороде.» Взял лопату, копнул пару раз, устал, труд монотонный, поливать надо, сажать убирать… и решил, а давайте лучше сделаю ферму на гидропонике! Сел за расчеты модные, купил банки чтобы сажать и бланки, чтобы подписывать банки, разработал систему полива, автоматику там внедрил, рассчитал экономический эффект. Капитальные вложения в 1000р разделил на экономию и обрадовался, что уже через 5 лет его система окупиться!
…
Прошли два года, система поизносилась и морально устарела. Об окупаемости Кролик уже не думал, он вложил еще 1000р и модернизировал систему микроклимата и строгого контроля подачи питательных веществ.
…
Теперь он мог сидеть в кресле, и с наслаждением поддерживать свою мини-ферму в работоспособном состоянии до старости. Конечно не забывая обновляться каждые 2-3 года.
Идея была простой — не покупать Морковку, а выращивать самому. Но Кролик был стильным модным хипстером и просто не мог себе позволить копать землю лопатой, ведь можетбытькогданибудь он станет морковным магнатом, и его маленькая ферма вырастет в международную корпорацию.
Надеюсь аналогию можно легко перенести на современную разработку, и это касается не только некоего сферического стартапа, но и более фундаментальных компонент.
В данном примере проблема видна и очевидна. В нашей же области, «Лопата» просто отсутствует(!) и не потому, что ее нельзя сделать, а потому что все покупают фермы на гидропонике!
visirok Автор
09.10.2018 14:17В нашей же области, «Лопата» просто отсутствует(!) и не потому, что ее нельзя сделать, а потому что все покупают фермы на гидропонике!
Надеюсь я правильно понял Вашу мысль: Можно было бы делать дешёвые продукты, но все хотят покупать дорогие. Но это не так. Почти в любой области ПО есть дешёвые либо бесплатные альтернативы. И у них есть свой рынок.
Хотя соглашусь с Вами в том, что нередко покупается SAP там, где хватило бы Excel.HenT
09.10.2018 14:51Кролики и Лопаты здесь для того, чтобы вызвать у каждого человека свои ассоциации. Инструментами могут быть не только SAP, но и Docker, Google Chrome или XML формат.
Иногда лопата есть! Например, XML формату легко выбрать куда менее тяжеловесную альтернативу. Но я говорю о том, что люди зачастую начинают ДУМАТЬ в XML. И тем самым они даже помыслить не могут об альтернативе этому Инструменту, ведь они уже навесили на свое приложение задачи, которые хорошо решает именно XML, забывая о том нужно ли решать эти задачи для достижения Цели.
visirok Автор
09.10.2018 15:48Не уверен, что аналогии с допатами и кроликами так уж плодотворны.
Если оставаться в терминологии программной инженерии, ваш тезис сводится к тому, что у некоторых коллег наблюдается излишняя любовь к определённым инструментам, которые они пробуют применять где надо и не надо.
Иногда это объясняется незнанием альтернатив. Часто — особенностей и глубин использования любимого инструмента — например — используемого языка программирования.
У многих нет времени изучить альтернативы.
Я думаю, принятие на вооружение описанной в статье парадигмы материализации может помочь в выборе правильных инструментов.
Хотя на данный момент это больше гипотеза и надежда, чем доказанное утверждение.HenT
09.10.2018 16:17Далеко не всегда и не всему есть альтернатива.
Опять же, какая альтератива у JS?visirok Автор
09.10.2018 16:39Если Вам надо реализовывать много логики на JS, можно рассмотреть в качестве альтернатив:
- Чистый JS
- TypeScript
- CoffeeScript
- Генерацию из Kotlin
и т.д.
Ну а если Ваш JS переплетён с HTML — то тут тьма фраймворков, которую кажется Вы упоминали.HenT
10.10.2018 05:31-1Очень хороший пример.
Вместо Капельного Полива вы предлагаете сделать Аэропонику или Фитильную систему за счет поверхностного натяжения. но всё это Гидропоника, а где Лопата?
Всё Вами описанное — те же яйца, только в профиль.
В качестве правильного ответа можно было бы привести WebAssembly.
anonymous
Софистика чистой воды.
Как заняться чем угодно, только не работой.