Re[14]: Огни разработки
От: Юрий Жмеренецкий ICQ 380412032
Дата: 11.07.09 08:47
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

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


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


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


Это не варианты поведения, а состояния. Если взять строку, то у нее вариантов поведения — три: пустая, непустая и полная под завязку. Для каждого варианта определен определен свой набор применимых операций и множество состояний. Выполнение какой-либо операции может привести к переходу в другое состояние, которое не принадлежит текущему варианту поведения.

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

Это опять же состояния, коих декартово произведение множеcтва значений всех "геттеров"

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

+1, только у меня терминология отличается.
Re[15]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 11.07.09 09:14
Оценка:
ЮЖ>+1, только у меня терминология отличается.

согласен, это лишь спор о терминах
Re[14]: Огни разработки
От: IT Россия linq2db.com
Дата: 11.07.09 17:32
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

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


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


Какое это имеет отношения, например, к SRP?

DG>Сложность реализации — сколько вариантов надо рассматривать при реализации ПП.


Это зависит от базовой сложности системы + количество вариантов, которые добавляются при выборе тех или иных способов решения поставленной задачи.

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


Какое это имеет отношения к SRP?

DG>Сложность восприятия реализации — сколько вариантов надо рассмотреть при попытке понять реализацию.


См. пунк 2.

DG>Сложность внесения исправления — сколько вариантов надо рассмотреть для внесения изменения, и складывается из сложности восприятия решения и сложности реализации исправления


Какая разница между сложность внесения исправления и сложностью реализации исправления?

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

DG>соблюдая первый огонь

Вот об этом я тебе и говорю. Знаешь почему у тебя каша в голове? Потому что ты смешал в одну кучу сложность самого продукта и сложность разрабатываемого кода. Попробуй разделить эти вещи и сконцентрироваться на коде. И тогда ты увидишь, что все принципы, которые ты озвучил в самом начале относятся именно к коду и могут быть разложены по полочкам в терминах сложности кода.
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 11.07.09 18:14
Оценка: +1
IT>Какое это имеет отношения, например, к SRP?

SRP уменьшает кол-во рассматриваемых вариантов, и поэтому уменьшает сложность использования, реализации, внесения исправления и тестирования ПП.

потому что если мы возьмем responsibility A со сложностью Na и responsibility B со сложностью Nb,
и реализуем их вместе, то сложность получится Na*Nb,
если же реализуем по отдельности, то сложность будет Na+Nb

IT> Знаешь почему у тебя каша в голове?


с чего ты решил что у меня каша в голове?

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


System.Windows.Forms.Control — это продукт или код?

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


ну, да — я согласен, что они хорошо раскладываются в терминах введенной мной сложности.
о чем спор?
Re[16]: Огни разработки
От: IT Россия linq2db.com
Дата: 11.07.09 21:49
Оценка:
Здравствуйте, DarkGray, Вы писали:

IT>> Знаешь почему у тебя каша в голове?

DG>с чего ты решил что у меня каша в голове?

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

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


DG>System.Windows.Forms.Control — это продукт или код?


Смотря с какой стороны смотреть. Для тебя лично — это инструмент.

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


DG>ну, да — я согласен, что они хорошо раскладываются в терминах введенной мной сложности.


Ещё раз повторяю. Введённая тобой определение сложности сильно ограничено. А попытка прилепить к ней количественную меру мягко говоря нежизнеспособна.
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 00:09
Оценка:
IT>Ещё раз повторяю. Введённая тобой определение сложности сильно ограничено. А попытка прилепить к ней количественную меру мягко говоря нежизнеспособна.

пока это лишь слова.
раз есть ограничение, то покажи его, покажи нежизнеспособность.
Re[18]: Огни разработки
От: IT Россия linq2db.com
Дата: 12.07.09 04:31
Оценка:
Здравствуйте, DarkGray, Вы писали:

IT>>Ещё раз повторяю. Введённая тобой определение сложности сильно ограничено. А попытка прилепить к ней количественную меру мягко говоря нежизнеспособна.


DG>пока это лишь слова.

DG>раз есть ограничение, то покажи его, покажи нежизнеспособность.

Например, один и тот же код может быть простым для тебя, но сложным для меня при одном и том же (как ты там говоришь?) количестве вариантов поведения ПП. Это может происходить потому, что я не имею достаточный уровень обучения и мне нужно больше усилий для того, чтобы понять этот код. Т.е. рассматриваемый нами код имеет ещё и сложность обучения, проще говоря порог вхождения.
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 08:04
Оценка:
IT>Т.е. рассматриваемый нами код имеет ещё и сложность обучения, проще говоря порог вхождения.

