Re[2]: Как Вы боретесь с ошибками? - Философия программирования

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

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

AVK>>>Вот если я ее уже кому то отдал, то да. А если я ее только разрабатываю?

B>>Разрабатываешь все равно с целью получить стабильные интерфесы,
B>>которые не придется постоянно перелапачивать.

AVK>Ну то есть тесты надо писать в конце, когда уже все интерфейсы стабилизировались?

Например так.
Порядок (тесты->код или наоборот) для меня особой роли не играет.
Важно, чтобы в итоге тесты были.
Когда я отдаю стабильную версию на сторону (может быть коллега-сосед),
предпочитаю чтобы тесты были. Но в принципе не принципиально.

B>>В общем это абстрактный спор

AVK>А по мне так совершенно конкретный.

Конкретным он был бы, если бы вместе работали над одним проектом.
А без конкретики, нужны ли юнит-тесты или не нужны — спор не очень конструктивен.
Иначе я не могу понять, почему это интерфейсы нельзя зафиксировать настолько,
чтобы можно было задуматься о юнит тестах, а для тебя будет смешной мысль о том,
что интерфесы надо бы продумать и по возможности прийти к стабильному варианту.

B>>Верю, что в твоем конкретном случае юнит-тесты не работают,
B>>но это не повод мне, и другим, от него отказываться.

AVK>А я и не призываю никого отказываться. Я призываю голову включать, а не агитировать за совецкую власть.
Забавно, что и к тому же самому призываю

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

FDS>Угу, особенно хорошо получается, когда не уверен в том, что документация по контроллеру правильная... точнее уверен, что в ней ошибка.
FDS>Тогда уже вообще не понятно, что тестируешь: устройство или драйвер для него.
Ну от этого никто не застрахован, бывает и тесты ошибки содержут

в купе с шаблонами, если это С++.

FDS>О! В январе так делал. Правда на Delphi, а не на C#. Сначала я написал бо-о-о-ольшую процедуру (200-300 строк). Её предназначение было — распознавание зашумлённых шестнадцатиричных чисел, написанных от руки на неровной поверхности. Дальше у меня появились предложения по улучшению... я стал писать вложенные процедуры, по 50-70 строк. Дальше это всё отказалось стабильно и хорошо работать

. В итоге вся эта первоначальная процедура с вложенными функциями занимала почти 1000 строк.
Рефакторить всегда сложнее...

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

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

FDS>>Угу, особенно хорошо получается, когда не уверен в том, что документация по контроллеру правильная... точнее уверен, что в ней ошибка.
FDS>>Тогда уже вообще не понятно, что тестируешь: устройство или драйвер для него.
A>Ну от этого никто не застрахован, бывает и тесты ошибки содержут

Мда, это точно. Я однажды долго не мог найти ошибки в коде, а потом оказалось, что тест неправильные данные генерировал... сколько я времени убил потом, что бы они стали правильными! С тех пор не люблю UT.

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

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

FDS>>Ммм. А если их сложно напечатать, что делать?
FDS>>Например, 4-х мерная матрица 100х100х100х100 (помню, я так и не написал ту программу из-за того, что не смог нормально проанализировать её содержание)
FDS>>Или, скажем, граф с представлением в виде списков следования? Это ж замучиться распечатывать! (я форму специальную делал)

A>А что мешает в этом случае делать дамп в файл? Тесты даже могут сравнивать его с заранее правильным файлом.

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

: мол, файлы не всегда спасают

IT>>>3. Copy/Paste vs. повторное использование. Copy/Paste — это разносчик багов, что есть плохо. Но шизиловка, когда каждые две строчки кода оформляются в виде отдельного метода ни чем не лучше. Поэтому настоящие индейцы копипейстят, но только один раз. Если некоторый фрагмент кода повторяется уже в третий раз, то это хорошая причина для оформления его в виде отдельного метода.

FDS>>Хм. А вот что делать, если мне нужно реализовать процедуру умножения транспонированных матриц (очень просто, неправда ли?).
FDS>>Варианты реализации:

A>[skip]

FDS>>Какой из этих вариантов предпочтительней?
FDS>>И не будет ли после того, как написал два раза одинаковый код, мучительно вспоминать, а где же я его ещё писал-то?

A>inline спасет... я так думаю

в купе с шаблонами, если это С++.

