На сайте ведутся работы ТРИЗ и программирование | Нематериальное стимулирование, компенсационные пакеты | Бизнес-форум TRIZ-RI
9737
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ
Все категории » Нематериальное стимулирование, компенсационные пакеты » Что мешает программистам IT-отделов…

ТРИЗ и программирование

Ваши данные (просмотреть)
в избранные темы
Политика конфиденциальности

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
Создать аналогичное обсуждение...

Авторы

Скрыть / Показать
2003-10-15 13:26:47
Лаптев Валерий Викторович » Всем
Очень интересует данная тема. Кто-нибудь может просветить: сайты, ссылки, литература. Можно и просто подискутировать.
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-10-15 15:22:05
Наталья Швец » Лаптев Валерий Викторович

Уважаемый Валерий Викторович,

Правильно ли я поняла, что Вы хотите решить задачу с помощью приемов ТРИЗ, которая возникла в процессе написания программы?

Или Вас интересует перечень задач по программированию, которые можно решить с помощью методов ТРИЗ?

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-10-15 15:36:35
Лаптев Валерий Викторович » Наталья Швец
Добрый день, спасибо за ответ.
Для начала - и то, и то. Я пока в этой сфере плохо себе представляю, какой вообще прием может быть для программирования применен.
Я уже пару-тройку лет со студентами пытаюсь автоматизировать обучение программированию. Несколько дипломов разного уровня написали по разным программистским предметам. Основой должен быть лабораторный практикум. Понятно, что в нем должна быть база заданий, как-то описанная, сценарии выполнения, тоже как-то описанные. Система следит за действиями студента и "бьет по рукам", если он не в ту сторону сворачивает, одновременно, показывая правильный путь. Естественно, база типичных ошибок тоже есть и тоже как-то описана. Есть даже семантическая сеть, показывающая взаимосвязь и взаимовлияние ошибок.
Есть в системе и тестирующая часть, которая позволяет устраивать "летучие контрольные".
Но таким образом мы учим совершенно типовым приемам. А хотелось бы добавить сюда и творческий элемент, с помощью которого для СИЛЬНЫХ студентов можно решать совершенно нетривиальные задачи. Или задачи по оптимизации ПО и БД.

Извините, что многословно. Понятно, что-нибудь?
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-10-17 13:52:38
Сергей Валерьевич Сычев » Лаптев Валерий Викторович

Уважаемый Валерий Викторович!

Скажите, пожалуйста, а есть ли у Вас первичная картотека задач.

И, если, да, то какой ее объем.

Большое спасибо!

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-10-17 17:57:26
Лаптев Валерий Викторович » Сергей Валерьевич Сычев
Создаем. Могу сказать, что активно используется xml.
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-10-18 12:45:46
Сергей Валерьевич Сычев » Лаптев Валерий Викторович

Добрый день!

Создаем. Могу сказать, что активно используется xml.

1. Если не секрет, конечно, каково количество задач в картотеке:

  • единицы;
  • десятки;
  • сотни;
  • тысячи;
  • ... более ....

2. Какой формуляр используется для сбора задач? Могли бы Вы здесь привести его + показать несколько примеров (3-4) задач, описанных по этому формуляру.

С Уважением,

Ответить Сообщение для всех [Нет ответов на это сообщение]
2003-10-20 00:21:04
Роман Анатольевич Булыгин » Лаптев Валерий Викторович

Очень интересно было бы ознакомиться с вашими наработками. Наткнулся на сайт, при поверхностном осмотре некоторые приёмы ТРИЗ можно применить и в программировании. На вскидку -- "сделать наоборот". Могу предположить, что можно выделить целую подгруппу приёмов для работы с информационными, а не с техническими объектами.

Ответить Сообщение для всех [Нет ответов на это сообщение]
2003-10-26 23:51:59
Кирилл Лебедев » Лаптев Валерий Викторович

Уважаемый Валерий Викторович!

В конце прошлого - начале этого года мною был написан ряд статей, посвященных исследованию, классификации и поиску типовых программных ошибок (ошибок программистов, допущенных при написании программ).

При написании статей была использована собранная на основе личного опыта и опыта коллег картотека ошибок.

С опубликованными материалами Вы можете ознакомиться по следующим ссылкам:

 
 
С уважением,
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-02 11:16:57
Комарчева Лариса Дмитриевна » Всем

Уважаемые коллеги!

На официальном сайте Oracle опубликована статья о ТРИЗ:

"Seeing the Forest for the TRIZ" by Marta Bright 

С уважением,

Исполнительный директор Официального Фонда Г.С. Альтшуллера Лариса Дмитриевна Комарчева

http://www.altshuller.ru

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-05 22:52:05
Кирилл Лебедев » Всем

Уважаемые коллеги!

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

Некоторые авторы сумели выделить целый ряд так называемых "шаблонов проектирования" и "шаблонов ошибок". Например:

  1. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. – СПб.: Питер, 2001
  2. Эрик Аллен. Типичные ошибки проектирования. - М., СПб: Питер, 2003. (Книжка полезная, но перевод ужасный.)

Но почему-то дальше набора шаблонов дело не пошло. Например, с момента выхода первого издания книжки 1 прошло уже больше 10 лет. Однако список шаблонов так и не пополнился. Да и проектирование с учетом шаблонов не получила особого распространения. Каждый программист решает сам, использовать этот метод или нет. 

Интересно, в чем заключается причина такого явления?

С уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-06 09:37:34
Сергей Григорьев » Кирилл Лебедев

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

Вы можете привести конкретный пример из своей практики, который можно назвать "изобретательской задачей"? Есть ли определение что такое "изобретательская" задача?

Да и проектирование с учетом шаблонов не получила особого распространения. Каждый программист решает сам, использовать этот метод или нет. Интересно, в чем заключается причина такого явления?

Рискну предположить, что полезность этих шаблонов неочевидна для начинающих. И, в ряде случаев, их использование противопоказано. Это не универсальное решение. А опытные люди на серьезных проектах их используют в полный рост.

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-11 00:27:24
Кирилл Лебедев » Сергей Григорьев

Уважаемый Сергей!

Вы можете привести конкретный пример из своей практики, который можно назвать "изобретательской задачей"?Есть ли определение что такое "изобретательская" задача?

