Здравствуйте, VGn, Вы писали:
IT>>Я то тут при чём? Тебе понятно или нет? Или вопрос требует слишком конкретного для тебя ответа? VGn>Это шутка о тепловыделении, если не понял.
Я не понял другого. Почему ты не даёшь ответы на вполне конкретные вопросы? Хотя, что тут не понятного
IT>>Тебе нужно в соседней теме с DG пообщаться. Он пытается измерять сложность в вариантах, а ты в колоджоулях. Вы должны найти с ним много общего.
VGn>Ну вот. Теперь ты мне ставишь в вину именно ту логическую ошибку, которую я поставил в вину тебе. Замечательно.
Можешь поставить мне в вину сразу хоть весь список своих логических ошибок. А лучше, чтобы не повторяться, создай домашнюю страничку с таким списком и раздавай на неё ссылки всем своим собеседникам.
Наличие ошибки в суждениях, как и любую свою позицию, нужно обосновывать, разве ты этого не знал?
Например, у меня к тебе имеется притензия в том, что ты не отвечаешь на элементарные вполне конкретные вопросы, которые тебе задаются в ответ на твои суждения. Вот один из примеров:
IT>>А что такое упорядочивание?
VGn>Наведение порядка
VGn>Структурирование.
Ну да. SRP упорядочивает код или не упорядочивает?
Где твой ответ?
Видишь? У меня есть к тебе претензия и я могу её подкрепить конкретными примерами. Ты же просто кидаешь обвинения в воздух и почему-то считаешь их уже доказанными. Где логика, где твоё ассоциативное мышление? Ты вообще сам читаешь ссылки, которые здесь приводишь?
VGn>>>Кстати заметь, опять с усилий на сложность перескочил. Как бы невзначай. IT>>Почитай статью. Только повнимательнее, там в первых же абзацах написано. VGn>Куда, куда ты меня послал?
Да ясно всё с тобой и куда тебя следовало послать с самого начала. Жалко только времени, потраченного на бессмысленный трёп с любителями выдавать умственную ветошь за истину.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Silver_s, Вы писали:
S_>При принятии решения о "заранее выделить код" на завтра приходится учитывать. S_>1) Если при выборе одного из двух решений, потом в случае неудачного выбора откат назад слишком трудоемкий (в сумме труды на первый вариант + переделка на второй). Тогда тут 10 раз надо сначала подумать.
Если оба варианта равновероятны, то надо выбирать тот, который потребует меньше писанины.
Если нет, то тот, который наиболее вероятен.
S_>2) Надо пытаться предсказать что потребуется завтра, если пункт 1 заставляет. Причем надо оценить не только вероятности того насколько подойдет вариант, но и сложность создания обоих вариантов, а также перевода одного варианта в другой.Но ясновидцев нет. Только эмпирические интуитивные прогнозы можно делать. И бывает когда они не делаются.
Не надо предсказывать. Надо руководствоваться правилос выше.
Почти любая попытка "продумать наперед" обычно не приносит полезных результатов.
S_>3) Надо учитывать что бывают случаи, если что-то не сделаешь сегодня, то завтра на это уже в 5 раз больше усилий затратишь.
Такого не бывает, если не пытаться "продумать наперед".
S_>А если писал фичу две недели, и есть подозрения на 50% что потом к ней потребуется добавка которую 1 час писать, а если отложить на 2 недели, то потребуется 8 часов чтобы ту же добавку написать (переключение контекста). S_>Если подсчитать матожидание затрат (как бы не смешно звучало) : в первом случае 1 час, во втором 0.5*8
Неверно. Это только сдвинет переключение контекста, а не уберет его.
Кроме того переключение контекста — очень субъективная вещь.
S_>В реальности матожидания рассчитывать невозможно, слишком много факторов, с постоянно меняющимися стоимостями,вероятностями и прочими... Только интуитивные оценки остаются в ральных ситуациях. А в теории можно только обозначить разные факторы, чтоб знать где вобще копать.
Не надо копать, надо делать то что нужно сейчас и уменьшать связность.
Здравствуйте, gandjustas, Вы писали:
S_>>3) Надо учитывать что бывают случаи, если что-то не сделаешь сегодня, то завтра на это уже в 5 раз больше усилий затратишь. G>Такого не бывает, если не пытаться "продумать наперед".
Это довольно спорное утверждение. Как раз продумывать наперёд надо. Надо ли делать наперёд — это другой вопрос. Вполне конкретный пример с не продумали наперёд — Linq 2 SQL в части поддержки нескольких провайдеров. Закончилось всё закрытием проекта. Кстати, альтернативные проекты страдают такой же точно проблемой. Между тем реализация нескольких провайдеров не представляет большой сложности, если продумать наперёд, а ещё лучше сразу реализовать.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
S_>>>3) Надо учитывать что бывают случаи, если что-то не сделаешь сегодня, то завтра на это уже в 5 раз больше усилий затратишь. G>>Такого не бывает, если не пытаться "продумать наперед".
IT>Это довольно спорное утверждение. Как раз продумывать наперёд надо. Надо ли делать наперёд — это другой вопрос. Вполне конкретный пример с не продумали наперёд — Linq 2 SQL в части поддержки нескольких провайдеров. Закончилось всё закрытием проекта. Кстати, альтернативные проекты страдают такой же точно проблемой. Между тем реализация нескольких провайдеров не представляет большой сложности, если продумать наперёд, а ещё лучше сразу реализовать.
Создание фреймворка отличается от создания приложения.
Для фреймворка необходимо продумывание того что он будет делать. Но это уже продумывание будет на более высоком уровне, чем отдельные классы или фичи.
Здравствуйте, gandjustas, Вы писали:
G>Создание фреймворка отличается от создания приложения.
И отличается и пересекается, всё вместе.
G>Для фреймворка необходимо продумывание того что он будет делать. Но это уже продумывание будет на более высоком уровне, чем отдельные классы или фичи.
В том то и дело, что думали. В Linq 2 SQL даже выделенный для этого (правда засиленный) модуль есть. Но вот ни в деталях, ни на уровне отдельных классов, ни на более высоком уровне ничего путного не получилось. Я уже это неоднократно озвучивал, озвучу ещё раз:
Чем позже архитектура начинает учитывать определённые детали, тем менее приспособленной она становится для внесения соответствующих изменений.
С ростом кода его гибкость теряется и его приходится периодически размягчать с помощью соотвествующих техник и рефакторинга. Но иногда это становится невозможным, как, например, в случае с компилятором Немерле. Замечательный язык, а компилятор — отшлифованный до блеска кусок гранита. Сразу не учли всего несколько пустяков, вроде вменяемой поддержки locations, и создание интеграции для студии превратилось в многолетний кошмар. Нужно ли было сразу писать интеграцию? Вряд ли. Можно ли было учесть определённые детали? Безусловно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Silver_s, Вы писали:
S_>>1) Если при выборе одного из двух решений... Тогда тут 10 раз надо сначала подумать. G>Если оба варианта равновероятны, то надо выбирать тот, который потребует меньше писанины. G>Если нет, то тот, который наиболее вероятен. G>Не надо предсказывать. Надо руководствоваться правилос выше.
В правиле выше сказано про вероятности. А определение вероятностей это и есть попытка сделать предсказание. Не по звездам делаются адекватные оценки вероятностей. И не по пакетам программ мат-статистики, когда о таких вещах речь идет. К тому же определить вариант где меньше писанины это тоже гадание. Да и какая писанина интересует, в краткосрочном плане или в долгосрочном?
G>Почти любая попытка "продумать наперед" обычно не приносит полезных результатов.
А вот с этим, как ни странно согласен. Главное чтобы это не вело к ложным выводам и действиям, большим потерям времени.
Но когда проходятся точки невозврата, после которой остановить паровоз и отправить обратно становится тяжело. Тогда стоит гораздо больше времени потратить на попытки предсказать к чему может привести вариант. И кроме того на поиск еще и других вариантов можно потратиться, которые на первый взгляд не видны.
Но под "продумать наперед" я не имею ввиду проектирование сверху-вниз, а потом продавливание этих первоначальных решений до потери пульса, игнорируя все факты несостоятельности таких первоначальных решений. Это как раз, надекватная оценка способностей продумать ситуацию наперед, не удалось продумать а все равно упрямится...
Думаю не станешь отрицать что существуют конторы где программисты говорят "Ой как все криво,косо сделано" Но переделать невозможно. Такие системы и конторы держатся на плаву если слабая связь между отдельными программистами(один не может проушить работу другого, и не должен знать что делает сосед). И слабая связь с предыдущими годами работы(добавления не смогут порушить старое). Переделывать в этом случае невыгодно, когда больше 200 человеко-лет вложено, переделка может обойтись дорого.
Т.е. там может быть важна(из-за чего контора на плаву держится) не столько архитектура, а поддержка пользователей,предметная область,сама бизнес логика. А в архитектурном плане много лет много человек делают абсолютно одно и тоже, клонируют кусок кода втыкают бизнес логику, и добавляют в общий массив. И плюс часть времени на борьбу с багами, обход граблей, возникающих из-за кривизны.
А бывают системы где все заходит вобще в полный тупик из-за какой-то мелочи или кривизны архитектуры. И откаты назад с глубокими переделками неизбежны, поскольку нужно не наращивание за счет количества, а качественное развитие. Там скорее принципы XP более актуальны.
S_>>А если писал фичу две недели, и есть подозрения на 50% что потом к ней потребуется добавка которую 1 час писать, а если отложить на 2 недели, то потребуется 8 часов чтобы ту же добавку написать (переключение контекста). S_>>Если подсчитать матожидание затрат (как бы не смешно звучало) : в первом случае 1 час, во втором 0.5*8 G>Неверно. Это только сдвинет переключение контекста, а не уберет его. G>Кроме того переключение контекста — очень субъективная вещь.
G>Не надо копать, надо делать то что нужно сейчас и уменьшать связность.
Да, копать сомо по себе не надо,как самоцель, надо прокачивать интуицию для таких случаев где формальный анализ бессилен.
А интуиция по оценке неких свойств системы или некой области, насколько знаю, прокачивается только путем наблюдения и экпериментального изучения (действие-наблюдение реакции,результата).
За какими факторами,свойствами, атрибутами, наблюдаешь. По ним и будешь иметь представление. За чем не наблюдаешь, того нет.
А то что нужно сейчас, конечно тоже надо делать. После этого уже возможно появятся идеи как это можно сделать лучше по-другому. Из ничего идеи трудно создать. Да и вобще мне больше нравится философия XP где все "здесь и сейчас" но не доводя до абсурда.
-----
Если на дырки в земле не обращать внимания,то суслики не существуют.И непонятно кто капусту жрет в огороде — самоликвидируется наверно.
Но в принципе, если огород в порядке нет смысла каждую неровность в земле изучать.
Это замечание уже скорее по поводу вопросов из обсуждаемой статьи.
К примеру ту же WPF могли сделать только одним способом? Или много вариантов из которых тяжело выбирать — один по своему хорош другой по своему и каждый в чем-то проигрывает. По условию бы делала команда одного проф. уровня и специализации. А не сравнивать с тем что бы сделала конвеерная бригада по производству учетных систем.Для которых слово заказчика-закон и менеджер проектов никогда не ошибается.
Или такой частный случай. Hеализация и работа property в WPF сложнее чем в WinForms? Если сложнее то зачем так сделали? Везде ли подойдет такая реализация пропертей или могут обозвать извращенцем того кто такое же сделал в другой задаче? Ясно что такие пропертя определенные неудобства тоже причиняют (кроме положительных моментов).Кроме того их еще изучить надо чтобы понять. Когда существует простой и очевидный способ из объектов просто собирать через Reflection.
Если кому то в статье бросается в глаза только то что она формально не строгая. Значит с аналогичными проблемами на практике не сталкивались, и эти вопросы просто не актуальны.
На просьбу сделать попытку изложить то же, но более формально. Скорее всего будет ответ — невозможно формализовать то чего нет.
Сложность определяется энтропией, а поскольку к данным вопросам формулы энтропии не подходят. А другие логичные формулы и строгое описание не придумываются, значит это субьективизм,ересь, и пустопорожние разговоры оторванные от жизни.
З.Ы. Надоело срочить по клаве, перехожу в читатели.
А если кратко то к каждой строчке на которые отвечал написал бы "Согласен, с оговоркой что не всегда так бывает". Кроме ... неявного утверждения что не надо гадать а просто выбирать наибольшую вероятность
Надеюсь ветка продолжится. И не в виде борьбы за чистоту терминов.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Silver_s, Вы писали:
S_>>>1) Если при выборе одного из двух решений... Тогда тут 10 раз надо сначала подумать. G>>Если оба варианта равновероятны, то надо выбирать тот, который потребует меньше писанины. G>>Если нет, то тот, который наиболее вероятен. G>>Не надо предсказывать. Надо руководствоваться правилос выше.
S_> В правиле выше сказано про вероятности. А определение вероятностей это и есть попытка сделать предсказание. Не по звездам делаются адекватные оценки вероятностей. И не по пакетам программ мат-статистики, когда о таких вещах речь идет. К тому же определить вариант где меньше писанины это тоже гадание.
Елси нету заранее точных оценок, то варианты можно считать равновероятными.
S_>Да и какая писанина интересует, в краткосрочном плане или в долгосрочном?
В краткосрочном.
S_> Думаю не станешь отрицать что существуют конторы где программисты говорят "Ой как все криво,косо сделано" Но переделать невозможно. Такие системы и конторы держатся на плаву если слабая связь между отдельными программистами(один не может проушить работу другого, и не должен знать что делает сосед). И слабая связь с предыдущими годами работы(добавления не смогут порушить старое). Переделывать в этом случае невыгодно, когда больше 200 человеко-лет вложено, переделка может обойтись дорого.
Я сам в такой работал. Но не понял в чем необходимость переделок.
Обычно переделок много на этапе интенсивного развития пока не окончательно сформирована концепция создаваемой системы, тогда как после 200 человеко-лет работы развитие идет экстенсивно, те код просто дописывается в нужных местах и фиксятся баги.
IT>Вот и не бойся, давай, давай. Меньше слов — больше дела. Применяй свои абстракции.
Вот только демагогии не надо.
VGn>Приведи пример задачи, которую нельзя декомпозировать на одном либо на разных уровнях абстракции.
Например, добавление генерации отладочной информации в компилятор. Необходимо протянуть её от парсера до кодо-генератора через все преобразования, ничего не сломав и сохранив все детали. Давай, вводи абстракцию.
В качестве примера невозможности декомпозиции привёл компилятор, который сам же обозначил "от парсера до кодо-генератора". Чего от меня-то хочешь? Конкретного решения своей "сложной" задачи? Конкретного решения способа протягивания абстрактной отладочной информации через абстрактный компилятор к вопросу о моделях?
Я не буду этим заниматься.
IT>Ну да. SRP упорядочивает код или не упорядочивает?
IT>Где твой ответ?
Я принял вопрос за риторический. Потому что само собой ведение речи об областях ответственности уже структурирует разработку, ибо область ответственности — это как раз и есть одна из абстракций верхнего уровня.
VGn>>Это шутка о тепловыделении, если не понял.
IT>Я не понял другого. Почему ты не даёшь ответы на вполне конкретные вопросы? Хотя, что тут не понятного
IT>>>Тебе нужно в соседней теме с DG пообщаться. Он пытается измерять сложность в вариантах, а ты в колоджоулях. Вы должны найти с ним много общего.
VGn>>Ну вот. Теперь ты мне ставишь в вину именно ту логическую ошибку, которую я поставил в вину тебе. Замечательно.
IT>Можешь поставить мне в вину сразу хоть весь список своих логических ошибок. А лучше, чтобы не повторяться, создай домашнюю страничку с таким списком и раздавай на неё ссылки всем своим собеседникам.
IT>Наличие ошибки в суждениях, как и любую свою позицию, нужно обосновывать, разве ты этого не знал?
Хорошо. Иногда я выражаюсь не очень связно. Особенно когда думаю, что человек настолько образован, что ему известны предпосылки моих суждений.
Придётся разжевать.
Очень часто при анализе сложных систем и процессов используют аналогии из термодинамики. Потому что термодинамика — одна из самых стройных наук и при этом имеет большую философскую основу.
Поэтому во многих обсуждениях можно услышать "энтропия", "работа", "энергия" и т.д.
(не поверю, что ты не знаешь фразу "энтропия кода")
Поставив в заголовок "закон сохранения" ты практически автоматически перешёл на эту аналогию, потому что законы сохранения обычно ассоциируются с законами термодинамики.
Теперь о самой аналогии.
За энтропией как мерой хаоса, можно характеризовать такие вещи, как:
— беспорядок в требованиях,
— беспорядок в модели,
— беспорядок в коде,
— беспорядок в головах
Естественно, что с беспорядком борятся упорядочиванием, структуризацией, построением иерархий.
В сущности абстрагирование — это в какой-то мере и есть построение иерархии.
Собственно из теории.
Состояния с высокой энтропией являются более равновесными состояниями, чем с низкой.
Что означает:
— на структурирование необходимо затратить энергию
— система стремится перейти из структурированного состояния в хаотичное (не будем для краткости учитывать нелинейность, локальные экстремумы и т.д., хотя именно на нелинейности таких переходов и основаны те эффекты, которые ты обсуждаешь в статье)
Собственно о сложности
Как описывалось ранее и другими участниками дискуссии, человеческий разум устроен таким образом, что проще воспринимается структурированная информация, а значит связывать сложность с энтропией вполне приемлемо (отсюда и термин "энтропия кода"). Отсюда и аналогии энергии и полезной работы с усилиями по разработке кода.
Тем более, что знаменитое суждение "программирование — борьба со сложностью" в принципе связано не только со сложностью кода, но и с наведением порядка в объекте, для которого создаётся ПО.
Собственно, чем сложнее модель, тем больше энергии надо затратить на её структурирование.
Вобщем такая аналогия применяется довольно часто и мне даже трудно понять, почему ты о ней не знаешь.
Собственно и из этих предпосылок я и заявил, что тождественное приравнивание сложности и затрачиваемых усилий — это бред.
Очень нужная статья. Мне кажется её главная ценность не в постулируемом "законе" — это и так все знают, а в попытке выделить различные виды сложности, с которыми чаще всего приходится иметь дело при разработке приложений. Именно с этой точки зрения нужно оценивать любое решение при разработке ПО.
Пусть у нас имеется несколько вариантов действий из которых нужно выбрать. Можно представить каждое из возможный действий как точку в пятимерном пространстве различных типов сложностей. Разработав некоторую функцию, которая для может для точек этого пространства определять нашу способность бороться со сложностями (в идеале сразу в человек/часах), мы можем свести обсуждение вариантов к оценке коэффициентов в этой функции для каждого конкретного коллектива программистов.
Разумеется, есть разные взгляды на возможные классификации сложности. Вот продукт недолгого гугления:
Дейкстра [Э. Дейкстра. Заметки по структурному программированию // У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. -- М.: Мир, 1975. -- с. 7-97.] выделяет три интеллектуальные возможности человека, используемые при разработке ПС[ПРОГРАММНЫХ СРЕДСТВ]:
· способность к перебору,
· способность к абстракции,
· способность к математической индукции.
Способность человека к перебору связана с возможностью последовательного переключения внимания с одного предмета на другой с узнаванием искомого предмета. Эта способность весьма ограничена -- в среднем человек может уверенно (не сбиваясь) перебирать в пределах 1000 предметов (элементов). Человек должен научиться действовать с учетом этой своей ограниченности. Средством преодоления этой ограниченности является его способность к абстракции, благодаря которой человек может объединять разные предметы или экземпляры в одно понятие, заменять множество элементов одним элементом (другого рода). Способность человека к математической индукции позволяет ему справляться с бесконечными последовательностями.
Если заменить слова "способность" на "сложность", то мы получим альтернативное разбиение субъективных сложностей из приведенной в статье классификации (Сложность восприятия + Алгоритмическая сложность + Сложность обучения).
С другой стороны, оценки этих "способностей" могут быть использованы как коэффициенты для функции оценки способности борьбы со сложностью.
Вообще поднятый вопрос очень правильный и ждет своих евангелистов и баззз-вордов для продвижения в сознание масс.
G>>Почти любая попытка "продумать наперед" обычно не приносит полезных результатов.
S_>Но когда проходятся точки невозврата, после которой остановить паровоз и отправить обратно становится тяжело. Тогда стоит гораздо больше времени потратить на попытки предсказать к чему может привести вариант. И кроме того на поиск еще и других вариантов можно потратиться, которые на первый взгляд не видны.
Пример: компания "Медиател" пару лет терпела многомилионные убытки, являвшиеся фактически единственной статьёй убытка концерна Ситроникс.
Из-за того, что титульный продукт начался с относительно наколенной разработки, развился экстенсивно и разбрёлся на несколько форков с отдельными группами разработки.
Только потому, что перестраивать архитектуру в своё время было "долго".
В конце концов, на сколько я знаю, часть заказчиков была утеряна и продукт был заменён полностью.
Здравствуйте, VGn, Вы писали:
VGn>Очень часто при анализе сложных систем и процессов используют аналогии из термодинамики. Потому что термодинамика — одна из самых стройных наук и при этом имеет большую философскую основу. VGn>Поэтому во многих обсуждениях можно услышать "энтропия", "работа", "энергия" и т.д. VGn>(не поверю, что ты не знаешь фразу "энтропия кода") VGn>Поставив в заголовок "закон сохранения" ты практически автоматически перешёл на эту аналогию, потому что законы сохранения обычно ассоциируются с законами термодинамики.
Эпиграф: "Все аналогии фальшивы"
VGn>Теперь о самой аналогии. VGn>За энтропией как мерой хаоса, можно характеризовать такие вещи, как: VGn>- беспорядок в требованиях, VGn>- беспорядок в модели, VGn>- беспорядок в коде, VGn>- беспорядок в головах VGn>Естественно, что с беспорядком борятся упорядочиванием, структуризацией, построением иерархий. VGn>В сущности абстрагирование — это в какой-то мере и есть построение иерархии. VGn>Собственно из теории. VGn>Состояния с высокой энтропией являются более равновесными состояниями, чем с низкой.
Кхм, если говорить строго, то система может быть или равновесной, или нет. "Более" или "менне" здесь не применимы. VGn>Что означает: VGn>- на структурирование необходимо затратить энергию VGn>- система стремится перейти из структурированного состояния в хаотичное (не будем для краткости учитывать нелинейность, локальные экстремумы и т.д., хотя именно на нелинейности таких переходов и основаны те эффекты, которые ты обсуждаешь в статье)
Вот здесь у нас протекает аналогия с термодинамикой — при остывании жидкости она отдает энергию, при этом становясь более структурированной. Если быть точным, то структурированная термодинамическая система может иметь большую энтропию, чем неструктурированная.
Безусловно, без внешнего воздействия энтропия системы растет и её понижение требует внешнего вмешательства.
Безусловно, это относится только к термодинамике. Структурированность кода всегда падает, если не прилагать усилий.
VGn>Собственно о сложности VGn>Как описывалось ранее и другими участниками дискуссии, человеческий разум устроен таким образом, что проще воспринимается структурированная информация, а значит связывать сложность с энтропией вполне приемлемо (отсюда и термин "энтропия кода"). Отсюда и аналогии энергии и полезной работы с усилиями по разработке кода.
"Все аналогии фальшивы." Да и сама по себе энтропия в термодинамике не есть функция энергии (или наоборот).
VGn>Тем более, что знаменитое суждение "программирование — борьба со сложностью" в принципе связано не только со сложностью кода, но и с наведением порядка в объекте, для которого создаётся ПО. VGn>Собственно, чем сложнее модель, тем больше энергии надо затратить на её структурирование.
Как только дашь определение энергии для ИТ, тогда можно будет его использовать в рассуждениях. Пока я только человеко-месяц знаю — тоже не супер, но что имеем тем и пользуемся. VGn>Вобщем такая аналогия применяется довольно часто и мне даже трудно понять, почему ты о ней не знаешь.
VGn>Собственно и из этих предпосылок я и заявил, что тождественное приравнивание сложности и затрачиваемых усилий — это бред.
С этим я согласен. В предыдущем посте я как раз писал о функции, которая может "определять нашу способность бороться со сложностями". Конечно, она зависит не только от сложности. (Правда я не понял, где ты нашел противное утверждение?)
Здравствуйте, VGn, Вы писали:
VGn>Пример: компания "Медиател" пару лет терпела многомилионные убытки, являвшиеся фактически единственной статьёй убытка концерна Ситроникс. VGn>Из-за того, что титульный продукт начался с относительно наколенной разработки, развился экстенсивно и разбрёлся на несколько форков с отдельными группами разработки. VGn>Только потому, что перестраивать архитектуру в своё время было "долго". VGn>В конце концов, на сколько я знаю, часть заказчиков была утеряна и продукт был заменён полностью.
Интересно. Дашь пруфлинк — положу в избранное. Буду использовать при убеждении в необходимости рефакторинга.
M>Кхм, если говорить строго, то система может быть или равновесной, или нет. "Более" или "менне" здесь не применимы.
Как назвать равновесное состояние с меньшим уровнем энергии?
VGn>>Что означает: VGn>>- на структурирование необходимо затратить энергию VGn>>- система стремится перейти из структурированного состояния в хаотичное (не будем для краткости учитывать нелинейность, локальные экстремумы и т.д., хотя именно на нелинейности таких переходов и основаны те эффекты, которые ты обсуждаешь в статье) M>Вот здесь у нас протекает аналогия с термодинамикой — при остывании жидкости она отдает энергию, при этом становясь более структурированной.
Смотря в чём. Или ты вообще споришь с понятием энтропии?
Имхо офтопик.
M>Как только дашь определение энергии для ИТ, тогда можно будет его использовать в рассуждениях. Пока я только человеко-месяц знаю — тоже не супер, но что имеем тем и пользуемся.
Дополнение:
очевидно и в новом виде продукт потерпел неудачу. Скорее всего из-за утраты доверия.
Вместо Медиателовского (Sitronics Telecom Solutions) CRM решили поставить Siebel и доверили это Квазару.
Я даже не знаю на сколько они теперь сократили количество разработчиков.
VGn>>Приведи пример задачи, которую нельзя декомпозировать на одном либо на разных уровнях абстракции.
VGn>Например, добавление генерации отладочной информации в компилятор. Необходимо протянуть её от парсера до кодо-генератора через все преобразования, ничего не сломав и сохранив все детали. Давай, вводи абстракцию.
VGn>В качестве примера невозможности декомпозиции привёл компилятор, который сам же обозначил "от парсера до кодо-генератора". Чего от меня-то хочешь? Конкретного решения своей "сложной" задачи? Конкретного решения способа протягивания абстрактной отладочной информации через абстрактный компилятор к вопросу о моделях? VGn>Я не буду этим заниматься.
Не хочешь не занимайся. Ты просил привести пример, я привёл тебе пример. Могу даже сказать где взять исходники и на всё это взглянуть. Там абстракций уже выше крыши, по всем законам компиляторостроения, и новые абстракции на задачу не натягиваются. Но главное даже не это. Сложность такой задачи не в невозможности ввести новый уровень абстракции, а в том, что задача не решается частями. Ввод нового элемента в AST сразу ломает весь компилятор и приходится работать в слепую, пока задача не будет решена полностью.
Если нам не помогут, то мы тоже никого не пощадим.
IT>>Ну да. SRP упорядочивает код или не упорядочивает?
IT>>Где твой ответ?
VGn>Я принял вопрос за риторический. Потому что само собой ведение речи об областях ответственности уже структурирует разработку, ибо область ответственности — это как раз и есть одна из абстракций верхнего уровня.
Вопрос был вполне конкретный. А вёл я к тому, что даже процесс упорядочивания не ведёт к обязательному упрощению. Иногда бывает совсем наоборот.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VGn, Вы писали:
VGn>Хорошо. Иногда я выражаюсь не очень связно. Особенно когда думаю, что человек настолько образован, что ему известны предпосылки моих суждений. VGn>Придётся разжевать.
Вот. Уже гораздо лучше
VGn>Очень часто при анализе сложных систем и процессов используют аналогии из термодинамики. Потому что термодинамика — одна из самых стройных наук и при этом имеет большую философскую основу. VGn>Поэтому во многих обсуждениях можно услышать "энтропия", "работа", "энергия" и т.д. VGn>(не поверю, что ты не знаешь фразу "энтропия кода")
Если бы сложность разработки ПО можно было описать с помощью других аналогий, то её бы уже давно описали и без нас с тобой. Поверь мне на слово. Но пока этого не произошло. Не помогает здесь почему-то ни термодинамика, ни философия. Некоторые принципы и аналогии позаимствовать можно, но не более того.
VGn>Поставив в заголовок "закон сохранения" ты практически автоматически перешёл на эту аналогию, потому что законы сохранения обычно ассоциируются с законами термодинамики.
По поводу названия и некоторых терминов я уже отвечал. Если это тебе не нравится, предлагай свои. Меня это всё мало волнует. Если ты думаешь, что я думаю, что я изобрёл новый закон, то могу тебя обрадовать, я так не думаю. Наверное, смайлик сразу после названия был бы вполне уместен. Что поделать, есть у меня страсть к пафосным названиям, вроде Закона сохранения сложности или Память больше не ресурс
VGn>Теперь о самой аналогии. VGn>За энтропией как мерой хаоса, можно характеризовать такие вещи, как: VGn>- беспорядок в требованиях, VGn>- беспорядок в модели, VGn>- беспорядок в коде, VGn>- беспорядок в головах VGn>Естественно, что с беспорядком борятся упорядочиванием, структуризацией, построением иерархий. VGn>В сущности абстрагирование — это в какой-то мере и есть построение иерархии.
Ты забыл добавить ещё
— беспорядок упорядочивания
— беспорядок абстрагирования
VGn>Собственно из теории. VGn>Состояния с высокой энтропией являются более равновесными состояниями, чем с низкой. VGn>Что означает: VGn>- на структурирование необходимо затратить энергию VGn>- система стремится перейти из структурированного состояния в хаотичное (не будем для краткости учитывать нелинейность, локальные экстремумы и т.д., хотя именно на нелинейности таких переходов и основаны те эффекты, которые ты обсуждаешь в статье) VGn>Собственно о сложности VGn>Как описывалось ранее и другими участниками дискуссии, человеческий разум устроен таким образом, что проще воспринимается структурированная информация, а значит связывать сложность с энтропией вполне приемлемо (отсюда и термин "энтропия кода"). Отсюда и аналогии энергии и полезной работы с усилиями по разработке кода. VGn>Тем более, что знаменитое суждение "программирование — борьба со сложностью" в принципе связано не только со сложностью кода, но и с наведением порядка в объекте, для которого создаётся ПО. VGn>Собственно, чем сложнее модель, тем больше энергии надо затратить на её структурирование. VGn>Вобщем такая аналогия применяется довольно часто и мне даже трудно понять, почему ты о ней не знаешь.
Да это всё понятно и так. Без теорий. Достаточно здравого смысла.
Не понятно как твои теории объясняют то, что при упорядочивании сложность кода может увеличиваться. В программировании это называется overarchitecture. Штука, встечающаяся чуть ли не чаще, чем вообще полное отсутствие архитектуры. Любой инструмент, любая техника, любой принцип, любая теория в программировании может быть использована не только во благо, но не редко совсем наоборот. Происходит это в следствии того, что попытка устранения сложности в одном месте всегда, ВСЕГДА!, сопровождается добавлением сложности в другом. Статья именно об этом.
VGn>Собственно и из этих предпосылок я и заявил, что тождественное приравнивание сложности и затрачиваемых усилий — это бред.
Я не ставлю знака равенства между усилиями по разработке кода и затраченной энеригией в любом виде. С чего ты вообще это взял? Это твой домысел и, соответственно, твой бред. Я вообще против того, чтобы искать способы, которыми можно было бы количественно измерить сложность. И это тоже явно и не двусмысленно указано в статье. Меня не интересуют точные количественные оценки, меня интересуют тенденции.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