А шаблоны тут зачем?
Т.е. вы предлагаете вариант со свойствами и объявлением метода доступа к элементу как inline?
Пожалуй, сойдёт. Только придётся в метод передавать указатель на метод доступа: не слишком красиво.
Вообще, я уже что-то подобное в ФП обсуждал. Только немного с другой стороны. Насколько я помню, мне всё-таки предложили довольно хорошее и, в общем-то, очевидное решение

FDS>>О! В январе так делал. Правда на Delphi, а не на C#. Сначала я написал бо-о-о-ольшую процедуру (200-300 строк). Её предназначение было — распознавание зашумлённых шестнадцатиричных чисел, написанных от руки на неровной поверхности. Дальше у меня появились предложения по улучшению... я стал писать вложенные процедуры, по 50-70 строк. Дальше это всё отказалось стабильно и хорошо работать

. В итоге вся эта первоначальная процедура с вложенными функциями занимала почти 1000 строк.
A>Рефакторить всегда сложнее...

А я про то же. Зачем писать крупные модули, если можно было сразу сделать мелкие? Правда, я очень торопился и постоянно менял алгоритм — это единственное, что является оправданием крупным модулям.

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

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

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

FDS>>Вот с этого начнём, точнее закончим. Не согласен

FDS>>Где прятаться багам, если методы до отупения просты? Представьте себе, у вас все методы из 3-5 строк. Ну 10 максимум, обычно.

B>У тебя никогда не было такого, что каждый отдельный метод на 3-5 строк делает
B>вроде все правильно, а вот в совокупности получается фигня?

Было. Это значит, что ты не понимаешь алгоритм расчётов или в одном из методов всё-таки допустил ошибку по невнимательности. Но точно такие же ошибки у меня получились бы и при использовании больших методов. Я просто специально статистику вёл в нескольких программах: ошибок стало меньше, а программировать стало субъективно (и объективно) проще.

Плюс, это может быть, если ты неправильно называешь методы: т.е. метод делает не то, что написано в его названии, или не только то. Короче говоря, тут уже вопрос не в твоей внимательности, а в твоей логике. Лично мне гораздо проще соблюдать логичность кода, чем держать в фокусе внимания большие куски кода. Плюс, отпадает необходимость программирования с использованием псевдокода: названия методов и есть этот псевдокод, остаётся только самый минимум комментариев.
Мелкие методы, к тому же, не дают сделать многих ошибок от усталости. У меня было раньше такое, что я невыспавшись писал код, разные части которого (сейчас — разные методы) просто перекрывались, совершенно случайно

. Например, часть следующего действия попадала в цикл из предыдущего действия

Что касается большого количества "странствующих" по методам параметров (не помню, как они по человечески называются), то Delphi и Nemerle позволяют писать вложенные функции и кол-во этих параметров уменьшается до 0. На C++/C# всё, конечно, хуже.

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

FDS>Ммм. А если их сложно напечатать, что делать?
FDS>Например, 4-х мерная матрица 100х100х100х100 (помню, я так и не написал ту программу из-за того, что не смог нормально проанализировать её содержание)
FDS>Или, скажем, граф с представлением в виде списков следования? Это ж замучиться распечатывать! (я форму специальную делал)

И как ты в конце концов решил эту проблему?

FDS>Хм. А вот что делать, если мне нужно реализовать процедуру умножения транспонированных матриц (очень просто, неправда ли?).
FDS>Варианты реализации:
...
FDS>Какой из этих вариантов предпочтительней?

9. Настоящие индейцы руководствуются прежде всего здравым смыслом.

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

FDS>Вот с этого начнём, точнее закончим. Не согласен

FDS>Где прятаться багам, если методы до отупения просты? Представьте себе, у вас все методы из 3-5 строк. Ну 10 максимум, обычно.

Это было отражено во втором пункте.

FDS>При этом есть одно условие: название вызываемого метода говорит о том, что этот метод делает, а этот метод делает только то, что сказано в названии (это, кстати, рекомендация Макконнелла). Тогда получаем кучу вот этих самых методов, которые просто и в которых не где прятаться багам, так как, фактически, такой код представляет собой обычный псевдокод.

Просматривая реализацию ты будешь вынужден скакать по всему коду взад вперёд. Это не удобно. Если объём метода не вредит понимабельности и не грозит потенциальными багами, то искуственно разбивать его на отдельные методы не имеет смысла.