Условно изобретательские задачи в программировании, как и в «железном» ТРИЗ, можно разделить на макси-задачи и мини-задачи. Макси-задача связана с проектированием новой системы (программы, библиотеки, функциональной части программы). Для ее решения требуется сформулировать и решить множество мини-задач.

Примеры макси-задач:

Разработать библиотеку контролей (элементов пользовательского интерфейса) или даже написать какой-нибудь один контроль (тулбар, строку состояния, список, тултип и т.д.).

Написать водителя-автомата (бота) для гоночной игры.

Разработать и реализовать физическую модель средства передвижения.

Разработать игровой движок.

Внести поддержку многопоточности в игровой движок.

Под мини-задачей, в принципе, можно понимать часть макси-задачи. Решение макси-задачи образуют решения целого «куста» мини-задач. Но не все из этих мини-задач можно считать творческими, изобретательскими.

Примеры неизобретательских мини-задач:

Написать функцию, возвращающую значение переменной.

Написать функцию перебора элементов массива.

Написать комментарий.

Под неизобретательскими мини-задачами будем понимать то, что надо просто сделать, и хорошо известно, как это можно сделать. В таких мини-задачах не содержится никакого противоречия.

Примеры изобретательских мини-задач:

Пример 1.

В редакторе геометрических фигур (в основном – ломаных линий и многоугольников) существуют несколько режимов редактирования. Два из них отвечают за изменение формы редактируемых фигур. Первый режим – режим перемещения точек – позволяет с помощью мыши передвинуть любую вершину фигуры в заданную точку. Второй режим позволяет добавить к контуру новую вершину (щелчком мыши ребро разбивается на две части). Пользователям (дизайнерам) очень неудобно работать с таким редактором. Им приходится постоянно переключаться из одного режима в другой. Для переключения нужно нажать мышью кнопку на тулбаре. Как быть?

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

Для решения можно использовать принципы разрешения противоречия в пространстве и в структуре. Если курсор мыши попадает в вершину (или в небольшую область рядом с ней), то автоматически включается режим редактирования (перемещения) точек. Если же курсор мыши при щелчке попадает в отрезок, то включается режим разбиения отрезка на части.

Пример 2.

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

Переключение из режима в режим осуществляется с помощью кнопок тулбара.

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

Код обработчика будет слишком тяжел для понимания и сопровождения.

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

Таким образом, сформулируем противоречия.

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

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

Первое противоречие разрешается с помощью приемов «вынесение» и «дробление». Вместо одного обработчика на одно мышиное сообщение пишутся четыре: по одному на каждый из режимов.

Второе противоречие разрешается с помощью приема «объединение». Все обработчики, относящиеся к одному и тому же режиму, объединяются в отдельный класс (отдельную структуру данных). Для всех классов пишется абстрактный базовый класс, который объявляет интерфейс режима редактирования. А каждый из режимов редактирования реализуется в производном классе.

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

Из примеров видно, что изобретательская мини-задача обязательно содержит противоречие.

Рискну предположить, что полезность этих шаблонов неочевидна для начинающих. И, в ряде случаев, их использование противопоказано. Это не универсальное решение. А опытные люди на серьезных проектах их используют в полный рост.

Шаблоны проектирования – это аналог стандартов в «железной» ТРИЗ. Например, если не ошибаюсь, то решение, приведенное в примере 2, может быть получено с помощью применения шаблона «Состояние» (“State”). Среди шаблонов проектирования существуют аналоги и других ТРИЗ-приемов, например, «принципа посредника».

Один из недостатков шаблонов проектирования – это отсутствие четких указаний, когда и как их нужно применять. Т.е. отсутствует модель описания задачи и указатель применения шаблонов.

Вот мне и странно, почему это не было сделано ни авторами книжки «Приемы объектно-ориентированного проектирования. Паттерны проектирования», ни другими.

Шаблоны проектирования – это достаточно мощный инструмент. Но пригоден он только для решения мини-задач. Мне кажется, что ограниченное применение шаблонов связано именно с отсутствием инструмента для решения макси-задач, который бы позволял сводить любую макси-задачу к набору мини-задач.

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

С уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-11 00:28:22
Кирилл Лебедев » Всем

Уважаемые коллеги!

Хочу привести цитату из книжки, посвященной методологиям разработки ПО (Алистер Коберн. Быстрая разработка программного обеспечения. – М.: Издательство «Лори», 2002).

Вот как автор вкратце описывает свою методологию Crystal Clear быстрой разработки ПО:

«Поместите от четырех до шести человек в комнату с рабочими станциями, белыми досками и доступом к пользователям. Убедите их производить для пользователей работающие, протестированные программы каждые один-два месяца, во всем остальном оставьте их в покое» (с. 18).

Почему-то эта цитата напомнила мне цитаты из других западных книжек, посвященных методикам креатива в рекламе и PR.

С уважением,

Ответить Сообщение для всех [Нет ответов на это сообщение]
2003-11-11 11:20:41
Сергей Григорьев » Кирилл Лебедев

Уважаемый Кирилл!

Прежде всего, хочу выразить искреннюю благодарность за столь развернутый ответ.

Однако вы не ответили на вопрос: Есть ли определение что такое "изобретательская" задача?

Может более опытные коллеги подскажут?

Вы делите задачи на "мини" и "макси".

Из вашего письма следует, что "макси":

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

А "мини" делятся на

  • неизобретательские (не содержащие противоречия) 
  • изобретательская (содержит хотябы одно противоречие)

То есть вы ставите в один ряд формулировки "изобретательская потому, что не четко сформулированная и/или слишком общая" и изобретательская потому, что содержит противоречие. Я правильно Вас понял?

Вобщем получается: сформулировал, раздробил, решил противоречие (которое сам увидел/придумал/выстрадал) неважно каким способом (сам придумал способ решения или не сам придумал) - сделал изобретение? Так?

У Вас не возникает ощущения, что вы подменяете слово "реализация" словом "изобретение"?

Отдельная благодарность за последний абзац про "критерии". Очень здорово было бы еслиб кто-то их сформулировал. А пока их нет - каждый их сам себе придумывает и исходя из придуманного делает и  оценивает.

