Здравствуйте, IB, Вы писали:
IB>В том-то и дело, что для C++, для C# вы так и не смогли привести ни одного убедительного сценария.
Тебе уже сто раз сказали, удобство важнее твоих фантиков.
Давай поставим вопрос ребром, зачем ты вообще решил увеличивать инкапуляцию? Ради упрощения поддержки? Ладно, я согласен, поддержка упростилась. Зачем тебе упрощать поддержку? Да всё очень просто, чтобы разработка стала дешевле. То есть конечно можно считать разного рода рейтинги, проводить аналитику, строить весёлые разноцветные графики, но это не цель, это средство. Все эти механизмы это жалкая (именно так!) попытка найти зависимость между структурой кода и ценой проекта. Попытка жалкая, но механизмов лучше пока нет.
Всё что выше не просто очевиданя правда, это вообще не специфично для C#, .Net, императивных языков или ООП. Это верно для Си, это верно для Ерланга, это, просто напросто, верно вообще для разработки проограммного обеспечения. Для любого производства где правильной организацией труда пытаются удешевить конечный продукт.
Теперь о главном. Жадный алгоритм не работает. Совсем. Оптимизировав цену каждого модуля в отдельности ты не получишь в итоге самый дешёвый проект. Причина тому проста — разные модули повторно используются разное количество раз и в разном объёме: некоторые вообще не используются повторно, а некоторые десятки раз. Стоимость функционала в библиотеке — это конечная стоимость, конечная стоимость функционала вне библиотеки — сумма стоимостей во всех приложениях. Это очевидная истина. Потому и пишут библиотеки, чтобы удешевлять, чтобы создать дорогой код, цена которого рассется по всем использующим его проектам.
Есть менее очевидные моменты, касающиеся даже не кода, а интерфейса в обощённом смысле. Разные библиотеки покрывающий один и тот же функционал не идентичны при использовании. У них разный интерфейс, какой-то удобнее (и дешевле в применении), какой-то менее очевиден и удобен. Конечно можно удешевить библиотеку оставив MiddleString внутри класса String, и вынеся LeftSubstring и RightSubstring наружу, как нам наивно предлагает AndrewVK. Можно удешевить библиотеку и... удорожить проект, потому что каждая минута, когда программист попадает в ступор не находя нужного метода, каждая минута, когда программист вспоминает что метод был, но не помнит где, каждая минута, когда он роется в документации, каждая менитура рефакторинга с метода который вспомнили, на метод который оптимален, оплачивается. Оплачивается в вечнозелёных американских долларах, в деревянных рублях, в евро, в лари, в гривнах, в чём угодно, но только не в рейтинге инкапсуляции. Имеет значение всё, например, формат файла конфигурации. У многих порог вхождения в Spring большой, потому что конфиграция в XML. Это сложность обучения и использования, методами с узкой областью применения ты их не измеришь.
Конечно можно встать в позу и сказть что вокруг все дураки и рейтинги рулят, но цену разработки это не отменит.
Здравствуйте, Aikin, Вы писали:
A>Ок, за исключением одной вещи -- смерти человека.
Ну пока код для игрушечных приложений пишется — оно конечно да, исправить можно все. Аты представляешь какой кровью дается обратная совместимость с предыдущими версиями API своего же продукта? Я бы посмотрел, как ты будешь исправлять свой код, на котором кастомер уже пару решений построил и впарил третьему клиенту.
A> Да, есть масса общепринятых практик. Твое правило к которым очевидно не относится.
Очевидно относится, так как основано на тех же самых практиках.
A>Программист страдающий амнезией? Занятно.
Это не занятно, это жизнь.
A>Маленький бардак может оказаться вовсе не бардаком.
Угу, а несколькими бардаками.
Здравствуйте, Ziaw, Вы писали:
Z>Другие возражения были.
Это какие? Единственное что тебя не устроило — это отсутствие статик хелперов.
Z>Примотался я к статик хелперам потому, что этот вариант выноса самый корявый. Что доказывает отсутствие нормальных библиотек широко использующих эти самые хелперы.
Во-первых, хелперы не для библиотек, для приложения хелперы вполне приемлемый вариант. А во-вторых, в восьмой раз тебе говорю, не хелперами едиными.
Z> Пока не увидел ни одного выбора в пользу внешнего в общеизвестных библеотеках.
WCF, любой IoC контейнер.
Z>Как должны выглядеть эти классы/класс?
Как внешний класс или сервис.
Z>Да ничего подобного, читабельность кода не поддается автоматической оценке, не существует метрик ее измеряющих. Тем не менее она может стать самой серьезной проблемой при модификации/расширении.
Только вопрос — ухудшает ли читаемость предлагаемый подход остается открытым.
Z>То, что некоторые метрики можно выразить числом еще не означает, что они доминирующие.
Это не означает, что их можно игнорировать.
Здравствуйте, adontz, Вы писали:
A>Тебе уже сто раз сказали, удобство важнее твоих фантиков.
Раз возразить нечего, значит фантики? Я не сомневался..
Я уже сто раз на это ответил, что приносить надежность кода в пользу удобству — дурная затея, тем более, что вопрос удобства остается открытым.
A> Да всё очень просто, чтобы разработка стала дешевле.
Ты пропустил один важный шаг — чтобы ошибок было меньше и обнаруживались они раньше.
Ром, у тебя косяк в логике: A>Теперь о главном. Жадный алгоритм не работает. Совсем. Оптимизировав цену каждого модуля в отдельности ты не получишь в итоге самый дешёвый проект
То что ниже, свосем не подтверждает фразу выше.. A>Причина тому проста — разные модули повторно используются разное количество раз и в разном объёме: некоторые вообще не используются повторно, а некоторые десятки раз. Стоимость функционала в библиотеке — это конечная стоимость, конечная стоимость функционала вне библиотеки — сумма стоимостей во всех приложениях. Это очевидная истина. Потому и пишут библиотеки, чтобы удешевлять, чтобы создать дорогой код, цена которого рассется по всем использующим его проектам.
Ну и так же, в своей пламенной речи, ты опять ловким образом забыл, про цену ошибки в библиотеке, которая расползется по всему использующему ее коду.
A> Можно удешевить библиотеку и... удорожить проект, потому что каждая минута, когда программист попадает в ступор не находя нужного метода, каждая минута, когда программист вспоминает что метод был, но не помнит где, каждая минута, когда он роется в документации, каждая менитура рефакторинга с метода который вспомнили, на метод который оптимален, оплачивается. A>Оплачивается в вечнозелёных американских долларах, в деревянных рублях, в евро, в лари, в гривнах, в чём угодно, но только не в рейтинге инкапсуляции.
Рома, слезь с броневика..
Хочешь, я распишу тебе про ужасы появления монстрообразных классов, борьбу за выживание в лапшеобразном коде, погрязшем в сильной связности, беготню от кастомеров, котрым ты в очередной раз все сломал из-за кривого API и обреченность разработчика осознавшего, что надо бы впихнуть еще один метод в класс, а уже нельзя?.. Я тоже так могу, просто время жалко.. =)
Но главный твой косяк в другом. Я тебе сейчас все объясню. Понимаешь, непосредственно на кодирование, поиск методов и копание в доке конкретной библиотеки уходит 1%-2% времени, все остальные 98% толковый разработчик думает. Меня уже очень много лет совершенно не парит объем предстоящего кодирование и мифическое "удобство". Это все равно другой порядок малости по сравнению со временем, которое я потрачу на проектирование.
Так что, на какой-нибудь не окрепший разум эта пламенная речь наверное произведет впечатление, но на серьезную аудиторию рассчитывать не советую..
A>Имеет значение всё, например, формат файла конфигурации. У многих порог вхождения в Spring большой, потому что конфиграция в XML. Это сложность обучения и использования, методами с узкой областью применения ты их не измеришь.
Ром, ты с XML-ем что ли не справился? XML сложен в изучении? Похоже тебя занесло..
Здравствуйте, IB, Вы писали:
IB>Но главный твой косяк в другом. Я тебе сейчас все объясню. Понимаешь, непосредственно на кодирование, поиск методов и копание в доке конкретной библиотеки уходит 1%-2% времени, все остальные 98% толковый разработчик думает.
То есть из 8 рабочих часов разработчик печатает от 4 минут 48 секунд, до 9 минут 36 секунд, а остальное время думает. Весьма реалистично.
Здравствуйте, IB, Вы писали:
IB>Я уже сто раз на это ответил, что приносить надежность кода в пользу удобству — дурная затея
Ты так и не привёл каких-либо доказательств этого сомнительного тезиса. То что хелперы уменьшают количество багов — это миф. Незначительное повышение инкапуляции за которое ты воюешь может как-то влиять на рефакторинг, но не на изначальное качество.
С другой стороны, сделать нормальный интерфейс, усложнив внутренее устройство, и, как следствие, потратить на разработку, включая отладку, больше времени, может быть, в целом, выгоднее по времени и деньгам.
Здравствуйте, IB, Вы писали:
IB>Ну и так же, в своей пламенной речи, ты опять ловким образом забыл, про цену ошибки в библиотеке, которая расползется по всему использующему ее коду.
Что значит расползёться? Это что вирус? Библиотеки потому, в том числе, и выгоднее что любой баг правиться только один раз, в библиотеке и никуда не расползается. Ты может придумал способ писать без багов? А вечный двигаетль заодно не изобрёл?
IB>Рома, слезь с броневика..
Ты утверждаешь что эффект от применения хелперов настолько силён, что количество багов заметно уменьшиться. И кто отстаивает, мягко говоря, сомнительные идеи? И кто на броневике?
IB>Хочешь, я распишу тебе про ужасы появления монстрообразных классов, борьбу за выживание в лапшеобразном коде, погрязшем в сильной связности, беготню от кастомеров, котрым ты в очередной раз все сломал из-за кривого API и обреченность разработчика осознавшего, что надо бы впихнуть еще один метод в класс, а уже нельзя?..
Иван, ты так и не понял, что, в отличие от тебя, никто в крайности не впадает, не просит все методы какие можно засовывать в классы, не просит все методы какие можно доставать из классов, и уж точно не о кривом API идёт речь. Речь как раз о прямом API, причём прямом с точки зрения тех, кто его использует, а не с точки зрения тех, кто проектирует. Не надо наводить красоту там где её не видно, за счёт тех мест где видно. Ты если бы не только писал, но и читал, не отвечал бы так невпопад.
A>>Имеет значение всё, например, формат файла конфигурации. У многих порог вхождения в Spring большой, потому что конфиграция в XML. Это сложность обучения и использования, методами с узкой областью применения ты их не измеришь. IB>Ром, ты с XML-ем что ли не справился? XML сложен в изучении? Похоже тебя занесло..
Во-первых, я написал "У многих". С чего ты взял, что у меня? Во-вторых, никто не говорил, что XML или язык конфигурации Spring, построенный на основе XML, сложен. Просто сам метод конфигурирования библиотеки кому-то может быть не близок. Ты отвечаешь на уровне "Не смог прочесть текст на испанском, потому что не умеет пользоваться программой Notepad". Вобщем, как всегда, переврал.
Здравствуйте, AndrewVK, Вы писали:
A>> потратить на разработку, включая отладку, больше времени, может быть, в целом, выгоднее по времени и деньгам. AVK>Знакомо.
Видимо плохо, раз минусуешь. Посмотри фильм Турецкий Гамбит
Здравствуйте, AndrewVK, Вы писали:
AVK>Наоборот, слишком хорошо. Мне последнее время все в большем объеме приходится чужой код до ума доводить.
Это твоё личное негатичное впечатление на тему "я в говне копаюсь, пока остальные творят". Есть фирме выгоднее так делать проект, твое личное негативное впечатление ничего не решает и никого не волнует. Если ошибочка вышла и не выгоднее, факты в студию (можно и о другом проекте), а иначе пустая болтовня получается.
Здравствуйте, adontz, Вы писали:
A>Это твоё личное негатичное впечатление на тему "я в говне копаюсь, пока остальные творят".
Не сочиняй. Я не говорил, что я в говне копаюсь. Просто я, по служебной необходимости, очень хорошо знаком с большим количеством разных "архитектурных" подходов. И неоднократно видел, к чему приводят подобные подходы в условиях промышленной разработки.
Ивану, кстати, насколько я знаю, тоже приходится руководить командой разработчиков, и следить за качеством их кода.
A> Есть фирме выгоднее так делать проект, твое личное негативное впечатление ничего не решает и никого не волнует.
Моей фирме — не выгодно так делать проект. Причем ОЧЕНЬ невыгодно. А фирмы, которых не волнует качество кода и его поддержка — не волнуют уже меня, как пример правильной архитектуры (и как потенциальные работодатели).
A> Если ошибочка вышла и не выгоднее, факты в студию (можно и о другом проекте), а иначе пустая болтовня получается.
У меня есть отличнейший факт, демонстрирующий все результаты такого подхода — реструктуризатор в Янусе. Он уже обошелся дороже, чем если бы в свое время я написал его сам.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Не сочиняй. Я не говорил, что я в говне копаюсь. Просто я, по служебной необходимости, очень хорошо знаком с большим количеством разных "архитектурных" подходов. И неоднократно видел, к чему приводят подобные подходы в условиях промышленной разработки. AVK>Ивану, кстати, насколько я знаю, тоже приходится руководить командой разработчиков, и следить за качеством их кода.
Ну ты ведь не пиписьками меряться собрался, а то я пишу правила по которым проводиться code review А ещё у меня за спиной 3 библиотеки на экспорт с ежедневным фидбеком от очень разных людей разного уровня и, как следствие, реальное понимание чего хотят пользователи от библиотеки. Однако, чей-либо личный авторитет, не может быть подтверждением той или иной идеи. Истина остаётся истиной вне зависимости от количества и знаменитости стороников, так что давай заканчивать говорить о себе. Тут очень многие были если не ПМ и архитекторами, то хотя бы старшими разработчиками. В дискуссии достаточно хамства и грязных намёков, не хватало только драки стенки на стенку.
A>> Если ошибочка вышла и не выгоднее, факты в студию (можно и о другом проекте), а иначе пустая болтовня получается. AVK>У меня есть отличнейший факт, демонстрирующий все результаты такого подхода — реструктуризатор в Янусе. Он уже обошелся дороже, чем если бы в свое время я написал его сам.
Янус — не библиотека и как пример, положительный или отрицательный, не уместен.
Здравствуйте, AndrewVK, Вы писали:
AVK>Судя по словам автора — да.
Я так понимаю, единственная (ну или самая существенная с большим отрывом от других) проблема Реструктуризатора в том, что он написан без использования внешних манипуляров-хелперов, как следствие код менее инкапсулирован чем хотелось бы и это в итоге привело к большому количеству проблем. Потому что мы тут обсуждаем хелперы и если проблема Реструктуризатора не в недостаточном выносе кода в хелперы, то пример Реструктуризатора непонятно что подтверждал бы. Если у Реструктуризатора другие проблемы, то это очень плохо, но оффтопик. Ну порайней мере область дискуссии стала бы слишком широка.
Здравствуйте, adontz, Вы писали:
A> Библиотеки потому, в том числе, и выгоднее что любой баг правиться только один раз, в библиотеке и никуда не расползается.
Вся проблема в том, что он вносится один раз, а обнаруживается в очень многих местах.
Тезис же о том, что правится такой баг только один раз, так же сомнителен, на практике ошибка в библиотеке зачастую выливается в серию воркэраундов в приложениях, которые ее используют, так как править библиотеку дорого и не всегда возможно. Потом выходит новая версия библиотеки, с уже исправленым багом, и бедный разработчик ставится в раскоряку, так как уже потрачены драгоценные человеко-дни на обход бага, теперь, вроде бы, надо писать новый код без лишних приседаний, но и старый выкидывать нельзя, так как есть активные ветки кода, которые используют старую версию. И вот, наш герой стоит перед суровой неизбежностью поддерживать две версии работы с библиотекой — с багом и без бага... (Дальше идет плачь о выкинутых деньгах, потраченном времени, провалу по срокам проекта, а дома детки не кормлены). Но! Зато API у библиотеки, чудо как удобен..
A>Ты может придумал способ писать без багов?
Нет, я просто описываю давно известный способ минимизировать число ошибок.
A>Ты утверждаешь что эффект от применения хелперов настолько силён, что количество багов заметно уменьшиться.
Про хелперы я ничего не утверждаю. Тебе еще раз принцип напомнить?
A> И кто отстаивает, мягко говоря, сомнительные идеи?
Ты конечно. Например, идея бросить все на алтарь удобства просто восхитительный образец сомнительности.
A> И кто на броневике?
Не будем показывать пальцем, но твой монументальный профиль торчит на нем с момента твоего вступления в дискуссию.. =)
A>Иван, ты так и не понял, что, в отличие от тебя, никто в крайности не впадает,
А, так это была еще не крайность?
A> не просит все методы какие можно засовывать в классы, не просит все методы какие можно доставать из классов,
Ну да, просто размажем все ровным слоем, как левая пятка захочет, зато эстетика соблюдена..
A> и уж точно не о кривом API идёт речь.
Прости, но прямым твой подход назвать — язык не поворачивается.
A>Во-первых, я написал "У многих". С чего ты взял, что у меня?
Больше я ни у кого сложностей с XML-ем не припомню..
A> Просто сам метод конфигурирования библиотеки кому-то может быть не близок.
Я верю, что в спринге может быть проблема с осознанием самой идеи контейнера, но чтобы были проблемы с пониманием идеи конфигурации... Ром, ты увлекся.. )) Сам по себе конфиг там мутный и стремный, но идея понятна с первого взгляда.. App.config проблем не вызывает? =)
Здравствуйте, adontz, Вы писали:
A>Я так понимаю, единственная (ну или самая существенная с большим отрывом от других) проблема Реструктуризатора в том, что он написан без использования внешних манипуляров-хелперов
Не единственная, но это там тоже имеется в классах описания структуры. А главная проблема — что писалось "как удобнее", а не как по нормальному. К примеру — вместо нормальной модели драйверов нужно наследоваться от специального класса, в котором гора виртуальных методов.
A> Ну порайней мере область дискуссии стала бы слишком широка.
Ты сам начал философствовать:
С другой стороны, сделать нормальный интерфейс, усложнив внутренее устройство, и, как следствие, потратить на разработку, включая отладку, больше времени, может быть, в целом, выгоднее по времени и деньгам.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Мы уже победили, просто это еще не так заметно...