FDS>Я почему это говорю, я не так давно пробовал (на C++) писать исключительно мелкими методами, как сказал, и скорость разработки у меня повысилась приблизительно в 1,5 раза (с отладкой). При этом большое количество багов из разряда логических ошибок перекочевало в разряд "забыл вызвать метод", "при кодировании использовал неправильный алгоритм расчётов". Кстати, в последнем случае, в мелких методах гораздо лучше видно несоответствие кода используемому алгоритму и несоответствие алгоритма решаемой задачи.

Исключительно мелкие методы — это тоже крайность, но другая. Ты решил одну проблем, но получил другую. В частности, как я уже сказал, понимать такой код сложнее.

FDS>Как вы это объясните?

Что именно? То что со временем твой метод превратился сначала в несколько методов, а потом в класс? Так вроде я именно об этом и говорю. Или нет?

FDS>Кстати, таких примеров из моей личной практики программирования до фига. Я имею ввиду, преимущества мельких методов над крупными, но с комментариями над каждой частью.

Честно говоря, я так и не понял, ты споришь или соглашаешься.

FDS> Например, год назад я писал рассчёт обратной задачи кинематики плоского манипулятора с замкнутой кинематикой (на C#) и заметил ошибку в реализации метода Ньютона только когда разбил его на много мелких методов. До этого же эта ошибка существовала чуть ли не с самого начала, я о ней знал, но думал совершенно на другие части программы.

И какой вывод из этого следует?

FDS>Может быть я вас неправильно понял?

Возможно ты просто путаешь декомпозицию метода с повторным более углублённым его переосмыслением.

FDS>Вот этот уродец (он и сейчас такой

):

А что получилось в результате?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

FDS>Вот с этого начнём, точнее закончим. Не согласен

FDS>Где прятаться багам, если методы до отупения просты? Представьте себе, у вас все методы из 3-5 строк. Ну 10 максимум, обычно.
FDS>При этом есть одно условие: название вызываемого метода говорит о том, что этот метод делает, а этот метод делает только то, что сказано в названии (это, кстати, рекомендация Макконнелла). Тогда получаем кучу вот этих самых методов, которые просто и в которых не где прятаться багам, так как, фактически, такой код представляет собой обычный псевдокод.

Всё это замечательно, только на практике когда таких методов несколько десятков, то уже начинаешь банально во всём этом сокровище путаться. Ведь каждый метод может иметь побочные эффекты. И часто бывает думаешь, вот здась кокой из методов: A() ил B() и C() последовательно, — вызывать. С одной стороны, A() имеет больший уровень абстракции A(), чем B() и C(), но с другой стороны, не факт, что у A() нет побочных эффектов, которые приведут к чему-то нехорошему в данном месте. Тогда мы идём в A() и смотрим, что там имеется, и охреневаем. Потому что A() кроме вызова B() и C() содержит так же вызов D() и правит поле q. И понеслись скачки по графу программы... И это всего лишь для написания одного метода!

Конечно, мне сейчас скажут там что-то про уровни абстракции, про разделение, декомпозицию, про классы. Но на практике опять же всё сложнее. Зачастую некоторые реальные вещи бывают жутко связанными. Можно их "разделить" искусственно, но тогда увеличится количество межклассовых вызовов, и тогда мы перейдём от запутанного графа методов к запутанному графу классов...

ЛИчно мне такая вот нехорошесть встретилась при написании грида. Конечно, кое-в-чём виноваты MS (руки им за такой кривой бандинг поотрывать мало!), но основные трудности были именно из-за специфики самого контрола. Ну не выражается красиво его логика в терминах ООП! Вообще, написание сложных контролов натолкнуло меня на мысль, что язык вроде C# не соджержит сам по себе хороших абстракций для таких вещей. Что же предложить в замен я не знаю.

... << RSDN@Home 1.2.0 alpha rev. 672>>

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

_>Проведение рефакторинга системы без юнит-тестов — это bugs*bugs при котором bugs -> infinity

Э-э-э, а при чём тут кортеж из двух bugs, да ещё и функция, отображающая bugs в infinity

(

)

... << RSDN@Home 1.2.0 alpha rev. 672>>

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

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

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

FDS>>>Например, 4-х мерная матрица 100х100х100х100 (помню, я так и не написал ту программу из-за того, что не смог нормально проанализировать её содержание)
A>>А что мешает в этом случае делать дамп в файл? Тесты даже могут сравнивать его с заранее правильным файлом.
FDS>Мешает то, что никто не знает, какой он правильный. Для этого его сначала вручную посчитать надо — спасибо, не хочу.
[skip]
FDS>Т.е. речь идёт о том, что в файл информацию сохранять нет смысла, потому что легче сразу обрабатывать некоторую её часть по запросу тестировщика и выдавать в соотв. виде. Т.е. я просто забыл поесть и стал придираться к словам

: мол, файлы не всегда спасают
Правильный — это для тестов, а файл — для удобства просмотра (ведь можно хоть после каждой итерации новый файл писать и потом
diff-ом его, если больше одной ячейки за итерацию меняется... Или наоброт один файл сделать и например FAR будет видеть что файл
изменился и перечитывать, а у тебя будет выглядеть как в реалтайме меняющаяся картина матрицы...

FDS>>>Какой из этих вариантов предпочтительней?
FDS>>>И не будет ли после того, как написал два раза одинаковый код, мучительно вспоминать, а где же я его ещё писал-то?

A>>inline спасет... я так думаю

в купе с шаблонами, если это С++.
FDS>А шаблоны тут зачем?
FDS>3. Записать метод с передачей в него флагов транспонированности, но тогда там тоже будет небольшой copy/paste Минус: пользователь запутывается с флагами и становится тяжело использовать метод или необходимо написать 4 доп. метода, вызывающих этот для разных вариантов перемножений

Но вместо функции с параметрами делаем шаблон с параметрами и для разных параметров шаблон раскроется в соотвествующую
функцию http://www.boost.org/libs/mpl/doc/tutorial/dimensional-analysis.html

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

Практически все уже сказано. Только скромно добавлю, что настоящий индеец следует также и завету Кента Бека по парному программированию: зачастую свежий глаз напарника-индейца, который по умолчанию критично, в отличие от вас, расположен к наблюдаемому коду, быстро ловит проектную ошибку в вашем коде. Соответственно, необходимо избавиться от ревнительности: вашему коду полезен рефакторинг чужими руками. Причем, как заметил по себе, наиболее эффективно работаешь, когда твой напарник "посильнее" тебя — подтягиваешься до него.

... << RSDN@Home 1.2.0 alpha rev. 676>>

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

FDS>>Или, скажем, граф с представлением в виде списков следования? Это ж замучиться распечатывать! (я форму специальную делал)

IT>И как ты в конце концов решил эту проблему?

Формой с методами обработки информации. Я ей указывал на этапе исполнения, что обрабатывать. Она обрабатывала часть данных и выдавала мне некоторый результат. А в файл выводить, там были бы сотни килобайт и ничего не понятно. Обрабатывать всё: слишком долго и опять же, много ненужных данных.

IT>9. Настоящие индейцы руководствуются прежде всего здравым смыслом.

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

FDS>>Где прятаться багам, если методы до отупения просты? Представьте себе, у вас все методы из 3-5 строк. Ну 10 максимум, обычно.

IT>Это было отражено во втором пункте.

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

IT>Просматривая реализацию ты будешь вынужден скакать по всему коду взад вперёд. Это не удобно. Если объём метода не вредит понимабельности и не грозит потенциальными багами, то искуственно разбивать его на отдельные методы не имеет смысла.

Если группировать функции, то скачки можно минимизировать.
Дело в том, что у меня объём кода всегда грозит багами

Поэтому и стал об этом писать. Т.е. у вас это не так?

FDS>>Я почему это говорю, я не так давно пробовал (на C++) писать исключительно мелкими методами, как сказал, и скорость разработки у меня повысилась приблизительно в 1,5 раза (с отладкой). При этом большое количество багов из разряда логических ошибок перекочевало в разряд "забыл вызвать метод", "при кодировании использовал неправильный алгоритм расчётов". Кстати, в последнем случае, в мелких методах гораздо лучше видно несоответствие кода используемому алгоритму и несоответствие алгоритма решаемой задачи.

IT>Исключительно мелкие методы — это тоже крайность, но другая. Ты решил одну проблем, но получил другую. В частности, как я уже сказал, понимать такой код сложнее.

Вот с моей точки зрения, мешают пониманию только очень редкие скачки между функциями. Тут ведь ещё в чём вопрос.
Каждый метод можно понять без изучения вызываемых им методов, просто по названиям (не всегда, правда). Поэтому методы изучаются последовательно и скачков получается очень мало. Тем более, сами методы группируются так, чтобы они были рядом.
Поэтому, лично мне кажется, понимать такой код проще, правда если заранее знаешь, что он написан именно в том стиле, о каком я говорю: т.е. название метода полностью описывает совершаемые им действия.

FDS>> Например, год назад я писал рассчёт обратной задачи кинематики плоского манипулятора с замкнутой кинематикой (на C#) и заметил ошибку в реализации метода Ньютона только когда разбил его на много мелких методов. До этого же эта ошибка существовала чуть ли не с самого начала, я о ней знал, но думал совершенно на другие части программы.

IT>И какой вывод из этого следует?

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

FDS>>Может быть я вас неправильно понял?

IT>Возможно ты просто путаешь декомпозицию метода с повторным более углублённым его переосмыслением.

Нет, не путаю

Если декомпозицию делать сразу, то и смысл быстрее выявляется и он лежит на поверхности. В этом весь и прикол. Что не нужно повторного более глубокого осмысления. Оно и так насатаёт

FDS>>Вот этот уродец (он и сейчас такой

):

IT>А что получилось в результате?

Сам код я менять не стал. Всё хорошо и работает, а больше он вряд ли понадобится. Т.е. он такой и есть, я в скобках написал. Но именно на эту функцию я убил больше всего (и большую часть) времени на отладке.

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

IT>1. Настоящий индеец прежде всего заходит в меню Debug и в диалоге Exceptions включает галку Thrown на CLR Exceptions для managed языков. Это позволяет сэкономить не просто хучу, а туеву хучу времени при поиске ошибок. Отсюда следствие — настоящие индейцы не используют логику на исключениях, иначе весь кайф пропадает.

Не знаю что там за ошибки такие ловятся, но по крайней мере зверя ContextSwitchDeadLock я буду включать только через свой труп — он мне столько нервов попортил... Находишь с трудом ошибку, доходишь до неё через кучу махинаций с брейкпоинтами, а потом раз и выбрасывается исключение, что мол где-то там в CLR 60 сек. прошло, перезагружай прогу... так и поседеть недолго

.

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

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

IT>6. Автоматическое тестирование. Настоящие индейцы обязательно пишут тесты для тестирования библиотечного кода, который используется другими частями приложения. Прикладной код тоже иногда может автоматически тестироваться, но это может оказаться банально дорого, т.к. тестирование библиотечного кода и например UI — это принципиально разные вещи. Юнит тест для библиотеки не стоит практически ничего, подготовка и периодическое изменение теста для UI может занять больше времени, чем работа над самим UI.

Золотые слова! Только что-то сомневаюсь, что покрытие библиотечного кода юнит тестами будет отлавливать много багов. У меня лично в таком коде очень редко ошибки появляются, а те что появляются — и без ЮТ о себе заявляют очень быстро, т.к. общие методы используются часто. Но, конечно, и создавать тесты для такого кода очень просто.

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

FDS>>Т.е. речь идёт о том, что в файл информацию сохранять нет смысла, потому что легче сразу обрабатывать некоторую её часть по запросу тестировщика и выдавать в соотв. виде. Т.е. я просто забыл поесть и стал придираться к словам

: мол, файлы не всегда спасают
A>Правильный — это для тестов, а файл — для удобства просмотра (ведь можно хоть после каждой итерации новый файл писать и потом
A>diff-ом его, если больше одной ячейки за итерацию меняется... Или наоброт один файл сделать и например FAR будет видеть что файл
A>изменился и перечитывать, а у тебя будет выглядеть как в реалтайме меняющаяся картина матрицы...

Это не матрица, но всё равно.
Просто его потом ведь ещё замучеешься анализировать. Т.е. сделал diff, нашёл, какие ячейки изменились. Но тут же стал интересоваться некоторой другой информацией. А найти её можно только линейный поиском по файлу

А в рантайме ячейки хранят ссылки, которые программе легко считать и вывести информацию.

FDS>>3. Записать метод с передачей в него флагов транспонированности, но тогда там тоже будет небольшой copy/paste Минус: пользователь запутывается с флагами и становится тяжело использовать метод или необходимо написать 4 доп. метода, вызывающих этот для разных вариантов перемножений

A>Но вместо функции с параметрами делаем шаблон с параметрами и для разных параметров шаблон раскроется в соотвествующую
A>функцию http://www.boost.org/libs/mpl/doc/tutorial/dimensional-analysis.html

Ужос! Хотя это не совсем то, что я думал, если я правильно понял.

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

K>Всё это замечательно, только на практике когда таких методов несколько десятков, то уже начинаешь банально во всём этом сокровище путаться. Ведь каждый метод может иметь побочные эффекты. И часто бывает думаешь, вот здась кокой из методов: A() ил B() и C() последовательно, — вызывать. С одной стороны, A() имеет больший уровень абстракции A(), чем B() и C(), но с другой стороны, не факт, что у A() нет побочных эффектов, которые приведут к чему-то нехорошему в данном месте. Тогда мы идём в A() и смотрим, что там имеется, и охреневаем. Потому что A() кроме вызова B() и C() содержит так же вызов D() и правит поле q. И понеслись скачки по графу программы... И это всего лишь для написания одного метода!

Замечательно. Я так НИКОГДА не пишу. В этом весь и смысл. Что у A нет побочных эффектов, у неё есть только тот эффект, который стоит в названии метода, он может оказаться побочным в смысле функционального подхода, но не в смысле логики метода. Иногда бывает, что всё время они лезут (побочные эффекты), но если подумать, лично пока мне всегда удавалось избавиться от них. Иногда это требует написания дополнительно класса.

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

K>Конечно, мне сейчас скажут там что-то про уровни абстракции, про разделение, декомпозицию, про классы. Но на практике опять же всё сложнее. Зачастую некоторые реальные вещи бывают жутко связанными. Можно их "разделить" искусственно, но тогда увеличится количество межклассовых вызовов, и тогда мы перейдём от запутанного графа методов к запутанному графу классов...

Самое интересное, что именно это у меня получается на C#. Причём только на C#.

Мне хотелось бы услышать пример того, какие вещи являются жутко связанными. Честно говоря я себе это очень слабо представляю. Скорее всего это связано с уже "неправильно" разработанными сторонними библиотеками. Я не верю, что если программист может составить алгоритм работы программы, то задача уменьшения связности методов/классов не может быть разрешена. Иначе бы он просто не мог держать в голове весь этот алгоритм.
Т.е. речь идёт именно о правильной декомпозиции.

K>ЛИчно мне такая вот нехорошесть встретилась при написании грида. Конечно, кое-в-чём виноваты MS (руки им за такой кривой бандинг поотрывать мало!), но основные трудности были именно из-за специфики самого контрола. Ну не выражается красиво его логика в терминах ООП! Вообще, написание сложных контролов натолкнуло меня на мысль, что язык вроде C# не соджержит сам по себе хороших абстракций для таких вещей. Что же предложить в замен я не знаю.

Можно подробнее. Я не очень понимаю, в чём там дело. А уж по C# я тут выше уже вопил (мне даже смайликов наставили), что не получается на нём нормально программировать

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

IT>>1. Настоящий индеец прежде всего заходит в меню Debug и в диалоге Exceptions включает галку Thrown на CLR Exceptions для managed языков. Это позволяет сэкономить не просто хучу, а туеву хучу времени при поиске ошибок. Отсюда следствие — настоящие индейцы не используют логику на исключениях, иначе весь кайф пропадает.

_M>Не знаю что там за ошибки такие ловятся,

Это самый быстрый способ локализовать проблему. Быстрее просто не бывает.

_M>но по крайней мере зверя ContextSwitchDeadLock я буду включать только через свой труп — он мне столько нервов попортил...

Не включай. Я лично вообще такого исключения ни разу в жизни не видел.

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

_M>Согласен, только иногда существуют такие блоки в этих линейных методах, которым очень легко придумать название отдельного метода и оно очень четко функциональность этого блока описывает... В общем в таком случае получается, что дробление метода только увеличивает понятность, т.к. с хранением этих мелких методов почему-то проблем не возникает — их легко находить, а на практике и вообще не надо их находить, т.к. достаточно посмотреть на название метода, чтобы понять, что там делается. И совершенно не важно, кто этот метод вызывает, а кто вызывается им.

Да ради бога. Я лишь имею в виду, что разделение на методы ради разделения на методы там где это не нужно, это так же плохо как и неразделение на методы, там где это нужно.

_M>Золотые слова! Только что-то сомневаюсь, что покрытие библиотечного кода юнит тестами будет отлавливать много багов. У меня лично в таком коде очень редко ошибки появляются, а те что появляются — и без ЮТ о себе заявляют очень быстро, т.к. общие методы используются часто. Но, конечно, и создавать тесты для такого кода очень просто.

Редкость и быстрота отлова — это плохие отговорки. Достаточно однажды, например, написать новый функционал, который слегка где-нибудь сломает старый, закомитить результат и уехать в отпуск на месяц. Если такой баг заблокирует работу нескольких человек, то либо они достанут тебя с берега лазурного моря и испортят весь кайф, либо порвут тебе жопу на немецкий крест когда ты вернёшься. Другими словами, дело не в простоте отлова и редкости. Дело в уровне ответственности. Чем чаще используется один и тот же код, тем больше должно быть контроля, что его изменение не приведёт к фатальным или блокирующим последствиям.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IT>>И как ты в конце концов решил эту проблему?

FDS>Формой с методами обработки информации.

Т.е. написал для отладки отдельный гуй?

IT>>Это было отражено во втором пункте.

FDS>Вот я и не понял. Как же он хорошо отформатирован, если он большой?

Форматирование кода и его размер никак не пересекаются. Под форматированием подразумеваются отступы, выравнивания и прочая мелочь, делающая код лучше для восприятия.

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

Всё же я не пойму с чем ты споришь. Если тебя начинает что-то напрягать, то бери и выноси в отдельные методы и классы. Но делать это только ради того, чтобы вынести каждые две строчки в отдельный метод не имеет никакого смысла.

Повторю свою мысль ещё раз. Нет проблем с размером методов, есть проблемы, которые пораждают запутанный код этих методов. Если код линеен и прозрачен, то смысл разделять длинный метод на много методов не имеет смысла. Так понятнее?

FDS>Если группировать функции, то скачки можно минимизировать.
FDS>Дело в том, что у меня объём кода всегда грозит багами

Поэтому и стал об этом писать. Т.е. у вас это не так?

Объём кода никуда не девается. Уменьшить объём кода можно только повторным его использованием и принципиально другими алгоритмами. Декомпозиция метода не уменьшает кода, декомпозиция позволяет выделить небольшие более менее самодостаточные блоки. Но, во-первых, это не обязательно делать методами, во-вторых, это может привести к передаче контекста, что выльется в длинный список параметров.

Кстати, один из способов, позволяющих решить эту проблему, это локальные функции. К сожалению, в C# этого нет, и пока, как я понял не планируется.

IT>>И какой вывод из этого следует?

FDS>Вывод из этого следует, что не стоило писать по вашей рекомендации. Как раз делал как вы говорили и получил незаметную ошибку.

Не факт, что ты получил незаметную ошибку именно по-этому.

IT>>Возможно ты просто путаешь декомпозицию метода с повторным более углублённым его переосмыслением.

FDS>Нет, не путаю

Убейте меня застрелите. Я не понимаю как декомпозиция метода позволяет мне глубже осмыслить алгоритм над которым я работаю

... << RSDN@Home 1.2.0 alpha rev. 0>>

От:	FDSC	consp11.github.io блог
Дата:	29.03.07 16:35
Оценка:

	От:	bkat
	Дата:	29.03.07 17:11
	Оценка:	+1

	От:	bkat
	Дата:	29.03.07 17:20
	Оценка:	+1

	От:	aka50
	Дата:	29.03.07 17:24
	Оценка:

	От:	aka50
	Дата:	29.03.07 17:33
	Оценка:

От:	konsoletyper	https://github.com/konsoletyper
Дата:	29.03.07 18:30
Оценка:

От:	rsn81	http://rsn81.wordpress.com
Дата:	29.03.07 18:40
Оценка:	+1

	От:	_Mihail
	Дата:	29.03.07 18:45
	Оценка:	33 (1) +2

От:	IT	linq2db.com
Дата:	29.03.07 19:09
Оценка:	6 (1) +2