Теперь что касается шаблонов :-)

почитайте К. Ларман "Применение UML и шаблонов проектирования", возможно, картина станет яснее.

В книге Э. Гамма и др. "Приемы объектно-ориентированного проектирования. Паттерны проектирования", на которую вы ссылаетесь, на мой некомпетентый взгляд (:-) достаточно четко сформулированы "Назначение, Мотивация, Применимость, Структура, Участники, Отношения, Результаты, Реализация, Известные применения, Родственные паттерны" для описываемых шаблонов.

Вы пишите:

Шаблоны проектирования – это достаточно мощный инструмент. Но пригоден он только для решения мини-задач. Мне кажется, что ограниченное применение шаблонов связано именно с отсутствием инструмента для решения макси-задач, который бы позволял сводить любую макси-задачу к набору мини-задач.

Теперь посмотрите на сформулированное Вами определение "макси задачи":

Макси-задача связана с проектированием новой системы (программы, библиотеки, функциональной части программы). Для ее решения требуется сформулировать и решить множество мини-задач.

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

В книге К. Ларман есть замечательный абзац, который я позволю себе процитировать:

«

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

»

На всякий случай сформулирую вопросы, на которые ответы очень хочется получить (не важно от кого).

  1. Есть ли определение что такое "изобретательская" задача?
  2. Что есть "изобретение"?

Еще раз спасибо за примеры.

С уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-15 16:30:42
Михаил Едошин » Лаптев Валерий Викторович
Навскидку вспоминаются два примера задач программирования, неплохо иллюстрирующие принципы ТРИЗ. Первый --- знаменитая байка Дейкстры о вагонах и туалетах. Там выводов никаких не делается, но с точки зрения ТРИЗ задача решена формулировкой ИКР --- структура данных *сама* решает задачу. Второй --- пример из книги Бентли(?) "Жемчужины программирования" о битовой сортировке (самая первая задача). Там сам Бентли вплотную подходит к ТРИЗовским приемам --- заострение противоречия, отказ от типичного программистского компромисса "память-скорость".
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-15 16:52:50
Лаптев Валерий Викторович » Михаил Едошин
Могу привести пример того, что можно назвать изобретательской задачей и изобретением (сами решите, что к чему относится).
1.Как известно, умножение комплексных чисел в алгебраической форме требует 4-х умножений
(a+bi)*(c+di)
Но можно сделать за 3 (три).
Количество сложений/вычитаний и переменных любое.

x = (a+b)*c
y = (c+d)*b
z = (c-d)*a

Искомый результат: (x-y)+(x-z)i

Итого: 3 умножения, 2 сложения и 3 вычитания.

2.Умножение двух матриц 2х2 требует 8 умножений.
Можно сделать за 7.
Математик, который это сделал, заслуживает если не нобелевской премии, то докторской степени - точно.
Ответить Сообщение для всех [Нет ответов на это сообщение]
2003-11-15 16:56:44
Лаптев Валерий Викторович » Кирилл Лебедев
Ну почему же не получило!
Во-первых, шаблоны - это уже в достаточно крупном проекте. Не даром в начале книги приводится пример редактора - это не простая программа.
Во-вторых, шаблоны явно не для начинающих. Зайдите в форумы RSDN.ru и поспрашивайте. Я уверен, что каждый второй участник Вам ответит, что он применяет их постоянно.
Есть там и пара-тройка статей о применении конкретных шаблонов в работе.
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-15 16:59:07
Лаптев Валерий Викторович » Кирилл Лебедев
Спасибо за ссылки. Обязательно прочитаю все через некоторое время и отвечу по содержанию.
У меня пару студентов занимались как раз похожими делами - составляли типа тезауруса типичных ошибок начинающих программистов. Потом сделали семантическую сеть связанных друг с другом ошибок - чтобы советы давать начинающему.
Ответить Сообщение для всех [Нет ответов на это сообщение]
2003-11-16 16:35:30
Михаил Едошин » Сергей Григорьев
Изобретательская задача --- это задача, решение которой неизвестно. Изобретение --- это нахождение способа такую задачу решить.
Ответить Сообщение для всех [Нет ответов на это сообщение]
2003-11-17 18:11:37
Сергей В. Сычев » Сергей Григорьев

"Изобретательской" называется задача, содержащая техническое противоречие - см. здесь www.altshuller.ru

Однако речь идет не о том, что цит.: "cам увидел/придумал/выстрадал", а о том, что есть в системе.

Например, противоречие между "функциональностью и сложностью", "весом и мощностью", "скоростью и точностью" и т.д., и т.п.

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-17 23:41:33
Михаил Едошин » Сергей В. Сычев
Ну и какое же противоречие содержится в задаче, например, о подземоходе? Или в задаче коммивояжера? Или это не изобретательские задачи?
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 09:30:05
Сергей В. Сычев » Михаил Едошин

Уважаемый коллега!

Если Вы имеете в виду вот эту задачу: "Задача 3.10. Нужно предложить подземоход, способный передвигаться в земной коре со скоростью 10 км/ч при запасе хода в 300—400 км.". И если Вы, при этом, действительно полагаете, что такая задача технических противоречий не содержит, то даже не буду с Вами спорить.

 

Если же в Вашем вопросе содержится просьба указать на конкретные технические противоречия в данной задаче (замечу 5-го уровня), то приведу цитату из первоисточника :

"Здесь хорошо видна характерная особенность задач пятого уровня: к моменту постановки подобных задач средства их решения лежат за пределами современной науки. Не известны те физические эффекты, явления, принципы, на основе которых может быть создан подземоход (а вместе с ним новая отрасль техники - глубинный транспорт).

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

Источник: Г.С. Альтшуллер, "Найти идею" (3-е изд., дополн. - Петрозаводск: Скандинавия, 2003. - С. 49 -54)

Также см. www.altshuller.ru/triz/levels.asp

Успеха!

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 09:44:09
Сергей Григорьев » Сергей В. Сычев

Именно "техническое"?

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 09:55:28
Сергей В. Сычев » Сергей Григорьев

Если не выходить за рамки техники, то "да" ("техническое", либо "физическое"). В контексте обсуждения посвященного программированию, мне кажется, за эти рамки выходить не стоит.

