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

Существует одна проблема с этим методом. Какова область его реального применения? Как оценить сколько таких типовых функциональных блоков (т.е. таких блоков для которых могут быть заранее написаны спецификации вход/выход) в современных программах?

Поэтому вопрос родился конкретный вопрос к местному комьюнити:

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

Вопрос несколько абстрактный, но иначе пока сформулировать не могу.

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

C>Я работаю над диссертацией посвященной проблемам анализа программного кода. В ходе работы родился метод, предназначенный для вероятностного распознования типовых функциональных блоков по заданной спецификации вход/выход. Метод предполагает, что человек задает на некотором специальном языке спецификацию функционального блока. Спецификация описывает отношения между входными и выходными данными характерными для определенного функционального блока. Все спецификации складываются в базу спецификаций. Затем специальная программа пробегает по анализируемому коду, и сравнивая фрагменты кода с базой спецификаций говорит, что в таких-то местах были распознаны такие-то функциональные блоки с вероятностью такой-то.

C>Существует одна проблема с этим методом. Какова область его реального применения? Как оценить сколько таких типовых функциональных блоков (т.е. таких блоков для которых могут быть заранее написаны спецификации вход/выход) в современных программах?

C>Поэтому вопрос родился конкретный вопрос к местному комьюнити:

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

C>Вопрос несколько абстрактный, но иначе пока сформулировать не могу.

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

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

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

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

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

C>Поэтому вопрос родился конкретный вопрос к местному комьюнити:

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

Уже и не помню, когда приходилось самому реализовывать подобный функционал.
Нужен стандартный функционал? Пользуйся стандартными библиотеками (например STL для С++).
Если есть какая-то новая вещь — кандидат на типовой функционал,
то проходит довольно много времени, чтобы осознать, что это действительно так,
и придумать типовое решение и типовые сценарии их использования.
Еще больше времени уходит на то, чтобы другие программисты тоже приняли это типовое решение
и действительно стали бы его использовать так, как задумано.
Автоматизировать тут что-либо бесполезно.
Нужно просто хорошо документировать и терпеливо объяснять другим,
что ты имел ввиду и что ты собственно предложил.

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

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

C>Да. Примерно такой функционал предоплагается. Например имеется некоторый уникальный алгоритм, при выполнении которого в качестве побочного эффекта достигается сортировка массива, получение максимального элемента массива и расчет факториала, то метод должен это все обнаружить. Он конечно не идентифицирует весь алгоритм в целом но укажет на то, что в этом месте программы наблюдается "симбиоз" таких-то функциональных блоков

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

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

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

C>Поэтому вопрос родился конкретный вопрос к местному комьюнити:

C>Насколько часто вы _реализуете_ (т.е. не берете говотые, а именно реализуете) в своих программах типовой функционал...

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

Пример: создать объект, заполнить поля, записать в БД.

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

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


B>Т.е. вы предлагаете метод, который позволял бы изобретателям велосипедов
B>находить в своем коде эти самые велосипеды? А смысл?
B>Лучше потратить силы на обучение.

Речь идет не совсем о велосипедных алгоритмах. Речь идет о типовых функциональных блоках попадающих под заданную спецификацию. Например существует некоторый очень уникальный алгоритм поиска чего-то где-то. В качестве входной информации алгоритм получает некоторый критерий подходящего результата K, а в качестве выходной информации получает объект a для которого K(a) = true или ничего. Не важно, что это за алгоритм, главное он попадает под спецификацию типового функционального блока поиска элемента. Конечно под это попадают и велосипеды, поскольку для них очень просто написать спецификацию. Мне просто интересно насколько часто в коде практикующих программистов встречаются такие типовые блоки для которых можно легко написать спецификацию вход/выход.

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

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

B>Можно, кстати, почитать о том, как именно вы делаете?

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

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

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


B>>Т.е. вы предлагаете метод, который позволял бы изобретателям велосипедов
B>>находить в своем коде эти самые велосипеды? А смысл?
B>>Лучше потратить силы на обучение.

