IT>Ты намешал здесь всё в одну кучу. Как пользователю тебе всё равно каким способом будет решена твоя задача. Твоё дело определить функциональные требования. Требования к коду исходят от разработчика. Именно разработчик борется со сложностью кода, а не заказчик.

полностью не согласен.

т.е. тебе как пользователю/заказчику пофигу, чем тебе в сервисе колесо к машине прикрутили: скотчем, сваркой или все-таки винтами?



пойдем конкретно по пунктам:

программное решение должно решать поставленную нами задачу за конкретный срок в том окружении, которое есть; и быть готовым к переформулировке или корректировке задачи по ходу (примечание: время на разработку и модификацию программного решения входит в срок)

1. т.е. тебе как пользователю пофигу — данный форум открывается за 1 секунду или за день? (за конкретный срок)
2. т.е. тебе как пользователю пофигу — будет на твоем компьютере данный форум открываться или нет? (в том окружении, которое есть)
3. т.е. тебе как пользователю пофигу — за сколько времени данный форум сможет поддержать задачу вставлять таблицы (если вдруг ты это захочешь)? (быть готовым к переформулировке или корректировке задачи по ходу)
4. т.е. тебе как пользователю пофигу — сколько кнопок надо нажать и сколько приседаний сделать, чтобы запостить сообщение на данный форум (требование: программное решение должно легко использоваться)

IT>Кратко сложность можно определить как меру усилий, требуемых для решения поставленной задачи.

имхо, сложность стоит вводить следующим образом

Сложность программного решения — это количество вариантов поведения программного решения.

Сложность(количество вариантов) растет очень быстро: раз развилка, два развилка... десятая развилка...двадцатая развилка и вот уже количество вариантов стало 2^20 — миллион, а миллион вариантов в голове уже не удержишь, даже 100-1000 вариантов с трудом умещаются.

Но крутиться как-то надо, надо уметь работать и с такой сложностью, и вот появляются инструменты для уменьшения кол-ва вариантов.

например:
Разделение на независимые части — при разделение программного решения на независимые части, сложность ПР уменьшается. Пока части были соединены в единой целое — сложность отдельных развилок перемножалась, но как только мы выделили независимые части — сложность между частями начинает складываться, а не перемножаться. Части должны быть как можно более независимые, т.к. только одна часть начинает влиять на другую, так сразу мы опять получаем взрывной рост вариантов.

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

DG>1. т.е. тебе как пользователю пофигу — данный форум открывается за 1 секунду или за день? (за конкретный срок)

Это нефункциональное требование к системе, а не к коду.

DG>2. т.е. тебе как пользователю пофигу — будет на твоем компьютере данный форум открываться или нет? (в том окружении, которое есть)

См. выше.

DG>3. т.е. тебе как пользователю пофигу — за сколько времени данный форум сможет поддержать задачу вставлять таблицы (если вдруг ты это захочешь)? (быть готовым к переформулировке или корректировке задачи по ходу)

Сроки меня интересуют. Но как разработчики этого добьются — нет.

DG>4. т.е. тебе как пользователю пофигу — сколько кнопок надо нажать и сколько приседаний сделать, чтобы запостить сообщение на данный форум (требование: программное решение должно легко использоваться)

Это usability. К коду, ну, например, конкретно к single responsibility principle, тоже не имеет никакого отношения.

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

IT>>Кратко сложность можно определить как меру усилий, требуемых для решения поставленной задачи.

DG>имхо, сложность стоит вводить следующим образом

DG>Сложность программного решения — это количество вариантов поведения программного решения.

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

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

В данном случае, сложность — это сколько вариантов надо рассмотреть программисту, который вносит исправление (или пытается просто понять что делает код).

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

и в любом случае, придется разбирать два варианта: то ли название не соответствует содержимому, то ли содержимое не соответствует названию.


IT> Например, Singleton сокращает количество вариантов поведения программного решения, но увеличивает сложность модификации кода.

в чем увеличение сложности модификации кода?

IT>Сроки меня интересуют. Но как разработчики этого добьются — нет.


разработчикам часто платят за время, поэтому вменяемого заказчика более чем интересует каким образом разработчики будут добиваться решения: оптимальным или не оптимальным.

как минимум заказчик поинтересуется, как тоже самое делают другие, как максимум может заказать аудит.

Еще раз попробую сформулировать основную мысль:

есть заказчик перед которым стоит какая-то задача, для решения данной задачи он заказывает программное решение.

программное решение — это может быть (по степени уменьшения):
система
сервис
программа
библиотека
модуль
класс
функция
строчка кода