Для тех случаев, когда техническое противоречие неочевидно ответ дан выше.

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 10:20:16
Михаил Едошин » Сергей В. Сычев

Мне просто не нравится определение изобретательской задачи как "задачи, содержащей противоречие". Сами же цитируете: "Условия задачи пятого уровня обычно не содержат прямых указаний на противоречие." Да и не только пятого  --- ведь отыскание и четкая формулировка противоречия как раз и составляют суть АРИЗ, т. е. противоречие в большинстве задач вовсе не лежит на поверхности. Получается, что определение звучит примерно так: "Изобретательская задача --- это задача, которая содержит такую штуковину, которую мы, основательно покумекав, можем в ней найти". Ну и зачем такое определение? Где его практический смысл?

На мой взгляд определение "ИЗ" как  "З, которую неизвестно, как решать" куда проще и понятнее.

Ответить Сообщение для всех [Нет ответов на это сообщение]
2003-11-18 10:25:07
Сергей Григорьев » Сергей В. Сычев

Но ведь программа не может иметь технических/физических противоречий. Что тогда понимать под "изобретательской задачей" в программировании?

Лебедев говорит - есть противоречие (!не техническое!) - значит изобретательская, непонятно до конца что делать (слишком общая/незаконченная формулировка) - изобретательская.

Можно конечно взять определение "изобретательской задачи" пятого уровня, но тогда что понимать под "отсутствием прототипа"?

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 11:41:06
Сергей В. Сычев » Сергей Григорьев
Я, как и К. Лебедев, попробую привести примеры. Они намеренно не самые сложные – надо проиллюстрировать модель. Те же примеры с исходниками направлены по E-mail’у.
 
Фрагменты из картотеки С.В. Сычева, А.Б. Кавтревой (формулировка задач и принципов решения). Программист, который затем реализовывал решения приведенные ниже - Р.Ю. Панасенко.
 
Пример 1:
 
Изобретательская ситуация: Довольно часто, когда получаешь задание на оптимизацию базы данных, сталкиваешься с предполагаемым обилием запросов и - более того – с обилием форм. Из-за этого размер базы существенно вырастает, что затрудняет ее обслуживание и «тормозит быстродействие».
 
Так, например, при совершенствовании первой версии одной из баз данных, написанной для риэлторов, пришлось столкнуться с тем, что для каждого типа квартир использовался отдельный запрос и отдельная форма.
 
Изобретательская задача (формулировка в виде противоречия):
 
Запросов и форм должно быть много, так как нужен отдельный запрос и форма для каждого типа квартир. Но запросов и форм должно быть мало для быстроты работы самой программы.
 
Одно из возможных решений: заключалось в применении одной формы, которая использовалась во всех типах квартир. При этом запрос менялся в зависимости от типа квартир прямо в форме, что позволило вообще избавиться от сохраненных запросов, с сохранением их функций. В результате база получилась на удивление мала и даже более функциональна.
 
К данному решению можно прийти, используя любой из следующих приемов:
 
Принцип 1. «Свертывания».
 
Принцип 1.1.  «Свертка на форме».
«Если у Вас много запросов, которые должны выводиться в форме, используйте одну форму, которая жестко не привязана к сохраненному запросу. Пусть в зависимости от параметров вызова формы, запрос формировался бы в самой форме при ее открытии».
 
Принцип 1.2. «Свертка на событии».
«Если у Вас много похожих запросов, то используйте один запрос, параметры которого менялись бы при наступлении определенного события. Например, открытие формы, в которую помещаются результаты запроса».
 
Принцип 2. "Динамичности".
«Если надо решить задачу, типа "много – мало" однотипных объектов", используйте один объект, свойства которого менялись бы в зависимости от ситуации».
 
Пример 2:
 
Изобретательская ситуация: Есть таблица, с большим количеством полей. И постоянно приходиться делать выборку из такой таблицы, с большим количеством условий типа поле1 = значение1, поле2 <> значение2, и т.д. При таком раскладе запросы становятся очень большими, дольше выполняются. Иногда, при сложных запросах, где объединяются несколько таких «больших подзапросов», база данных просто отказывается выполнять их, ссылаясь на слишком сложный запрос.
 
Изобретательская задача (формулировка в виде противоречия):
 
Для правильной выборки необходимо большое количество параметров в запросе, типа поле1 = значение1, поле2 <> значение2, и т.д. Но – с другой стороны - запросы должны быть «легкими», то есть, необходимо малое количество параметров, т.к. чем больше таких параметров, тем сложнее запрос и тем медленнее он выполняется.
 
Одно из возможных решений:
 
Один из вариантов решения, ввести новое поле в таблицу, значением которого является некое число (так называемый вес).  Диапазон чисел может быть любой, в зависимости от необходимой точности. Тогда исходный запрос может превратиться в запрос с одним условием вес = N.
 
При использовании такого метода, необходимо реализовать программный код, который бы при добавлении каждой новой записи, устанавливал соответствующий вес, исходя из тех же параметров поле1 = значение1, поле2 <> значение2.
 
К данному решению можно прийти, используя следующий прием:
 
Принцип 3: «Переход в другое измерение». («Матрешка»).
«Если параметров отбора данных слишком много, перейдите к методу отбора с одним параметром. Значения этого параметра сформируйте из первоначальных».
 
Пример 3:
 
Изобретательская ситуация: В большой таблице необходимо произвести пересчет определенных полей по сложной функции. Первое, что напрашивается – запрос на обновление, и это правильно. Но когда программист сталкивается с проблемой реализации своего алгоритма вычислений в запросе на обновление, то он начинает искать другие способы пересчета. Например, перебор в цикле всех записей, а это резко влияет на быстродействие системы. Скажем, очень легко пересчитать результат в запросе на обновление по формуле a=b/c, но что делать, если это не просто деление, а более сложная функция, в которой есть условные операторы или/и циклы.
 
Изобретательская задача (формулировка в виде противоречия):
 
Необходимо изменить каждую запись по сложному алгоритму, а этот алгоритм невозможно напрямую встроить в запрос на обновление. 
 