C>Речь идет не совсем о велосипедных алгоритмах. Речь идет о типовых функциональных блоках попадающих под заданную спецификацию. Например существует некоторый очень уникальный алгоритм поиска чего-то где-то. В качестве входной информации алгоритм получает некоторый критерий подходящего результата K, а в качестве выходной информации получает объект a для которого K(a) = true или ничего. Не важно, что это за алгоритм, главное он попадает под спецификацию типового функционального блока поиска элемента. Конечно под это попадают и велосипеды, поскольку для них очень просто написать спецификацию. Мне просто интересно насколько часто в коде практикующих программистов встречаются такие типовые блоки для которых можно легко написать спецификацию вход/выход.

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

Единственное реальное применение вашего подхода, которое я вижу — это обучение студентов.
Тоже в общем нужная вещь.

C>А по поводу велосипедов. Не верю я, что большиство программистов постоянно придумывают новые и новые алгоритмы. Скорее всего берутся старые, хорошо известные алгоритмы, приемы, "хаки" и немного модифицируются под задачу. Стандартизовать и запихнуть в стандантные все возможные более или менее популярные алгоритмы очень трудно.

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

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

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

B>>Можно, кстати, почитать о том, как именно вы делаете?

C>Пока нельзя. Я еще не ученый, я только учусь Пока пытаюсь объяснить свою находку только себе и моему начуному руководителю. Возник вот такой вопрос. Если это успешно разрешится, то объязательно опубликую где-нибудь статью с описанием метода.

Понятно...
Такие вещи довольно тяжело обсуждать без конкретики.

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



C>Насколько часто вы _реализуете_ (т.е. не берете говотые, а именно реализуете) в своих программах типовой функционал.

Ну... Сказать, что всегда реализую нетиповой функционал (НТФ) — не могу, также, как и сказать, что реализую типовой (ТФ)... Точнее такой функционал, который является ТФ невозможно описать в виде вход-выход (например: GUI, запросы к базе данных и т.д.). А тот функционал, который можно описать в виде вход-выход является явно НТФ, точнее множество определенно последовательных вызовов ТФ. Последний раз я писал аля-сортировка на 3 курсе института, на олимпиаде, до этого только на первом, ибо во все современные языки уже включены эти функции с возможность указать, как сравнивать объекты. Просто наука программирования уже не может математически строго описать творчество программиста.
IMHO, сейчас для этих целей нужно создавать самообучаемый анализатор, который сможет найти не только алгоритмы по входу-выходу, а также типовые блоки кода (по синтаксической матрице и дереву) и паттерны вызовов и взаимодействий между различными модулями системы.

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

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


B>>Т.е. вы предлагаете метод, который позволял бы изобретателям велосипедов
B>>находить в своем коде эти самые велосипеды? А смысл?
B>>Лучше потратить силы на обучение.

C>Речь идет не совсем о велосипедных алгоритмах. Речь идет о типовых функциональных блоках попадающих под заданную спецификацию. Например существует некоторый очень уникальный алгоритм поиска чего-то где-то. В качестве входной информации алгоритм получает некоторый критерий подходящего результата K, а в качестве выходной информации получает объект a для которого K(a) = true или ничего. Не важно, что это за алгоритм, главное он попадает под спецификацию типового функционального блока поиска элемента. Конечно под это попадают и велосипеды, поскольку для них очень просто написать спецификацию. Мне просто интересно насколько часто в коде практикующих программистов встречаются такие типовые блоки для которых можно легко написать спецификацию вход/выход.

C>А по поводу велосипедов. Не верю я, что большиство программистов постоянно придумывают новые и новые алгоритмы. Скорее всего берутся старые, хорошо известные алгоритмы, приемы, "хаки" и немного модифицируются под задачу. Стандартизовать и запихнуть в стандантные все возможные более или менее популярные алгоритмы очень трудно.

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