M>>Недавно было специально выделено время на очистку кода этого самого багтрекера. Не мудрствуя лукаво весь яваскрипт перевели на jQuery. Тот же код (по логике) неожиданно стал работаь во всех браузерах, заявленных на сайте jQuery 
Фирма сэкономила время на тестах, программисты сэкономили нервы. Все довольны
Z>A если бы "неожиданно" не стал работать? Сколько лет вы бы ещё дожидались чужого дядю, который вам скрипт к опере привяжет?
Еще раз цитирую.
Из всего этого следуют Правила большого пальца:
1. Все, что можно купить, нужно покупать (cюда же входит подбор бесплатных компонентов, при их наличии)
2. Все, что нельзя купить, нужно аутсорсить
3. Нельзя аутсорсить "core" — то, за что тебе платят деньги.
По пункту 1:
1. Определиться с основными требованиями к решению. Как правило, происходит на этапе написания SRS, который, вообще говоря, не зависит от того, собственный будет велосипед или готовое решение.
2. Пойти в инет и выбрать некоторое количество решений-кандидатов.
Это делается при помощи Google; как правило более 4х часов на поиски отводить смысла нет. Иногда, в особо запущенных случаях (не удается подобрать хороший запрос для гугла) кидается вопрос в тематический форум(ы). Это удешевляет данный шаг, но делает его дольше (надо дать хотя бы неделю, чтобы завсегдатаи ответили)ю
3. Полученный на предыдущем шаге список просеивается на предмет получения двух-трех кандидатов, которые похожи на то, что надо. Как правило, на это достаточно 8 часов
4. Для отобранных финалистов достаются демы/триалы, и выполняется некоторый набор тестов для проверки п.1. Опять же, жедательно ограничить это дело максимум 8 часов на кандидата.
5. По результатам отбирается лучший вариант. Он и идет в проект — покупается необходимая лицензия и в бой.
Примечания:
— если на шаге 4 ни один из финалистов не выдержал испытания, то надо вернуться на шаг 3 и выбрать других.
— если на шаге 3 не удалось ничего найти, возвращаемся на шаг 2.
— если и здесь нас ждет облом, заключаем, что выхода нет и пишем свой велосипед.
В большинстве случаев, мы получаем готовый результат за одну рабочую неделю одного разработчика. Возможны, конечно, варианты:
1. Если ищется готовое решение для большой проблемы, то имеет смысл умножить оценки для этапа 4 на эмпирический коэффициент.
2. Если ищется какая-нибудь экзотика, то нужно увеличить оценки для этапа 2, т.к. гугл хорошо ищет только популярный контент.
3. В некоторых случаях имеет смысл не делить на шаги, а делать "поиск с возвратами": пытаться зайти как можно дальше с каждым из вариантов, возвращаясь назад в случае обнаружения нерешаемой проблемы. Симптомы того, что у вас и есть некоторый случай:
— не требуется выбрать самое лучшее решение. Достаточно удовлетворительного.
— рынок завален готовыми решениями, и анализ всего списка будет потерей времени.
Если бы не заработал jQuery, взяли бы mochikit, dojo или prototype. Не подошел бы ни один из них, то только тогда начали бы писать что-то свое.
Z>Я на самом деле рад, что jQuery вам там помог, раздражает то, что это объясняется невероятными способностями jQuery чудесного свойства, пусть бы они там и были.
Где я это объясняю "невероятными способностями jQuery чудесного свойства"?
Z>Я это вижу по-другому. Сначала вы набираете себе проектов по горло, затем разводите там свои зоопарки, с которыми не можете совладать, потом единый подход вырабатывать не хотите, к тому же ещё ошибки долго-долго поймать не получается... и в таком вот загнанном вспененном состоянии как-то само собой сразу тянет поэкономить время/деньги/нервы и тому подобное.
Добро пожаловать в реальный мир. Програмисту платят за выполненый проект. И почти никогда этот проект не включает в себя разработку чего-то стороннего (как таким является разработка собственного js-фреймворка или сведение в один кучи js-кода от различных программистов).
Z>В этом нет ничего плохого, вам было худо, вам дали таблетку, и вас отпустило. Только не надо всех поголовно считать больными и совать им в рот лекарство. Если кому-то вообще не нужна таблетка jQuery или она им нужна исключительно в наиболее тяжёлых случаях, то это и есть адекватный/оптимальный/точечный подход за который я и выступаю, в этом стиле и сам язык спроектирован. Если можешь, то сделай сам. А не можешь, то остаётся только верить в: "бросайте писать свой уродский "чистый javascript", идите в нашу церковь "другого чистого javascript-a", тут тепло и сухо" (цитата вымышлена).
Я считаю, что всех веб-программистов надо обязательно подвергать двух-годичному прикладному программированию. Тогда желание писать все ручками сильно поубавилось бы
AKS>>>Zeroglif предложил целую кучу различных вариантов развития этой темы в конструктивном ключе — выбирайте на свой вкус!
M>>Не вижу. Последний конструктив бы в http://rsdn.ru/forum/message/2616848.1.aspxАвтор: Zeroglif
Дата: 10.08.07
и в http://rsdn.ru/forum/message/2617158.1.aspxАвтор: AKS.
Дата: 10.08.07
. Все остальное сводилось к "а ведь ручками в 10-30 строчек кода легче было" без единого аргумента
Z>Если под конструктивом подразумевается то, что я буду тешить тебя кодом на каждый чих, то во-первых строках моего письма в этом было отказано.
Но именно это ты и предлагаешь. Все, что от тебя было услышано (кроме вопроса по isFunction) — это "а на JS это делается в 5-10 строчек и быстрее"
Z>Да и потом смотри, я говорил о том, что не javascript плох и сложен, а где-то на уровне программистов проблема, в которой не каждый и признается. И опа, мои слова подтвердил один из собеседников (мало времени, много проектов и т.п.), спасибо ему за это.
Это программерская реальность.
Z>Я говорил, что чужую библиотеку нужно знать очень хорошо, иначе можно напороться, потому что это javascript, и опа, ты же сам это и подтвердил, показав своё незнание всего одной простейшей функции из либы, и объясняя мой пример цитатами из ECMAScript, да ещё и не к месту. Какие аргументы. Они сами собой рисуются, я не виноват.
Ок. В том примере я был неправ, что и признал. На работу библиотеки это никак не влияет. Что дальше?
M>>Встроенные объекты не рекомендуется расширять, потому что нарушается работа с этими элементами (например, JavaScript “Associative Arrays” Considered Harmful)
Z>Полностью с тобой согласен. Не с тем, что прототип нельзя расширять, наоборот, можно, для этого делегирование и вшито в javascript, чтоб нам было удобно,
Прототипы _встроенных_ объектов (типа Array) расширять не рекомендуется. По одной простой причине, что это нарушает работу с такими объектами.
Z>а согласен с тем, что даже "наискосок" сразу находятся проблемки. Где угодно. И в тултипе этом, и в jQuery, и тем более в плагинах к ней и т.д. и т.п. Любая либа, как и любой код на javascript местами "fragile", ты же сам это подтверждаешь.
Так чем же jQuery в этом плане отличается от самописной либы?
M>>Вторая проблема. Обожаю, когда экономят два-три байта и называют это оптимизацией. Названия функций t, c, g, m просто таки говорят сами за себя.
Z>Это ничем не отличается от пакнутой jQuery, код маленький, отдельный модуль, разобраться не составляет никакого труда, если не требуется соблюдение своих правил написания, то каждый себе хозяин.
Это полностью отличается от пакнутой jQuery — на то она и пакнутая.
M>>В общем, неважно. На простеньком документе:
M>>M>><div title="test tooltip">test tooltip</div>
M>><!--и еще 34 таких же дива, всего 35 штук-->
M>>
M>>этот скрипт выдал мне 31.25 миллисекунд, 287 вызовов
M>>То же самое с jQuery дало мне 62.5 миллисекунд, 1064 вызовов.
M>>Если мне надо будет использовать _только_ тултип на странице, я, быть может, возьму предложенный скрипт. Если мне понадобится хоть какая-то еще дополнительная функциональность, я возьму jQuery
Z>Согласен, но я бы сказал так:
Z>если я могу написать такого рода модуль — напишу сам, если не умею писать — выберу себе чужой модуль, если мне нужно много-много функциональности — напишу сам, если не умею или меня загрузили по уши — возьму чужую либу. А если бы меня после этого попросили написать что-нибудь хорошее о jQuery, то, если я её взял от неумения — ничего бы не писал, стыдно, если я её взял, потому что меня загрузили по уши — тоже ничего бы не писал, нет времени на это , но если бы ход времени замедлился, то я бы написал о jQuery много хорошего, но точно не стал бы её противопоставлять javascript, как таковому, стыдно, а просто рекомендовал бы её по причине удобства тем, кому как и мне не дали времени, чтобы сделать нужную работу самому...
Я и не противопоставляю jQuery ничему. Блин, взяли выдумали себе проблему
Вся статья говорит о том, как легко, удобно и приятно работать с jQuery.
Z>p.s. И кстати, вся эта ветка (за исключением моих тупейших постов, конечно) лично для меня необычайно конструктивна, я в некоторой степени скорректировал свою позицию в отношении javascript вообще и либ, в частности, это интересно.
И в какую сторону?