Одно из возможных решений: Если возникают трудности реализовать сложную функцию, встроенную в SQL – запрос, вынесите эту функцию из запроса, напишите ее отдельно. А затем просто вызывайте ее из запроса по имени, можно с параметрами, можно без них, в зависимости от сложности функции.
 
К данному решению можно прийти, используя, в зависимости от конкретных условий, один из следующих приемов:
 
Принцип 4.: «Использование Посредника».
 
Принцип 4.1:«Посредник». («Вынесение»).  Если возникают трудности при реализации сложной функции, встроенной в SQL – запрос, вынесите эту функцию из запроса, напишите ее отдельно. А затем просто вызывайте ее из запроса по имени, можно с параметрами, можно без них, в зависимости от сложности функции.
 
Принцип 4.2:«Посредник». («Местное качество»).  Лучшим способом изменения большого числа записей является запрос на обновление. (Даже если при изменении записей необходимо выполнить некоторые вычисления). Для этого необходимо написать функцию, в которой происходят все вычисления, и вставить ее в тело запроса.
 
Примечание: Но будьте внимательны к таким процедурам, они должны быть максимально облегчены.
 
Как видно из описания, принцип 4.2., в определенном смысле, обратный принципу 4.1.
============================================
Поймите правильно. Хотелось бы избегнуть общих  и малополезных рассуждений о том «относится ли программирование к техническим дисциплинам» и т.п. и, поэтому уместен ли термин «техническое» и т.п.
 
Мне кажется более полезным мог бы стать сбор картотеки примеров решенных задач. Например, первичная модель описания каждой задачи могла бы выглядеть так:
 
«Ситуация» - «Противоречие» - «Решение» - «Прием, принцип» (как обобщение).
 
Уверен в том, что уже 40-50 примеров «прояснят дефиниции» лучше любых силлогизмов.
 
С Уважением,
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 12:22:33
Сергей Григорьев » Сергей В. Сычев

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

Что сделает Редакция с этой картотекой? Что будет в результате?

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 12:40:33
Сергей В. Сычев » Сергей Григорьев

Вы можете прислать по адресу: sch@triz-ri.ru , а не в Редакцию 5-6 задач, которые были для Вас трудны, однако, относительно которых у Вас нет понимания "изобретательская" задача это или нет.

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

После чего Вы получите подробный ответ.

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 12:53:17
Сергей Григорьев » Сергей В. Сычев

Если я уже решил задачу - зачем я буду ее присылать? Она уже решенная. И мне без разницы какая она с точки зрения ТРИЗ. Однако если я буду понимать что я посылаю ее Вам для какого-то полезного или нужного дела, и что это принесет какую-то пользу кому-то - я пришлю.

Вобщем наверно не только мне нужно понимание - ради чего что-то делается.

Вы не ответили для чего будет использована картотека примеров. Какую задачу мы решаем? Сформулируете?

И возможно общими усилиями мы быстрее достигнем результата.

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 13:22:30
Сергей В. Сычев » Сергей Григорьев

Вы спросили здесь и выше о том,что такое изобретательская задача.

Я попробовал Вам ответить на Ваш вопрос. Для этого привел не только "точку зрения", но и примеры.

Готов и на Ваших (как решенных, так и не решенных) примерах, а не только своих попробовать это показать.

Такова "мини-задача": честно ответить на Ваш вопрос. Если он Вас, конечно, действительно интересует.

Пока, я думаю, этого достаточно. Ибо, сказано: "Большое пьянство начинается с маленьких рюмок".

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 13:47:15
Сергей Григорьев » Сергей В. Сычев

Я действительно спросил что есть "изобретательская задача" Вы  привели определение и согласились с тем, что это определение для технических изобретательских задач.

Вам, также как и Кириллу Лебедеву огромное спасибо за примеры.

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

Из ваших примеров следует, что любая программисткая задача, которая содержит противоречие - это изобретательская задача.

Я правильно Вас понял?

P.S. А причем тут алкоголизм? :-)

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 14:48:17
Сергей В. Сычев » Сергей Григорьев
Из ваших примеров следует, что любая программистская задача, которая содержит противоречие - это изобретательская задача. Я правильно Вас понял?
 
Да, наличие противоречия - это критерий. Быть может он не единственный, но основной. Если нет противоречия = ничто объективно не мешает реализовать замысел (=известен способ решения), то нет и изобретательской задачи. Надо просто "взять и сделать".
 
Когда же имеем противоречие: "функциональность конфликтует с быстродействием", "точность со сложностью" или гамма других, а адекватного способа решения не имеем; либо, когда при улучшении (изменении, измерении…) одной части системы происходит резкое ухудшение (усложнение, разрушение…) другой части, то вот указание на "изобретательскую задачу".
 
Кроме самого понятия "изобретательская задача", важно учитывать тот факт, что изобретательские задачи бывают разного качественного уровня. Скажем, примеры, приведенные мной ранее, выше третьего уровня оценить нельзя. А, например, если Вы поставите себе задачу создать такую систему, чтобы скорость загрузки страницы сайта в принципе не зависела бы от ее размера (и байт, и гигабайт "грузились" бы с одинаковой скоростью - быстро, мгновенно... причем, даже по самому узкому каналу)", то это будет изобретательская задача пятого уровня. То есть, противоречия, которые придется преодолеть, будут "покруче". Не факт, но не исключено и то, что для решения задачи такого уровня надо выйти за рамки собственной специальности.
 
Что же касается картотек задач (зачем они), то задачи - это сырье, из которого и "выплавляются принципы". (То есть, не из головы, а из картотеки фактически решенных задач). Например, Н.И. Пирогов для того, чтобы создать основы хирургии, как науки, не только провел, но и задокументировал по формуляру 12 000 операций + для того, чтобы в короткий период времени получить большой поток разнородных медицинских задач, отправился... на войну.
 
В картотеке каждая запись сама по себе не говорит ни о чем, но, в целом, хорошая картотека задач образует систему, которую можно использовать для формулирования тех или иных приемов и алгоритмов.
 
С Уважением,
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 16:38:33
Сергей Григорьев » Сергей В. Сычев

Огромное спасибо!

Итак у нас есть единственный (пока?) критерий изобретательской задачи - наличие любого противоречия. Получается есть противоречие -- есть изобретательская задача. 

