Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Задела меня за живое фраза...
Спасибо, интересное изложение
К сожалению, на рсдн пост был воспринят не совсем верно — вместо обсуждения идеи — критика несущественных частей предполагаемой реализации. Попробуем исправить ситуацию
Итак,
обсуждаемая идея
Создание открытого универсального хранилища независимых кусочков кода (сниппетов), используя которые, можно легко собирать приложение как конструктор-лего
Вместо предисловия.
Материал для ознакомления.
Вооружившись базовым пониманием проблемы, попытаемся разобраться
Что же такое независимый кусочек кода?
Давай прикинем, как будут выглядеть сниппеты (обособленный кусочек) на практике.
Примеры
Начнем с самой простой штуки, знакомой с пятого класса
Класс отрезка на плоскости (segment2).
Реализовывать его целиком, смысла нет, поэтому опишем реализацию одного из обязательных алгоритмов — определение точки пересечения двух отрезков (метод intersect).
Возможное решение:
Проводим прямые через вершины отрезков, находим точку их пересечения (*) и проверяем, принадлежит ли она обеим отрезкам.
Стоп. Прямые проводить нельзя — это уже другой класс, а мы договорились избегать зависимостей. Workaround — вставляем код определения пересечения прямых прямо в тело метода intersect и натыкаемся на большую засаду — дублирование кода — один и тот же кусок кода придется использовать для каждой новой сущности — прямой, луча, ломанной, треугольника... Аналогичная ситуация для других алгоритмов.
Звезда синтаксического оверхеда померкла и превратилась в тусклую точку.
Еще один момент — мы не сможем написать код пересечения отрезка и прямой, ведь они локализованы и ничего не знают друг о друге.
Прошу заметить — помимо очевидного дублирования, раздутие кода вступает в конфликт с изначальным положением "окинуть весь код сниппета одним взглядом".
И на самом-то деле, выбор у нас небольшой — создавать связи между классами и отказывать от идеи независимости или дублировать код.
Поток (тот, который Thread)
Достаточно быстро бросается в глаза, что он может существовать только в контексте процесса, напрямую связан с критическими секциями и кучей других средств синхронизации. Термин поток просто не применим на практике в отрыве от других понятий предметной области.
Регэксп
Штука жутко распространенная, полезная и компактная — любое вменяемое регулярное выражение можно уместить в одну строчку.
Новая неприятность — реализацию регэкспов, вряд ли можно окинуть одним взглядом, да вдобавок, строятся они на конечных автоматах (КА), классе который, безусловно, также присутствует в нашей кодопедии — получаем неустранимую зависимость между сниппетами.
Еще одно важное замечание. В википедии можно записать — "базой для регэкспов являются КА", дать "висящую" ссылку, и кто-то добрый, позднее, составит статью КА. С кодом такой фокус не пройдет – для компилируемости и корректной работы регулярных выражений (и их тестов) необходим законченный конечный автомат.
Кроме того, как и каждую блестящую идею, кодопедию может запороть куча "бытовых" "мелочей" — подход к обработке ошибок, использование юникода и т.д. (рабочий код, решающий одинаковые задачи может сильно отличаться в зависимости от условий применения)
Почему же часто не получается выделить сниппеты?
Потому что код, описывающий некоторую предметную область, оперирует не одним единственным термином, а группой понятий полностью ее покрывающих.
Пардон, а как же википедия?
Открываем любую ссылку на
http://wikipedia.org, внимательно и пристально на нее смотрим минуту.
Оказывается, в вики нет ни одного независимого термина. На любой страничке можно увидеть кучу гиперссылок, направленных, как внутрь энциклопедии, так и вне ее (это интересный момент) — получается кодопедия в изначальной своей задумке, являла вовсе не аналог википедии, а ее полный антипод.
Более того, после некоторого размышления, приходим к очевидному выводу — действительно независимых кусочков кода, не так уж и много.
Неужели все так плохо?
Заметим одно — вовсе не нужно бежать от предметной области каждого сниппета, лучше воспринимать ее такой, какой она есть
, аки любимая женщина
со всеми достоинствами и недостатками.
Отложим пока этот вопрос немного на потом и посмотрим,
Что есть сейчас и как можно использовать чужие наработки?
А есть, на самом деле, многое
Как выглядит использование "совсем чужого кода" (**) на практике?
Ищется он (код) достаточно просто, хоть и тоскливо — запрос, определение релевантности результата, коррекция запроса… действо, как кажется, знакомое с младенчества.
Далее
анализ кода. Не только муторный, но и весьма утомительный процесс. Отбрасываются грязный исходный код, анализируется архитектура, решения конкретных проблем, стиль написания, оценивается возможность адаптации к своему проекту... Честно скажу, меня надолго не хватает — через три-четыре часа плотной загрузки, рабочий день заканчивается.
Дивиденды? Они есть и их много. Помимо того, что мы можем уточнить собственную задачу и лучше въехать в тему, в ход можно отправить если не все, то многое — части кода (иногда и правда, целые классы), названия методов, функций и переменных (вопрос о компактном, красивом и точном имени чего угодно не оставит безучастным ни одну душу ), архитектурные решения, способы обхода возникавших проблем, тонкости реализации, наконец полезными могут оказаться просто ссылки в коде на онлайн-документы. В результате, получаем приличную экономию время и силы.
Вывод: банален до безобразия и знаком с первого курса — применять чужой код можно и нужно.
Что мешает искать и использовать чужой код?
Беда кроется как минимум в трех объективных причинах — отсутствии приличной каталогизации, качественной документации (здесь появляется некоторая, тонкая связь с
Doxygen, JavaDoc со товарищи...Автор: c-smile
Дата: 25.09.05
, но об этом попозже ) и неопределенная надежность.
Объективная сложность поиска.
Тратить несколько часов на поиск и просеивание чужого кода — не самое приятное времяпровождение (да и успех не гарантирован).
Однако, допустим, во время наших поисков было найдено решение, вроде бы подходящее для нашей задачи, но станем ли мы использовать его? Большой вопрос.
Чем определяется степень доверия чужому коду.
Отзывы и использование в других проектах.
Степень покрытия, и качество юнит-тестов
Документация
Время без крупных правок. Косвенно говорит о стабильности кода. (естессно, тут идет речь о постоянно используемом коллегами коде, а не трех строчках положенных на http://sf.net пять лет назад анонимом)
Если все условия выполняются, то почему бы и нет — такому коду вполне можно доверять. Но таких сниппетов, увы, встретится весьма немного.
Что больше всего отпугивает программиста в чужом решении?
Неизвестны условия использования автором и применимость к текущим условиям.
Попросту говоря, когда мы открываем чужой исходник, остается только догадываться какими мотивами руководствовался автор при написании своего детища, соответственно мы не можем сказать, а подойдет ли это решение нам.
Ограничения по используемым технологиям и особенностям языка, стиль разработки и оформления кода, exception safety и миллион других вопросов — на всех них можно получить ответы только одним способом — тщательно проанализировав
весь код. Как правило, это более чем утомительно, более того, исследовать кучу сниппеттов, а потом прийти к выводу, что ни один тебе не годится — весьма печально, именно отсюда растут корни велосипедостроения.
Чего хотелось бы видеть в документации?
(помимо one-minute description, five minute introduction, ten minute tutorial и проч клиентского стаффа — сейчас разговор только про кодопедию)
Для решения какой проблемы был создан код. Четкое перечисление используемых технологий, сторонних библиотек и возможностей языка. Обязательно, ссылки на предметную область и дискуссии по поводу архитектуры (здесь важным становится критика, и четко очерченная область применения); альтернативные реализации сниппета, их качественное сравнение.
Т.е. прежде всего, документация должна отвечать на вопрос
"почему?"
Наличие такой подробной документации требуется для нескольких целей — понизить требуемый уровень добровольца для вхождения в проект, упростить внесение изменений и наконец, четко показать клиенту кодопедии, а подойдет ли ему этот сниппет, а если даже нет — то в какую сторону потребуется двигаться, чтобы адаптировать его под свои нужды.
Пример такой документации можно посмотреть
здесьАвтор(ы): Сергей Сацкий
Дата: 24.06.2003
С помощью конечных автоматов можно успешно решать обширный класс задач. Это обстоятельство подмечено давно, поэтому в литературе по проектированию программного обеспечения часто приводятся рассуждения на тему примененения автоматов. Однако в процессе моделирования автомат рассамтривается с более высокого уровня, нежели это делается в момент его реализации с использованием конкретного языка программирования.
А простой пользователь может и вовсе никогда не заглядывать в эти дискуссии — они ему попросту не нужны.
Индустрия давно уловила это веяние — поэтому и появились форумы подобные rsdn или тематические ньюз-группы, более того сейчас эта идея активно развивается — целью некоторых новых проектов является не только хранение кода, но и его обсуждение "где-то рядом" — например Trac, отчасти
Каким должен быть сайт сообщества будущего?Автор: AlexanderLozhechkin
Дата: 25.08.05
.
Итак, что же требуется для решения проблем?
Категоризация. Документирование.
Кто и как будет заниматься их решением? Кто угодно — код и документация могут свободно редактироваться. Пример вики показывает, что этот прием работает.
Чем в итоге получился сниппет?
А вот не знаю
Ясно одно — принцип "окинуть весь код сниппета одним взглядом" можно будет применить не всегда.
Нужны ли юнит-тесты?
Имхо, это краеугольный камень, на котором будет держаться весь проект, решающий помимо прочего три задачи:
поддержание кода в работоспособном состоянии
антивандализм
повышение степени доверия
Но
Честно говоря, с большим скепсисом отношусь к юнит тестам в качестве способа документирования – в самом деле, посмотрим на
MultiByteToWideChar — вполне себе сниппет (хоть и на костылях). Возможно, не белый, компактный и пушистый
, это уж звиняйте, зато рабочий и используемый (
Пусть кричат "Уродина!" А она нам нравится! Хоть и не красавица!Автор: SchweinDeBurg
Дата: 11.12.04
) Рискну предположить, что юнит-тест для такой функции будет иметь весьмааа нехилый размер.
Так вот, если построить в длинную очередь тех, кто будет шарахаться от изучения сниппетов по таким чудным тестам –
Зверёк окажется в первой тройке и будет ругаться за то, кто должен идти первым
К сожалению, юнит-тесты не идеальное средство для тестирования кода, а иногда их и вовсе невозможно использовать. Простейший пример — сниппет проигрывающий звук с постепенным понижением громкости.
Резюмируя — тема тестирования открыта для новых идей.
Очень не хочется об этом говорить, но не сказать нельзя.
Пять тонн хрусталя отличной идеи падает с высоты километра, — необходимо определить, по какой лицензии будет распространяться код (больше писать ничего не буду)
Вывод.
Его пока нет
Обсуждаем
Пожалуй, все. Хотя, нет.
То, что обсуждалось в дискуссии и не вошло в этот пост.
Реализация. Wikipedia или VСS? Вопрос слишком ранний — какая разница, как — текст можно отредактировать в блокноте или вики (естессно, онлайн эдитор предпочтительнее и в идеале должен быть именно он), но пока разговор об идее. Прочие вопросы по реализации — двадцать пятые и тридцать седьмые — пинаем их ногами в конец очереди.
Как быть с наличием нескольких языков? Проще, чем кажется. Как и в википедии, каждому языку — своя площадка. Пусть никто не уйдет обиженным
(c).
Что необходимо для запуска проекта?
Удачная базисная технология — как вики для редактирования текста. Большое стартовое кол-во добровольцев и несколько стабильных лидеров. Возможно, что-то еще — пока об этом рано говорить.
Была еще пара мыслей, но они вылетели из головы раньше, чем успел их записать
Вот. Теперь точно все.
Спасибо.
(*) для простоты, случаи совпадения и параллельности прямых, не рассматриваем.
(**) для педантов. Совсем чужой код – тот, который мы получили не от коллег по работе, организаций-партнеров или извлекли из известных библиотек, а от совершенно неизвестного лица. Степень доверия и качества кода — неопределенная.
PS
http://codepedia.com/ 
) и рсдн-овский трафик в дальнейшем 