заказчика при этом интересует:
1. когда будет результат (а именно когда он окончательно решит свою задачу)
2. насколько хорошо ПР будет решать задачу
a) причем именно ту задачу, которую заказчик подразумевал, а не ту задачу которую поняли разработчики
3. насколько заказчик сможет это ПР использовать

формализовывая и расписывая эти пункты получаем следующее:
4. ПР должно быстро разрабатываться (из п.1)
5. ПР должно решать поставленную задачу
a) правильно (из п.2)
b) быстро (из п.1)
c) с минимальными затратами ресурсов (из п. 3)
d) целиком (из п.2 и п.3)
* порядок именно такой (т.е. лучше правильно, чем быстро; лучше быстро, чем оптимально и т.д.)
6. ПР должно легко использоваться (из п.3, и п.1 — легче используется, меньше времени на обучение и ошибки)
7. ПР должно быть готовым к любым условиям использования (из п. 3)
а) ПР должно легко повторно использоваться (из п.3 — насколько это решение получится использовать в более большом комплексе, который уже есть (или будет) у заказчика)
b) ПР должно вести себя адекватно даже в непредвиденной ситуации (из п.3)
8. ПР должно легко модифицироваться (из п.2а)
a) ПР должно читаться (легко пониматься) человеком и компьютером
b) ПР должно быть достаточно формализовано (должна оставаться возможность автоматического\автоматизированного рефакторинга)

зы
с каким именно выводом ты не согласен?

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

K>Лично я не против многих путей. Просто, когда вдруг при этом ни с того ни с сего поминают про искусство, у меня возникают опасения, что сторонник какого-то пути не может объяснить чем этот путь лучше других.

Засада в том, что ты хочешь только логического объяснения. Ну не получится полностью разложить по полочкам то, что содержит в себе иррациональное. Однако, ты же не станешь отрицать существование красоты только потому, что она не вписыватся в построенную тобой логическую модель мира?
Я не знаю, как это объяснить, кроме как показать и сказать: смотри! Неужели у тебя никогда не возникали моменты, когда ты смотрел в код и видеел, что он просто красив?! — не важно, что он делал и для чего предназначался...

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

[...]

У тебя слишком много слов "должен". Получается, что шаг влево, шаг вправо — расстрел.

Имхо железных правил должно быть два:

Первое:
DG>1. Код должен решать поставленную задачу.
При этом постановка задачи должна быть исчерпывающей.

И второе: никакие другие правила, кроме этих двух, не должны быть абсолютными. Т.е. всё, что ты перечислил далее должно звучать как "хотелось бы, чтобы при этом также выполнялось...", но не более.

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

IT>1. single responsibility principle.

IT>Главным образом упрощает восприятие и процесс поддержки кода, т.к. программная сущность, удовлетворяющая такому принципу, отвечает за одну единственную функцию. Имеет прямое отношение к cohesion

И к coupling тоже. По сути, SRP это более интуитивно понятно сформулированное требование low coupling/high cohesion

IT> (как там правильно перевести).

Чаще всего переводять как зацепление.

F>У тебя слишком много слов "должен". Получается, что шаг влево, шаг вправо — расстрел.

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

> При этом постановка задачи должна быть исчерпывающей.

можно считать, что исчерпывающая постановка задачи начинается с этих должен.

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

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

DG>В данном случае, сложность — это сколько вариантов надо рассмотреть программисту, который вносит исправление (или пытается просто понять что делает код).

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

DG>если соглашение об именованиях не используется, то придется рассматривать все варианты, где данный класса/переменная используется, если же название правильное, то никаких вариантов разбирать не надо.

Слишком сложно. Не надо усложнять. Усложнять — просто, упрощать — сложно. (c) закон Мейера.

DG>и в любом случае, придется разбирать два варианта: то ли название не соответствует содержимому, то ли содержимое не соответствует названию.

Другими словами несоблюдение соглашений увеличивает сложность восприятия кода.

IT>> Например, Singleton сокращает количество вариантов поведения программного решения, но увеличивает сложность модификации кода.

DG>в чем увеличение сложности модификации кода?

Ну как же, это же Singleton Singleton — это способ прибивания гвоздями состояния к одному месту. Если модификация заключается в разнесении состояния по разным местам, то сложность модификации весьма увеличивается.

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

DG>разработчикам часто платят за время, поэтому вменяемого заказчика более чем интересует каким образом разработчики будут добиваться решения: оптимальным или не оптимальным.
DG>как минимум заказчик поинтересуется, как тоже самое делают другие, как максимум может заказать аудит.

Всё это очень правильно, но не имеет абсолютно никакого отношения, например, к атомарности. Ты же о ней хотел поговорить в этой теме?

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