Теперь я попробую научиться формулировать противоречия. Надеюсь Вы мне в этом поможете.

Возьмем ваш пример номер 3.

Каким образом он попал в картотеку:

1. Программист сам сформулировал противоречие. приходит к Вам и говорит:

- я не могу сделать расчет потому что "Необходимо изменить каждую запись по сложному алгоритму, а этот алгоритм невозможно напрямую встроить в запрос на обновление. "

Потом он узнает (сам или от Вас) про Принцип 4.: «Использование Посредника». И ищет как бы ему переложить на свою задачу "принцип посредника", находит и решает задачу. То есть противоречие было сформулировано  самостоятельно, и решено благодаря существованию принципа №4.

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

Как было дело? Кто формулировал противоречие?

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

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

Так вот, имея на руках: "Как мне изменить значение поля SUMMA в каждой записи по заданной сложной формуле, есле эта формула должна содержать цикл, а  в команде UPDATE цикл не напишешь, а я кроме команды Update и SELECT больше больше (пока) ничего не знаю"

Какие шаги я должен выполнить чтобы: сформулировать из вот этого противоречия другое противоречие.

Можно взять любой другой пример. Возможно этот слишком примитивен. Суть одна: есть предельно точно сформулированное противоречие. По какому алгоритму я должен прийти к противоречию, имея которое а могу зайти в ТИПОВЫЕ ПРИЕМЫ УСТРАНЕНИЯ ТЕХНИЧЕСКИХ ПРОТИВОРЕЧИЙ

и ТАБЛИЦА ПРИМЕНЕНИЯ ПРИЕМОВ РАЗРЕШЕНИЯ ТЕХНИЧЕСКИХ ПРОТИВОРЕЧИЙ найти там нужное (ПУСТЬ ХОТЯ БЫ ВОБЩЕМ) направление, в котором дальше копать?

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-11-18 18:01:27
Сергей В. Сычев » Сергей Григорьев

Что касается Примера 3. Реально дело обстояло следующим образом.

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

Я дал требование сформулировать:

а. в виде противоречия - это получилось несложно, ибо он подробно рассказывал "почему невозможно";

б. без терминов.

Сейчас трудно сказать, кто формулировал на самом деле (я или он), поскольку был диалог, к тому же, программист упирался и спрашивал: "Зачем это надо?". Принцип посредника подсказал я. После реализации пример попал в картотеку. Аналогично было и с задачей про "упрощение запроса" (введение веса) и др.

Однако хочу обратить Ваше внимание, что это частный случай. Он ничего не доказывает и ничего не опровергает. Важно иметь много таких задач и тогда можно сделать формализованную процедуру (не сводящуюся к тому, как это было "у Сычева", "у Иванова", "У Сидорова", а универсальную), о которой, судя по всему, Вы и пишете. Замечу, что для создания таблицы приемов устранения ТП Г.С. Альтшуллеру потребовались годы работы в патентной библиотеке (это и есть первичная картотека ТРИЗ).

Как я предполагаю это должно быть сделано? Даже у приведенных выше примеров уже есть правила (приемы), например:

  • «Если у Вас много запросов, которые должны выводиться в форме, используйте одну форму, которая жестко не привязана к сохраненному запросу. Пусть в зависимости от параметров вызова формы, запрос формировался бы в самой форме при ее открытии».
  • «Если у Вас много похожих запросов, то используйте один запрос, параметры которого менялись бы при наступлении определенного события. Например, открытие формы, в которую помещаются результаты запроса».
  • «Если надо решить задачу, типа "много – мало" однотипных объектов", используйте один объект, свойства которого менялись бы в зависимости от ситуации».
  • «Если параметров отбора данных слишком много, перейдите к методу отбора с одним параметром. Значения этого параметра сформируйте из первоначальных».
  • "Если возникают трудности при реализации сложной функции, встроенной в запрос, вынесите эту функцию из запроса, напишите ее отдельно. А затем просто вызывайте ее из запроса по имени, можно с параметрами, можно без них, в зависимости от сложности функции".
  • .....  и т.д. потому, что еще есть . Например, Вам известна задача об отделении разработки от сопровождения =  "дроблении кода на функции (в ФСА-смысле) и хранении их в таблицах реляционной базы данных с последующей генерацией в плоский файл", задача "о критической программе" и проч.

Далее. Нам надо соотнести задачи (типы задач) и приемы. Что должно лежать в основе типизации задач? Могу предположить, что "тип противоречия". Например, противоречия типа "много-мало" решаются такими-то приемами; противоречия типа "сложное - простое" - такими-то...

В очень упрощенном виде в настоящий момент, универсальная процедура (а не "как было в частном случае") могла бы выглядеть так: "Столкнувшись со сложной  задачей, программист должен:

шаг 1. Формализовать ее по след. правилам: см. "ПРАВИЛА ФОРМУЛИРОВАНИЯ ПРОТИВОРЕЧИЯ"

шаг 2. Проверить типовое противоречие или нет; если типовое - шаг 3., нет - шаг 4.

шаг 3. См. "ПРАВИЛА ВЫБОРА ПРИЕМА" 

шаг 4. Иные инструменты решения (тоже есть, и корни их тоже из ТРИЗ, но сейчас преждевременно об этом говорить)

Иными словами, надо написать ТРИЗ-приложение для решения задач программирования.

С Уважением,

Ответить Сообщение для всех [Нет ответов на это сообщение]
2003-11-19 01:27:51
Кирилл Лебедев » Лаптев Валерий Викторович

Уважаемый Валерий Викторович!

 

Спасибо за полезную ссылку!

 

У меня пару студентов занимались как раз похожими делами - составляли типа тезауруса типичных ошибок начинающих программистов.

 

Имеются ли какие-нибудь публикации у Вас или у Ваших студентов на эту тему? Мне было бы интересно ознакомиться с ними.

 

С уважением,

Ответить Сообщение для всех [Нет ответов на это сообщение]
2003-11-19 01:29:47
Кирилл Лебедев » Сергей Григорьев

Уважаемый Сергей!

 

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

 

Не смотря на приложенные усилия, науки и/или методики они так и не создали.

 

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

 

