ТРИЗ: устранение программных противоречий
От: Critical Error ICQ: 123736611
Дата: 04.02.09 06:53
Оценка:
Хочу вернуться к тематике применения ТРИЗ в разработке программного обеспечения. Возникла мысль: а не сделать ли таблицу решения программных противоречий, возникающих при разработке ПО? Тема эта актуальна потому как такой таблицы пока нет в природе, а полезность ее для меня является очевидной, ведь так много разработчиков (особенно начинающих), которые просто по неопытности не знают как бороться с некоторыми проблемами и пишут код довольно низкого качества в архитектурном плане при этом удивляются, что это у них программы так медленно работают и начинают заниматься «оптимизацией» совсем не там где это надо. Таблица эта также будет полезна и опытным разработчиком так как она может натолкнуть на оригинальные технические решения. Кроме того такая таблица очень проста в использовании в отличие от тяжеловесных «CookBook-ов» и «Библий программиста».

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

Приемы:

  1. Дробление.
  2. Объединение.
  3. Map-Reduce.
  4. Вынесение. Вынесение части объекта.
  5. Инкапсуляция. Внесение объекта внутрь другого объекта.
  6. Оптимизация части.
  7. Универсальность.
    a. Использовать стандартные библиотеки.
    b. Использовать одни и те же алгоритмы для разных данных.
    c. Использовать единые интерфейсы.
  8. Предобработка.
    a. В некоторых алгоритмах необходимо преобразовать данные, что влечет за собой снижение скорости и иногда создание дополнительного буфера. Можно исключить преобразование, обработав данные заранее.
    b. Разбить поток байт на токены с помощью конечного автомата (или регулярных выражений).
  9. Хеширование.
  10. Подмена.
    a. Можно подменить большие объекты заранее взвешенными весами, чтобы в дальнейшем обрабатывать не объекты, а их веса.
  11. Обработка на месте.
  12. Непрерывность.
    a. Сортировка при вставке.
    b. Балансировка дерева при вставке.
  13. Периодичность.
  14. Еждевенчество.
    a. Использование данных, сгенерированных в ходе работы другого алгоритма.
    b. Посчитать и сохранить веса объектов в ходе обхода или сортировки.
  15. Ленивость.
    a. Сортировка при необходимости.

Параметры, вступающие в противоречие:

Память, Скорость, Сложность, Изменчивость, Неизменчивость, Транзакционность, Надежность, Масштабируемость

Примеры решений:

Понизить расход памяти: обработка данных на месте.
Увеличить скорость: предобработка, подмена, хеширование, кэширование.
Понижаем расход памяти – уменьшается скорость: предобработка, дробление данных.
Повышаем скорость – увеличивается расход памяти: предобработка, подмена, дробление данных.
Обратить изменчивость системы: Visitor.
Разорвать связность одного объекта с другим: Inversion Of Control.
Транзакционность и устойчивость к ошибкам: Copy And Swap.
Повысить масштабируемость можно путем разрыва зависимостей между подсистемами и одновременного дробления данных.
Понизить cложность: универсальностью.
триз
Re: ТРИЗ: устранение программных противоречий
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 05.02.09 09:04
Оценка: +1
Здравствуйте, Critical Error, Вы писали:

CE>Хочу вернуться к тематике применения ТРИЗ в разработке программного обеспечения. Возникла мысль: а не сделать ли таблицу решения программных противоречий, возникающих при разработке ПО? Тема эта актуальна потому как такой таблицы пока нет в природе, а полезность ее для меня является очевидной, ведь так много разработчиков (особенно начинающих), которые просто по неопытности не знают как бороться с некоторыми проблемами и пишут код довольно низкого качества в архитектурном плане при этом удивляются, что это у них программы так медленно работают и начинают заниматься «оптимизацией» совсем не там где это надо. Таблица эта также будет полезна и опытным разработчиком так как она может натолкнуть на оригинальные технические решения. Кроме того такая таблица очень проста в использовании в отличие от тяжеловесных «CookBook-ов» и «Библий программиста».


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

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