DG>есть заказчик перед которым стоит какая-то задача, для решения данной задачи он заказывает программное решение.

Предыдущий шаг был сделан в правильном направлении. Этот куда-то в сторону. Огни разработки и заказчик — это как минимум два разных человека. Твоему заказчику на твои огни наплевать. Если не веришь мне, спроси у него самого.

http://rsdn.ru/forum/philosophy/2055616.1.aspx

Автор: minorlogic
Дата: 13.08.06

5 копеек

IT>Ты всё же определись для себя что же такое сложность — это "количество вариантов поведения программного решения" или "сколько вариантов надо рассмотреть программисту, который вносит исправление (или пытается просто понять что делает код)". Если сумеешь разобраться, то обещаю, что тебе полегчает

Сложность использования — сколько вариантов поведения ПП надо рассматривать (держать в голове) при попытке использования ПП.
Сложность реализации — сколько вариантов надо рассматривать при реализации ПП.
Сложность тестирования — сколько вариантов надо рассмотреть при тестировании ПП.
Сложность восприятия реализации — сколько вариантов надо рассмотреть при попытке понять реализацию.
Сложность внесения исправления — сколько вариантов надо рассмотреть для внесения изменения, и складывается из сложности восприятия решения и сложности реализации исправления

Рассмотрим все это на примере функции string.ToLower:

а) Сложность использования = 1, т.к. всего лишь один вариант поведения — на входе строка, на выходе — строка, где все буквы в нижнем регистре.
b) Сложность использования (уточненная) = 2, т.е. если посмотреть детальнее, то заметим, что мы еще забыли вариант с null-строкой, на которую функция кидает исключение, а не возвращает null (как могло быть для уменьшения вариантов поведения)
с) Сложность реализации — (зависит от реализации) возьмем для простоты Ascii-строки без использования символов выше 128-го.
при реализации в лоб — сложность = 128, для каждого символа определяется на какой символ он должен замениться
при думающей реализации — сложность = 2, т.к. для каждого символа есть лишь два варианта поведения:
если это большая английская буква, то заменить ее на маленькую,
иначе оставить символ как есть
от длины строки сложность решения не меняется, т.к. каждый символ обрабатывается независимо и одинаковым образом

string ToLower(string s)
{
   var builder = new StringBuilder(s.Length);
   foreach (var ch in s)
     builder.Append('A' <= ch && ch <= 'Z' ? (char)(0x20+(int)ch) : ch);
   return builder.ToString();
}

d) Сложность тестирования 6 + 128=134, т.к. несмотря на незавимость решения от длины все равно необходимо проверить на всякий случай — поведение ПП при следующих длинах:
1. null-строка,
2. пустая строка,
3. строка длины 1,
4. небольшая строка,
5. очень большая строка,
6. строка настолько большая, что кидает исключение по нехватке ресурсов
+ надо проверить, что каждый символ обрабатывается правильно (128 — вариантов)
e) Сложность восприятия реализации — 2 (если код выполняет все соглашения и т.д.), т.к. достаточно проверить два варианта, что убедиться, что функция имеет алгоритм — если большая буква, то поменять, иначе оставить как есть
f) Сложность внесения исправления при добавлении обработки русских букв = 4, и складывается из сложности восприятия решения=2 и сложности нового решения = 2, сложность низкая потому что обработка русских букв не зависит от обработки английских букв.

DG>>если соглашение об именованиях не используется, то придется рассматривать все варианты, где данный класса/переменная используется, если же название правильное, то никаких вариантов разбирать не надо.

IT>Слишком сложно. Не надо усложнять. Усложнять — просто, упрощать — сложно. (c) закон Мейера.

это для тебя такая концепция еще сложна, потому что ты ее пытаешься прожевать целиком, а надо двигаться последовательно.
соблюдая первый огонь

1. жуй по частям (сложные вещи делаются, как складывание простых элементов)

IT>Всё это очень правильно, но не имеет абсолютно никакого отношения, например, к атомарности. Ты же о ней хотел поговорить в этой теме?

да, я хотел поговорить в том числе и об атомарности, но не просто поболтать, а поговорить с точки зрения системного подхода.

Системный подход учит — что для того, чтобы можно было отделить важное от неважного необходимо как минимум:
1. сформулировать изначальную задачу (изначальная задача — это то, что заказчик хочет ПП)
2. научиться измерять исследуемое хотя бы качественно (сложность ПП — это кол-во вариантов необходимое для рассмотрения)

IT>Твоему заказчику на твои огни наплевать. Если не веришь мне, спроси у него самого.

Смотря как спрашивать.