Примеры:

 

 

Не случайно на заре XVII века Френсис Бэкон в своей работе «Новый органон» предложил иной (индуктивный) подход к созданию науки: выведение закономерностей на основе реальных фактов. И описал приемы сбора таких фактов и правила вывода закономерностей.

 

2.      По причине из п. 1 на начальном этапе исследования (а изучение творческих задач в программировании с позиций ТРИЗ началось сравнительно недавно) невозможно дать точное определение изучаемым понятиям.

 

«Из науковедения известно: исчерпывающе точные определения вырабатываются в споре ряда научных школ не на "заре" новой науки (дисциплины), а на её "закате"...» (И.Л. Викентьев, Легкость в мыслях обыкновенная…).

 

Можно назвать лишь критерии понятия (сущности). В случае с изобретением таким критерием является разрешение технического противоречия. Об этом в своих сообщениях Вам хорошо сказал Сергей В. Сычев.

 

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

 

Перечислю несколько вариантов.

 

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

 

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

 

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

 

Вариант 2. Противоречия между новыми требованиями к программе и ее текущей реализацией.

 

Пример. Работа с программой для создания земной поверхности (террэйна) производится по следующему алгоритму. Сначала дизайнер добавляет в стек модификаторы (модули, отвечающие за какую-нибудь отдельную операцию: триангуляцию, текстурирование, выравнивание и т.д.). Затем он применяет стек модификаторов и получает террэйн.

 

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

 

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

 

Вариант 3. Противоречия между стилем программирования, принятым в фирме, и требованиями пользователя.

 

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

 

Согласно правилам Компании «никакая функция не должна содержать код, специфичный для двух и более сущностей» (в данном случае – режимов редактирования), и «необходимо добиваться, чтобы внесение/редактирование/удаление сущности было локализовано в одном месте (файле, классе, функции)».

 

Таким образом, правила написания исходного кода вступили в противоречие заданием. И это противоречие было разрешено.

 

4.     В упомянутой книге Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. «Приемы объектно-ориентированного проектирования. Паттерны проектирования» отсутствует ряд вещей, необходимых для практического применение «шаблонов проектирования».

 

К этим вещам относятся:

 

·        Сводный указатель применения шаблонов проектирования по модели «Задача – Шаблон».

·        Методика постановки задачи – алгоритм, который бы позволял переводить проблему (изобретательскую ситуацию – термин Г.С. Альтшуллера) в задачу.

·        Разбиение задач на уровни.

 

Спасибо за полезную ссылку!

 

С уважением,

Ответить Сообщение для всех [Нет ответов на это сообщение]
2003-12-11 13:17:52
Сергей Середа » Лаптев Валерий Викторович

Уважаемые коллеги!

К сожалению, я вышел на этот форум только сегодня (11/12/2003), поэтому моя реплика несколько отстала от жизни, но всё же.

Прошу оценить мою статью "Законы развития технических систем и программное обеспечение"  (http://cie.ase.md/~sereda/os_devel.htm).

Хотя она и не посвящена именно программированию, но в тему обсуждения вписываться должна. (Кстати, редакция сайта http://www.triz.minsk.by [ныне www.trizminsk.org] зарубила статью на корню без каких бы то ни было комментариев...)

P.S. Если вспомнить о том, что изобретения (ради которых, собственно и создавалась ТРИЗ) делятся по уровням, то я бы квалифицировал уровень задач программирования как 1-2, т.е. при программировании решаются задачи техники, но не технологии.

Задачи усложняются при переходе от разработки программного кода к разработке технологий обработки данных.

С уважением,

Сергей Середа

Движение "ПОтребитель"

http://cie.ase.md/~sereda

http://consumer.nm.ru

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-12-11 14:44:47
Лаптев В.В. » Сергей Середа
Цитата:
P.S. Если вспомнить о том, что изобретения (ради которых, собственно и создавалась ТРИЗ) делятся по уровням, то я бы квалифицировал уровень задач программирования как 1-2, т.е. при программировании решаются задачи техники, но не технологии.

Ого! Смелое заявление! А как же все технологии программирования? Паттерны -
(шаблоны - немного неверный термин. Лучше сказать - типовые решения. Но это длинно, поэтому я использую термин "паттерн". Еще и потому, что "щаблон" - это в С++ template)
это уже из области технологий, а не задач. Сам термин - "типовое решение" - уже предполагает наличие некоей технологии.
А вот изобретение самого типового решения - это изобретательская задача (какая игра слов, а ? :-)).

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-12-11 15:51:59
Сергей Середа » Лаптев В.В.
Уважаемый Валерий Викторович!

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

> Ого! Смелое заявление! А как же все технологии
> программирования? Паттерны -
> (шаблоны - немного неверный термин. Лучше сказать - типовые
> решения. Но это длинно, поэтому я использую термин "паттерн".
> Еще и потому, что "щаблон" - это в С++ template)
> это уже из области технологий, а не задач. Сам термин -
> "типовое решение" - уже предполагает наличие некоей
> технологии.
> А вот изобретение самого типового решения - это
> изобретательская задача (какая игра слов, а ? :-)).

Дело в том, что во-первых, сам термин "технология программирования" явно напрямую переведён с английского "programming technology", а они называют "технологиями" всё, что Бог на душу положит. Как правило их "technology" необходимо переводить как "техника" (Если нужно, могу привести источник). Во-вторых, даже "технология программирования" и "программирование" это совсем не одно и то же.

Насчёт изобретения типового решения (ТПР) спорить не буду. Просто, опять же, необходимо разделять "типовые болты и гайки" (Delphi components, etc.) и "типовые технологии" (COM, CGI, etc.).


P.S. Я могу ответить завтра-послезавтра, т.к. не каждый день сижу в Сети, так что не обижайтесь, если что.


С уважением,
Сергей Середа


Движение "ПОтребитель"

http://cie.ase.md/~sereda
http://consumer.nm.ru
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-12-11 18:51:32
Яков Немировский » Сергей Середа

Уважаемый Сергей,

Попытался зайти по указанной Вами ссылке http://cie.ase.md/~sereda/os_devel.htm, но она почему-то не работает... Нашел названную Вами статью по адресу http://consumer.nm.ru/os_devel.htm и ознакомился с ней. Впечатления:

