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

Скорее это тоже следствие. Источником является комбинаторная сложность.

VGn>Источником является комбинаторная сложность.

комбинаторная сложность и кол-во вариантов поведения это не одно и тоже?

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

ГВ>>Чему обучать? Программированию?
DG>да, как учить программированию, причем не просто программированию, а хорошему стилю при программировании.

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

ГВ> И если уж говорить о стиле (который всегда соседствует с вкусом), то лучше всего его развивает не бормотание тайных метафор, а посещение музеев искусства и много-много практики.

хмм, а почему с тобой не согласны художественные школы, которые учат в том числе и стилю?
они ошибаются?

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

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

Это вопрос доверия.
Сэкономили на стоимости разработки, тратьте на аудит. К процессу разработки отношения не имеет.
Кто-то лезет под дно при покупке автомашины. Кто-то — нет.

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

ГВ>>Это общее внутрикомандное соглашение об оформлении текста программы.
DG>какие еще внутрикомандные соглашения желательны (кроме code style)? и в каком виде они должны формулироваться?

Зависит от команды. Они могут быть самыми невероятными — вплоть до dress code. Про code style я вспомнил, потому что такие соглашения есть почти у всех.

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

ГВ>> И если уж говорить о стиле (который всегда соседствует с вкусом), то лучше всего его развивает не бормотание тайных метафор, а посещение музеев искусства и много-много практики.

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

Я о технарях говорю. Хорошо, пусть не музеи искусства, а просто образцы инженерных решений.

ГВ>Зависит от команды. Они могут быть самыми невероятными — вплоть до dress code. Про code style я вспомнил, потому что такие соглашения есть почти у всех.

это ты ерничаешь, или серьезно?

ок, более конкретный вопрос: то, что static переменных лучше избегать — стоить записать в общекомандное соглашение или нет?

VGn>>Источником является комбинаторная сложность.

DG>комбинаторная сложность и кол-во вариантов поведения это не одно и тоже?

Количество вариантов поведения — результат комбинаторной сложности. (динамика vs статика), но в общем — да. Я ещё не достаточно углубился в ветку.

хорошо, т.е. твою текущую позицию я понял так:

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

я корректно сформулировал?

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

ГВ>>Зависит от команды. Они могут быть самыми невероятными — вплоть до dress code. Про code style я вспомнил, потому что такие соглашения есть почти у всех.
DG>это ты ерничаешь, или серьезно?

Естественно, серьёзно. Я всегда серьёзные вещи говорю полушутя, это вот дурь какую-нибудь вытворяю со страшно серьёзной миной.

DG>ок, более конкретный вопрос: то, что static переменных лучше избегать — стоить записать в общекомандное соглашение или нет?

ИМХО, не стоит. Потому что их не нужно специально избегать, иногда такие переменные очень полезны. Иногда они наоборот, вредны.

VGn>Количество вариантов поведения — результат комбинаторной сложности. (динамика vs статика), но в общем — да. Я ещё не достаточно углубился в ветку.

тогда как свежему человеку, у выражения a+b какая комбинаторная сложность?

ГВ>ИМХО, не стоит. Потому что их не нужно специально избегать, иногда такие переменные очень полезны. Иногда они наоборот, вредны.

и соответственно пытаться разобраться, когда стоит, когда не стоит — тоже не надо?
и если все-таки разобрали, то это не надо записывать?

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

DG>pps
DG>кстати, наверное, заказчик "Ariane 5 Flight 501" очень переживал, что не смотрел какую именно резьбу (какие единицы измерения) используют разработчики.

Просто ради исторической справедливости: так переживал, вероятно, заказчик Mars Surveyor. А Arian 5 была другая причина катастрофы -- там разработчики ПО не знали, чем Arian 5 отличается от Arian 4.

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

I>>В некоторых областях обучать лучше через лозунги

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

Я примерно это и имел ввиду.

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

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

OMG. Нет, не бесполезно передавать знания. Глупо ставить метафоры впереди всего. Метафоры на то и метафоры, что они выражают опыт в некоем определённом контексте. Вот как твой плакат с болтуном и шпионами. Так вот, до объяснения самого контекста метафоры будут только путать. Возвращаясь к плакату: если не знать контекста, то легко представить, что по телефону вообще разговаривать нельзя.

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


ГВ>>ИМХО, не стоит. Потому что их не нужно специально избегать, иногда такие переменные очень полезны. Иногда они наоборот, вредны.

DG>и соответственно пытаться разобраться, когда стоит, когда не стоит — тоже не надо?

Надо.

DG>и если все-таки разобрали, то это не надо записывать?

Надо. Но это отменяет необходимости разобраться.

ГВ>Надо. Но это отменяет необходимости разобраться.

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

DG>тогда как свежему человеку, у выражения a+b какая комбинаторная сложность?

Решил отвлечь меня на конечные автоматы? Имхо наша тема более абстрактна.

VGn>Это вопрос доверия.

а как же доверяй, но проверяй?

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