и в чем измеряется сложность обучения? разве не в кол-ве вариантов которые надо зазубрить (запомнить)?
Re[20]: Огни разработки
От: FR  
Дата: 12.07.09 08:53
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>и в чем измеряется сложность обучения? разве не в кол-ве вариантов которые надо зазубрить (запомнить)?


Нет, если человек не понимает наример что такое указатель то никакая зубрежка ему не поможет.
Re[21]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 09:12
Оценка:
Здравствуйте, FR, Вы писали:

DG>>и в чем измеряется сложность обучения? разве не в кол-ве вариантов которые надо зазубрить (запомнить)?


FR>Нет, если человек не понимает наример что такое указатель то никакая зубрежка ему не поможет.


Ты сильно не прав.
Re[22]: Огни разработки
От: FR  
Дата: 12.07.09 09:19
Оценка:
Здравствуйте, Ikemefula, Вы писали:

FR>>Нет, если человек не понимает наример что такое указатель то никакая зубрежка ему не поможет.


I>Ты сильно не прав.


Угу наполовину беременный это нормально.
Re[20]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 09:23
Оценка:
Здравствуйте, DarkGray, Вы писали:


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


DG>и в чем измеряется сложность обучения? разве не в кол-ве вариантов которые надо зазубрить (запомнить)?


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

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

И тут есть один неприятный нюанс — нельзя просто объяснить нЕчто что бы поднять этот уровень. Нужно время при чем, не только время на изучение, использование, но и время на отдых, который тем больше чем более новая, необычная была информация.
Re[14]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 09:29
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


We know how many beans make five
Re: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 09:34
Оценка:
Здравствуйте, DarkGray, Вы писали:


DG>хочется собрать в одном месте, какие концепции(стремления) применяются в программировании (или про что надо помнить при программировании)


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

DG>пока не могу сформулировать что такое именно стремление, попробую по ходу.


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


Это информация примерно такая — тому, кто не в теме, еще рано, а тому, кто в теме, уже без толку.


DG>

DG>время будет — добавлю и структурирую, пока все валом записываю


Если бы ты понимал, что там у тебя, то выдывал бы в структурированом виде
Re[2]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 09:41
Оценка:
I>Если бы ты понимал, что там у тебя, то выдывал бы в структурированом виде

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

могу провести аналогию:
можно понимать как написать программу, но появление готового кода — все равно потребует время.
Re[23]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 09:50
Оценка:
Здравствуйте, FR, Вы писали:

FR>>>Нет, если человек не понимает наример что такое указатель то никакая зубрежка ему не поможет.


I>>Ты сильно не прав.


FR>Угу наполовину беременный это нормально.


Я не понял что ты этим хотел сказать. Вероятно, это шумы подсознания возникшие при попытке спросить "Почему ?"

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

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

Т.е. твой пример с указателями это тавтология(!A || A), потому что реально тебе было лень сформулировать более внятно.
Re[24]: Огни разработки
От: FR  
Дата: 12.07.09 09:56
Оценка:
Здравствуйте, Ikemefula, Вы писали:


I>Я не понял что ты этим хотел сказать. Вероятно, это шумы подсознания возникшие при попытке спросить "Почему ?"


I>Объясни, что ты вкладывал в понятие указатель, и поймешь, что указатели там ни при чем.


Там перед словом "указатели" было слово "например", указатели тут непричем. Можешь туда же подставить
свои любимые виртуальные функции или замыкания.

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

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


Нет это уже совсем другое.
Re[24]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 09:57
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>Т.е. твой пример с указателями это тавтология(!A || A), потому что реально тебе было лень сформулировать более внятно.


И даже так может быть — указатели не понимает и это никак не мешает и чел будет крут аки господь бог.
Re[25]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 10:08
Оценка: :)
Здравствуйте, FR, Вы писали:


FR>Там перед словом "указатели" было слово "например", указатели тут непричем. Можешь туда же подставить

FR>свои любимые виртуальные функции или замыкания.

Ты привел плохой пример.

Пример про вирт. методы такой же плохой как и про указатели, а вот замыкания это то что нужно.

FR>Просто это хороший пример что в обучении без качественных скачков не обойтись, поэтому

FR>зубрежка часто полностью бесполезна.

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

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


FR>Нет это уже совсем другое.


Это то же самое.
Re[3]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 11:08
Оценка:
Здравствуйте, DarkGray, Вы писали:

I>>Если бы ты понимал, что там у тебя, то выдывал бы в структурированом виде


DG>могу выдать в структурированном виде, но это требует от меня время, которого у меня прямо сейчас нет.


В том то и проблема, что тебе надо время для структурирования. Когда человек хорошо осваивает какой то вопрос, ему не надо время на структутирование.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.