Если спрашивать как "Тебе нужна атомарность?", то да ответ — нафиг не нужна, ты мне мою задачу лучше реши.
а если — как "Решение можно сделать атомарным или монолитным, атомарное тебе(заказчику) позволит решить твои задачи лучше — вот потому-то и потому-то, так какое тебе решение лучше сделать?", то ответ — да, атомарное.
особенно это важно бывает — когда пытаются сравнить несколько решений от разных производителей, которые решают одну и ту же задачу.

ps
может, конечно, по классификации выдрова, ты и я на разный класс заказчиков работаем:
ты больше на изиотов, я больше на привиред/профессионалов.

IT>Ты всё же определись для себя что же такое сложность — это "количество вариантов поведения программного решения" или "сколько вариантов надо рассмотреть программисту, который вносит исправление (или пытается просто понять что делает код)". Если сумеешь разобраться, то обещаю, что тебе полегчает

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

кол-во вариантов полного поведения ПП бесконечно — т.к. если брать тот же string.ToLower, то полное кол-во вариантов поведения функции для unicode-строки = кол-во вариантов символа * все возможные длины = 65536 * бесконечность.
у функции клонирования двумерного массива bool-ов полная сложность = 2 * бесконечность^2.

поэтому кол-во вариантов полного поведения ПП никого не интересует, т.к. оно сразу зашкаливает в бесконечность.
а всех интересует — кол-во рассматриваемых вариантов, соответственно для этого разработано куча методик, как свести к минимуму кол-во рассматриваемых вариантов; и большинство принципов(или огней в терминологии данного треда) программирования направлено именно на уменьшение рассматриваемых вариантов.

вот, например, разбор code style именно с этой позиции

...
именно из этого последовательно выросли:
1. разбиение кода на процедуры
2. запрет на goto
3. один оператор на строке
4. что код внутри блока должен быть сдвинуть относительно обрамляющего блока
5. отдельная часть кода должна влазить в монитор без необходимости скролинга
...
все это направленно на то, чтобы можно было двигаться следующим образом:
1. взять большой еще непонятный кусок
2. быстро выделить из него 3-7 подчастей (или если переформулировать в рамках данного поста: рассмотреть небольшое кол-во вариантов, которое формируется этими 3-7 подчастями)
3. каждую подчасть разобрать отдельно(по этому же алгоритму) и сформировать свою упрощенную модель этой части.
4. из полученных моделей скомпоновать свою модель уже всей части -> т.е. получить понимание этой части
...
соответственно:
1. зачем нужно разбиение на методы? чтобы свою модель строить уже на основе готового опыта: какие атомарные операции над этим объектом есть/допустимы
2. зачем нужны четкое название и комментарии на модуль, объект, метод? чтобы можно было не лезть внутрь модуля, объекта, метода, а сразу сформировать свою модель этой сущности
3. почему комментарии внутри метода вредны?
а) это симптом о том, что сам по себе код пишется такой, что он не понятен читающему
b) текста становится больше, и он начинает вываливаться из головы.
причем если код обычно формальный, и на основе его легко строить модели, то комментарии уже неформальные, и в них приходится вчитываться

полный вариант предпосылки code style

кстати очень интересно применить вот это

Сложность использования — сколько вариантов поведения ПП надо рассматривать (держать в голове) при попытке использования ПП.

к текущему интерфейсу кнопок для вставки тегов в сообщения


допустим я хочу вставить таблицу и ищу подходящий тег.
текущая сложность будет = 29 = 5 рассмотренных варианта на то, чтобы понять что никакой логики в расположении кнопок нет + 24 варианта полный перебор кнопок.

какие есть варианты улучшения? оценим их:

отсортировать кнопки по алфавиту = 8 = 3 рассмотренных варианта на то, чтобы понять что кнопки идут по алфавиту + 7 рассмотренных вариантов при поиске по алфавиту (быстрый переход в нужное место + небольшой поиск в окрестностях)
но улучшение сработает только если я угадал, как кнопка должна называться

объединить кнопки, т.е.
кнопки code/ccode/vb/php и т.д. объединить в одну code с выпадающим списком, в котором можно уточнить какой именно язык использовать
кнопки list/list=1/list=a объединить в одну list с выпадающим списком, в котором можно уточнить нумерацию пунктов
сложность уменьшится до 17 = 5 рассмотренных варианта на то, чтобы понять что никакой логики в расположении кнопок нет + 12 вариантов полного перебора кнопок

разбить визуально на группы:
раскраска текста: b/i/q/hr/code(+выпадающий список)
ссылка: img/url=/msdn/email
список: list(+выпадающий список)/*
посчитать варианты использования оставляю в качестве домашнего задания