- да, действительно операционные системы развиваются по принципам ЗРТС.

- конкретные достоинства конкретных ОС вопрос уж очень избитый и спорный.

- обращаю Ваше внимание, что реальное развитие ОС подчиняется еще и законам рынка, кроме того тесно взаимосвязано с развитием железа...

Ваш Яков.

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-12-16 16:12:32
Кирилл Лебедев » Всем

Уважаемый коллеги!

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

Фаулер М. Рефакторинг: улучшение существующего кода. - Пер. с англ. - СПб: Символ-Плюс, 2003. - 432 с., ил.

С уважением,
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2003-12-23 16:52:03
Сергей Середа » Яков Немировский
Уважаемый Яков!

Спасибо за то, что прочли статью.

По поводу конкретных достоинств ОС. Я, в меру своих сил, постралася уйти от тех моментов, которые обычно обсуждаются в так называемых "holy wars". Т.е. я не пишу, что "Винды маст дай", а "Линукс рулез форева", я попытался проанализировать соответствие развития ряда ОС законам развития, а уже по степени этого соответствия делал суждения.
Что касается оценочной таблицы в конце, не следует принимать её слишком близко к сердцу, в ней - сугубо моё мнение.

Относительно законов рынка. Дело в том, что ЗРТС являются объективными и от рыночной формации не зависят. Так что как таковое развитие технических систем НИКАКИМ ЗАКОНАМ РЫНКА НЕ ПОДЧИНЯЕТСЯ. Другой вопрос, что ЗАКОНЫ РЫНКА МОГУТ ВЛИЯТЬ НА ТЕМПЫ РАЗВИТИЯ ТЕХНИКИ. Это бесспорно. К сожалению, современный рынок, как правило оказывает тормозящее воздействие на технический прогресс...

Спасибо за отзыв.

С уважением,

Сергей Середа


Движение "ПОтребитель"

http://cie.ase.md/~sereda
http://consumer.nm.ru

Ответить Сообщение для всех [Нет ответов на это сообщение]
2003-12-26 12:25:23
Сергей Середа » Кирилл Лебедев

Интересующимся "рефэкторингом", по-русски - упорядочением и оптимизацией программного кода на ЯВУ, могу посоветовать перед тратами на книгу воспользоваться одним из сервисов Сети сетей, а именно поисковым.

Задав, например, поисковый критерий \'code + refactoring\' поисковику google, можно получить значительное количество ссылок на полезные ресурсы (разумеется, если задавать критерий поиска на английском, то в ответ текстов на русском не получишь), в частности, следующие ссылки:

www.refactoring.com
http://jerry.cs.uiuc.edu/~garrido/CRefactory.html
http://www.perl.com/lpt/a/2003/10/09/refactoring.html
http://www.cs.usfca.edu/~parrt/course/601/lectures/refactoring/refactoring.html
http://www.caetano.com/richard/Articles/fog0000000033.html

Тем, кто не владеет английским, могу советовать поискать материалы, задав критерий поиска на русском языке. Что-то вроде

\'рефакторинг || рефэкторинг || "оптимизация кода" || "Мартин Фоулер" || "Мартин Фаулер"\'.

Если информации в найденных данных будет недостаточно, тогда уж придётся тратить деньги на книгу.

С уважением,

Сергей Середа

Движение "ПОтребитель"

(http://consumer.nm.ru v http://cie.ase.md/~sereda/)

Ответить Сообщение для всех [Нет ответов на это сообщение]
2004-01-03 17:21:01
Федоров Д.Н. » Всем

Очень интересное обсуждение ! Особенно фраза :

........А, например, если Вы поставите себе задачу создать такую систему, чтобы скорость загрузки страницы сайта в принципе не зависела бы от ее размера (и байт, и гигабайт "грузились" бы с одинаковой скоростью - быстро, мгновенно... причем, даже по самому узкому каналу)", то это будет изобретательская задача пятого уровня. То есть, противоречия, которые придется преодолеть, будут "покруче". Не факт, но не исключено и то, что для решения задачи такого уровня надо выйти за рамки собственной специальности.........

  Постановка задачи правильная :) Дополню только , что при этом самый узкий канал связи - отсутствующий.
Принципиально такая задача решена , почти по ТРИЗ .  Работает прием предварительного действия.  Если вы отправили гигабайт информации сегодня , а пришел он в точку назначения вчера , то у вас есть целый день форы на загрузку страницы сайта :)
  Для правильного решения этой задачи , мало профессионально знать ТРИЗ ...  Нужно кое , что еще ... например , жить в России , тут фантазия работает лучше , да и люди не очень озабочены добычей  денег :)   Главным становится вопрос о главном производственном процессе ,  для чего такое сжатие информации нужно людям ?  И вопрос о защите способа от "дурака" , например , от того кому нужны деньги :)
 
Ответить Сообщение для всех [Нет ответов на это сообщение]
2005-05-20 17:14:18
Редакция » Всем

Уважаемые Коллеги!

Появился первый материал (из серии...), посвященный применению ТРИЗ в программировании.

Ответить Сообщение для всех [Нет ответов на это сообщение]
2005-06-07 15:48:13
Редакция » Всем

Уважаемые Коллеги!

 
Выложены еще два материала С.В. Сычева и  К.А. Лебедева, посвященные креативу и программированию:

В этих материалах задачи, изложенные ранее в статье  С.В. Сычев, К.А. Лебедев "Как вспомнить "и так известное" , разобраны иным способом.

 

Спасибо,

Ответить Сообщение для всех [Нет ответов на это сообщение]
2006-03-20 14:09:19
Редакция » Всем

Уважаемые Коллеги!

 
Выложены еще два материала С.В. Сычева и  К.А. Лебедева, посвященные креативу и программированию:

Спасибо,

Ответить Сообщение для всех [Нет ответов на это сообщение]
2007-01-27 14:34:10
Редакция » Всем

Уважаемые Коллеги!

Появился  еще  один материал С.В. Сычева и К.А. Лебедева, посвященный креативу и программированию:

Спасибо,

Ответить Сообщение для всех [Нет ответов на это сообщение]


Яндекс.Метрика