В остальном — категорически согласен. Времени только нет.
The God is real, unless declared integer.
Re: ТРИЗ: устранение программных противоречий
От: Beam Россия  
Дата: 05.02.09 10:27
Оценка: +1
Здравствуйте, Critical Error, Вы писали:

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


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

1. Может быть есть смысл провести в начале такую систематизацию? Это может позволит упростить создание таблицы. Кроме этого в результате такой систематизации могут быть каким-то образом сгруппированы параметры, вступающие в противоречие.

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

3. Как уже сказал netch80, можно посмотреть на паттерны и методы рефакторинга и оттуда вычленить приемы. Опять же, с поправкой на универсальность (т.е. берем ООП паттерны и вычленяем приемы).

CE>Приемы:

CE>
  • Обработка на месте.
    CE>
  • Периодичность.
    Вот это не совсем понятно.

    CE>Память, Скорость, Сложность, Изменчивость, Неизменчивость, Транзакционность, Надежность, Масштабируемость

    Неплохо было бы как-то согласовать терминологию. Сложность, надежность — достаточно размытые понятия. Что такое (не)изменчивость?

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

    P.S. Может быть есть смысл сделать небольшое "Введение в ТРИЗ" на пол-странички? Думаю, тогда побольше народа подключится к обсуждению.
  • Best regards, Буравчик
    Re[2]: ТРИЗ: устранение программных противоречий
    От: Critical Error ICQ: 123736611
    Дата: 05.02.09 11:40
    Оценка:
    Здравствуйте, Beam, Вы писали:

    B>Среди перечисленных Вами приемов отсутствует какая-то систематизация — есть абстрактные (дробление, объединение, оптимизация), есть вещи, связанные с построением алгоритмов (хэширование, непрерывность, предобработка), есть относящиеся к дизайну (инкапсуляция, универсальность) и т.д.


    B>1. Может быть есть смысл провести в начале такую систематизацию? Это может позволит упростить создание таблицы. Кроме этого в результате такой систематизации могут быть каким-то образом сгруппированы параметры, вступающие в противоречие.


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

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

    В общем сейчас я пытаюсь собрать список типа "улучшение -> ухудшение: прием". В этот список надо скидывать абсолютно все, что найдется. Затем будет стадия систематизации данных. Ну и наконец можно будет составить таблицу.
    Re: ТРИЗ: устранение программных противоречий
    От: dmp  
    Дата: 05.02.09 19:19
    Оценка:
    Здравствуйте, Critical Error, Вы писали:

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


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


    CE>
  • Дробление.
    CE>
  • Объединение.

    Просто приём ничего не даёт. Надо бы типы задач, в которых стоит в первую очередь его пробовать.
    Например: Дробление — проблемы высокой связности (взаимозависимости), проблемы контроля.

    CE>
  • Map-Reduce.

    Имеется ввиду параллелизация процессов? Это скорей инженерный приём, "в лоб".

    CE>
  • Вынесение. Вынесение части объекта.

    Не совсем понятно, чем отличается от дробления.

    CE>
  • Инкапсуляция. Внесение объекта внутрь другого объекта.

    Пересекается с термином из ООП, с ним не совпадая. Частный случай объединения.

    CE>
  • Оптимизация части.

    Оптимизация обычно почти всегда делается только "части".
    Для каких задач полезен этот приём? На ум приходит только задача сокращения времени разработки.
    (думаю, можно обобщить до "сделать только достаточный минимум")

    CE>
  • Универсальность.
    CE> a. Использовать стандартные библиотеки.
    CE> b. Использовать одни и те же алгоритмы для разных данных.
    CE> c. Использовать единые интерфейсы.

    Я бы назвал "Унификация". Унифицировать способы взаимодействия с разнородными сущностями.

    CE>
  • Предобработка.
    CE> a. В некоторых алгоритмах необходимо преобразовать данные, что влечет за собой снижение скорости и иногда создание дополнительного буфера. Можно исключить преобразование, обработав данные заранее.
    CE> b. Разбить поток байт на токены с помощью конечного автомата (или регулярных выражений).

    Классический приём "Сделать заранее". Зачем придумывать новое название?

    CE>
  • Хеширование.
    CE>
  • Подмена.
    CE> a. Можно подменить большие объекты заранее взвешенными весами, чтобы в дальнейшем обрабатывать не объекты, а их веса.

    Это, по-моему, перекликается с классическим "использовать копию объекта". Громоздкий объект подменяется лёгким для манипуляций подобием. Хеш-функция производит значение, идентифицирующее объект (или группу объектов меньшего масштаба, при коллизиях) — чем не "копия" из классического приёма ТРИЗ ?


    CE>
  • Обработка на месте.
    CE>
  • Непрерывность.
    CE> a. Сортировка при вставке.
    CE> b. Балансировка дерева при вставке.
    CE>
  • Еждевенчество.
    CE> a. Использование данных, сгенерированных в ходе работы другого алгоритма.
    CE> b. Посчитать и сохранить веса объектов в ходе обхода или сортировки.

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

    CE>
  • Периодичность.

    Не понятно. Можно примеры ? Или имеется ввиду что-то вроде "сделать потом", "размазать процесс во времени" ?

    CE>
  • Ленивость.
    CE> a. Сортировка при необходимости.

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

    CE>Параметры, вступающие в противоречие:


    CE>Память, Скорость, Сложность, Изменчивость, Неизменчивость, Транзакционность, Надежность, Масштабируемость


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

    Думаю, не меньшую пользу можно извлечь из применения других аспектов ТРИЗ к программированию. Лично я при проектировании программ извлекал пользу из:

    — Моделирование маленькими человечками
    — Теории развития систем
    — "9 экранов"
    — вепольного анализа
    (последние два под вопросом, помню, что использовал, не помню, успешно или нет)
    Думаю, список не полный — это то, что вспомнилось за 1 минуту.
  • Re[2]: ТРИЗ: устранение программных противоречий
    От: Critical Error ICQ: 123736611
    Дата: 05.02.09 22:50
    Оценка:
    Здравствуйте, dmp, Вы писали:

    dmp>Будет полезно. Однако приёмов чисто "программных" не так уж много, по моему опыту. Многое сводится к стандартным приёмам классической ТРИЗ. Возможно, более полезно был бы разбор классических (общих, не специфических) приёмов с примерами применения в области программирования. Плюс (конечно самое интересное) приёмы, специфические для программирования.


    Стандартные приемы из классического ТРИЗ конечно имеются (разбиение на части, универсальность, предобработка...) Я только лишь изменил названия для удобства использования.

    CE>> Дробление.

    CE>> Объединение.

    dmp>Просто приём ничего не даёт. Надо бы типы задач, в которых стоит в первую очередь его пробовать.

    dmp>Например: Дробление — проблемы высокой связности (взаимозависимости), проблемы контроля.

    Тут уже предложили разбить таблицу на две области: дизайн кода и работа с данными. Так вот эти два приема тоже необходимо разбить на две части: дробление данных и дробление кода (мб. декомпозиция?), объединение данных (аггрегация?) и объединение кода.

    CE>> Map-Reduce.


    dmp>Имеется ввиду параллелизация процессов? Это скорей инженерный приём, "в лоб".


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

    CE>> Вынесение. Вынесение части объекта.


    dmp>Не совсем понятно, чем отличается от дробления.


    Тем, что это прием работы с кодом. Варианты названия этого приема: Декомпозиция или Вынесение.

    CE>> Инкапсуляция. Внесение объекта внутрь другого объекта.


    dmp>Пересекается с термином из ООП, с ним не совпадая. Частный случай объединения.


    Коненчо же это моя ошибка. Скорее уж Аггрегация или Объединение данных (более свободный термин, так как способ аггрегации только один, а Объединение можно делать по разному).

    CE>> Оптимизация части.


    dmp>Оптимизация обычно почти всегда делается только "части".

    dmp>Для каких задач полезен этот приём? На ум приходит только задача сокращения времени разработки.
    dmp>(думаю, можно обобщить до "сделать только достаточный минимум")

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

    CE>> Универсальность.


    dmp>Я бы назвал "Унификация". Унифицировать способы взаимодействия с разнородными сущностями.


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

    CE>> Предобработка.


    dmp>Классический приём "Сделать заранее". Зачем придумывать новое название?


    Я пытался сократить стандартные имена до одного слова. Так легче использовать таблицу. Но можно и оставить "Сделать заранее".

    CE>> Хеширование.

    CE>> Подмена.

    dmp>Это, по-моему, перекликается с классическим "использовать копию объекта".


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

    CE>> Обработка на месте.

    CE>> Непрерывность.
    CE>> Еждевенчество.

    dmp>Это ближе к чисто-программистским приёмам, хотя тут прослеживается классический принцип "использовать в первую очередь ресурсы внутри системы"


    Совершенно верно.

    CE>> Периодичность.


    dmp>Не понятно. Можно примеры ? Или имеется ввиду что-то вроде "сделать потом", "размазать процесс во времени" ?


    Не совсем, имеется в виду например задачи по таймеру (например отправка изменений в БД раз в сутки или автосохранение).


    dmp>Не вижу практической пользы в составлении списка параметров. Он может быть очень большим, и в действительности, зависит от задачи. Привязка к конкретным параметрам уменьшает обобщённость приёмов и сужает спектр их действия (ограничивает мышление)


    Да, тут надо не спешить, список параметров будет составлен при составлении самой таблицы на последней стадии.

    dmp>Думаю, не меньшую пользу можно извлечь из применения других аспектов ТРИЗ к программированию.


    Естественно. Только этим занимаются другие люди. Я же решил заняться конкрено таблицей. Очень уж она меня впечетлила по части эффективености.
    Re[3]: ТРИЗ: устранение программных противоречий
    От: dmp  
    Дата: 06.02.09 03:54
    Оценка: +1
    Здравствуйте, Critical Error, Вы писали:

    CE>Тут уже предложили разбить таблицу на две области: дизайн кода и работа с данными. Так вот эти два приема тоже необходимо разбить на две части: дробление данных и дробление кода (мб. декомпозиция?), объединение данных (аггрегация?) и объединение кода.


    Т.к. приёмы для кода и данных пересекаются, считаю нужно в конкретном приёме всегда иметь ссылку на более общий (или хотя бы "приём для кода" + ссылка на "приём для данных"). Либо общий список приёмов с конкретизацией: вот так — для кода, а так — для данных.

    CE>>> Map-Reduce.


    dmp>>Имеется ввиду параллелизация процессов? Это скорей инженерный приём, "в лоб".


    CE>Ну тут я скорее имел в виду не параллельную обработку, а простую комбинацию из Дробления данных, обработки частей и Объединения. Это прием работы с иданными.

    А для кода ? Дробление большой задачи и выполнение подзадач командой ?

    CE>>> Хеширование.

    CE>>> Подмена.

    dmp>>Это, по-моему, перекликается с классическим "использовать копию объекта".


    CE>По той же причине. Укорочение имен. Копией я бы эти приемы называть не стал, потому как сбивает с толку. Опирация копирования в программировании четко определена. Потому принцип копирования я решил разбить на два принципа: Хэширования и Подмены.


    А вот подходящий термин — проекция. Суть отражает, при этом термин можно трактовать довольно широко.

    CE>>> Периодичность.


    dmp>>Не понятно. Можно примеры ? Или имеется ввиду что-то вроде "сделать потом", "размазать процесс во времени" ?


    CE>Не совсем, имеется в виду например задачи по таймеру (например отправка изменений в БД раз в сутки или автосохранение).


    Ну как раз и размазывается процесс во времени.
    Re: ТРИЗ: устранение программных противоречий
    От: FR  
    Дата: 08.02.09 05:14
    Оценка:
    Здравствуйте, Critical Error, Вы писали:

    CE>Хочу вернуться к тематике применения ТРИЗ в разработке программного обеспечения.


    В первый раз о том как триз полностью изменит программирование и поднимет его на недосягаемую до
    этого высоту я читал в 1991 году. За это время ничего ни изменилось
    Re[2]: ТРИЗ: устранение программных противоречий
    От: dmp  
    Дата: 08.02.09 10:50
    Оценка:
    Здравствуйте, FR, Вы писали:

    FR>Здравствуйте, Critical Error, Вы писали:


    CE>>Хочу вернуться к тематике применения ТРИЗ в разработке программного обеспечения.


    FR>В первый раз о том как триз полностью изменит программирование и поднимет его на недосягаемую до

    FR>этого высоту я читал в 1991 году. За это время ничего ни изменилось

    То, что кто-то имел завышенные ожидания по поводу этого набора методик, никак не умаляет его полезности лично для меня. За время, которое я знаком с ТРИЗ (примерно 15 лет), пользы мне это знакомство принесло много.
    Поэтому я считаю попытки адаптировать методики к сфере software engeneering достойными внимания.

    Critical Error, как я понял, тоже не ставит каких-то амбициозных задач, а хочет получить удобный инструмент впервую очередь для себя.
    Re[3]: ТРИЗ: устранение программных противоречий
    От: FR  
    Дата: 08.02.09 15:00
    Оценка: +1
    Здравствуйте, dmp, Вы писали:

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


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

    dmp>Поэтому я считаю попытки адаптировать методики к сфере software engeneering достойными внимания.


    Все попытки адаптации пока дали практически нулевой выхлоп.
    По моему есть какая то принципиальная несовместимость ТРИЗА с программированием и проектированием программ.
    Все кроме общих принципов (типа эволюции систем и надсистем) или не работает в нашей области или дает очень скромные и протеворечивые результаты (это мнение у меня сложилось во многом из обсуждений ТРИЗ здесь на RSDN http://www.rsdn.ru/forum/message/1790637.flat.1.aspx
    Автор: Кирилл Лебедев
    Дата: 18.03.06
    http://www.rsdn.ru/forum/message/2516100.flat.1.aspx
    Автор: borisman3
    Дата: 06.06.07
    )
    Re[4]: ТРИЗ: устранение программных противоречий
    От: dmp  
    Дата: 08.02.09 16:27
    Оценка:
    Здравствуйте, FR, Вы писали:

    FR>Я тоже тогда зачитывался книжками Альтшулера, у него интересная философия, но практической пользы (ну не изобретатель я) не увидел.


    Практическая польза из личного опыта:

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

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

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

    После формулировки противоречия сразу вылезло решение — передавать пакет некритичного только вслед за критичным. На практике такое решение не показало желаемой производительности.

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

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

    Из этого сразу стало очевидным решение — приклеивать данные некритичного траффика к критичному, скорость некритичного регулировать размером этого приелеенного "хвоста" и количеством пакетов критичного в секунду.

    Это решение оказалось рабочим, и было воплощено в жизнь.

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

    FR>Все попытки адаптации пока дали практически нулевой выхлоп.

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

    FR>По моему есть какая то принципиальная несовместимость ТРИЗА с программированием и проектированием программ.

    FR>Все кроме общих принципов (типа эволюции систем и надсистем) или не работает в нашей области или дает очень скромные и протеворечивые результаты (это мнение у меня сложилось во многом из обсуждений ТРИЗ здесь на RSDN http://www.rsdn.ru/forum/message/1790637.flat.1.aspx
    Автор: Кирилл Лебедев
    Дата: 18.03.06
    http://www.rsdn.ru/forum/message/2516100.flat.1.aspx
    Автор: borisman3
    Дата: 06.06.07
    )


    Осуждаемые там статьи я бегло читал, не впечатлился.
    Re[5]: ТРИЗ: устранение программных противоречий
    От: FR  
    Дата: 09.02.09 03:24
    Оценка:
    Здравствуйте, dmp, Вы писали:

    dmp>Здравствуйте, FR, Вы писали:


    FR>>Я тоже тогда зачитывался книжками Альтшулера, у него интересная философия, но практической пользы (ну не изобретатель я) не увидел.


    dmp>Практическая польза из личного опыта:


    Я ничего ни имею против ТРИЗ'а как философии или способа мышления (как разновидности диалектического мышления). Мне в свое время он тоже помог осознать некторые вещи, например то, что когда я решаю сложные задачи, мое мышление вполне описывается ТРИЗ'овскими экранами. То есть общие их положения (многие из них из области психологии творческого мышления) конечно вполне применимы везде где требуется такое мышление.
    Но ТРИЗ меня просто поразил своей сверхэффективностью в своей первоначальной сфере применения, там он без всяких скидок и "панация" и "серебрянная пуля". Во воторой раз он меня проразил тем, что в других сферах включая и программирование, он малоэффективен.
    Re[6]: ТРИЗ: устранение программных противоречий
    От: dmp  
    Дата: 09.02.09 03:54
    Оценка:
    Здравствуйте, FR, Вы писали:

    FR>Но ТРИЗ меня просто поразил своей сверхэффективностью в своей первоначальной сфере применения, там он без всяких скидок и "панация" и "серебрянная пуля". Во воторой раз он меня проразил тем, что в других сферах включая и программирование, он малоэффективен.


    Как любое специализированное решение, он наиболее эффективен в той области, для которой создавался. Эффективность в других сферах оценить не могу, не имею достаточной статистики. Могу говорить только субъективно — для меня эффект есть, незначительным его я бы не назвал. При этом основная моя область деятельности — программирование. То, что никто не приложил достаточно усилий для создания хорошей специализированной методики на основе ТРИЗ для поиска решений в области программирования не значит, что этим заниматься не нужно. Те попытки, которые я видел — были очень поверхностные и узкие. Можно глубже и щире.
    Re[7]: ТРИЗ: устранение программных противоречий
    От: FR  
    Дата: 09.02.09 04:20
    Оценка:
    Здравствуйте, dmp, Вы писали:

    dmp>Как любое специализированное решение, он наиболее эффективен в той области, для которой создавался. Эффективность в других сферах оценить не могу, не имею достаточной статистики. Могу говорить только субъективно — для меня эффект есть, незначительным его я бы не назвал. При этом основная моя область деятельности — программирование.


    По предыдущим обсуждениям у меня сформировалось мнение что традиционные для программировании методики намного эффективнее чем ТРИЗ.

    dmp>То, что никто не приложил достаточно усилий для создания хорошей специализированной методики на основе ТРИЗ для поиска решений в области программирования не значит, что этим заниматься не нужно. Те попытки, которые я видел — были очень поверхностные и узкие. Можно глубже и щире.


    А мне кажется что специализация ТРИЗ в программировании будет еще одной малоэффективной методикой
    Re[8]: ТРИЗ: устранение программных противоречий
    От: dmp  
    Дата: 09.02.09 09:06
    Оценка:
    Здравствуйте, FR, Вы писали:

    FR>По предыдущим обсуждениям у меня сформировалось мнение что традиционные для программировании методики намного эффективнее чем ТРИЗ.


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

    Буду рад узнать источники, где описаны такие методики.
    Re[9]: ТРИЗ: устранение программных противоречий
    От: FR  
    Дата: 09.02.09 11:59
    Оценка:
    Здравствуйте, dmp, Вы писали:

    dmp>Я не знаю методик (специфичных для программирования) для поиска новых нестандартных решений.


    А нет таких формальных методик вообще. Это область психологии.
    ТРИЗ тоже не является такой методикой, он просто для узкой области смог формализовать решение
    задач уровня 1 — 2 и частично 3 (по ТРИЗ'овской классификации http://www.treko.ru/show_article_549 ) а для уровней 4 — 5 дает универсальный, совершенно не технический рецепт, развивать творческое мышление. Ну и плюс конечно что он помогает это мышление в какой-то степени развить.

    dmp>Не пытаюсь приуменьшить важность стандартных решений — это база. А вот для случаев, когда стандартные решения не работают — лучшее что встречал в книгах — отдельные несвязанные методы.


    Тот же универсальный рецепт развивать мышление
    Re[10]: ТРИЗ: устранение программных противоречий
    От: dmp  
    Дата: 09.02.09 18:35
    Оценка: 1 (1)
    Здравствуйте, FR, Вы писали:

    FR>Здравствуйте, dmp, Вы писали:


    dmp>>Я не знаю методик (специфичных для программирования) для поиска новых нестандартных решений.


    FR>А нет таких формальных методик вообще. Это область психологии.

    FR>ТРИЗ тоже не является такой методикой, он просто для узкой области смог формализовать решение
    FR>задач уровня 1 — 2 и частично 3 (по ТРИЗ'овской классификации http://www.treko.ru/show_article_549 ) а для уровней 4 — 5 дает универсальный, совершенно не технический рецепт, развивать творческое мышление. Ну и плюс конечно что он помогает это мышление в какой-то степени развить.

    Ну вот есть набор методов, которые описывают, в какую сторону думать, предлагают абстракции для представления задач. Есть набор рекомендаций, как этими методами пользоваться. Как подходить к задаче, какой метод использовать в первую очередь итд. Причём при следовании этим рекомендациям у меня получается находить эффективные решения, которые до этого найти не получилось. Т.е решения не стандартные — стандартные пробуются в первую очередь. Я считаю, что такой набор методов и правил вполне можно назвать методикой. Так как с ней удаётся больше, чем без неё — считаю её эффективной.

    Решения, о которых я говорю — совсем не обязательно что-то супер-новое. Чаще как раз уровень 2.
    Решения от того, как построить архитектуру программной системы, до того, как найти особо упрямый баг.
    Естественно, я не чётко следую "классической" ТРИЗ, что-то делаю "по чутью", использую методы
    из других источников. Но в целом получается что-то по мотивам ТРИЗ. Если для меня это работает, не вижу причин, почему это не может работать для других.

    Касательно других методов поиска решений — я попытку описания таких методов в применении к программированию видел у Д. Бентли в "Programming Pearls" и у Leo Brodie в "Thinking Forth". Некоторые явно перекликались с имеющимися в ТРИЗ, однако между собой никак не связывались.
    Re[2]: ТРИЗ: устранение программных противоречий
    От: LaptevVV Россия  
    Дата: 14.02.09 09:19
    Оценка: +1
    Здравствуйте, netch80, Вы писали:

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

    Учебник по ТРИЗ — это где можно найти? Весьма буду благодарен за ссылку.
    Про сайт ТТРИЗ знаю и читал, а вот учебника не встречал.
    Книжку Альтшулера "Творчество как точная наука" тоже встречал, но не читал. Читал последователей. Половинкина, например.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
    Re[3]: ТРИЗ: устранение программных противоречий
    От: netch80 Украина http://netch80.dreamwidth.org/
    Дата: 14.02.09 10:49
    Оценка:
    Здравствуйте, LaptevVV, Вы писали:

    LVV>Здравствуйте, netch80, Вы писали:


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

    LVV>Учебник по ТРИЗ — это где можно найти? Весьма буду благодарен за ссылку.
    LVV>Про сайт ТТРИЗ знаю и читал, а вот учебника не встречал.
    LVV>Книжку Альтшулера "Творчество как точная наука" тоже встречал, но не читал. Читал последователей. Половинкина, например.

    http://www.ozon.ru/context/detail/id/4172335/
    подходит это под Ваше определение учебника или нет?
    The God is real, unless declared integer.
    Re[4]: ТРИЗ: устранение программных противоречий
    От: LaptevVV Россия  
    Дата: 14.02.09 12:45
    Оценка:
    Здравствуйте, netch80, Вы писали:

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

    LVV>>Учебник по ТРИЗ — это где можно найти? Весьма буду благодарен за ссылку.
    LVV>>Про сайт ТТРИЗ знаю и читал, а вот учебника не встречал.
    LVV>>Книжку Альтшулера "Творчество как точная наука" тоже встречал, но не читал. Читал последователей. Половинкина, например.

    N>http://www.ozon.ru/context/detail/id/4172335/

    N>подходит это под Ваше определение учебника или нет?
    Cпасибо! Там же есть еще несколько аналогичных.
    Хочешь быть счастливым — будь им!
    Без булдырабыз!!!
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.