Re: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.07.09 15:42
Оценка: 66 (5) +1 -2 :))) :))) :))) :)
Здравствуйте, DarkGray, Вы писали:

DG>исходный пост http://blog.metatech.ru/post/ogni-razrabotki.aspx


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


Вообще говоря, это не "огни", а лозунги. ИМХО, руководствоваться ими в практической деятельности (именно руководствоваться, а не просто знать о существовании), это "надо совсем головы не иметь". Понимаешь, можно вбить ровно один гвоздь, и выработать на этом несколько таких агитпроповских высказываний:

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

И так далее. Вы, правда, "хотите поговорить об этом"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: О! Ещё огонёк придумался
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.07.09 16:46
Оценка: :))) :))
Русские аббревиатуры не заслуженно обойдены вниманием. Ну что за безобразие: KISS есть, а, кхм... нет. В общем, так, ловите ещё огонёк: "полное исследование задачи дополняет аргументацию". Аббревиатуру сами придумайте.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.07.09 12:03
Оценка: 24 (1) +1 :))
Здравствуйте, Klapaucius, Вы писали:

K>Дело в том, что в искусстве нет неправильных путей.


Ой ли?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 07.07.09 08:19
Оценка: 17 (4)
исходный пост http://blog.metatech.ru/post/ogni-razrabotki.aspx

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

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

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

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

навскидку:
1. unix-way(Пусть каждая программа делает одну вещь, но хорошо)
а) single responsibility principle
2. premature optimization is the root of all evil
3. любую проблему можно решить путём введения дополнительного абстрактного слоя (кроме проблемы слишком большого количества абстрактных слоёв).
4. Don't Repeat Yourself (acronym DRY, also known as Single Point of Truth and Single Point of Maintenance)
а) single point of knowledge
5. Keep it simple, stupid (acronym KISS), "Не плодить сущностей без необходимости." (Бритва Оккама)
а) кода должно быть чем меньше, тем лучше
6. Код должен читаться (легко пониматься)
7. Код должен не мешать повторному использованию
8. Атомарность
9. Связность и связанность
а) Tell, don't ask
10. Код должен вести себя адекватно даже в непредвиденной ситуации
а) безопасность исключений
11. Время разработки
12. Время выполнения
13. Оптимальность выполнения
14. SOLID: An abbreviation for five basic class design principles in Object-Oriented-Design: Single responsibility principle, Open/closed principle, Liskov substitution principle, Interface segregation principle, Dependency inversion principle
15. GRASP (англ. General Responsibility Assignment Software Patterns (общие образцы распределения обязанностей)) — паттерны, используемые в объектно-ориентированном проектировании для решения общих задач по назначению обязанностей классам и объектам.
16 CoC (Convention over configuration) — http://en.wikipedia.org/wiki/Convention_over_configuration
17. get, don't set — формируй новую реальность, а не меняй имеющуюся
18. "утверждение"(кусок кода) должно быть самодостаточным (требовать как можно меньше обращений к внешним справочникам)
19. число поддерживаемых внешних вариантов должно быть как можно больше, число внутренних вариантов поведения как можно меньше
20. полнота (код, по возможности, должен уметь обрабатывать все варианты входной информации)
21. there's more than one way to do it
a) There should be one-- and preferably only one --obvious way to do it.
22. структура кода должна быть формализованной (достаточно понятной для автоматики)
а) должна оставаться возможность автоматического\автоматизированного рефакторинга

Огни которые применяются в разных языках/подходах и т.д.
1) python: The Zen of Python (import this)
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let's do more of those!
2)*nix: Unix-way
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
there's more than one way to do it
все есть файл
http://www.freesource.info/wiki/Stat'ja_Klassicheskijj_Unix_Way
зы
время будет — добавлю и структурирую, пока все валом записываю

Re: Огни разработки
От: IT Россия linq2db.com
Дата: 07.07.09 15:51
Оценка: +3 :)
Здравствуйте, DarkGray, Вы писали:

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


Печальнее всего то, что знание всех этих принципов никак не защищает от ошибок и глупостей
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Огни разработки
От: IT Россия linq2db.com
Дата: 07.07.09 18:14
Оценка: 11 (2) +1
Здравствуйте, DarkGray, Вы писали:

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


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


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

Ну, например.

1. single responsibility principle.

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

2. premature optimization is the root of all evil.

Любая оптимизация усложняет код в разы. Преждевременная оптимизация усложняет код в разы, не решая при этом никаких других проблем. Т.е. при premature optimization мы вносим дополнительное усложнение в код, не получая ничего взамен.

и т.д.

В результате может оказаться, что этот список базвордов можно сократить как минимум вдвое и увидеть где они пересекаются и дополняют друг друга, а где противоречат и почему.
Если нам не помогут, то мы тоже никого не пощадим.
Re: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.07.09 08:32
Оценка: 5 (1) +2
Здравствуйте, DarkGray, Вы писали:

DG>исходный пост http://blog.metatech.ru/post/ogni-razrabotki.aspx


DG>навскидку:


Я не заметил самого важного "огонька": "Программа должна работать!" (т.е. делать именно то, за что заплатили ее заказчики/покупатели).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[3]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.07.09 20:56
Оценка: -1 :))
F>У тебя слишком много слов "должен". Получается, что шаг влево, шаг вправо — расстрел.

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

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


можно считать, что исчерпывающая постановка задачи начинается с этих должен.
Re[6]: Огни разработки
От: IT Россия linq2db.com
Дата: 13.07.09 04:29
Оценка: +2 :)
Здравствуйте, Ikemefula, Вы писали:

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


Это из области копания траншей. Если нужно выкопать траншею в два раза длинней, то нужно либо в два раза больше землекопов, либо в два раза больше лозунгов.
Если нам не помогут, то мы тоже никого не пощадим.
Re[26]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.07.09 10:54
Оценка: +3
Здравствуйте, Undying, Вы писали:
U>Т.е. покупать себе автомобиль вместе с человеком, который в автомобилях разбирается это плохой, неправильный путь?
Вы путаете разные вещи. Качество сборки автомобиля напрямую влияет на его эксплуатационные характеристики — в частности, частота предстоящего ремонта.
Поэтому при покупке автомобиля с рук мне конечно же крайне важно выяснить — не был ли он реально в аварии, не переставлен ли там двигатель, да и вообще на месте ли все запчасти.
Когда я заказываю код, мне совершенно наплевать, на каком языке он написан — код не подвергается износу; если он один раз протестирован на корректность работы, то он детерминированно продолжит работать корректно всю жизнь.

Если мне делают веб-сайт, то я не полезу в его исходники смотреть, как там всё свёрстано — дивами или таблицами. Я вообще имею право не отличать HTML от HTTP. Зачем мне это?
Мне важнее потребительские характеристики — то есть структура, эстетика наполнения, и скорость загрузки. Если с последним проблемы — это повод потребовать улучшений от подрядчика. А если проблем с этим нет, то совершенно наплевать, какой там CSS применён внутри. Зачем мне забивать себе этим голову?

Вообще, всем людям свойственно преувеличивать важность своей работы. Бухгалтер уверен, что все просто обязаны знать тонкие различия между субсчетами 20-1 и 20-2, в то время как на самом деле всем остальным вообще всё равно, как там что учитывается.
Админ уверен, что нет ничего важнее выбора операционки для гейтвея. Соответственно, программисты тут искренне уверены, что заказчик будет смотреть внутрь вашего кода.
Нет, не будет. Не обязан он это делать. В ваш код никто, кроме peer review и аудиторов, никогда смотреть не будет.

Поэтому все практики насчёт кода — ваше глубоко личное дело. Впутывать сюда заказчиков против их воли не надо. Вас водоканал терзает вопросами типа "правильно ли мы заменили чугунные трубы в магистрали на металлопластиковые?"? Нет? Вот и вы к нему не лезьте со своей атомарностью.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Огни разработки
От: dotneter  
Дата: 13.07.09 06:38
Оценка: 18 (2)
Отсюда можно чего нибудь полезного выудить.
http://commons.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know
Talk is cheap. Show me the code.
Re[6]: Огни разработки
От: IT Россия linq2db.com
Дата: 10.07.09 13:20
Оценка: 10 (1) +1
Здравствуйте, DarkGray, Вы писали:

IT>>Это всё следствия.


DG>следствия чего?


Если кратко, то следствия борьбы со сложностью. Если подробно, то в терминах борьбы со сложностью можно разобрать зачем нужнен и насколько полезен любой из принципов, если это, конечно, интересно.
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Огни разработки
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 09.07.09 09:52
Оценка: 5 (1) -1
Здравствуйте, DarkGray, Вы писали:

DG>4. Код должен быть готовым к любым условиям использования

DG> а) Код должен легко повторно использоваться
DG> b) Код должен вести себя адекватно даже в непредвиденной ситуации

Из этого следует, что код должен быть безопасен, а следовательно:

1) Любая уязвимость, допущенная в коде будет рано или поздно использована (антиогонек "безопасность через сокрытие")
1.1) Безопасность через сокрытие скрывает безопасность
2) Код уязвим настолько, насколько уязвима его самая незащищенная часть (принцип слабого звена)

Я это к чему... Огни разработки безопасного кода интересны?

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[6]: Огни разработки
От: Klapaucius  
Дата: 16.07.09 10:33
Оценка: 5 (2)
Здравствуйте, frogkiller, Вы писали:

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

F>Засада в том, что ты хочешь только логического объяснения.

Где я такое написал? Когда мы говорим о выборе пути для реализации чего-то объективно ценного, мне нужно проверяемое обоснование. Логика куда угодно завести может — меня это не увтраивает.

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


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

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


Это вариация вопроса о том, перестал ли уже оппонент пить коньяк по утрам, да? "Логическую модель мира", которую я якобы построил, вы сами выдумали. И красоту с иррациональностью также вы отождествляете, в отличие от меня.

F>Я не знаю, как это объяснить, кроме как показать и сказать: смотри! Неужели у тебя никогда не возникали моменты, когда ты смотрел в код и видеел, что он просто красив?! — не важно, что он делал и для чего предназначался...


Я уже пытался донести до вас свою мысль примером с красотой сверхзвукового самолета, в котором нет вообще ничего иррационального. Разумеется, я видел красивый код, красивые уравнения и красивые диаграммы Фейнмана. Но все это просто концентрированная рациональность. Что иррационального в их красоте? Рациональной красоты больше, чем кажется. Иррациональная крастота — это "Цветы зла" Бодлера, например. В программировании ситуация весьма нетипичная.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[27]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.07.09 11:25
Оценка: 3 (1) +1
хм, мне кажется, что происходит не понимание что такое Заказчик и Разработчик из начального поста.

Заказчик и Разработчик — это две крупные роли с довольно сильно отличающимися целями, ответственностями и т.д.

ответственность Заказчика:
1. выбрать Разработчика
2. поставить задачу
3. оплатить работу
4. проконтролировать выполнение
5. воспользоваться результатом

ответственность Разработчика
1. разработать продукт

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

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

Заказчик => Представитель Заказчика => Разработчик
со следующим распределением ответственностей
Заказчик:
0. Выбрать Представителя Заказчика
1. оплатить работу
2. воспользоваться результатом

Представитель Заказчика
1. Выбрать Разработчика
2. Поставить задачу
3. Проконтролировать выполнение

Разработчик
1. Разработать продукт

Может идти дальнейшее размывание роли заказчика, например, на заказчика (оплачивает) и пользователя (пользуется результатом),
может идти размывание роли Представитель Заказчика, но все это происходит в ранее сформулированной модели.
Re: Огни разработки
От: Qbit86 Кипр
Дата: 07.07.09 08:30
Оценка: 1 (1) +1
Здравствуйте, DarkGray, Вы писали:

DG>9. Связность и связанность


Стоит привести и английские варианты — cohesion и coupling.

DG> а) Tell, don't ask


Впервые слышу о «Tell, don't ask». Можно подробнее?

Ещё есть Принцип Наименьшего Удивления.
Глаза у меня добрые, но рубашка — смирительная!
Re[5]: Огни разработки
От: SergH Россия  
Дата: 07.07.09 12:19
Оценка: 1 (1) :)
Здравствуйте, Klapaucius, Вы писали:

K>Конечно нет. Вы же сами ссылку на подтверждение и дали.




Не будем спорить про определение искусства А то ведь окажется, что арифметическое переполнение это был перфоманс, а может даже и инсталляция

Но, например, в такой области как архитектура неправильные пути определённо есть. Неправильные дома падают. Это не мешает архитектору одной ногой быть художником. Другой ногой он, конечно, должен быть инженером. А возможно ему ещё третья нога понадобится, из области экономики-логистики.
Делай что должно, и будь что будет
Re: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.07.09 06:09
Оценка: 1 (1) +1
Здравствуйте, DarkGray, Вы писали:

DG>исходный пост http://blog.metatech.ru/post/ogni-razrabotki.aspx


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


Существуют же еще и "анти-огни". Например, не изобретай велосипед. И как одно из частных его проявлений NIH syndrome.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 17:30
Оценка: 1 (1) +1
ГВ>Вообще говоря, это не "огни", а лозунги. ИМХО, руководствоваться ими в практической деятельности

Чем "огонь" отличается от лозунга?

и такие вопросы:
техника безопасности из чего состоит?
а военный устав?

ps
вот, например, ТБ на работу с инструментом.
это тоже лозунги?

Работайте только острозаточенным режущим инструментом.

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

Если вы упустили режущий инструмент, то не старайтесь поймать его на лету.

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

С хрупкими материалами надо работать в защитных очках. Если их у вас не оказалось, то сделайте такие очки сами из любой прозрачной пластины и резинки.

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

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

Работать стальной щеткой будет удобнее и безопаснее, если снабдить ее дополнительной ручкой (например, от двери), укрепленной сверху.

Re[12]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 13.07.09 09:05
Оценка: 1 (1) +1
Здравствуйте, DarkGray, Вы писали:

DG>pps

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

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[4]: Огни разработки
От: Klapaucius  
Дата: 07.07.09 12:13
Оценка: +1 :)
Здравствуйте, eao197, Вы писали:

K>>Дело в том, что в искусстве нет неправильных путей.


E>Ой ли?


Конечно нет. Вы же сами ссылку на подтверждение и дали.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[5]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.07.09 12:18
Оценка: +2
Здравствуйте, Klapaucius, Вы писали:

K>>>Дело в том, что в искусстве нет неправильных путей.


E>>Ой ли?


K>Конечно нет. Вы же сами ссылку на подтверждение и дали.


Тогда программирование -- несомненно искусство. А ПО разбившегося Ариан 5 одно из ярчайших проявлений направления "шок-арт": одним маленьким арифметическим переполнением пустить на воздух $500M!


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.07.09 17:50
Оценка: +2
Здравствуйте, Klapaucius, Вы писали:

E>>Тогда программирование -- несомненно искусство. А ПО разбившегося Ариан 5 одно из ярчайших проявлений направления "шок-арт": одним маленьким арифметическим переполнением пустить на воздух $500M!


K>Иманно это я и написал:

K>

K>И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ракета, арифметическое переполнение

K>Это лицо программирования как искусства. Нет багов — есть выражение внутреннего мира художника. Тесты и спецификации не нужны — неверных путей все равно нет.

Все это получается только в том случае, если вашу точку зрения считать правильной. Если же, напротив, верить в то, что в искусстве вполне есть неправильные направления (тот же самый шок-арт или творения типа "Черного квадрата"), то и картина выходит совсем другой.

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

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

Другое дело, что искусство это прикладное...


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Огни разработки
От: IT Россия linq2db.com
Дата: 10.07.09 16:52
Оценка: +2
Здравствуйте, DarkGray, Вы писали:

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


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

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


См. выше.

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


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

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


Это usability. К коду, ну, например, конкретно к single responsibility principle, тоже не имеет никакого отношения.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Огни разработки
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.07.09 20:42
Оценка: +2
Здравствуйте, IT, Вы писали:

IT>1. single responsibility principle.


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


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

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


Чаще всего переводять как зацепление.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233 on Windows Vista 6.1.7100.0>>
AVK Blog
Re[6]: Огни разработки
От: minorlogic Украина  
Дата: 12.07.09 17:18
Оценка: +2
Здравствуйте, Геннадий Васильев, Вы писали:

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


M>>>>Если бы эти правила были так очевидны ... , может мы с вами живем в паралельных вселенных ?

M>>А не надо выдумывать , никто не предлагает молиться на эти правила. Но в моей вселенной 95% кода не соответствует этим правилам. И я очень завидую молодежи которая может прочесть Мак Коннела и уяснить для себя то с чем я лбом сталкивался и набивал шишки много лет.

ГВ>Так в том-то и дело, что это тебе, набившему шишки за много лет, Мак Коннел понятен и естественен. Думаешь, если бы такой талмуд сунули тебе в руки в юности, ты бы кинулся реализовывать его советы, наплевав на собственный полёт мысли? Ой, смею в этом усомниться.


Совершенно верно, я бы кинулся реализовывать его советы. Потому что у него не просто советы ,а подробное описание зачем и почему
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[2]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 17:20
Оценка: +1 :)
ГВ>Понимаешь, можно вбить ровно один гвоздь, и выработать на этом несколько таких агитпроповских высказываний:

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

или для тебя новость, что гвозди тоже учат забивать?...
Re[4]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 18:02
Оценка: :))
ГВ>В отличие от, например, "there's more than one way to do it". Что за it? Какие ways?

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

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

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

и это такая же техника безопасности, только для программ, как и то, что оружие нельзя направлять на людей.
Re[4]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 18:17
Оценка: +2
ГВ>Ни там, ни там нет никаких лозунгов. Совсем.

а вот это ТБ или не ТБ?
лозунг или инструкция?



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

поэтому все и всегда старались скучные формальные инструкции переложить на лозунги, что и показывает запосченный мной плакат.
Re[23]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 09:40
Оценка: +1 -1
Здравствуйте, DarkGray, Вы писали:


ГВ>>Негативно. Это полезно уже состоявшимся специалистам, как своеобразная юморная памятка, как сборник пословиц и поговорок, вроде "тестируют программы только не уверенные в себе".


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


Ты удивишься, но капканы и ловушки можно обойти только на своём собственном опыте. Чужой опыт — это не больше, чем подсказка, полезная, когда понимаешь 9/10 причинно-следственных связей.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[27]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 10:20
Оценка: +1 -1
Здравствуйте, DarkGray, Вы писали:

ГВ>> А проще — систематически изложить то, что под этими высказываниями подразумевается. Возвращаемся к необходимости систематического обучения, которому все эти метафоры — параллельны.

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

Извини за грубость, ты в своём уме?

DG>ps

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

Так... С кем я спорю, куда я попал, кто эти люди?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 10:37
Оценка: -1 :)
VGn>> Они оформляют договор?

DG>чего?


Расшифровываю, с какого ... это заказчик?
Заказчик подразумевает заказ.
И даже игнорируя такую странную постановку вопроса,
важны только внешние интерфейсы. Иначе гнать такого разработчика в шею.

DG>помедленнее, пожалуйста, я записываю (С)


Контора пишет (с)
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[27]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.07.09 10:44
Оценка: +1 :)
Здравствуйте, DarkGray, Вы писали:
DG>и т.д.
Это — не метафоры и не лозунги. Это неумолимые правила, т.е. предикаты, описывающие корректный русский текст. Дело не в том, что нужно "стараться писать жи/ши с буквой и", а что жы и шы — заведомо неправильные варианты.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 11:26
Оценка: -1 :)
S>Это — не метафоры и не лозунги. Это неумолимые правила, т.е. предикаты, описывающие корректный русский текст. Дело не в том, что нужно "стараться писать жи/ши с буквой и", а что жы и шы — заведомо неправильные варианты.

но из фразы "жи/ши пиши с буквой и" — все это не следует.
"жи/ши .." — это действительно лозунг, для всего то, что написал.
Re[26]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 11:42
Оценка: :))
Здравствуйте, FR, Вы писали:

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


FR>Так в программировании индустриальная эра еще не наступила и эта возможность под вопросом


Ой, что сейчас начнётся...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[10]: Огни разработки
От: IT Россия linq2db.com
Дата: 13.07.09 13:50
Оценка: :))
Здравствуйте, Undying, Вы писали:

IT>>Как пользователю тебе всё равно каким способом будет решена твоя задача.


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


Никогда не видел пользователя бабу Маню, спрашивающую программистов "А ты использовал атомарность в своём код? Если нет, то я не буду пользоваться такой программой".
Если нам не помогут, то мы тоже никого не пощадим.
Re[32]: Огни разработки
От: SergH Россия  
Дата: 13.07.09 17:37
Оценка: +2
Здравствуйте, DarkGray, Вы писали:

DG>сложность изучения инкапсуляции выше, чем сложность использования 10 кейзов — потому что сложность изучения инкапсуляции — 6-8 + 3-10*6-8 = 32-80, что явно больше, чем 10


сорри... Откуда эти числа и эта формула (a + b * c)?

Мне, вообще, кажется, что численные оценки тут невозможны и потому неуместны, но раз ты их даёшь -- возможно ты видишь то, чего не вижу я.
Делай что должно, и будь что будет
Re[29]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.07.09 02:23
Оценка: +2
Здравствуйте, DarkGray, Вы писали:
DG>но из фразы "жи/ши пиши с буквой и" — все это не следует.
Следует.
DG>"жи/ши .." — это действительно лозунг, для всего то, что написал.
Нет. Лозунг — это "краткость — сестра таланта". Или "мойте руки перед едой".
А приведенные правила — именно предикаты. То, что там используется повелительное наклонение, не должно смущать тех, кто понимает смысл.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[32]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.07.09 10:42
Оценка: -1 :)
Здравствуйте, DarkGray, Вы писали:

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

Этого утверждения никто не делал.

DG>как минимум в п.8 и п. 10

DG>

DG>8. Атомарность
DG> а) Tell, don't ask
Чем это помешает проверке результата?

DG>10. Программа всегда(даже после ошибки) должна стремиться находиться в корректном состоянии
DG> a) транзакционность (изменение состояния делается только в самом конце)
DG> b) безопасность исключений

Чем это помешает проверке результата?
DG>deadlock-и обычно упираются в правильную архитектурную декомпозицию, а под это уже больше половины огней заточено
Открою тайну: дедлоки обычно упираются в неверный порядок захвата ресурсов. Про это никаких огней нет; архитектурная декомпозиция к этому никакого отношения не имеет.


DG>все огни направлены на уменьшение кода

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

DG>и соответственно на уменьшение кол-ва ошибок

DG>как пример
DG>

DG>25. a) должно быть как можно меньше side-effect-ов

DG>выполнения этого правила уменьшает кол-во ошибок в коде, который эту функцию использует.
Во-первых, выполнение этого правила ничего не уменьшает. Контрольный вопрос: пусть в коде, вызывающем функцию с side-effects, было 0 ошибок. Сколько ошибок станет в нём после того, как side-effects будут убраны?

Во-вторых, какое отношение это имеет к приёмке кода заказчиком? Намекну на всякий случай, что заказчика не интересует наличие либо отсутствие побочных эффектов внутри кода. Заказчика интересует наличие заказанных прямых эффектов и отсутствие незаказанных.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Огни разработки
От: anonymous Россия http://denis.ibaev.name/
Дата: 15.07.09 11:13
Оценка: +2
Здравствуйте, Геннадий Васильев, Вы писали:

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

ГВ>Два, может быть — три раза. Лучше всего закрепляют материал собственные отбитые пальцы. Рецепт, проверенный поколениями.

Лучше всего закрепляют материал упавшие ракеты. Рецепт, проверенный поколениями. Вообще, конечно, отличный подход, если у нас есть 2, может быть 3, лишние ракеты.
Re: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.07.09 08:22
Оценка: 30 (1)
Сформулировано введение, которое показывают откуда берутся огни

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

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

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

Огни:
...

Re[2]: Огни разработки
От: Qbit86 Кипр
Дата: 07.07.09 08:32
Оценка: 10 (1)
Здравствуйте, Qbit86, Вы писали:

Q>Ещё есть Принцип Наименьшего Удивления.


Principle of least astonishment
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: Law of Demeter
От: Qbit86 Кипр
Дата: 07.07.09 09:04
Оценка: 10 (1)
Здравствуйте, DarkGray, Вы писали:

DG>http://www.pragprog.com/articles/tell-dont-ask


Эта статья напомнила, что есть еще Закон Деметры или Принцип Наименьшего Знания. Имхо, его тоже стоит вынести отдельным пунктом.
Глаза у меня добрые, но рубашка — смирительная!
Re: Огни разработки
От: mazurkin http://mazurkin.info
Дата: 07.07.09 10:08
Оценка: 10 (1)
DarkGray wrote:

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


Open for extension, closed for modification
http://en.wikipedia.org/wiki/Open/closed_principle

Lisvov principle
http://en.wikipedia.org/wiki/Liskov_substitution_principle

IMHO — надо сразу делать словарик со ссылками на статьи
Posted via RSDN NNTP Server 2.1 beta
Re[2]: Огни разработки
От: Klapaucius  
Дата: 07.07.09 11:52
Оценка: 10 (1)
Здравствуйте, frogkiller, Вы писали:

F>Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.


Ага. И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ракета, арифметическое переполнение.
Дело в том, что в искусстве нет неправильных путей. В программировании они есть. Это важное различие. Давайте о нем не забывать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 08.07.09 08:28
Оценка: 10 (1)
из нового

23. пиши в коде то, что ты действительно хотел сделать, а не что получается записать
а) пиши логику, а не физику
24. Все строки кода должны постоянно работать/использоваться (иначе их съедает ржа)
а) Покрывай тестами(или часто используемыми сценариями) весь код
b) резерв должен быть горячим, а не холодным
25. Название должно точно отражать содержимое (уже по названию должно быть понятно, что содержится внутри)
а) Программа должна работать
b) должно быть как можно меньше side-effect-ов
26. новое делай снаружи, старое интегрируй внутрь
а) чем большим количеством что-то используется, тем более оно ядернее и интегрируемее должно быть (и наоборот)
b) get, don't set — формируй новую реальность, а не меняй имеющуюся
c) Open for extension, closed for modification
27. Единообразие, согласованность (говоря A, говори и B)
a) Principle of least astonishment
28. Выделяй главное, убирай(скрывай) несущественное
a) Инкапсуляция
b) Вводи метафоры и абстракции
29. Скопируй, разберись, сделай лучше

Re[8]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 08:14
Оценка: 3 (1)
ГВ>Не совсем. Я вообще против "инструкций о том, как писать программу".

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

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

ps
кстати, добавлю, обучение со списком метафор — действительно работает, без него намного хуже, т.к. тогда обучаемый вообще не понимает к чему следует стремится, и на что ориентироваться.
Re[37]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.07.09 08:27
Оценка: 3 (1)
VGn>что делает из тестера программиста, кроме того, что он тоже сидит жопой на стуле, уставившись в монитор?

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

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

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

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

Ps
VGn> что делает из тестера программиста

и еще раз повторю, что не тестер является программистом
а программист является тестировщиком(диагностом)

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

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

кстати в формулу оценки абстракции, надо еще добавить кол-во рассмотров которое надо сделать для убеждения другого, что что в этом что-то есть


IT> .. что это менее удобно. ..


Т.е. все-таки скобка под скобкой удобнее.
а почему? можешь объяснить в рамках своей концепции?
потому что это твое субъективное мнение?

IT>Теперь домашнее задание — как в твои количество просмотров включить возможности hardware и как положение скобки соотносится с количеством просмотров. Я это правда не понимаю, смотреть то нужно одинаковое количество раз


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

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

при этом окно просмотра получается где-то 3x3 символа для 2-х символьного отступа и следующие локальные правила проверки:
одна строчка идет под другой — для одного блока
следующая строка сдвинута на 2 символа вправо, если переход во вложенный блок
следующая строка сдвинута на 2 символа влево, если выход из вложенного блок
вход во внутренний блок происходит по открывающей скобкой
выход из внутреннего блока происходит по закрывающей скобке
вход во внутренний блок из одной строки происходит по if,for,else и т.д., если на следующей строке нет открывающей скобки
Re[18]: Огни разработки
От: IT Россия linq2db.com
Дата: 19.07.09 03:56
Оценка: 2 (1)
Здравствуйте, DarkGray, Вы писали:

IT>>Количество вариантов чего?


DG>кол-во вариантов рассмотров.


Т.е. как я и говорил, сравниваем тёплое с мягким, количество вариантов поведения и количество просмотров.

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


DG>по двум основным причинам:

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

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

Теперь домашнее задание — как в твои количество просмотров включить возможности hardware и как положение скобки соотносится с количеством просмотров. Я это правда не понимаю, смотреть то нужно одинаковое количество раз
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: Огни разработки
От: SergH Россия  
Дата: 07.07.09 14:13
Оценка: 1 (1)
Здравствуйте, VGn, Вы писали:

SH>> А возможно ему ещё третья нога понадобится, из области экономики-логистики.

VGn>Быстро убегать от заказчика?

Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.
Делай что должно, и будь что будет
Re[5]: Огни разработки
От: dotneter  
Дата: 07.07.09 14:31
Оценка: 1 (1)
Здравствуйте, DarkGray, Вы писали:

D>>Может стоит перенести в http://wiki.rsdn.ru/ ?


DG>пока рано.


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

DG>а для этого нужна большая аудитория и диалог (в вики и то, и другое — хуже)
DG>вот когда более-менее устаканится (по крайней мере, первая волна), можно переносить в вики.
Дискутировать уже есть где, а как редактировать? Например зачем 1а и 9 когда есть solid и grasp?
Talk is cheap. Show me the code.
Re: Огни разработки
От: minorlogic Украина  
Дата: 11.07.09 05:52
Оценка: 1 (1)
http://rsdn.ru/forum/philosophy/2055616.1.aspx
Автор: minorlogic
Дата: 13.08.06

5 копеек
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[23]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.07.09 09:45
Оценка: 1 (1)
S>Просто в следующий раз я закажу у компании, которая делает мебель оговорённого качества в оговорённые сроки.

И где гарантия что ты это получишь?
Он окажется таким же, тоже сроки срывает, и делает фигню
так и будешь всю жизнь менять подрядчиков?

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

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

> Буду ли я теперь выяснять у исполнителя детали устройства его производственного процесса? Спрашивать "а носят ли ваши сотрудники фирменные комбинезоны", "своя ли у вас производственная база или вы её арендуете", "есть ли у вас раскроечный стол или вы пилите всё ручной циркуляркой" и т.п.?


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

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

как бы если тебе на этот вопрос отвечают — а мы себе такой задачи не ставим, то можно уже о цвете фирменных комбинезон и не спрашивать.
кстати тут бывают уникумы, которые могут ответить — а у нас как-то само получается, это может быть и нормально — просто человек не умеет вербализировать свою "программу".
Re[3]: Огни разработки
От: dotneter  
Дата: 07.07.09 13:42
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

Может стоит перенести в http://wiki.rsdn.ru/ ?
Talk is cheap. Show me the code.
Re[2]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 07.07.09 17:08
Оценка: +1
IT>Печальнее всего то, что знание всех этих принципов никак не защищает от ошибок и глупостей

да есть такое, и особенно, на данный момент, меня беспокоит, что часто разработчики пытаются спорить о том, какой код/решение лучше/хуже — не зная(не помня) этих принципов
Re[3]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.07.09 17:37
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

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


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


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Огни разработки
От: VsevolodC Россия  
Дата: 08.07.09 07:02
Оценка: +1

Концептуальное единство
У большинства европейских соборов части, построенные разными
поколениями строителей, имеют различия в планировке и архитектурном стиле.
Более поздние строители испытывали соблазн "улучшить" проект своих
предшественников, чтобы отразить новые веяния моды и свои личные вкусы. В
итоге мирный норманнский трансепт создает конфликт с примыкающим к нему
возносящимся в высь готическим нефом, и результат столь же служит
восхвалению славы Господней, сколь и гордыни строителей.
Архитектурное единство Реймского собора находится в прямой
противоположности с таким смешением стилей. Источником наполняющей зрителя
радости служат как цельность конструкции, так и отдельные образцы
совершенства. Как сказано в путеводителе, цельность была достигнута
благодаря самоотречению восьми поколений строителей собора, пожертвовавших
своими идеями ради чистоты общего замысла. То что получилось в результате,
служит восхвалению не только славы Господней, но и Его могущества,
способного спасти грешных людей от их гордыни.
Хотя на создание программных систем не уходят века, в большинстве своем
они демонстрируют меньшую согласованность концепций, чем в любом соборе.
Обычно это происходит не оттого, что главные проектировщики сменяют друг
друга, а потому, что проект расщепляется на ряд задач, выполняемых разными
разработчиками.
Я убежден, что концептуальная целостность является важнейшей
характеристикой системного проекта. Лучше убрать из системы отдельные
необычные возможности и усовершенствования и реализовать единый набор
конструктивных идей, чем оснастить ее многими хорошими, но
невзаимосвязанными и несогласованными идеями.

Фредерик П.Брукс. Мифический человеко-месяц или как создаются программные системы
Re[8]: Огни разработки
От: Klapaucius  
Дата: 09.07.09 13:11
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Все это получается только в том случае, если вашу точку зрения считать правильной. Если же, напротив, верить в то, что в искусстве вполне есть неправильные направления (тот же самый шок-арт или творения типа "Черного квадрата"), то и картина выходит совсем другой.


На самом деле ничего не изменится. Даже если мы предположим, что в искусстве неправильные пути есть — мы не сможем отличить их от правильных — mensura Zoili-то у нас нет. Так что и смысла говорить о неправильных путях нет — раз уж различать мы их не умеем. Где те требования, которым должна отвечать картина "Охотники на снегу" и как мы проверим соответсвие? Требования эти только в головах существуют и во всех головах могут быть разными. А требования к программам, как правило, представляет сама жизнь — они объективны. И ракета замечательно соответствие этим требованиям проверила. С огоньком.

E>Между тем и там, и там есть настоящие шедевры. Которые возникли благодоря озарению автора и большому количеству вложенного автором труда. Например, различные виды сортировок, алгоритмы поиска, семафор Дейкстры и пр. Такие вещи вполне можно считать произведениями искусства программирования.


Это не столько программирование, сколько CS. Да и это даже не техническая эстетика сверхзвукового самолета, которую каждый может оценить, хотя это и красота практически полностью произошедшая из целесообразности. Это красота целесообразности, доступная только специалисту.
Так что это "искусством" можно назвать только в смысле "умение", а не в смысле "продукт творческой деятельности", о которой мы тут и говорим, нет?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[4]: Огни разработки
От: IT Россия linq2db.com
Дата: 10.07.09 03:10
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

DG>цель же вроде была прописана во введении — это разве не ответ на вопрос "зачем?"


DG>

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


Это всё следствия.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.07.09 05:59
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

E>>Время, как правило, все расставляет на свои места.

S>Совершенно непонятно, что и куда расставляет время.

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

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

E>>Никогда не мог понять, почему может существовать CS в отрыве от программирования.

S>Хм. А ничего, что, к примеру, функан существует в отрыве от гидродинамики?

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.07.09 13:34
Оценка: +1
Здравствуйте, Klapaucius, Вы писали:

E>>Нет, не технику рисунка. А способность с помощью рисунка, например, передать настроение натурщика.


K>Эта способность состоит из двух частей:

K>1) Техники передачи эмоций — это знание того, что человек определенным образом интерпретирует линии определенной кривизны — и такому можно каждого научить, даже аутиста, который интуитивно эмоции не воспринимает.

Интересно. Как можно передать эмоцию, которую не воспринимаешь?

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


В том-то и дело. Что выполнив одну и ту же композицию (нарисовав один и тот же портрет с одной и той же точки) два разных художника используют разные техники рисунка (или разные их сочетания). И получат два разных изображения с разным ритмом и настроением. Почему они поступили так, как поступили?

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

На мой взгляд, дело здесь именно в умении, т.е. сочетании опыта, вкуса, знаний и каких-то других факторов (в том чисте и иррациональных).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Огни разработки
От: IT Россия linq2db.com
Дата: 10.07.09 15:50
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

DG>я хотел решить задачу: оттянуться

DG>для этого мне нужна была программа — игра, которая бы решала эту задачу
DG>этой программе я как пользователь ставлю цель:
DG>[quote]
DG> код{программа} должен решать поставленную нами задачу{помочь оттянуться} за конкретный срок в том окружении, которое есть; и быть готовым{готовой} к переформулировке или корректировке задачи по ходу (примечание: время на разработку и модификацию кода{программы} входит в срок)
DG>[/quote]

DG>формализуя эту цель мы получили требования (см. предыдущие сообщения).


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

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


Конечно. Код должен быть простым и понятным. Зачем? Затем, чтобы его было проще понимать и проще модифицировать. Проще в данном контексте — это антоним сложности. Т.е. код должен быть простым и понятным, чтобы уменьшить сложность восприятия и модификации кода.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Огни разработки
От: IT Россия linq2db.com
Дата: 10.07.09 16:07
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

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


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


Не большая, а все.

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


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

Если более подробно, то скорее всего это выльется в приличный по размерам пост. Я подумаю и попробую что-нибудь сочинить
Если нам не помогут, то мы тоже никого не пощадим.
Re[9]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.07.09 16:32
Оценка: +1
IT>Кратко сложность можно определить как меру усилий, требуемых для решения поставленной задачи.

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

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

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

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

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

Re[5]: Огни разработки
От: frogkiller Россия  
Дата: 10.07.09 19:55
Оценка: +1
Здравствуйте, Klapaucius, Вы писали:

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


Засада в том, что ты хочешь только логического объяснения. Ну не получится полностью разложить по полочкам то, что содержит в себе иррациональное. Однако, ты же не станешь отрицать существование красоты только потому, что она не вписыватся в построенную тобой логическую модель мира?
Я не знаю, как это объяснить, кроме как показать и сказать: смотри! Неужели у тебя никогда не возникали моменты, когда ты смотрел в код и видеел, что он просто красив?! — не важно, что он делал и для чего предназначался...
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[12]: Огни разработки
От: IT Россия linq2db.com
Дата: 11.07.09 02:38
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

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


Предыдущий шаг был сделан в правильном направлении. Этот куда-то в сторону. Огни разработки и заказчик — это как минимум два разных человека. Твоему заказчику на твои огни наплевать. Если не веришь мне, спроси у него самого.
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 11.07.09 07:12
Оценка: :)
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. жуй по частям (сложные вещи делаются, как складывание простых элементов)

Re[13]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 11.07.09 07:29
Оценка: :)
IT>Твоему заказчику на твои огни наплевать. Если не веришь мне, спроси у него самого.

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

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

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

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


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


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


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

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

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

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

+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[25]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 10:08
Оценка: :)
Здравствуйте, FR, Вы писали:


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

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

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

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

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

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

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

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


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


Это то же самое.
Re[21]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 13:54
Оценка: :)
IT>Зазубрить что? Варианты поведения разработываемого ПП?

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

например, char.ToLower

The lowercase equivalent of c, or the unchanged value of c, if c is already lowercase or not alphabetic.


подумай немного
а теперь ответь что здесь написано и зачем?

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


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


сложность — это кол-во вариантов которые надо рассмотреть.
что не так?
Re[4]: Огни разработки
От: minorlogic Украина  
Дата: 12.07.09 17:02
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

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



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


M>>Если бы эти правила были так очевидны ... , может мы с вами живем в паралельных вселенных ?

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

В целом, совершенно не по делу твое высказывание. Не было бы этих правил если бы все им следовали с первых минут програмирования.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[5]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.07.09 17:09
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

M>В целом, совершенно не по делу твое высказывание. Не было бы этих правил если бы все им следовали с первых минут програмирования.


Заморочка не в правилах самих по себе, а в отношении к ним. Если бы к ним относились с должной долей юмора и не более того — проблем бы не было. Но пытаться интерпретировать эти правила как реальные практические наставления, как какие-то направляющие принципы, которыми можно набить голову той самой молодёжи до набора практического опыта — глупость несусветная. Это, не знаю... Надо очень крепко спать, бодрствуя.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.07.09 17:18
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

M>А не надо выдумывать. Никто не относится к ним так , я повторяюсь. Это правила которые направляют а не предписывают.


Оглядись по сторонам, а? Почитай периодически возникающие обсуждения "паттернов" в Архитектуре Программирования. Это тебе и мне эти принципы — не предписание. Для других это может оказаться совсем не так.

M>Или у вас на работе они включены в код стайл ? тогда я могу понять идиосинкразию.


У меня идиосинкразия к наивным наблюдениям, подаваемым в отвязке от причинно-следственных связей.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: Огни разработки
От: minorlogic Украина  
Дата: 12.07.09 17:21
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

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


M>>А не надо выдумывать. Никто не относится к ним так , я повторяюсь. Это правила которые направляют а не предписывают.


ГВ>Оглядись по сторонам, а? Почитай периодически возникающие обсуждения "паттернов" в Архитектуре Программирования. Это тебе и мне эти принципы — не предписание. Для других это может оказаться совсем не так.


Не обращал внимания , или у меня иммунитет.

M>>Или у вас на работе они включены в код стайл ? тогда я могу понять идиосинкразию.


ГВ>У меня идиосинкразия к наивным наблюдениям, подаваемым в отвязке от причинно-следственных связей.


Именно поэтому читайте Мак Коннела , там нет советов без объяснений , там для каждого пункта дается четкое обоснование.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: Огни разработки
От: minorlogic Украина  
Дата: 12.07.09 17:23
Оценка: +1
Здравствуйте, DarkGray, Вы писали:


ГВ>>Понимаешь, можно вбить ровно один гвоздь, и выработать на этом несколько таких агитпроповских высказываний:


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


DG>или для тебя новость, что гвозди тоже учат забивать?...


Кстати да , легко представить что ты учишь забивать гвозди 3х летнего малыша.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[22]: Огни разработки
От: IT Россия linq2db.com
Дата: 12.07.09 17:29
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

IT>>Зазубрить что? Варианты поведения разработываемого ПП?


DG>открой документацию на любое ПП и посмотреть что пишут обычно в описании.


DG>например, char.ToLower

DG>

DG>The lowercase equivalent of c, or the unchanged value of c, if c is already lowercase or not alphabetic.


DG>подумай немного

DG>а теперь ответь что здесь написано и зачем?

Тебе перевести на русский?

DG>ps

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

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

Интересно, а сколько вариантов поведения у ООП, компонентности, ФП и прочих парадигм, без знания которых некоторый код будет непосильно сложным, а со знанием предельно простым?

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


DG>сложность — это кол-во вариантов которые надо рассмотреть.

DG>что не так?

О как! Меня радует гибкость твоих суждений. Раньше ты давал немного другое определение, но быстро исправился
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.07.09 17:42
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

ГВ>>Вообще говоря, это не "огни", а лозунги. ИМХО, руководствоваться ими в практической деятельности

DG>Чем "огонь" отличается от лозунга?

Именно, ничем.

DG>и такие вопросы:

DG>техника безопасности из чего состоит?
DG>а военный устав?

Ни там, ни там нет никаких лозунгов. Совсем. В отличие от, например, "there's more than one way to do it". Что за it? Какие ways?

DG>ps

DG>вот, например, ТБ на работу с инструментом.
DG>это тоже лозунги?

[skip цитата]

Вот это как раз не лозунги, а сугубо практические инструкции.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 18:11
Оценка: +1
ГВ>Хм. А мне такой пурги не несли. Просто учили правильно забивать гвозди не отбивая пальцев, и обращать внимание на окружающих. Видимо, у нас с тобой разный опыт по этой части.

т.е. учили стандартным ремесленным способом от мастера к подмастере? когда мастер подает пример подмастере, и пару лет личным примером показывает как надо?

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

и тут приходит понимание, что всю невербалику мастера по обучению — необходимо переложить в инструкцию, памятку и т.д.
так какие фразы будут в этой инструкции?
Re[5]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 06:38
Оценка: :)
Здравствуйте, DarkGray, Вы писали:

ГВ>>В отличие от, например, "there's more than one way to do it". Что за it? Какие ways?

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



DG>это крылатая фраза для обозначения подхода, который говорит:

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

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

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

DG>1. из основного меню
DG>2. из контекстного меню
DG>3. через горячие клавиши
DG>4. через скрипт (макрос) самого приложения
DG>5. из внешней программы

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


Хм. Что тут общего с ТБ? Действие доступно через кучу интерфейсов — от C API до вебсервиса и команд меню. Можно найти ещё вагон интерфейсов. Но это даже не do, это, скорее call.

P.S.: Да уж, видал я такой "культурный контекст" где подальше... Балаган какой-то...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 08:41
Оценка: +1
IT>Кратко сложность можно определить как меру усилий, требуемых для решения поставленной задачи. Абсолютной единицы измерений скорее всего нет, иначе всё было бы гораздо проще. Но в абстрактных попугаях, в терминах много, мало, больше, меньше померять можно.

Скорее это тоже следствие. Источником является комбинаторная сложность.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[11]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 08:59
Оценка: +1
VGn>>Источником является комбинаторная сложность.

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


Количество вариантов поведения — результат комбинаторной сложности. (динамика vs статика), но в общем — да. Я ещё не достаточно углубился в ветку.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[23]: Огни разработки
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.07.09 09:36
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

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


Ну, как то ты в крайности бросаешься, честное слово. Смысл в том, что учиться нужно не по лозунгам.
Re[24]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:50
Оценка: +1
ГВ>Ты удивишься, но капканы и ловушки можно обойти только на своём собственном опыте.

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

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

соответственно список огней и есть такой опыт других, который стоит разобрать каждому и интегрировать в свою работу.
Re[16]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 10:11
Оценка: :)
DG>а если под заказчиком понимать команду разработчиков, которая заказала одному из разработчиков этой же команды решить подзадачку
DG>то такому заказчику(команде разработчиков) важно знать как будет выполнена подзадача?

Они оформляют договор?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[28]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 10:25
Оценка: -1
ГВ>Извини за грубость, ты в своём уме?

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

систематизация обучения — очень долгий процесс, и начинается он именно с кратких названий/метафор/лозунгов существующего опыта.
далее эти метафоры разбираются, переформулируются, структурируются, поверх них вводится система и т.д. — и получается уже систематичный учебник
Re[2]: Огни разработки
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 13.07.09 10:32
Оценка: +1
Здравствуйте, dotneter, Вы писали:

D>Отсюда можно чего нибудь полезного выудить.

D>http://commons.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know

97... Да, мощно. Как бы не стать той сороконожкой, которая задумалась о порядке перестановки ножек.

Впрочем, бывает и круче: 169 Thins Every Driver Should Know
Re[30]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 10:35
Оценка: +1
ГВ>Ёшкин хвост, но система обучения программированию уже давным-давно есть, зачем подменять её наивными правилами?

ссылку на эту систему можно?

в российской информатике(как учебного предмета) нет никакой системы.
Re[2]: Огни разработки
От: Undying Россия  
Дата: 13.07.09 11:03
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

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


DG>

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


Я бы переформулировал цель следующим образом:

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

Под заказчиком понимается не только и не столько тот, кто собственно платит деньги, но и тот кто этим продуктом будет пользоваться. Специально упоминать в цели о сроках и окружении не нужно, т.к. это неотъемлимая часть поставленной задачи.
Re[21]: Огни разработки
От: Undying Россия  
Дата: 13.07.09 11:27
Оценка: +1
Здравствуйте, VGn, Вы писали:

VGn>>>Расшифровываю, с какого ... это заказчик?

VGn>>>Заказчик подразумевает заказ.

U>>Т.е. если разработка freeware, то сформулировать требования к коду нельзя? А как только разработка становится shareware сразу можно?


VGn>Не понял.


Что такое заказ для freeware-программы?

VGn>>>И даже игнорируя такую странную постановку вопроса,

VGn>>>важны только внешние интерфейсы. Иначе гнать такого разработчика в шею.

VGn>Читаем последнее предложение. ИМХО если разработчику доверия нет, то это значит, что работу фактически придётся делать дважды.


Т.е. интересоваться как решает задачу другой разработчик нельзя? Можно только уволить другого разработчика после того как его решение приведет к проблемам?
Re[29]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 11:39
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

S>>Это — не метафоры и не лозунги. Это неумолимые правила, т.е. предикаты, описывающие корректный русский текст. Дело не в том, что нужно "стараться писать жи/ши с буквой и", а что жы и шы — заведомо неправильные варианты.


DG>но из фразы "жи/ши пиши с буквой и" — все это не следует.

DG>"жи/ши .." — это действительно лозунг, для всего то, что написал.

Это всё даётся детям в рамках "правописания гласных с шипящими", если не ошибаюсь. А для лучшего запоминания дополнительно приводятся такие игривые оформления правил. И требуют в дальнейшем не запоминать игривые формулировки, а следовать правилам языка.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: Огни разработки
От: IT Россия linq2db.com
Дата: 13.07.09 13:46
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

DG>IT, ты много ерничаешь, и мало формулируешь свою позицию, но попробую все-таки записать твою позицию.


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

DG>ты согласен с тем, что:

DG>1. в программировании применяются огни,

Тут я больше согласен с ГВ

DG>2. огни направлены на уменьшение сложности ПП.


Эту мысль я тебе подбросил.

DG>также ты считаешь, что:

DG>1. заказчика интересует только результат, и не интересует способ разработки, а также какой способ разработки лучше или хуже,

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

DG>2. сложность ПП — это не формализуемая и не измеримая штука, поэтому и не стоит пытаться ее формализовать или измерить.


Измерять тут нечего. Но изучать, чтобы лучше понять, стоит.

DG>я корректно записал твою позицию?


Не совсем.
Если нам не помогут, то мы тоже никого не пощадим.
Re[28]: Огни разработки
От: IT Россия linq2db.com
Дата: 13.07.09 16:05
Оценка: :)
Здравствуйте, DarkGray, Вы писали:

IT>>Интересно, а сколько вариантов поведения у ООП, компонентности, ФП и прочих парадигм, без знания которых некоторый код будет непосильно сложным, а со знанием предельно простым?


DG>инкапсуляция — показывается где-то вариантах 6-8 (инкапсулированное/неинкапсулированное решение + клиент который использует/не использует данные, которые стоило спрятать + внесение изменения в инкасулированное/неинкапсулированное решение + изменения в клиентах)


Так, очень интересно. Значит у инкапсуляции 6-8 вариантов использования, а у свича на 10 кейзов соответственно 10 вариантов использования. Т.е. свич на 10 кейзов сложнее инкапсуляции?
Если нам не помогут, то мы тоже никого не пощадим.
Re[32]: Огни разработки
От: IT Россия linq2db.com
Дата: 13.07.09 18:13
Оценка: :)
Здравствуйте, DarkGray, Вы писали:

IT>>Мы говорим вроде как о сложности обучения. Сложность изучения инкапсуляции ниже сложности использования 10 кейзов?


DG>сложность изучения инкапсуляции выше, чем сложность использования 10 кейзов — потому что сложность изучения инкапсуляции — 6-8 + 3-10*6-8 = 32-80, что явно больше, чем 10


Т.е. использование switch в сотню case будет сложнее изучения ООП?
Если нам не помогут, то мы тоже никого не пощадим.
Re[35]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 19:13
Оценка: :)
IT>Т.е. использование switch в сотню case будет сложнее изучения инкапсуляции?

да, если switch с реальной рассматриваемой сложностью в сотню.

Ps
т.е. я напоминаю о том, что у вот такого switch-а
switch (ch)
{
  case 'A': return 'a';
  case 'B': return 'b';
  ...
}


реальная рассматриваемая сложность — 2, если не 1
Re[22]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.07.09 04:39
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

DG>что в этом примере надо сделать заказчику:

DG>1. чтобы решить эту ситуацию?
DG>2. что надо принять на будущее, чтобы такой ситуации не возникло в следующий раз?
Принять решение не пользоваться больше этим подрядчиком.

Вот простой реальный пример: попробовал я заказать шкаф себе в коридор. Ну, то есть я, конечно, и так поступил как педант — вместо многочисленных итераций устного обсуждения спецификации "ой, мне хотелось ящичков побольше, переделайте" я просто начертил набросок устройства шкафа. Но дальше я предпочитаю не вдаваться в подробности бизнес-процесса.
В итоге срок контракта был превышен в 7 раз; пришлось много чего переделывать по вине исполнителя, и всё такое.

Буду ли я теперь выяснять у исполнителя детали устройства его производственного процесса? Спрашивать "а носят ли ваши сотрудники фирменные комбинезоны", "своя ли у вас производственная база или вы её арендуете", "есть ли у вас раскроечный стол или вы пилите всё ручной циркуляркой" и т.п.?
Нет, не буду. Моя специальность — разработка софта. Если бы я хотел заняться изготовлением корпусной мебели — я бы так и сделал. Нанимать подрядчика, в процессы которого я буду должен постоянно вмешиваться вручную, у меня нет никакого желания.
Просто в следующий раз я закажу у компании, которая делает мебель оговорённого качества в оговорённые сроки.

Точно так же и у заказчиков софта никакого желания выяснять, как там внутри устроен процесс, и каково качество кода, нету.
Если заказчик начинает вмешиваться в это, то он фактически заказывает не софт, а арендует разработчиков. Менеджить процесс он хочет типа сам.
В целях борьбы против истощения природных ресурсов, лучше чётко проводить границу между этими видами бизнеса. Потому что иначе будет ситуация типа "давайте я сначала буду мешать вам работать, а потом стану требовать исполнения данных вами обещаний".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Огни разработки
От: minorlogic Украина  
Дата: 14.07.09 04:57
Оценка: +1
Здравствуйте, lomeo, Вы писали:

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


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


L>Ну, как то ты в крайности бросаешься, честное слово. Смысл в том, что учиться нужно не по лозунгам.


Это очевидно что за лозунгом лежит практика в которой необхобимо разобраться. А вот без лозунга ты можешь и не узнать что такая практика существует , и потратить годы пытаясь сформировать критерии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[26]: Огни разработки
От: minorlogic Украина  
Дата: 14.07.09 04:57
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Уже теплее. Только опять таки, чтобы интегрировать, нужно очень глубоко разобрать такие высказывания. А проще — систематически изложить то, что под этими высказываниями подразумевается. Возвращаемся к необходимости систематического обучения, которому все эти метафоры — параллельны.


Лозунг это напоминалка , привлечение внимания. Неужили ктонить утверждает, что разбираться в том что лежит за лозунгом не надо?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[22]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 14.07.09 10:26
Оценка: +1
DG>пока складывается впечатление, что ты себя воспринимаешь лишь по одну сторону баррикады, а именно на стороне исполнителя.
DG>и не пытаешься посмотреть со стороны тех людей, которые код заказывают и принимают.

Я уже не раз упоминал в этом форуме, что несколько лет работал представителем заказчика (МО РФ) на крупом предприятии, так что ты ошибаешься.

DG>что в этом примере надо сделать заказчику:

DG>1. чтобы решить эту ситуацию?
DG>2. что надо принять на будущее, чтобы такой ситуации не возникло в следующий раз?

1. Если возможно в рамках соглашения, надавить материально. Если нет — найти способы заключить доп. соглашение. В любом случае важен результат (в этом случае — качество), а не как оно там написано.
2. Правильно оформлять требования к качеству в ТЗ, ответственность в случае невыполнения требований. Правильно заключать договор на поддержку.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[27]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 14.07.09 10:32
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

ГВ>>Уже теплее. Только опять таки, чтобы интегрировать, нужно очень глубоко разобрать такие высказывания. А проще — систематически изложить то, что под этими высказываниями подразумевается. Возвращаемся к необходимости систематического обучения, которому все эти метафоры — параллельны.


M>Лозунг это напоминалка , привлечение внимания. Неужили ктонить утверждает, что разбираться в том что лежит за лозунгом не надо?


Надо, но...

То, как это должно быть в норме (-> сопровождается, => то, что получается):

1. [система знаний] + [практика] => [усвоенные знания] -> [метафорическая интерпретация]

То, что называется "огнями" (обрати внимание, здесь уже используется метафора "ориентир"):

2. [метафорическая интерпретация] => [?] + [??] => [???]

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

DG тут очень удачно вспомнил про плакат "Болтун — находка для шпиона", хотя сам же и ушёл от обсуждения. На самом деле, такие плакаты всегда дополняют "прокачивание" мозгов, а не заменяют. И ни одному вменяемому современнику этих самых плакатов в голову бы не пришло, что секретность на самом деле обеспечивается и направляется наглядной агитацией, которую надо как-то специально изучать и от её метафор отталкиваться. Это уже, знаешь, крайняя мера, для особо непонятливых.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.07.09 13:37
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

DG>Заказчик и Разработчик — это две крупные роли с довольно сильно отличающимися целями, ответственностями и т.д.

Ну да, всё правильно. И откуда в этой чудной модели возникнет заказчик, который лезет в исходники?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.07.09 07:27
Оценка: +1
Здравствуйте, DarkGray, Вы писали:
DG>из пункта "проконтролировать выполнение".
DG>и из того факта, что ряд вещей очень плохо контролируются по результату (методом "черного ящика"), и намного лучше контролируются при наличие доступа внутрь (методом "белого ящика")
Это всё необоснованные углубления в дебри. На всякий случай напомню, что контролировать нужно не всё, а выполнение того, что оговорено в контракте. Есть требования — есть их проверка. Дальнейшее, вообще говоря, излишество.
DG>1. требование, что ПП устойчиво работает при многопоточном выполнении — очень тяжело контролируется методом "черного ящика".
Ок. Каким образом проверка этого требования методом "белого ящика" упрётся в те "огни", которые ты там выше приводил?
DG>2. требование, что программа не имеет ошибок (или имеет кол-во ошибок меньше заданного на кол-во функциональный точек) — тоже методом "черного ящика" контролируется достаточно трудоемко.
Ок. Каким образом проверка этого требования методом "белого ящика" упрётся в те "огни", которые ты там выше приводил?

Выписанные тобой огни хоть как-то влияют из твоего списка исключительно на выполнение бюджетов. Но я позволю себе в очередной раз напомнить, что бюджеты — это не программистская епархия. Вопросам выполнения бюджетов посвящены совершенно отдельные "огни менеджмента", их преподают на post-graduate курсах.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.07.09 07:27
Оценка: +1
Здравствуйте, DarkGray, Вы писали:
DG>из этого я понял, что у тебя каши в голове нет, поэтому ты прямо сейчас готов системно изложить свое видение по обсуждаемой теме?
Не вижу смысла. Я вообще не до конца понимаю, что именно вам хочется обсудить.
По поводу программистской части работы IT высказался вполне определённо — всё сводится к борьбе со сложностью. Я с ним полностью согласен.

Всё остальное, что ты тут фантазируешь, относится к области менеджмента, и вообще говоря никак к программированию не относится.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.07.09 10:40
Оценка: +1
Здравствуйте, DarkGray, Вы писали:


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

DG>зачем ты хочешь разделить менеджмент и программирование?

Я тоже люблю винигрет, но только как салат.

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


Покажи.
Re[28]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 15.07.09 12:25
Оценка: :)
VGn>>1. Соглашение — взаимное правило. Формализация не обязательна. Работает на уровне исполнителя.
VGn>>2. Требование — бизнес-сущность. Формальный контракт. Работает на уровне заказчик-исполнитель.
VGn>>3. Контракт — общая совокупность ограничений, накладываемых на результат работы. Область действия зависит от контекста.

DG>общий термин для обозначения этих 3 сущностей есть?


А зачем? Чтобы устроить привычный бардак? Назови, к примеру, шнягой. Потому как общее обозначение этих сущностей именно шнягой и будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[33]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 15:22
Оценка: -1
VGn>есть ещё аналитика

в делении на программирование и менеджмент — нет такого.

т.е. аналитика — может быть уже идти как часть программирования или менеджмента, может идти на стыке программирования и менеджмента и т.д.
Re[34]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 02:48
Оценка: +1
Здравствуйте, DarkGray, Вы писали:
DG>как тогда понимать твою фразу?
DG>

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

Так и понимать. Если в контракте оговорено "поставка исходных кодов, оформленных в соответствии со стандартами качества" — тогда можно и нужно контролировать исходники.
А если оговорено "поставка исполняемых файлов, инструкций и т.п. необходимых для выполнения пользовательских задач в соответствии с п.п. 2.1-2.187", то нужно контролировать выполнение пользовательских задач. При этом совершенно неважно, насколько детально там всё оговорено в пунктах 2.1 — 2.187. Детали соответствия решения задаче можно оговаривать дополнительно и даже устно. Но задним числом начинать докапываться до вещей типа "о-о, мы думали вы сделаете это на ведге, а вы сделали на ASP.NET", или "В этой задаче можно было применить MVC фреймворк, а вы не применили" — нельзя. Вам было всё равно, на чём мы напишем, когда подписывали контракт? Вот и хорошо — пусть будет всё равно и дальше.
Было не всё равно? Ну так надо было как-то сформулировать свои пожелания. А если вам хотелось на ходу вмешиваться в наш процесс — то надо было подписывать не fixed price, а time & material basis контракт. Потому что ваши капризы за наш счёт — это нечестно.

Подчеркну: речь не идёт о исчерпывающем описании деталей реализации в контракте. Речь идёт о том, что контракт описывает взаимные обязанности. Если в контракте не прописан дресс-код для исполнителей, то они имеют право одеваться как хотят. Точка.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.07.09 09:45
Оценка: +1
VGn>Есть гипотеза, что Хомо Сапиенс сожрал неандертальцев (а не наоборот) именно потому, что имел преимущество в разделении труда.

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

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

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

на сторону оптимально лишь отдавать непрофильные стандартные.
плохо отдаются на сторону нестандартные профильные/непрофильные
опасно отдавать профильные стандартные.

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

соответственно, например, оценка сроков, рисков, требуемых ресурсов, составление плана работ по тому модулю, который непосредственно делает программист, оптимальнее делается самим программистом (если он, конечно, программист, а не кодер).
т.к. задача отчасти профильная (программисту платят именно за то, чтобы он разработал код при заданных ограничениях), нестандартная (код очень разный от задачи к задаче — если это именно программист), требует большого передачи информации (программист должен полностью рассказать, что и как он собирается делать, все подводные камни которые он видит и т.д.)
из этого получается, что программиста оптимальнее обучить минимальным основам менеджмента, чем пытаться на каждого программиста поставить по менеджеру, который за программиста будет оценивать бюджет, риски и т.д.
Re[36]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 09:47
Оценка: :)
Здравствуйте, DarkGray, Вы писали:
DG>Повторю вопрос третий раз: откуда взялся данный контракт? был дарован господом богом?
Этот вопрос выходит за рамки дисциплины "программирование". Я в очередной раз намекаю, что есть такая дисциплина, "менеджмент". Там про всё это и многое другое и

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

Потому, что обе стороны подписали контракт.

DG>т.е. заказчик и разработчик когда подписывали этот контракт они думали что они хотят? или не думали?

DG>если думали, то о чем?
Какая разница, о чём они думали? Ты теперь еще и в психологию бизнеса собрался полезть что ли?
DG>если контракт выполняется, то я с тобой согласен.
DG>но если контракт не выполняется (опять же, например, кол-во ошибок не уменьшается) то стоит требовать подписание доп. соглашение, по которому большие возможности контроля переходят к заказчику.
Опять двадцать пять. Если контракт не выполняется, то программистские мантры ничему не помогут. Есть отдельная наука про выполнение контрактов и контроль выполнения контрактов. Её постулаты никак не зависят от того, что это за контракт — на поставку окорочков или на разработку веб-поисковика.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.07.09 11:29
Оценка: :)
VGn>А ещё есть тестер, внедренец, снабженец, бухгалтер, завхоз, отдел кадров, директор и инвестор

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

если же это все класть на программиста, то конечно он все это должен уметь хотя бы в объеме для себя:
1. программист более, чем должен уметь протестировать свой код для себя
2. программист более, чем должен понимать и уметь внедрять(разворачивать) свой код
3. программист более, чем должен быть снабженцем для себя (уметь понимать какие инструменты ему нужны)
4. программист более, чем должен быть бухгалтером для себя (уметь фиксировать на что пошли свои ресурсы: время, нервы и т.д.)
5. программист более, чем должен быть завхозом для себя (понимать какой код уже есть и где)
6. программист более, чем должен быть отделом кадров для себя (понимать, например, какие права ему полагаются по ТК)
7. программист более, чем должен быть для себя директором (понимать куда надо развиваться и т.д.)
8. программист более, чем должен быть для себя инвестором (выделять себе ресурсы на дальнейшее развитие)

и вот это все не отдашь другим.
никто не будет за программиста думать — нарушено в отношении него ТК или нет,
никто не будет за программиста выделять ему время прочтение новой книжки о программировании,
никто не будет за программиста решать задачу — смотри какая клевая есть минибиблиотечка, она намного проще решает задачи, которые возникают каждый день и т.д.
Re[22]: Огни разработки
От: Klapaucius  
Дата: 16.07.09 11:49
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Сильно сомневаюсь, что идея о выдачи дерьма за произведение искусства нашла бы продолжение, скажем, в начале XIX века.


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

E>Я понимаю. Но если мы изначально идем от наличия/отсуствия иррациональности в программировании, то без субъективных оценом все равно не обойтись.


В программировании без субъективных оценок обойтись можно. В искусстве других просто не бывает.

K>>Вне нашего культурного контекста картины Рембрандта — это слои масляной краски и только.

E>Позволю себе несогласиться. Мало кому удасться наложить слои масляной краски так искуссно.

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

K>>И не какой это не ШИРпотреб. НЕт широкого потребления теперь. УЗпотреб в чистом виде.

E>В то время производство таких произведений было поставлено на поток. Так что ШИР был.

Вы вроде бы говорили про ЭТО время. Да и не нужно путать производство и потребление.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[20]: Огни разработки
От: Klapaucius  
Дата: 16.07.09 12:00
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Боюсь, что когда распознавание выражения глаз приравнивается к заучиванию знаков азбуки Морзе, продолжать уже нет смысла.


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

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

E>Соревнования демок. Имеют место быть.

Это не совсем то, ближе к анимации. Но вы примерно понимаете о чем идет речь. А говорили что за гранью понимания.

E>Прошу прощения, но это вы свели заявление frogkill-а к тому, что иррациональное в нем -- это только творчество и внутренний мир.


Нет. Я утверждаю, что иррациональное — малая часть творчества и внутреннего мира.

E>Я с вами не согласен. Поскольку, по моему, умение программировать -- очень иррациональная вещь. А потому и само программирование несет в себе изрядную долю иррациональности.


Все, чем занимается человек несет в себе долю иррациональности. Инженерные дисциплины отличаются от искусства необходимостью иррациональность контролировать и развитым инструментарием для такого контроля.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[41]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.07.09 13:33
Оценка: +1
S>Ты пойми, что различие ровно одно.
S>Для программиста главное — борьба со сложностью.
S>А для менеджера — борьба с непредсказуемостью.

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

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


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

можно какие-нибудь примеры, которые показывают — что в похожих ситуациях программист выберет простоту, а менеджер — предсказуемость
Re[2]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 07.07.09 08:38
Оценка:
E>Я не заметил самого важного "огонька": "Программа должна работать!" (т.е. делать именно то, за что заплатили ее заказчики/покупатели).

записал так
25. Название должно точно отражать содержимое (уже по названию должно быть понятно, что содержится внутри)
а) Программа должна работать
b) должно быть как можно меньше side-effect-ов
Re[2]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 07.07.09 08:44
Оценка:
DG>> а) Tell, don't ask

http://www.pragprog.com/articles/tell-dont-ask
Re: Огни разработки
От: Mazay Россия  
Дата: 07.07.09 09:00
Оценка:
Главное гармония ...
Re: «YAGNI разработки»
От: Qbit86 Кипр
Дата: 07.07.09 09:22
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>5. Keep it simple, stupid (acronym KISS)...


Родственным (но тем не менее отдельно выделяемым) принципом является YAGNI. Правда, в конкретной формулировке Википедии принцип может показаться спорным, но в бытовом смысле — очень здравое руководство.
Глаза у меня добрые, но рубашка — смирительная!
Re: Огни разработки
От: frogkiller Россия  
Дата: 07.07.09 11:02
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[2]: Огни разработки
От: SergH Россия  
Дата: 07.07.09 11:54
Оценка:
Здравствуйте, frogkiller, Вы писали:

F>Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.


Не кинут. Было в исходном посте.

21. there's more than one way to do it
Делай что должно, и будь что будет
Re[2]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 07.07.09 12:20
Оценка:
M>Open for extension, closed for modification
M>http://en.wikipedia.org/wiki/Open/closed_principle

добавлю в 26 пункт
26. новое делай снаружи, старое интегрируй внутрь
а) чем большим количеством что-то используется, тем более оно ядернее и интегрируемее должно быть (и наоборот)

M>Lisvov principle

M>http://en.wikipedia.org/wiki/Liskov_substitution_principle

это есть в 14 пункте
14. SOLID: An abbreviation for five basic class design principles in Object-Oriented-Design: Single responsibility principle, Open/closed principle, Liskov substitution principle, Interface segregation principle, Dependency inversion principle
Re[6]: Огни разработки
От: Klapaucius  
Дата: 07.07.09 12:31
Оценка:
Здравствуйте, eao197, Вы писали:

E>Тогда программирование -- несомненно искусство. А ПО разбившегося Ариан 5 одно из ярчайших проявлений направления "шок-арт": одним маленьким арифметическим переполнением пустить на воздух $500M!


Иманно это я и написал:

И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ракета, арифметическое переполнение

Это лицо программирования как искусства. Нет багов — есть выражение внутреннего мира художника. Тесты и спецификации не нужны — неверных путей все равно нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[6]: Огни разработки
От: Klapaucius  
Дата: 07.07.09 12:31
Оценка:
Здравствуйте, SergH, Вы писали:

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


Ну так я не спорю, что любой инженер может быть одной ногой художником — и архитектор и программист.
Я-то говорю о том, что инженер не может быть художником двумя ногами. Потому, что тогда падающие здания и ракеты нужно будет считать нормой, а так радикально перестроить мировосприятие человечеству будет сложно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[3]: Огни разработки
От: frogkiller Россия  
Дата: 07.07.09 12:42
Оценка:
Здравствуйте, SergH, Вы писали:

F>>Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.


SH>Не кинут. Было в исходном посте.


SH>21. there's more than one way to do it


Ух. Я до стольких считать не умею слишком много букв, я не осилил — и полез со своим перлом. Сорри.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[3]: Огни разработки
От: frogkiller Россия  
Дата: 07.07.09 12:44
Оценка:
Здравствуйте, Klapaucius, Вы писали:

F>>Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.


K>Ага. И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ракета, арифметическое переполнение.

K>Дело в том, что в искусстве нет неправильных путей. В программировании они есть. Это важное различие. Давайте о нем не забывать.

Ну, и единственный путь тоже может завести не туда

А вообще твой пример с переполнением не имеет никакого отношения к TIMTOWTDI.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[4]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 07.07.09 14:07
Оценка:
D>Может стоит перенести в http://wiki.rsdn.ru/ ?

пока рано.

пока это лишь черновик над который надо думать, дискутировать и т.д.
а для этого нужна большая аудитория и диалог (в вики и то, и другое — хуже)
вот когда более-менее устаканится (по крайней мере, первая волна), можно переносить в вики.
Re[6]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 07.07.09 14:09
Оценка:
SH> А возможно ему ещё третья нога понадобится, из области экономики-логистики.
Быстро убегать от заказчика?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[6]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 07.07.09 15:28
Оценка:
D> Дискутировать уже есть где, а как редактировать?

редактирование списка я пока хочу оставить за собой, потому что у любого проекта должен быть один "отец" особенно на ранний стадиях, и у меня есть идея(пока еще плохоформулируемая) как все это структурировать.
окончательный текущий вариант на http://blog.metatech.ru/post/ogni-razrabotki.aspx

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

D> Например зачем 1а и 9 когда есть solid и grasp?


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

1. жуй по частям (сложные вещи делаются, как складывание простых элементов)
a) unix-way(Пусть каждая программа делает одну вещь, но хорошо)
b) single responsibility principle


Solid уехал в раздел: "Огни применяемые в разных языках/подходах и т.д."
а grasp уехал в раздел "Паттерны, которые применяются для достижения вышеперечисленных огней"
Re: Огни разработки
От: mazurkin http://mazurkin.info
Дата: 07.07.09 16:00
Оценка:
DarkGray wrote:

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


Три богатыря: low coupling / high cohesion / tight incapsulation
Posted via RSDN NNTP Server 2.1 beta
Re[8]: Огни разработки
От: IT Россия linq2db.com
Дата: 07.07.09 18:28
Оценка:
Здравствуйте, SergH, Вы писали:

SH>Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.


Это называется — грам, градус, копейка
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 07.07.09 19:20
Оценка:
IT>Нужен не просто список принципов, нужен список с указанием где и когда каждый из принципов применим или не применим и почему. Тогда такому списку цены не будет.

именно, это и хочется сделать.
Re[8]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.07.09 04:03
Оценка:
Здравствуйте, SergH, Вы писали:
SH>Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.
Ага. Типичный пример — дизайн IKEA. То, что они делают — одновременно и эстетично, и функционально, и рентабельно. Всякий раз фигею с того, как они выбирают размер дощечек для шкафа так, чтобы их можно было сложить в упаковку с плотностью почти что 100%.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.07.09 06:32
Оценка:
SH>>> А возможно ему ещё третья нога понадобится, из области экономики-логистики.
VGn>>Быстро убегать от заказчика?

SH>Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.


С экономикой и так ясно. А логистика где?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[8]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.07.09 06:32
Оценка:
E> Обычный ширпотреб, коего и в программировании полно.

От картины есть польза. Она дырку на обоях закрывает.

... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[9]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 08.07.09 08:00
Оценка:
VGn> А логистика где?

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

это не относится к логистике, но задачи те же
Re[10]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.07.09 08:10
Оценка:
DG>управление проектом, распределение ресурсов своих и "соседей".
DG>принятие решений, что сделать сейчас, а что попозже

DG>это не относится к логистике, но задачи те же


Задачи логистики — эффективно добыть и довезти куда-то какой-нибудь жизненно необходимый хлам.
При чём тут распределение ресурсов, а тем более принятие решений в проекте?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[11]: Огни разработки
От: Qbit86 Кипр
Дата: 08.07.09 08:18
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>Задачи логистики — эффективно добыть и довезти куда-то какой-нибудь жизненно необходимый хлам.


Кроме того, задача логистики — это ещё и разводить рыбу в пруду :)
Глаза у меня добрые, но рубашка — смирительная!
Re[9]: Огни разработки
От: SergH Россия  
Дата: 08.07.09 08:19
Оценка:
Здравствуйте, VGn, Вы писали:

SH>>Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.


VGn>С экономикой и так ясно. А логистика где?


Тебе не кажется, что это немного оффтоп? Если что, речь про архитектора, который дома делает, а не архитектуру ПО

Экономика зависит от логистики. От того, какие материалы и ресурсы просто/возможно доставить к месту строительства. Или что нужно сделать, чтобы было просто. Вполне возможно, что этим отдельные люди занимаются, ни разу не участвовал в постройке большого дома.
Делай что должно, и будь что будет
Re[12]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.07.09 08:21
Оценка:

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[2]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 08.07.09 08:30
Оценка:
E>Существуют же еще и "анти-огни". Например, не изобретай велосипед. И как одно из частных его проявлений NIH syndrome.

поддерживаю.
записал так

Анти-Огни
1. Предварительное усложнение без четкого ответа "зачем?" корень всех зол
а) premature optimization is the root of all evil
b) любую проблему можно решить путём введения дополнительного абстрактного слоя (кроме проблемы слишком большого количества абстрактных слоёв).
2. не изобретай велосипед

Re[13]: «Вот, помню, был случай...»
От: Qbit86 Кипр
Дата: 08.07.09 08:32
Оценка:
Дело было в Лиманчике, играли как-то в крокодила, довелось мне объяснять жестами словосочетание «занимательная логистика» :) В общем, ключевым моментом для угадывания второго слова оказался изображённый жестами график одного из решений логистического дифура :)
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 09.07.09 11:57
Оценка:
KV>Из этого следует, что код должен быть безопасен, а следовательно:

поддерживаю.

KV>1) Любая уязвимость, допущенная в коде будет рано или поздно использована (антиогонек "безопасность через сокрытие")

KV>1.1) Безопасность через сокрытие скрывает безопасность
KV>2) Код уязвим настолько, насколько уязвима его самая незащищенная часть (принцип слабого звена)

KV>Я это к чему... Огни разработки безопасного кода интересны?


конечно, интересно, пиши. буду ждать.
Re[4]: Огни разработки
От: Klapaucius  
Дата: 09.07.09 13:11
Оценка:
Здравствуйте, frogkiller, Вы писали:

K>>Ага. И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ракета, арифметическое переполнение.

K>>Дело в том, что в искусстве нет неправильных путей. В программировании они есть. Это важное различие. Давайте о нем не забывать.
F>Ну, и единственный путь тоже может завести не туда

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

F>А вообще твой пример с переполнением не имеет никакого отношения к TIMTOWTDI.


А я ничего не говорю про TIMTOWTDI. Я говорю про искусство, которое не имеет никакого отношения к TIMTOWTDI.
Да и переполнение не причина — причина, как известно, творческий подход к повторному использованию кода.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[9]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 09.07.09 13:53
Оценка:
Здравствуйте, Klapaucius, Вы писали:

E>>Все это получается только в том случае, если вашу точку зрения считать правильной. Если же, напротив, верить в то, что в искусстве вполне есть неправильные направления (тот же самый шок-арт или творения типа "Черного квадрата"), то и картина выходит совсем другой.


K>На самом деле ничего не изменится. Даже если мы предположим, что в искусстве неправильные пути есть — мы не сможем отличить их от правильных — mensura Zoili-то у нас нет.


Время, как правило, все расставляет на свои места.

K>Это не столько программирование, сколько CS.


Никогда не мог понять, почему может существовать CS в отрыве от программирования.

K>Так что это "искусством" можно назвать только в смысле "умение", а не в смысле "продукт творческой деятельности", о которой мы тут и говорим, нет?


Применительно к упонянутой frogkiller-ом идиоме TIMTOWTDI, когда нужно суметь выбрать один путь из множества, речь идет именно об "умении".

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Огни разработки
От: IT Россия linq2db.com
Дата: 09.07.09 23:54
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


Уже гораздо лучше От кучи разношёрстных принципов обо всём мы перешли к вполне конкретному понятию — коду. Осталось ответить на вопрос — зачем. Зачем код дожен легко повторно использоваться, зачем быть легко модифицируемым, какая разница легко он читается или сложно?
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.07.09 00:21
Оценка:
IT> Зачем код дожен легко повторно использоваться, зачем быть легко модифицируемым, какая разница легко он читается или сложно?

цель же вроде была прописана во введении — это разве не ответ на вопрос "зачем?"

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


т.е. все это нужно для того, чтобы с помощью этого кода можно было комфортно решить стоящую передо мной задачу (или перед кем-то другим)
Re[10]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.07.09 03:08
Оценка:
Здравствуйте, eao197, Вы писали:

E>Время, как правило, все расставляет на свои места.

Совершенно непонятно, что и куда расставляет время.

E>Никогда не мог понять, почему может существовать CS в отрыве от программирования.

Хм. А ничего, что, к примеру, функан существует в отрыве от гидродинамики?

E>Хотя меня греет мысль, что некоторые результаты работы программистов все-таки можно считать искусством в смысле "продукта творческой деятельности".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Огни разработки
От: Vladek Россия Github
Дата: 10.07.09 05:05
Оценка:
Здравствуйте, eao197, Вы писали:

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


DG>>исходный пост http://blog.metatech.ru/post/ogni-razrabotki.aspx


DG>>навскидку:


E>Я не заметил самого важного "огонька": "Программа должна работать!" (т.е. делать именно то, за что заплатили ее заказчики/покупатели).


Это базовое требование к профессии.
Developers, developers, developers, developers, developers, developers, developers... © Steve Ballmer
Re[5]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.07.09 07:52
Оценка:
IT>Это всё следствия.

следствия чего?
Re[12]: Огни разработки
От: Трурль  
Дата: 10.07.09 10:08
Оценка:
Здравствуйте, eao197, Вы писали:

E>Доказательства по аналогии идут туда же, где находится математическая дисциплина "уравнения матфизики", существующая в отрыве от физики.

Не так всё просто. Сейчас "уравнения матфизики" применяются в экономике.
Re[12]: Огни разработки
От: Klapaucius  
Дата: 10.07.09 10:53
Оценка:
Здравствуйте, eao197, Вы писали:

E>Время отделяет искусство от моды.


Не обязательно отделяет. Вот Рембрандт Ван-Рейн только начал работать и вошел в моду. Потом время отделило искусство от моды и он умер в нищете. А потом время несколько раз снова соединяла искусство и моду — и снова разделяло. Последний раз мода на Рембрандта вернулась, кажется, в 60-е годы прошлого века. Какое все это имеет отношение к возможности объективно оценить искусство?

E>>>Никогда не мог понять, почему может существовать CS в отрыве от программирования.

S>>Хм. А ничего, что, к примеру, функан существует в отрыве от гидродинамики?
E>Доказательства по аналогии идут туда же, где находится математическая дисциплина "уравнения матфизики", существующая в отрыве от физики.

Это не доказательство по аналогии. И диффуравнения в частных производных не обязательно в физике применять.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[10]: Огни разработки
От: Klapaucius  
Дата: 10.07.09 10:59
Оценка:
Здравствуйте, eao197, Вы писали:

E>Время, как правило, все расставляет на свои места.


Об этом в ответе ниже.

E>Никогда не мог понять, почему может существовать CS в отрыве от программирования.


Это нормально, когда создание инструмента и применение инструмента разделено.

K>>Так что это "искусством" можно назвать только в смысле "умение", а не в смысле "продукт творческой деятельности", о которой мы тут и говорим, нет?

E>Применительно к упонянутой frogkiller-ом идиоме TIMTOWTDI, когда нужно суметь выбрать один путь из множества, речь идет именно об "умении".

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

Мой же довод, что программирование — это искусство, и поэтому оно по природе своей иррационально — вы тоже почему-то не воспринимаете

Так что именно творчество и внутренний мир, а не умение.

E>Хотя меня греет мысль, что некоторые результаты работы программистов все-таки можно считать искусством в смысле "продукта творческой деятельности".


Вы так говорите, как будто это что-то хорошее.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[13]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.07.09 11:00
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Не обязательно отделяет. Вот Рембрандт Ван-Рейн только начал работать и вошел в моду. Потом время отделило искусство от моды и он умер в нищете. А потом время несколько раз снова соединяла искусство и моду — и снова разделяло. Последний раз мода на Рембрандта вернулась, кажется, в 60-е годы прошлого века. Какое все это имеет отношение к возможности объективно оценить искусство?


Понятия не имею, это ваш пример с Рембрантом.

E>>>>Никогда не мог понять, почему может существовать CS в отрыве от программирования.

S>>>Хм. А ничего, что, к примеру, функан существует в отрыве от гидродинамики?
E>>Доказательства по аналогии идут туда же, где находится математическая дисциплина "уравнения матфизики", существующая в отрыве от физики.

K>Это не доказательство по аналогии. И диффуравнения в частных производных не обязательно в физике применять.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.07.09 11:07
Оценка:
Здравствуйте, Klapaucius, Вы писали:

E>>Никогда не мог понять, почему может существовать CS в отрыве от программирования.


K>Это нормально, когда создание инструмента и применение инструмента разделено.


Ok, мысль понятна.

K>>>Так что это "искусством" можно назвать только в смысле "умение", а не в смысле "продукт творческой деятельности", о которой мы тут и говорим, нет?

E>>Применительно к упонянутой frogkiller-ом идиоме TIMTOWTDI, когда нужно суметь выбрать один путь из множества, речь идет именно об "умении".

K>Вот уж нет. frogkiller использует апелляцию к тому, что программирование — искусство для обоснования иррационализма в программировании:

K>

K>Мой же довод, что программирование — это искусство, и поэтому оно по природе своей иррационально — вы тоже почему-то не воспринимаете

K>Так что именно творчество и внутренний мир, а не умение.

Умение -- это что, абсолютно детерминированная вещь? Если дать двум разным людям одинаковое количество уроков рисования, у них что будет одинаковое умение рисовать? Скорее всего, это умение будет сильно различаться. А его уровень будет определяться множеством факторов, в том числе и иррациональных.

E>>Хотя меня греет мысль, что некоторые результаты работы программистов все-таки можно считать искусством в смысле "продукта творческой деятельности".


K>Вы так говорите, как будто это что-то хорошее.


Да, на мой вгляд, это хорошо.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Огни разработки
От: Klapaucius  
Дата: 10.07.09 11:18
Оценка:
Здравствуйте, eao197, Вы писали:

E>Умение -- это что, абсолютно детерминированная вещь? Если дать двум разным людям одинаковое количество уроков рисования, у них что будет одинаковое умение рисовать? Скорее всего, это умение будет сильно различаться.


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

E>А его уровень будет определяться множеством факторов, в том числе и иррациональных.


Мне кажется, вы совсем не туда заходите. Уровень освоения, например, ТФКП студентом может зависить от иррациональных вакторов потому, что студент — человек и ничто человеческое ему не..., но от этого ТФКП не становится иррациональной.

E>Да, на мой вгляд, это хорошо.


Я понял. У меня на этот счет другое мнение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[14]: Огни разработки
От: Klapaucius  
Дата: 10.07.09 11:24
Оценка:
Здравствуйте, eao197, Вы писали:

K>>Не обязательно отделяет. Вот Рембрандт Ван-Рейн только начал работать и вошел в моду. Потом время отделило искусство от моды и он умер в нищете. А потом время несколько раз снова соединяла искусство и моду — и снова разделяло. Последний раз мода на Рембрандта вернулась, кажется, в 60-е годы прошлого века. Какое все это имеет отношение к возможности объективно оценить искусство?

E>Понятия не имею, это ваш пример с Рембрантом.

Попробую пояснить. Вы говорите, что время отделяет искусство от моды. Я говорю, что что-то может снова стать модным. Вы говорите, что время расставляет все на свои места, но время постоянно переставляет с одного места на другое. И в какой момент этого самого времени места "свои"? Хотите сказать, что лет через 50 Полет 501 станет вдруг выдающимся триумфом программирования?

K>>Это не доказательство по аналогии. И диффуравнения в частных производных не обязательно в физике применять.

E>И быстрая сортировка, надо полагать, применяется не только в программировании.

Я могу, например, книги рассортировать быстрой сортировкой в алфавитном порядке фамилий авторов. Это будет программированием?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[13]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.07.09 11:33
Оценка:
Здравствуйте, Klapaucius, Вы писали:

E>>Умение -- это что, абсолютно детерминированная вещь? Если дать двум разным людям одинаковое количество уроков рисования, у них что будет одинаковое умение рисовать? Скорее всего, это умение будет сильно различаться.


K>Если вы имеете под умением рисовать технику рисунка, то вобщем-то так и есть. Разброс будет как при обучении любой другой технике. Да и степень обученности технике рисунка можно объективно оценить. Но техника рисунка в искусстве — это не главное.


Нет, не технику рисунка. А способность с помощью рисунка, например, передать настроение натурщика.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[15]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.07.09 11:41
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>>>Не обязательно отделяет. Вот Рембрандт Ван-Рейн только начал работать и вошел в моду. Потом время отделило искусство от моды и он умер в нищете. А потом время несколько раз снова соединяла искусство и моду — и снова разделяло. Последний раз мода на Рембрандта вернулась, кажется, в 60-е годы прошлого века. Какое все это имеет отношение к возможности объективно оценить искусство?

E>>Понятия не имею, это ваш пример с Рембрантом.

K>Попробую пояснить. Вы говорите, что время отделяет искусство от моды. Я говорю, что что-то может снова стать модным. Вы говорите, что время расставляет все на свои места, но время постоянно переставляет с одного места на другое. И в какой момент этого самого времени места "свои"?


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

Будет ли тоже самое происходить с "дерьмом художника" через 450-500 лет? Если да, значит вы правы. Если нет, значит неправильные направления в искусстве все же есть.

K>Хотите сказать, что лет через 50 Полет 501 станет вдруг выдающимся триумфом программирования?


Вы делаете выводы на основании одного конкретного случая. Провалов и ширпотреба хватает везде.

K>>>Это не доказательство по аналогии. И диффуравнения в частных производных не обязательно в физике применять.

E>>И быстрая сортировка, надо полагать, применяется не только в программировании.

K>Я могу, например, книги рассортировать быстрой сортировкой в алфавитном порядке фамилий авторов. Это будет программированием?


Идею по демаркации CS и программирования я понял. Хотя было бы интересно посмотреть, как вы штук 50 книг отсортируете быстрой сортировкой с перемещеннием книг


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Огни разработки
От: Klapaucius  
Дата: 10.07.09 11:47
Оценка:
Здравствуйте, eao197, Вы писали:

E>Нет, не технику рисунка. А способность с помощью рисунка, например, передать настроение натурщика.


Эта способность состоит из двух частей:
1) Техники передачи эмоций — это знание того, что человек определенным образом интерпретирует линии определенной кривизны — и такому можно каждого научить, даже аутиста, который интуитивно эмоции не воспринимает.
2) Некоторых индивитуальных способностей художника, которым, вообще говоря, никто не учит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[16]: Огни разработки
От: Klapaucius  
Дата: 10.07.09 12:06
Оценка:
Здравствуйте, eao197, Вы писали:

E>В вашем примере мода влияет только на степень внимания к работам Рембрандта на какой-то момент времени. Оценка же его творений оказывается гораздо стабильнее.


Это неверно. Современники оценивали "Выступление стрелковой роты и т.д" (так называемый "Ночной дозор") низко. Позже ее стали оценивать высоко. Теперь ее оценивают скорее низко.

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


Не до сих пор, а в настоящий момент.

E>Будет ли тоже самое происходить с "дерьмом художника" через 450-500 лет? Если да, значит вы правы. Если нет, значит неправильные направления в искусстве все же есть.


Почему вас так волнует дерьмо художника? Вот например про Баха почти через сто лет, после того, как он творил можно было с уверенностью сказать, что испытания временем он не выдержал. А через 200 лет можно было сказать с уверенностью, что выдержал да еще как!
И откуда взялись числа 450-500? А если через 501 год дерьмо художника будет считаться высоким искусством, то это уже не считается? А если считается, то суд времени отдаляется от нас куда-то в +бесконечность, и не будет большой разницы, если мы посчитаем, что его вовсе не существует.

K>>Хотите сказать, что лет через 50 Полет 501 станет вдруг выдающимся триумфом программирования?

E>Вы делаете выводы на основании одного конкретного случая. Провалов и ширпотреба хватает везде.

Я указываю на принципиальную разницу — суд времени над этим "произведением искусства" свершился в момент аварийного подрыва ракеты. Откладывать его на +бесконечность не пришлось. Пересмотр оценки не предвидится.
История про ошибку 2000 и другие примеры антипаттерна "детонатор" также отличается от ситуации с искусством. "Детонатор" не становится плохим решением в момент срабатывания или непосредственно перед ним. Это с самого начала сомнительное решение, но, если мы знаем точный момент срабатывания, например, то можем обозначить временной интервал на котором такое решение в целом приемлемо. А когда сработает музыка Баха в ней не заложено.

E>Идею по демаркации CS и программирования я понял. Хотя было бы интересно посмотреть, как вы штук 50 книг отсортируете быстрой сортировкой с перемещеннием книг


В программировании быстрая сортировка тоже не всегда лучший выбор.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[17]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.07.09 13:28
Оценка:
Здравствуйте, Klapaucius, Вы писали:

E>>В вашем примере мода влияет только на степень внимания к работам Рембрандта на какой-то момент времени. Оценка же его творений оказывается гораздо стабильнее.


K>Это неверно. Современники оценивали "Выступление стрелковой роты и т.д" (так называемый "Ночной дозор") низко. Позже ее стали оценивать высоко. Теперь ее оценивают скорее низко.


Так ведь оценивают же. В отличие о многих современников того же Рембрандта, которые просто канули в лету.

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


K>Не до сих пор, а в настоящий момент.


Который длится, как минимум, лет пятьдесят.

E>>Будет ли тоже самое происходить с "дерьмом художника" через 450-500 лет? Если да, значит вы правы. Если нет, значит неправильные направления в искусстве все же есть.


K>Почему вас так волнует дерьмо художника?


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

K>И откуда взялись числа 450-500?


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

K>Я указываю на принципиальную разницу — суд времени над этим "произведением искусства" свершился в момент аварийного подрыва ракеты. Откладывать его на +бесконечность не пришлось. Пересмотр оценки не предвидится.


Здесь нет принципиальной разницы. Различие только во временных масштабах. Когда выполнялась приемка ПО Ариан, это ПО объективно доказывало свою состоятельность на имеющихся приемных испытаниях. Прошло какое-то время и бах! Не прокатило. С ошибкой 2000-го года похожая история, только время между приемкой и бабахом чуть побольше было.

В живописи временные отрезки еще больше. Но сама выбраковка, тем не менее, существует.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.07.09 14:26
Оценка:
IT>Если кратко, то следствия борьбы со сложностью. Если подробно, то в терминах борьбы со сложностью можно разобрать зачем нужнен и насколько полезен любой из принципов, если это, конечно, интересно.

совсем ничего я понял.

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

формализуя эту цель мы получили требования (см. предыдущие сообщения).


но теперь приходишь и ты говоришь: не фига, это все вторично — это все следствие того, что ты на самом деле хотел бороться со сложностью.
Re[7]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.07.09 14:48
Оценка:
IT>Если кратко, то следствия борьбы со сложностью. Если подробно, то в терминах борьбы со сложностью можно разобрать зачем нужнен и насколько полезен любой из принципов, если это, конечно, интересно.

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

IT> Если подробно, то в терминах борьбы со сложностью можно разобрать зачем нужнен и насколько полезен любой из принципов, если это, конечно, интересно.


да, интересно.

давай начнем с совмещения базисов, как ты определяешь понятие "сложность"? как его измеряешь? и т.д.
Re[9]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.07.09 16:25
Оценка:
IT>Ты намешал здесь всё в одну кучу. Как пользователю тебе всё равно каким способом будет решена твоя задача. Твоё дело определить функциональные требования. Требования к коду исходят от разработчика. Именно разработчик борется со сложностью кода, а не заказчик.

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

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



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

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


1. т.е. тебе как пользователю пофигу — данный форум открывается за 1 секунду или за день? (за конкретный срок)
2. т.е. тебе как пользователю пофигу — будет на твоем компьютере данный форум открываться или нет? (в том окружении, которое есть)
3. т.е. тебе как пользователю пофигу — за сколько времени данный форум сможет поддержать задачу вставлять таблицы (если вдруг ты это захочешь)? (быть готовым к переформулировке или корректировке задачи по ходу)
4. т.е. тебе как пользователю пофигу — сколько кнопок надо нажать и сколько приседаний сделать, чтобы запостить сообщение на данный форум (требование: программное решение должно легко использоваться)
Re[10]: Огни разработки
От: IT Россия linq2db.com
Дата: 10.07.09 17:04
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


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


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


Это очень ограниченное определение и покрывает в какой-то степени лишь количественную и алгоритмическую сложности. Например, Singleton сокращает количество вариантов поведения программного решения, но увеличивает сложность модификации кода. Не следование соглашениям об именованиях и отвратительное оформление кода вообще никак не влияют на количество вариантов поведения программного решения, но могут в разы увеличить сложность восприятия кода. Сложность понятие многогранное и неоднозначное и количественно не измеряется.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.07.09 19:14
Оценка:
IT> Не следование соглашениям об именованиях и отвратительное оформление кода вообще никак не влияют на количество вариантов поведения программного решения, но могут в разы увеличить сложность восприятия кода.

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

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

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


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


в чем увеличение сложности модификации кода?
Re[11]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.07.09 19:19
Оценка:
IT>Сроки меня интересуют. Но как разработчики этого добьются — нет.


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

как минимум заказчик поинтересуется, как тоже самое делают другие, как максимум может заказать аудит.
Re[11]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.07.09 19:40
Оценка:
Еще раз попробую сформулировать основную мысль:

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

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

заказчика при этом интересует:
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) ПР должно быть достаточно формализовано (должна оставаться возможность автоматического\автоматизированного рефакторинга)

зы
с каким именно выводом ты не согласен?
Re[2]: Огни разработки
От: frogkiller Россия  
Дата: 10.07.09 20:08
Оценка:
Здравствуйте, DarkGray, Вы писали:

[...]

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

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

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

И второе: никакие другие правила, кроме этих двух, не должны быть абсолютными. Т.е. всё, что ты перечислил далее должно звучать как "хотелось бы, чтобы при этом также выполнялось...", но не более.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[12]: Огни разработки
От: IT Россия linq2db.com
Дата: 11.07.09 02:31
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


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


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

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


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

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


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

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


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


Ну как же, это же Singleton Singleton — это способ прибивания гвоздями состояния к одному месту. Если модификация заключается в разнесении состояния по разным местам, то сложность модификации весьма увеличивается.
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Огни разработки
От: IT Россия linq2db.com
Дата: 11.07.09 02:35
Оценка:
Здравствуйте, DarkGray, Вы писали:

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

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

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

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

Системный подход учит — что для того, чтобы можно было отделить важное от неважного необходимо как минимум:
1. сформулировать изначальную задачу (изначальная задача — это то, что заказчик хочет ПП)
2. научиться измерять исследуемое хотя бы качественно (сложность ПП — это кол-во вариантов необходимое для рассмотрения)
Re[13]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 11.07.09 07:52
Оценка:
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
Re[13]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 11.07.09 08:20
Оценка:
кстати очень интересно применить вот это

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

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


допустим я хочу вставить таблицу и ищу подходящий тег.
текущая сложность будет = 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(+выпадающий список)/*
посчитать варианты использования оставляю в качестве домашнего задания
Re[15]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 11.07.09 09:14
Оценка:
ЮЖ>+1, только у меня терминология отличается.

согласен, это лишь спор о терминах
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[3]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 11:08
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


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


В том то и проблема, что тебе надо время для структурирования. Когда человек хорошо осваивает какой то вопрос, ему не надо время на структутирование.
Re[4]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 11:25
Оценка:
I>В том то и проблема, что тебе надо время для структурирования. Когда человек хорошо осваивает какой то вопрос, ему не надо время на структутирование.

спорить не буду.

одна из проблем, что я могу структурировать эти пункты десятком, если не сотней способов — соответственно надо подумать какой лучше.
Re[26]: Огни разработки
От: FR  
Дата: 12.07.09 11:26
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


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


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

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


Являются, эти вещи или понимаешь или нет, их нельзя понять наполовину.
Re[27]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 11:34
Оценка:
Здравствуйте, FR, Вы писали:

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


FR>Являются, эти вещи или понимаешь или нет, их нельзя понять наполовину.


Даже если человек их понял это _не_ означает качественного сдвига, вот в чем дело.

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


I>>В том то и проблема, что тебе надо время для структурирования. Когда человек хорошо осваивает какой то вопрос, ему не надо время на структутирование.


DG>спорить не буду.


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


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

Структурирование берется именно по отношению к цели и тут не может быть десятков способов, если только не строится "теория всего".
Re[28]: Огни разработки
От: FR  
Дата: 12.07.09 11:47
Оценка:
Здравствуйте, Ikemefula, Вы писали:

FR>>Являются, эти вещи или понимаешь или нет, их нельзя понять наполовину.


I>Даже если человек их понял это _не_ означает качественного сдвига, вот в чем дело.


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

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


Указатели это понимание косвенной адресации, виртуальные методы понимание полиморфизма,
обе вещи вполне фундаментальны и реально меняют мышление, но боюсь с моим достаточно интуитивным
мышлением я это не смогу внятно объяснить.
Re[6]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 12:10
Оценка:
I>Структурирование берется именно по отношению к цели и тут не может быть десятков способов, если только не строится "теория всего".

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


I>>Структурирование берется именно по отношению к цели и тут не может быть десятков способов, если только не строится "теория всего".


DG>одна из целей — чтобы другим было легче воспринять.


Это в просторечии "теория всего"
Re[20]: Огни разработки
От: IT Россия linq2db.com
Дата: 12.07.09 13:36
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


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


Зазубрить что? Варианты поведения разработываемого ПП? Ты когда начинаешь фантазировать всё же сверяйся со своей собственной оригинальной формулировкой.
Если нам не помогут, то мы тоже никого не пощадим.
Re[29]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 13:47
Оценка:
Здравствуйте, FR, Вы писали:

FR>Указатели это понимание косвенной адресации, виртуальные методы понимание полиморфизма,

FR>обе вещи вполне фундаментальны и реально меняют мышление, но боюсь с моим достаточно интуитивным
FR>мышлением я это не смогу внятно объяснить.

Я понял что ты хочешь сказать. Мышление меняет понимание полиморфизма и понимание ссылочных типов.

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

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

DG>ps

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

Их не надо запоминать в том смысле, что зазубривание тебе ничего не даст абсолютно.


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


DG>сложность — это кол-во вариантов которые надо рассмотреть.

DG>что не так?

К вариантам это нельзя свести.

Сложность это глубина просчета и объем материала который подлежит качественной оценке на этой глубине + сложность этой качественной оценки.

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

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

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

Разумеется, чем больше работаешь, тем бОльшим масштабом ты можешь оперировать в таких вот рассчетах.

P.S. фокус про масштаб мышления — это функция от (полоса пропускания интеллекта помножить на квадрат времени (работа+отдых))
Re[23]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.07.09 14:38
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>P.S. фокус про масштаб мышления — это функция от (полоса пропускания интеллекта помножить на квадрат времени (работа+отдых))



Ошибся, корень вместо квадрата. При постоянной полосе пропускания бы масштаб мышления рос линейно, время должно расти квадратично.
Re[2]: Огни разработки
От: minorlogic Украина  
Дата: 12.07.09 15:56
Оценка:
Если бы эти правила были так очевидны ... , может мы с вами живем в паралельных вселенных ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.07.09 16:41
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>Если бы эти правила были так очевидны ... , может мы с вами живем в паралельных вселенных ?


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

На счёт параллельных вселенных у меня тоже сомнения. У меня за плечами самая обыкновенная школа и институт образца позднего СССР. Гы-гы, может, и правда, параллельная вселенная для некоторых (это не в твой адрес, если что).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: Огни разработки
От: minorlogic Украина  
Дата: 12.07.09 17:11
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


M>>В целом, совершенно не по делу твое высказывание. Не было бы этих правил если бы все им следовали с первых минут програмирования.


ГВ>Заморочка не в правилах самих по себе, а в отношении к ним. Если бы к ним относились с должной долей юмора и не более того — проблем бы не было. Но пытаться интерпретировать эти правила как реальные практические наставления, как какие-то направляющие принципы, которыми можно набить голову той самой молодёжи до набора практического опыта — глупость несусветная. Это, не знаю... Надо очень крепко спать, бодрствуя.


А не надо выдумывать. Никто не относится к ним так , я повторяюсь. Это правила которые направляют а не предписывают. Или у вас на работе они включены в код стайл ? тогда я могу понять идиосинкразию.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[5]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.07.09 17:13
Оценка:
Здравствуйте, minorlogic, Вы писали:

M>>>Если бы эти правила были так очевидны ... , может мы с вами живем в паралельных вселенных ?

M>А не надо выдумывать , никто не предлагает молиться на эти правила. Но в моей вселенной 95% кода не соответствует этим правилам. И я очень завидую молодежи которая может прочесть Мак Коннела и уяснить для себя то с чем я лбом сталкивался и набивал шишки много лет.

Так в том-то и дело, что это тебе, набившему шишки за много лет, Мак Коннел понятен и естественен. Думаешь, если бы такой талмуд сунули тебе в руки в юности, ты бы кинулся реализовывать его советы, наплевав на собственный полёт мысли? Ой, смею в этом усомниться.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.07.09 17:36
Оценка:
Здравствуйте, DarkGray, Вы писали:


ГВ>>Понимаешь, можно вбить ровно один гвоздь, и выработать на этом несколько таких агитпроповских высказываний:

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

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

DG>или для тебя новость, что гвозди тоже учат забивать?...


Шуточка по поводу:

Рядовой Иванов, что вы сказали сержанту Петрову?
Я сказал: товарищ сержант, обратите, пожалуйста, внимание, что мне за шиворот капает расплавленное олово с вашего паяльника!

Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: Огни разработки
От: minorlogic Украина  
Дата: 12.07.09 17:48
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Вот это как раз не лозунги, а сугубо практические инструкции.


А это и были "сугубо практические инструкции"
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[4]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 17:51
Оценка:
ГВ>Вот это как раз не лозунги, а сугубо практические инструкции.

а вот где собака порылась...

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

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

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

DG>т.к. лозунги воздействует не только на разум, но и на эмоции.

В некоторых областях обучать лучше через лозунги
Re[9]: Огни разработки
От: _FRED_ Черногория
Дата: 13.07.09 05:12
Оценка:
Здравствуйте, Sinclair, Вы писали:

SH>>Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.

S>Ага. Типичный пример — дизайн IKEA. То, что они делают — одновременно и эстетично, и функционально, и рентабельно. Всякий раз фигею с того, как они выбирают размер дощечек для шкафа так, чтобы их можно было сложить в упаковку с плотностью почти что 100%.

А ты не замечал, что решив несколько второстепенных проблемм производства (упаковку, оптимальность раскроя и т.п.) и несколько первостепенных потребления (дёшево, удобно, симпотично) они заметно проигрывают в качестве и надёжности?
Help will always be given at Hogwarts to those who ask for it.
Re[10]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.07.09 05:36
Оценка:
Здравствуйте, _FRED_, Вы писали:
_FR>А ты не замечал, что решив несколько второстепенных проблемм производства (упаковку, оптимальность раскроя и т.п.) и несколько первостепенных потребления (дёшево, удобно, симпотично) они заметно проигрывают в качестве и надёжности?
По сравнению с чем? Если сравнивать с итальянской мебелью в ценовой категории "IKEA*5" — да, проигрывают.

А если сравнить с аналогичной по цене мебелью местного производства — извини, IKEA по качеству и надёжности рвёт их в кровавые ошмётки. Я имел щасте сравнить, к примеру, цены на кухонные гарнитуры в широком диапазоне возможных реализаций. В итоге выбрал ИКЕЮ. Потому, к примеру, что ближайший к ней аналог с покрытием из шпона (см.тж. качество) и выкатными элементами BLUM (см.тж. надёжность) стоил примерно в 2.5х от Икеи. И это не считая полученной нами скидки 50% на плиту и духовку — к слову, вполне себе качественные и надёжные плита с духовкой. Отличия от Bosch, который у нас остался в качестве "основного" решения, минимальные. В частности а) нет поддежки "адского отжига" (т.е. пиролитической очистки) в духовке, и б) управление варочной поверхностью не сенсорное, а рукоятками с духовки. При этом комплект Bosch обошёлся нам в 30тр (сейчас доступен примерно за 45тр), а комплект икеевского Whirlpoolа — за 12тр. Почюствуйте, как грица, разницу.

Даже если подходить с абсолютной точки зрения, не принимая во внимание бюджет, Икея выглядит совсем-совсем неплохо и по качеству, и по надёжности. Мне пока не удалось загубить ни одну из купленных в икее вещей.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 06:31
Оценка:
S>А если сравнить с аналогичной по цене мебелью местного производства — извини, IKEA по качеству и надёжности рвёт их в кровавые ошмётки.

а как же столплит http://shop.stolplit.ru/?

очень хорошо отзываются.
Re[5]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 06:47
Оценка:
Здравствуйте, DarkGray, Вы писали:

ГВ>>Ни там, ни там нет никаких лозунгов. Совсем.


DG>а вот это ТБ или не ТБ?

DG>лозунг или инструкция?

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

DG>


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

DG>т.к. лозунги воздействует не только на разум, но и на эмоции.

Мсье путает причины и следствия. Агитпроп, повторюсь — это дополнение к тому самому инструктажу под расписку, напоминание, но не обучение. Ты ещё плакаты в в/ч уставом назови.

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


Но без скучных формальных инструкций дело не обходилось никогда. То есть без прямого, без обиняков, введения в курс дела. После этого агитпроп, лозунги, это уже так, конфетти. И никому, кроме искусствоведов, может быть, и в голову бы не пришло руководствоваться тем, что намалёвано на стенах.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Огни разработки
От: _FRED_ Черногория
Дата: 13.07.09 06:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

_FR>>А ты не замечал, что решив несколько второстепенных проблемм производства (упаковку, оптимальность раскроя и т.п.) и несколько первостепенных потребления (дёшево, удобно, симпотично) они заметно проигрывают в качестве и надёжности?
S>По сравнению с чем? Если сравнивать с итальянской мебелью в ценовой категории "IKEA*5" — да, проигрывают.

Даже не *5, а *2. Уже тогда есть разница. Не на всё, именно разница заметна в мебели.

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


С аналогичной по цене — несомненно. Но дело в том, что качественная мебель — эта та, которую не стыдно будет потомкам оставить, а такового в ИКЕЕ нет.

S>Я имел щасте сравнить, к примеру, цены на кухонные гарнитуры в широком диапазоне возможных реализаций. В итоге выбрал ИКЕЮ.


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

S>Даже если подходить с абсолютной точки зрения, не принимая во внимание бюджет, Икея выглядит совсем-совсем неплохо и по качеству, и по надёжности. Мне пока не удалось загубить ни одну из купленных в икее вещей.


Какой ИКЕЕвоской мебелью ты пользовался лет пять?
Help will always be given at Hogwarts to those who ask for it.
Re[12]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.07.09 07:01
Оценка:
Здравствуйте, DarkGray, Вы писали:
DG>очень хорошо отзываются.
Ну, я с ними пока не сталкивался, отзывов не имею. Настораживает полное отсутствие на сайте комментариев относительно используемой фурнитуры (хитрецы, которые применяют вместо blum т.н. "офисные направляющие" сразу идут в девнулл). Кроме того, они походу ничего, кроме MDF и ламината, не обещают — что означает хреновые "качество и надёжность". По сравнению, я имею в виду, с пластиком и шпоном.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Поправка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 07:17
Оценка:
ГВ>...кроме искусствоведов, может быть, и в голову бы не пришло руководствоваться тем, что намалёвано на стенах.

...кроме искусствоведов, может быть, и в голову бы не пришло предметно изучать то, что намалёвано на стенах.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 07:23
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


Пальцем в такую область можно? Техническую, желательно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 07:35
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


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


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

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

DG>представил?

Угу, как всегда, либо количество, либо качество. Вы вольны выбрать что-то одно.

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

DG>так какие фразы будут в этой инструкции?

Уж точно не лозунги, а краткое, сжатое описание сути выполняемых действий. Инструкция по ТБ хороший пример: "Если вы упустили режущий инструмент, то не старайтесь поймать его на лету". Кратко, просто, легко запомнить и не надо разъяснять. И никакой метафоричности.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 07:53
Оценка:
Хорошо, давай подведем подитог.

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

я корректно сформулировал твою позицию?
Re[21]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 08:07
Оценка:
IT, ты много ерничаешь, и мало формулируешь свою позицию, но попробую все-таки записать твою позицию.

ты согласен с тем, что:
1. в программировании применяются огни,
2. огни направлены на уменьшение сложности ПП.

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

я корректно записал твою позицию?
Re[7]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 08:08
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>Хорошо, давай подведем подитог.

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

Что это такое — инструкция о том, как писать программу? Описание языка? Code style? UI guideline? Инструкция по инсталляции?

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

DG>я корректно сформулировал твою позицию?

Не совсем. Я вообще против "инструкций о том, как писать программу". Программирование — настолько сложная область, что применительно к нему какие-то инструкции общего характера сразу вырождаются в сборник метафор. Но метафоры требуют понимания, которое возможно только в контексте практического опыта (вариант — очень развитые способности к индукции), отсюда возвращаемся на исходные позиции. Так что, я против таких инструкций в любом виде, кроме как разновидности профессионального фольклора. Да, как юмор, как анекдоты — это прикольно. Но не наоборот.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[10]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 08:09
Оценка:
DG>т.е. тебе как пользователю/заказчику пофигу, чем тебе в сервисе колесо к машине прикрутили: скотчем, сваркой или все-таки винтами?

Вот именно, что тебя должны волновать только результаты: прочность, надёжность, удобство. А шаг резьбы на болтах — совершенно не твоего ума дело (как заказчика).
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[9]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 08:23
Оценка:
Здравствуйте, DarkGray, Вы писали:

ГВ>>Не совсем. Я вообще против "инструкций о том, как писать программу".

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

Чему обучать? Программированию?

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

DG>твой подход к обучению пока не понимаю.

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

DG>ps

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

Дурдом, что я тебе тут ещё могу сказать? Нужно заставлять не "стремиться", а находить компромисс между внешними требованиями и своими желаниями.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 08:23
Оценка:
DG>>т.е. тебе как пользователю/заказчику пофигу, чем тебе в сервисе колесо к машине прикрутили: скотчем, сваркой или все-таки винтами?

VGn>Вот именно, что тебя должны волновать только результаты: прочность, надёжность, удобство. А шаг резьбы на болтах — совершенно не твоего ума дело (как заказчика).


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

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

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

pps
кстати, наверное, заказчик "Ariane 5 Flight 501" очень переживал, что не смотрел какую именно резьбу (какие единицы измерения) используют разработчики.
Re[10]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 08:24
Оценка:
ГВ>Чему обучать? Программированию?

да, как учить программированию, причем не просто программированию, а хорошему стилю при программировании.
Re[10]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 08:26
Оценка:
ГВ>а находить компромисс между внешними требованиями и своими желаниями.

code style это внешнее требование?
личное(свое) желание разработчика?
что-то еще?
Re[12]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 08:33
Оценка:
VGn>>Вот именно, что тебя должны волновать только результаты: прочность, надёжность, удобство. А шаг резьбы на болтах — совершенно не твоего ума дело (как заказчика).

DG>почему меня, как заказчика, это не должно волновать?


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

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


Голова не болит. (в переводе на манагерский — Экономия ресурсов)
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[11]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 08:37
Оценка:
Здравствуйте, DarkGray, Вы писали:

ГВ>>а находить компромисс между внешними требованиями и своими желаниями.

DG>code style это внешнее требование?

Естественно — внешнее (по отношению к человеку). Это общее внутрикомандное соглашение об оформлении текста программы. Поправить его могут все, но и следовать ему должны тоже все.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 08:39
Оценка:
VGn>Потому что знание этих тонкостей не влияет на результат. Скорее наоборот, вдаваясь в такие детали, ты можешь пропустить что-нибудь важное в требованиях (сложность — она сложность и есть)

зайду чуть с другой стороны.
заказчик должен или не должен иметь возможность заказать внешний аудит, который залезит "под капот" разработки, и посмотрит что и как было сделано внутри?
Re[12]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 08:40
Оценка:
ГВ>Это общее внутрикомандное соглашение об оформлении текста программы.

какие еще внутрикомандные соглашения желательны (кроме code style)? и в каком виде они должны формулироваться?
Re[10]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 08:44
Оценка:
VGn>Источником является комбинаторная сложность.

комбинаторная сложность и кол-во вариантов поведения это не одно и тоже?
Re[11]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 08:47
Оценка:
Здравствуйте, DarkGray, Вы писали:

ГВ>>Чему обучать? Программированию?

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

Не, давай уж поделим одно и другое. Стиль — это стиль, программирование — это программирование. Иногда стилем можно и нужно жертвовать во имя других целей. И если уж говорить о стиле (который всегда соседствует с вкусом), то лучше всего его развивает не бормотание тайных метафор, а посещение музеев искусства и много-много практики.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 08:50
Оценка:
ГВ> И если уж говорить о стиле (который всегда соседствует с вкусом), то лучше всего его развивает не бормотание тайных метафор, а посещение музеев искусства и много-много практики.

хмм, а почему с тобой не согласны художественные школы, которые учат в том числе и стилю?
они ошибаются?
Re[14]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 08:50
Оценка:
VGn>>Потому что знание этих тонкостей не влияет на результат. Скорее наоборот, вдаваясь в такие детали, ты можешь пропустить что-нибудь важное в требованиях (сложность — она сложность и есть)

DG>зайду чуть с другой стороны.

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

Это вопрос доверия.
Сэкономили на стоимости разработки, тратьте на аудит. К процессу разработки отношения не имеет.
Кто-то лезет под дно при покупке автомашины. Кто-то — нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[13]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 08:52
Оценка:
Здравствуйте, DarkGray, Вы писали:

ГВ>>Это общее внутрикомандное соглашение об оформлении текста программы.

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

Зависит от команды. Они могут быть самыми невероятными — вплоть до dress code. Про code style я вспомнил, потому что такие соглашения есть почти у всех.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 08:54
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


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

DG>они ошибаются?

Я о технарях говорю. Хорошо, пусть не музеи искусства, а просто образцы инженерных решений.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 08:57
Оценка:
ГВ>Зависит от команды. Они могут быть самыми невероятными — вплоть до dress code. Про code style я вспомнил, потому что такие соглашения есть почти у всех.

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

ок, более конкретный вопрос: то, что static переменных лучше избегать — стоить записать в общекомандное соглашение или нет?
Re[14]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:00
Оценка:
хорошо, т.е. твою текущую позицию я понял так:

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

я корректно сформулировал?
Re[15]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 09:01
Оценка:
Здравствуйте, DarkGray, Вы писали:

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

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

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

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


ИМХО, не стоит. Потому что их не нужно специально избегать, иногда такие переменные очень полезны. Иногда они наоборот, вредны.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:02
Оценка:
VGn>Количество вариантов поведения — результат комбинаторной сложности. (динамика vs статика), но в общем — да. Я ещё не достаточно углубился в ветку.

тогда как свежему человеку, у выражения a+b какая комбинаторная сложность?
Re[16]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:04
Оценка:
ГВ>ИМХО, не стоит. Потому что их не нужно специально избегать, иногда такие переменные очень полезны. Иногда они наоборот, вредны.

и соответственно пытаться разобраться, когда стоит, когда не стоит — тоже не надо?
и если все-таки разобрали, то это не надо записывать?
Re[7]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.07.09 09:05
Оценка:
Здравствуйте, IT, Вы писали:

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


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


Я примерно это и имел ввиду.
Re[15]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 09:07
Оценка:
Здравствуйте, DarkGray, Вы писали:

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

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

OMG. Нет, не бесполезно передавать знания. Глупо ставить метафоры впереди всего. Метафоры на то и метафоры, что они выражают опыт в некоем определённом контексте. Вот как твой плакат с болтуном и шпионами. Так вот, до объяснения самого контекста метафоры будут только путать. Возвращаясь к плакату: если не знать контекста, то легко представить, что по телефону вообще разговаривать нельзя.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[17]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 09:08
Оценка:
Здравствуйте, DarkGray, Вы писали:


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


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


Надо.

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


Надо. Но это отменяет необходимости разобраться.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:10
Оценка:
ГВ>Надо. Но это отменяет необходимости разобраться.

т.е. должна быть не инструкция, а должен быть список вещей, которые программисту необходимо разобрать?
Re[13]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 09:16
Оценка:
DG>тогда как свежему человеку, у выражения a+b какая комбинаторная сложность?

Решил отвлечь меня на конечные автоматы? Имхо наша тема более абстрактна.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[15]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:16
Оценка:
VGn>Это вопрос доверия.

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

т.е. даже на самом официальном автосервисе рекомендуют периодически проверять, что и как было сделано.
а тут ПП, который на несколько порядков сложнее, чем машина — и лишь доверяй...
Re[14]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:18
Оценка:
VGn>Решил отвлечь меня на конечные автоматы? Имхо наша тема более абстрактна.

а все-таки? просто я хотел показать на этом простом примере, что в жизни применяются разные оценки комбинаторной сложности.
Re[19]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 09:20
Оценка:
Здравствуйте, DarkGray, Вы писали:

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

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

Конечно. И этот список начинается в профильном вузе.

Программист, как и всякий технический специалист, коль скоро мы именно о них, должен понимать, что из чего следует и к каким последствиям приведёт или не приведёт. "От обратного" тут адекватно научить очень сложно. ИМХО, списками наставлений тут не поможешь — сложные проблемы нельзя решить простыми способами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:24
Оценка:
ГВ>Конечно. И этот список начинается в профильном вузе.

тогда как ты относишься к утверждению:
при становлении программистом стоит разобрать следующий список: ?

Огни:
1. жуй по частям (сложные вещи делаются, как складывание простых элементов)
a) unix-way(Пусть каждая программа делает одну вещь, но хорошо)
b) single responsibility principle
4. Don't Repeat Yourself (acronym DRY, also known as Single Point of Truth and Single Point of Maintenance)
а) single point of knowledge
5. Keep it simple, stupid (acronym KISS), "Не плодить сущностей без необходимости." (Бритва Оккама)
а) кода должно быть чем меньше, тем лучше
8. Атомарность
а) Tell, don't ask
9. Разное делай разным, одиннаковое — одиннаковым
a) Связность и связанность (cohesion, coupling)
10. Программа всегда находится в корректном состоянии
a) транзакционность (изменение состояния делается только в самом конце)
b) безопасность исключений
16. CoC (Convention over configuration) — http://en.wikipedia.org/wiki/Convention_over_configuration
18. "утверждение"(кусок кода) должно быть самодостаточным (требовать как можно меньше обращений к внешним справочникам)
19. кажись сложным, будь простым (число поддерживаемых внешних вариантов должно быть как можно больше, число внутренних вариантов поведения как можно меньше)
...
и т.д.

Re[13]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 09:24
Оценка:
E>Просто ради исторической справедливости: так переживал, вероятно, заказчик Mars Surveyor. А Arian 5 была другая причина катастрофы -- там разработчики ПО не знали, чем Arian 5 отличается от Arian 4.

Сработал 10 огонёк. Точнее — антипаттерн "такого быть не может".
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[14]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:28
Оценка:
Здравствуйте, VGn, Вы писали:

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


VGn>Сработал 10 огонёк. Точнее — антипаттерн "такого быть не может".


еще нарушен 20-ый

20. b) Principle of least astonishment


программа в целом сильно всех удивила.
Re[21]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 09:29
Оценка:
Здравствуйте, DarkGray, Вы писали:

ГВ>>Конечно. И этот список начинается в профильном вузе.

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

[skip]

Негативно. Это полезно уже состоявшимся специалистам, как своеобразная юморная памятка, как сборник пословиц и поговорок, вроде "тестируют программы только не уверенные в себе". Сначала нужно усвоить, что своя голова должна превалировать над мнением окружающих, и в то же время, этих самых окружающих необходимо учитывать при своих действиях.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 09:29
Оценка:
DG>а всех интересует — кол-во рассматриваемых вариантов, соответственно для этого разработано куча методик, как свести к минимуму кол-во рассматриваемых вариантов; и большинство принципов(или огней в терминологии данного треда) программирования направлено именно на уменьшение рассматриваемых вариантов.

В правильном процессе количество рассматриваемых вариантов ограничивается зонами ответственности (уровнями абстракции).

В коде всё тоже самое (области отвественности кода — тоже важный паттерн), но имхо это вообще не дело заказчика.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[16]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 09:29
Оценка:
VGn>>Это вопрос доверия.

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


Тебе часто дают копаться в коробочном софте? Или покупка коробочного софта — только вопрос выбора?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[22]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:32
Оценка:
ГВ>Негативно. Это полезно уже состоявшимся специалистам, как своеобразная юморная памятка, как сборник пословиц и поговорок, вроде "тестируют программы только не уверенные в себе".

т.е. лучше все капканы и ловушки обходить самому, а не пользоваться чужим опытом?
Re[17]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:34
Оценка:
VGn>Тебе часто дают копаться в коробочном софте? Или покупка коробочного софта — только вопрос выбора?

а что кто-то мешает?
берешь дебагер, дизассемблер, reflector и вперед.

и все "подкапотное" пространство как на ладони.

и сразу видно, что кто-то разрабатывает надежно, а кто-то сопливо.
Re[24]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:55
Оценка:
L>Ну, как то ты в крайности бросаешься, честное слово.

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

L> Смысл в том, что учиться нужно не по лозунгам.


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

это кстати кратко записано как

29. Скопируй, разберись, сделай лучше

Re[15]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 09:58
Оценка:
VGn>В коде всё тоже самое (области отвественности кода — тоже важный паттерн), но имхо это вообще не дело заказчика.

а если под заказчиком понимать команду разработчиков, которая заказала одному из разработчиков этой же команды решить подзадачку
то такому заказчику(команде разработчиков) важно знать как будет выполнена подзадача?
Re[18]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 10:06
Оценка:
DG>а что кто-то мешает?
DG>берешь дебагер, дизассемблер, reflector и вперед.
DG>и все "подкапотное" пространство как на ладони.
DG>и сразу видно, что кто-то разрабатывает надежно, а кто-то сопливо.

Ну и как там разрабатывают Висту? Надёжно или сопливо?
И что тебе даст ответ на этот вопрос?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[25]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 10:08
Оценка:
Здравствуйте, DarkGray, Вы писали:

ГВ>>Ты удивишься, но капканы и ловушки можно обойти только на своём собственном опыте.

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

Кстати, сколько лет учат считать и писать? И как это делают? Напомнить? И что является целью прораммы среднего образования? Усвоение ряда поговорок про математику?

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

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

Завелась шарманка... Давай ещё сюда любимые коробки передач и сравнение Мерседеса с Виллисом.

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


Уже теплее. Только опять таки, чтобы интегрировать, нужно очень глубоко разобрать такие высказывания. А проще — систематически изложить то, что под этими высказываниями подразумевается. Возвращаемся к необходимости систематического обучения, которому все эти метафоры — параллельны.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 10:12
Оценка:
VGn>Ну и как там разрабатывают Висту? Надёжно или сопливо?

у микрософта довольно хороший код последнее время, и это кстати следствие тех инициатив, которые они внедрили по проверке качества кода.
и кстати они про эти инициативы постоянно всем рассказывают — это к теме интересно или нет заказчикам — как сделано ПО.
Re[26]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 10:18
Оценка:
ГВ> А проще — систематически изложить то, что под этими высказываниями подразумевается. Возвращаемся к необходимости систематического обучения, которому все эти метафоры — параллельны.

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

ps
это такие же метафоры как в русском:
жи/ши пиши с буквой и
мягкий знак в глаголах проверяется с помощью вопросов что делает/что делать
вводные слова отделяются запятой
и т.д.
Re[17]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 10:18
Оценка:
VGn> Они оформляют договор?

чего?

помедленнее, пожалуйста, я записываю (С)
Re[29]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 10:31
Оценка:
Здравствуйте, DarkGray, Вы писали:

ГВ>>Извини за грубость, ты в своём уме?

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

Ёшкин хвост, но система обучения программированию уже давным-давно есть, зачем подменять её наивными правилами?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[29]: PS
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 10:32
Оценка:
Здравствуйте, DarkGray,

Всё, смываюсь до завтра.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 10:38
Оценка:
DG>у микрософта довольно хороший код последнее время, и это кстати следствие тех инициатив, которые они внедрили по проверке качества кода.
DG>и кстати они про эти инициативы постоянно всем рассказывают — это к теме интересно или нет заказчикам — как сделано ПО.

ooftopic
Только в этом году работал с кодом Мелкософта. Код у них ОЧЕНЬ разный. В общей массе такое же говно, как и во всех корпоративных продуктах.
Но это не значит, что с ним нельзя работать. Альтернативы обычно намного хуже, если вообще есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[19]: Огни разработки
От: Undying Россия  
Дата: 13.07.09 11:09
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>Расшифровываю, с какого ... это заказчик?

VGn>Заказчик подразумевает заказ.

Т.е. если разработка freeware, то сформулировать требования к коду нельзя? А как только разработка становится shareware сразу можно?

VGn>И даже игнорируя такую странную постановку вопроса,

VGn>важны только внешние интерфейсы. Иначе гнать такого разработчика в шею.

Ты серьезно? Т.е. если за прекрасным внешним интерфейсом что-то будет делаться со стократным оверхедом, из-за чего другой разработчик завтра встрянет, то это нормально?
Re[31]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 11:17
Оценка:
Здравствуйте, DarkGray, Вы писали:

ГВ>>Ёшкин хвост, но система обучения программированию уже давным-давно есть, зачем подменять её наивными правилами?

DG>ссылку на эту систему можно?

Посмотри в программы профильных вузов.

DG>в российской информатике(как учебного предмета) нет никакой системы.


Значит, это плохая программа. Неполноценная.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 11:18
Оценка:
VGn>>Расшифровываю, с какого ... это заказчик?
VGn>>Заказчик подразумевает заказ.

U>Т.е. если разработка freeware, то сформулировать требования к коду нельзя? А как только разработка становится shareware сразу можно?


Не понял.

VGn>>И даже игнорируя такую странную постановку вопроса,

VGn>>важны только внешние интерфейсы. Иначе гнать такого разработчика в шею.

U>Ты серьезно? Т.е. если за прекрасным внешним интерфейсом что-то будет делаться со стократным оверхедом, из-за чего другой разработчик завтра встрянет, то это нормально?


Читаем последнее предложение. ИМХО если разработчику доверия нет, то это значит, что работу фактически придётся делать дважды.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[9]: Огни разработки
От: Undying Россия  
Дата: 13.07.09 11:22
Оценка:
Здравствуйте, IT, Вы писали:

IT>Как пользователю тебе всё равно каким способом будет решена твоя задача.


Способы решения задачи в плане удобства, надежности, быстродействия и возможности доработки пользователя весьма интересуют. Другое дело, что как правило его возможностей недостаточно для того, чтобы оценить все эти параметры в момент приемки продукта, поэтому обычно в этом аспекте потребителю приходиться надеятся на профессионализм и совесть разработчиков.
Re[19]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 11:28
Оценка:
VGn>Заказчик подразумевает заказ.

команда взяла и разместила заказ одному из членов этой команды,
что не так?

VGn>И даже игнорируя такую странную постановку вопроса,

VGn>важны только внешние интерфейсы. Иначе гнать такого разработчика в шею.

т.е. разработчик может не выполнять принятые в команде code style?
Re[3]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 11:31
Оценка:
U>Под заказчиком понимается не только и не столько тот, кто собственно платит деньги, но и тот кто этим продуктом будет пользоваться.

обычно это разделяют на заказчика и пользователя, т.к. у них разные цели.

U> Специально упоминать в цели о сроках и окружении не нужно, т.к. это неотъемлимая часть поставленной задачи.


если специально не упоминать, то в итоге каждый будет считать по своему
Re[25]: Огни разработки
От: FR  
Дата: 13.07.09 11:35
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


Так в программировании индустриальная эра еще не наступила и эта возможность под вопросом
Re[22]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 11:44
Оценка:
U>>>Т.е. если разработка freeware, то сформулировать требования к коду нельзя? А как только разработка становится shareware сразу можно?

VGn>>Не понял.


U>Что такое заказ для freeware-программы?


Не понял к чему приплели freeware и shareware.
Начали с кодирования, переползли на требования, вынырнули в модели реализации потребителю. Что дальше? Поговорим про оборудование?

VGn>>Читаем последнее предложение. ИМХО если разработчику доверия нет, то это значит, что работу фактически придётся делать дважды.


U>Т.е. интересоваться как решает задачу другой разработчик нельзя? Можно только уволить другого разработчика после того как его решение приведет к проблемам?


Это называется делегирование ответственности. Ты никогда не сможешь постичь водиночку все детали в крупном корпоративном продукте. Важен только контракт на разработку. Реализация контракта — область ответственности исполнителя.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[4]: Огни разработки
От: Undying Россия  
Дата: 13.07.09 11:48
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


DG>обычно это разделяют на заказчика и пользователя, т.к. у них разные цели.


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

U>> Специально упоминать в цели о сроках и окружении не нужно, т.к. это неотъемлимая часть поставленной задачи.


DG>если специально не упоминать, то в итоге каждый будет считать по своему


В качестве подпунктов разжевывающих цель упоминание о сроках и окружении будет полезно, но саму цель загромождать столь очевидными вещами не стоит.
Re[20]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 11:53
Оценка:
VGn>>И даже игнорируя такую странную постановку вопроса,
VGn>>важны только внешние интерфейсы. Иначе гнать такого разработчика в шею.

DG>т.е. разработчик может не выполнять принятые в команде code style?


Если команда — заказчик, значит исполнитель — подрядчик. Если Code Style не стояло в требованиях (а подрядчик здесь отдаёт не продукт, а код), то в принципе может не выполнять Code Style, принятые в ИХ команде.
Иначе хватит называть заказчиком всех кого не попадя.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[23]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 12:09
Оценка:
VGn>Это называется делегирование ответственности. Ты никогда не сможешь постичь водиночку все детали в крупном корпоративном продукте.

да, поддерживаю
но это не отменяет того факта, что ко всему коду не возникает требований

VGn> Важен только контракт на разработку.


нет, не только, или даже совсем не только.
т.е. если в контракте не написано, что программа не должна "воровать и убивать (С)", то программа может "воровать и убивать(С)"?

VGn> Реализация контракта — область ответственности исполнителя.


да, поддерживаю.
но это также не отменяет того факта, что у заказчика и к самому выполнению есть вопросы.
Re[5]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 12:13
Оценка:
U>В идеале цель у заказчика и пользователя одна

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

цели могут быть даже строго противоположные, например, в таких ПП — как контроль действий пользователей.
Re[21]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 12:25
Оценка:
VGn>Если команда — заказчик, значит исполнитель — подрядчик. Если Code Style не стояло в требованиях (а подрядчик здесь отдаёт не продукт, а код), то в принципе может не выполнять Code Style, принятые в ИХ команде.

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

как ты относишься к следующему примеру:

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


что в этом примере надо сделать заказчику:
1. чтобы решить эту ситуацию?
2. что надо принять на будущее, чтобы такой ситуации не возникло в следующий раз?
Re[10]: Огни разработки
От: IT Россия linq2db.com
Дата: 13.07.09 13:47
Оценка:
Здравствуйте, VGn, Вы писали:

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


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


Что это? И что за комбинаторная сложность?
Если нам не помогут, то мы тоже никого не пощадим.
Re[23]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 14:17
Оценка:
IT>Вообще-то благодаря моим формулировкам ты пока думаешь в правильном направлении, только вот зацепился за количественную оценку сложности и это не даёт тебе возможность двигаться дальше.

...

IT>Эту мысль я тебе подбросил.


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

ps
про связь принципов и сложности мной было сформулировано еще пару лет назад.
Re[24]: Огни разработки
От: IT Россия linq2db.com
Дата: 13.07.09 14:29
Оценка:
Здравствуйте, DarkGray, Вы писали:


IT>>Эту мысль я тебе подбросил.


DG>а вот можно без покровительственного тона?

DG>бесит, что ты считаешь себя самым умным, и разговариваешь сверху вниз.

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

DG>ps

DG>про связь принципов и сложности мной было сформулировано еще пару лет назад.

Что же ты сразу об этом не упомянул? Видимо за пару лет забыл, бывает.
Если нам не помогут, то мы тоже никого не пощадим.
Re[25]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 14:38
Оценка:
IT> Странно наблюдать как ты обходишь неудобные для себя вопросы.

на какие свои нериторические вопросы ты не получил ответа?

IT>Что же ты сразу об этом не упомянул?


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

IT>> Странно наблюдать как ты обходишь неудобные для себя вопросы.


DG>на какие свои нериторические вопросы ты не получил ответа?


Интересно, а сколько вариантов поведения у ООП, компонентности, ФП и прочих парадигм, без знания которых некоторый код будет непосильно сложным, а со знанием предельно простым?


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

IT>>Что же ты сразу об этом не упомянул?


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


А потом счёл
Если нам не помогут, то мы тоже никого не пощадим.
Re[27]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 15:39
Оценка:
IT>

IT>Интересно, а сколько вариантов поведения у ООП, компонентности, ФП и прочих парадигм, без знания которых некоторый код будет непосильно сложным, а со знанием предельно простым?


для человека, который уже умеет "работать" с абстракциями бывает достаточно варианта 3, чтобы схватить суть абстракции.
для человека, который еще плохо "чувствует" абстракции — потребуется столько вариантов рассмотреть, сколько необходимо для показа как абстракция работает, и соответственно плюс еще в 3-10 раз больше для закрепления.

ООП — это инкапсуляция, полиморфизм и наследование

инкапсуляция — показывается где-то вариантах 6-8 (инкапсулированное/неинкапсулированное решение + клиент который использует/не использует данные, которые стоило спрятать + внесение изменения в инкасулированное/неинкапсулированное решение + изменения в клиентах)

полиморфизм и наследование, навскидку, тоже показываются приблизительно на таком же кол-ве вариантов

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


IT>А потом счёл


раз сам IT упоминает, может это действительно важно, и надо вводить сразу...
Re[29]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 16:22
Оценка:
IT>Т.е. свич на 10 кейзов сложнее инкапсуляции?

инкапсуляция при использовании — в целом, вариантов не создает (например, в отличие от полиморфизма того же)
поэтому для человека который уже "чувствует" инкапсуляцию, конечно, да
Re[30]: Огни разработки
От: IT Россия linq2db.com
Дата: 13.07.09 16:43
Оценка:
Здравствуйте, DarkGray, Вы писали:

IT>>Т.е. свич на 10 кейзов сложнее инкапсуляции?


DG>инкапсуляция при использовании — в целом, вариантов не создает (например, в отличие от полиморфизма того же)

DG>поэтому для человека который уже "чувствует" инкапсуляцию, конечно, да

Мы говорим вроде как о сложности обучения. Сложность изучения инкапсуляции ниже сложности использования 10 кейзов?
Если нам не помогут, то мы тоже никого не пощадим.
Re[31]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 17:26
Оценка:
IT>Мы говорим вроде как о сложности обучения. Сложность изучения инкапсуляции ниже сложности использования 10 кейзов?

сложность изучения инкапсуляции выше, чем сложность использования 10 кейзов — потому что сложность изучения инкапсуляции — 6-8 + 3-10*6-8 = 32-80, что явно больше, чем 10
Re[31]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 17:28
Оценка:
IT>Мы говорим вроде как о сложности обучения. Сложность изучения инкапсуляции ниже сложности использования 10 кейзов?

ты кстати перескакиваешь с обучения(изучения) на использования и обратно. это так и задуманно?
Re[33]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 17:44
Оценка:
SH>сорри... Откуда эти числа и эта формула (a + b * c)?

SH>Мне, вообще, кажется, что численные оценки тут невозможны и потому неуместны, но раз ты их даёшь -- возможно ты видишь то, чего не вижу я.


грубая оценка — шла раньше http://rsdn.ru/forum/philosophy/3466551.aspx
Автор: DarkGray
Дата: 13.07.09


...
для человека, который еще плохо "чувствует" абстракции — потребуется столько вариантов рассмотреть, сколько необходимо для показа как абстракция работает, и соответственно плюс еще в 3-10 раз больше для закрепления.

...

инкапсуляция — показывается где-то вариантах 6-8 (инкапсулированное/неинкапсулированное решение + клиент который использует/не использует данные, которые стоило спрятать + внесение изменения в инкасулированное/неинкапсулированное решение + изменения в клиентах)
...


SH>Мне, вообще, кажется, что численные оценки тут невозможны и потому неуместны


я знаю, что проблема не имеет решения, но я пытаюсь придумать как ее решать...
Re[34]: Огни разработки
От: SergH Россия  
Дата: 13.07.09 17:53
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>...


Начал было отвечать, потом понял, что Игорь тебе некорректный вопрос поставил Щас его спрошу.

SH>>Мне, вообще, кажется, что численные оценки тут невозможны и потому неуместны

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

Я не уверен, что это проблема.
Делай что должно, и будь что будет
Re[35]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 17:57
Оценка:
DG>>я знаю, что проблема не имеет решения, но я пытаюсь придумать как ее решать...

SH>Я не уверен, что это проблема.


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

IT>>Мы говорим вроде как о сложности обучения. Сложность изучения инкапсуляции ниже сложности использования 10 кейзов?


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


Конечно! Ты хочешь найти количественную меру сложности, вот и расскажи, как сравнить количество ифов, безобразное оформление и минимально необходимый порог вхождения для понимания определённого кода.
Если нам не помогут, то мы тоже никого не пощадим.
Re[33]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 18:18
Оценка:
IT>Т.е. использование switch в сотню case будет сложнее изучения ООП?

как-то ты резко сделал переход от изучения инкапсуляции к изучению ООП...
Re[34]: Огни разработки
От: IT Россия linq2db.com
Дата: 13.07.09 19:07
Оценка:
Здравствуйте, DarkGray, Вы писали:

IT>>Т.е. использование switch в сотню case будет сложнее изучения ООП?


DG>как-то ты резко сделал переход от изучения инкапсуляции к изучению ООП...


Тебе не всё равно? Ладно, если тебе так удобнее.

Т.е. использование switch в сотню case будет сложнее изучения инкапсуляции?
Если нам не помогут, то мы тоже никого не пощадим.
Re[36]: Огни разработки
От: IT Россия linq2db.com
Дата: 13.07.09 20:31
Оценка:
Здравствуйте, DarkGray, Вы писали:

IT>>Т.е. использование switch в сотню case будет сложнее изучения инкапсуляции?


DG>да, если switch с реальной рассматриваемой сложностью в сотню.


На этом предлагаю закруглиться. Я для себя выяснил всё.
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: Огни разработки
От: Undying Россия  
Дата: 14.07.09 03:24
Оценка:
Здравствуйте, DarkGray, Вы писали:

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

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

И заказчик и пользователь должны руководствоваться интересами своего Дела. Да, на практике весьма часто заказчик и исполнитель интересы своего Дела подменяет своими шкурными и/или бюрократическими интересами, но мне как разработчику на шкурные и бюрократические интересы заказчика и пользователя должно быть плевать (если я, конечно, хочу сделать полезный и качественный продукт), я должен руководствоваться только интересами Дела заказчика и пользователя.
Re[34]: Огни разработки
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 14.07.09 07:46
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


— Голубчики, — сказал Фёдор Симеонович озабоченно, разобравшись в почерках. — Это же проблема Бен Бецалеля. Калиостро же доказал, что она не имеет решения.
— Мы сами знаем, что она не имеет решения, — сказал Хунта, немедленно ощетиниваясь. — Мы хотим знать, как её решать.

Re[25]: Огни разработки
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 14.07.09 07:52
Оценка:
Здравствуйте, minorlogic, Вы писали:

L>>Ну, как то ты в крайности бросаешься, честное слово. Смысл в том, что учиться нужно не по лозунгам.

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

Т.е. я правильно понял, что лозунг нужен для обучения вида: увидел лозунг — пошёл разбираться, что на самом деле имел в виду агитпроп — обучился новой практике?
Re[24]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.07.09 10:20
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>И где гарантия что ты это получишь?

Гарантии — нет. Но я могу минимизировать риски.

DG>Он окажется таким же, тоже сроки срывает, и делает фигню

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

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

DG>твои действия?
Точно такие же. Есть такая дисциплина — risk management. В неё не входит исследование кода подрядчика, зато входят многие другие практики.
Если у меня нет лишних ресурсов, то откуда я их возьму на code style review? По-прежнему безуспешно намекаю на то, что я не хочу тратить свои ресурсы на погружение в чужую предметную область. Если мне интересно, получу ли я нужный результат, я скорее поговорю с предыдущими кастомерами, и послушаю их фидбек.

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

DG>а тут как и всегда — нужно контролировать важное, и можно не котролировать неважное

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


DG>как бы если тебе на этот вопрос отвечают — а мы себе такой задачи не ставим, то можно уже о цвете фирменных комбинезон и не спрашивать.
DG>кстати тут бывают уникумы, которые могут ответить — а у нас как-то само получается, это может быть и нормально — просто человек не умеет вербализировать свою "программу".
Вот именно. Зачем задавать вопросы, ответы на которые тебе не помогут? Ну, то есть если чуваки говорят "мы сертифицированы по ISO9001" — то оно конечно хорошо. Но опять же, заметь, вся идея этой сертификации — чтобы её проводил не я, а какие-то другие люди.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 14.07.09 10:21
Оценка:
VGn>>Это называется делегирование ответственности. Ты никогда не сможешь постичь водиночку все детали в крупном корпоративном продукте.

DG>да, поддерживаю

DG>но это не отменяет того факта, что ко всему коду не возникает требований

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

VGn>> Важен только контракт на разработку.


DG>нет, не только, или даже совсем не только.

DG>т.е. если в контракте не написано, что программа не должна "воровать и убивать (С)", то программа может "воровать и убивать(С)"?

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

VGn>> Реализация контракта — область ответственности исполнителя.


DG>да, поддерживаю.

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

Область ответственности — это значит, что в другое ты не лезешь. Если область ответственности твоего заказчика определяется не только бинарниками, но и всем кодом вплоть до последней запятой, то он сам себе злобный буратино.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[25]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.07.09 10:26
Оценка:
VGn>Ещё раз: у бизнес-заказчика не должно быть требований к коду.

почему? и зачем?
сформулировать можешь? или так было написано в "святой библии программиста" которой ты догматично предан?
Re[25]: Огни разработки
От: Undying Россия  
Дата: 14.07.09 10:27
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Если у меня нет лишних ресурсов, то откуда я их возьму на code style review? По-прежнему безуспешно намекаю на то, что я не хочу тратить свои ресурсы на погружение в чужую предметную область. Если мне интересно, получу ли я нужный результат, я скорее поговорю с предыдущими кастомерами, и послушаю их фидбек.


Т.е. покупать себе автомобиль вместе с человеком, который в автомобилях разбирается это плохой, неправильный путь?
Re[25]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 14.07.09 10:28
Оценка:
Здравствуйте, minorlogic, Вы писали:

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


Пальцем в такой лозунг можно?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.07.09 10:46
Оценка:
S>Вот именно. Зачем задавать вопросы, ответы на которые тебе не помогут? Ну, то есть если чуваки говорят "мы сертифицированы по ISO9001" — то оно конечно хорошо. Но опять же, заметь, вся идея этой сертификации — чтобы её проводил не я, а какие-то другие люди.

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

второй пункт в ряде случае можно доверить самому исполнителю, можно доверить обществу в целом:
но стоит помнить, что это будет работать лишь в каких-то ограниченных рамках
Re[26]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.07.09 11:11
Оценка:
Здравствуйте, DarkGray, Вы писали:
DG>ты понимаешь, что ты вот этим утверждениями фактически нарушаешь SRP?
Нет, не понимаю. Это ты нарушаешь SRP, предполагая, что заказчик будет формулировать требования не только в терминах "что", но и в терминах "как".
DG>т.е. ты смешиваешь две разные ответственности (функции):
DG>1. заказчику стоит контролировать подрядчика (потому что подрядчик, по умолчанию, старается достичь своих целей, а не целей заказчика)
DG>2. непрофильную стандартную деятельность стоит отдавать на сторону
Это вообще какой-то бред написан. Ты извини, но ответственность не формулируется в терминах "стоит"; и ответственности "отдавать деятельность" не может быть.
Причем две стороны одной и той же деятельности (делегация исполнения задачи и контроль её результатов) ты считаешь разными ответственностями.
Разберись с кашей в голове.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.07.09 11:28
Оценка:
S>Причем две стороны одной и той же деятельности (делегация исполнения задачи и контроль её результатов) ты считаешь разными ответственностями.

Согласен, что в идеале они должны делаться совместно, и должны являться двумя сторонами одного и того же.

но на практике они часто делаются разрознено, поэтому это разные деятельности.
Re[27]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.07.09 11:51
Оценка:
S> Ты извини, но ответственность не формулируется в терминах "стоит"; и ответственности "отдавать деятельность" не может быть.

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

хорошо, переформулирую так:
Заказчику свойственна еще роль Субьекта, и в рамках этой роли у него есть ответственность:
1. оптимизировать свою деятельность
а в рамках 1 есть ответственность
1.а. передать другим те виды деятельности, которые они сделают оптимальнее, чем сам субъект
Re[27]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.07.09 12:04
Оценка:
S>Разберись с кашей в голове.

из этого я понял, что у тебя каши в голове нет, поэтому ты прямо сейчас готов системно изложить свое видение по обсуждаемой теме?
Re[26]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 14.07.09 12:34
Оценка:
DG>почему? и зачем?
DG>сформулировать можешь? или так было написано в "святой библии программиста" которой ты догматично предан?

Несколько раз всё объяснил. Причём с разных сторон. Читай ветку.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[28]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 14.07.09 12:40
Оценка:
DG>может идти размывание роли Представитель Заказчика, но все это происходит в ранее сформулированной модели.

Далеко не всегда. И это правильно. Как уже обсуждалось, заказчики могут обладать разными степенями дотошности. И это связано с множеством факторов. В любом случае следить за разработкой в разы дороже, чем просто очень хорошо тестировать результат.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[28]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.07.09 13:35
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>а в каких терминах должна формулироваться ответственность?

В терминах "обязан".
Ты уверенно лезешь в дебри. Какая тебе разница, какие еще ответственности есть у заказчика?
В рамках взаимоотношений заказчика и подрядчика вся ответственность заказчика — принять работы, т.е. либо подтвердить соответствие результата заявленным требованиям, либо предъявить список обоснованных претензий. Ну и своевременно провести оплату работ. Ты что, договоров никогда не читал?

Всё. Никакой ответственности по делегированию чего-то кому-то у заказчика нет. Ну, если только ты не пытаешься сейчас изобрести тезисы курса "Эффективный менеджер".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Огни разработки
От: minorlogic Украина  
Дата: 14.07.09 16:21
Оценка:
Здравствуйте, lomeo, Вы писали:

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


L>>>Ну, как то ты в крайности бросаешься, честное слово. Смысл в том, что учиться нужно не по лозунгам.

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

L>Т.е. я правильно понял, что лозунг нужен для обучения вида: увидел лозунг — пошёл разбираться, что на самом деле имел в виду агитпроп — обучился новой практике?


Да, на мой взгляд именно эту функцию может выполнять краткий яркий лозунг.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[26]: Огни разработки
От: minorlogic Украина  
Дата: 14.07.09 16:21
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


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


ГВ>Пальцем в такой лозунг можно?


SRP — подходит ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[28]: Огни разработки
От: minorlogic Украина  
Дата: 14.07.09 16:29
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


Возможно я особо непонятливый и мне ориентиры помогают.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[29]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.07.09 18:59
Оценка:
S>Ты уверенно лезешь в дебри. Какая тебе разница, какие еще ответственности есть у заказчика?

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

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


ответь тогда на следующий вопросы:
1. кто отвечает за то, чтобы все заработало в целом? при условии, что ты утверждаешь, что исполнитель/разработчик отвечает только за то, что написано в договоре?
2. ты понимаешь что в договоре нельзя учесть все нюансы, иначе это фактически будет равно тот код, который должен быть сделать исполнитель/разработчик?
3. как заказчик выполняет п.1., если в договоре все нюансы прописать нельзя по определению, и Заказчик не контролирует ведение работ Исполнителем?
Re[25]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.07.09 19:03
Оценка:
VGn>Ещё раз: у бизнес-заказчика не должно быть требований к коду.

а какие требования у него могут быть?
у него может быть требование к платформе на которой это должно быть реализовано?
может ли заказчик требовать, чтобы ему для тестирования предоставили ПП как "белый ящик", а не как "черный ящик"?

VGn>Под твою фразу попадают тоько требования к коду аутсорсеров.

VGn>Требования к коду в команде требованиями называть нельзя, потому что "требования" — это бизнес-сущность.
VGn>Это можно назвать соглашениями или контрактом.

чем отличаются друг от друга:
1. соглашение
2. требование
3. контракт
?
Re[29]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.07.09 19:19
Оценка:
S>Ну да, всё правильно. И откуда в этой чудной модели возникнет заказчик, который лезет в исходники?

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

например,
1. требование, что ПП устойчиво работает при многопоточном выполнении — очень тяжело контролируется методом "черного ящика".
2. требование, что программа не имеет ошибок (или имеет кол-во ошибок меньше заданного на кол-во функциональный точек) — тоже методом "черного ящика" контролируется достаточно трудоемко.
3. сроки и бюджет частично можно контролировать через черный ящик, но затруднительно — спиральная модель помогает, но не спасает от наблюдения, что первые 80% делаются за 80% бюджета, а оставшиеся 20% за другие 80% бюджета.
4. контроль по черному ящику не помогает от "посадки на иглу", когда после внедрения первой версии начинает искусственно вздуваться стоимость последующих работ.
Re[28]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 14.07.09 20:25
Оценка:
ГВ>На самом деле, такие плакаты всегда дополняют "прокачивание" мозгов

каким образом должно происходить, по твоему, "прокачивание" мозгов разработчиков?

ты, вроде, периодически упоминал что это должен делать институт, но, имхо, это тупиковый путь — потому что рабочий стаж как минимум 25 лет, а институт в лучшем случае может дать "прокачку" на пару лет вперед, в худшем (как например сейчас) — лет на двадцать назад.
Re[26]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 15.07.09 07:24
Оценка:
VGn>>Ещё раз: у бизнес-заказчика не должно быть требований к коду.

DG>а какие требования у него могут быть?

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

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

VGn>>Под твою фразу попадают тоько требования к коду аутсорсеров.

VGn>>Требования к коду в команде требованиями называть нельзя, потому что "требования" — это бизнес-сущность.
VGn>>Это можно назвать соглашениями или контрактом.

DG>чем отличаются друг от друга:

DG>1. соглашение
DG>2. требование
DG>3. контракт
DG>?

1. Соглашение — взаимное правило. Формализация не обязательна. Работает на уровне исполнителя.
2. Требование — бизнес-сущность. Формальный контракт. Работает на уровне заказчик-исполнитель.
3. Контракт — общая совокупность ограничений, накладываемых на результат работы. Область действия зависит от контекста.
?. Регламенты, стандарты и т.д.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[30]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 15.07.09 07:27
Оценка:
DG>2. ты понимаешь что в договоре нельзя учесть все нюансы, иначе это фактически будет равно тот код, который должен быть сделать исполнитель/разработчик?

Ты не видел ТЗ на военную технику
За что получают деньги те толпы людей вокруг разработчиков?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[30]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.07.09 07:27
Оценка:
Здравствуйте, DarkGray, Вы писали:

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

DG>и заказчик уйдет к нему.
DG>разве нет?
В данном контексте это совершенно неважно. Ты действительно хочешь озаглавить список огней "как сделать так, чтобы заказчик не ушёл к другому"?
Это совершенно отдельный вид деятельности. Ей занимаются sales managers, и делают они это совершенно не так, как ты тут себе фантазируешь.

DG>ответь тогда на следующий вопросы:

DG>1. кто отвечает за то, чтобы все заработало в целом? при условии, что ты утверждаешь, что исполнитель/разработчик отвечает только за то, что написано в договоре?
Что такое "всё" и что такое "в целом"?
DG>2. ты понимаешь что в договоре нельзя учесть все нюансы, иначе это фактически будет равно тот код, который должен быть сделать исполнитель/разработчик?
Понимаю. А какое отношение это имеет к обсуждаемой теме? Мы же говорим об ответственностях "по понятиям", а не "по документам". Заказчик обязан как можно лучше объяснить задачу, и обязан проверить, соответствует ли результат его задаче. Исполнитель обязан как можно лучше понять задачу, и решить именно её.
В этом уравнении нигде не фигурируют исходники — за исключением уже упомянутого вырожденного случая аутсорсинга, где покупается не решение, а инструмент.

DG>3. как заказчик выполняет п.1., если в договоре все нюансы прописать нельзя по определению, и Заказчик не контролирует ведение работ Исполнителем?

Контролирует, но не ведение, а результат.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[32]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 15.07.09 07:35
Оценка:
DG>>в российской информатике(как учебного предмета) нет никакой системы.

ГВ>Значит, это плохая программа. Неполноценная.


Null оценивать не корректно
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[31]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 10:16
Оценка:
S>Это всё необоснованные углубления в дебри. На всякий случай напомню, что контролировать нужно не всё, а выполнение того, что оговорено в контракте. Есть требования — есть их проверка. Дальнейшее, вообще говоря, излишество.

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

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

поэтому я не понимаю утверждение: в договоре будет что-то написано — и это есть правильно, и то что мы хотели.

DG>>1. требование, что ПП устойчиво работает при многопоточном выполнении — очень тяжело контролируется методом "черного ящика".

S>Ок. Каким образом проверка этого требования методом "белого ящика" упрётся в те "огни", которые ты там выше приводил?

как минимум в п.8 и п. 10

8. Атомарность
а) Tell, don't ask
10. Программа всегда(даже после ошибки) должна стремиться находиться в корректном состоянии
a) транзакционность (изменение состояния делается только в самом конце)
b) безопасность исключений


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

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

S>Ок. Каким образом проверка этого требования методом "белого ящика" упрётся в те "огни", которые ты там выше приводил?

все огни направлены на уменьшение кода и соответственно на уменьшение кол-ва ошибок
как пример

25. a) должно быть как можно меньше side-effect-ов

выполнения этого правила уменьшает кол-во ошибок в коде, который эту функцию использует.
Re[29]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 10:33
Оценка:
S>Всё остальное, что ты тут фантазируешь, относится к области менеджмента, и вообще говоря никак к программированию не относится.

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

я утверждаю, что такое жесткое разделение на менеджмент и программирование выплескивает с водой ребенка, и если интересно могу показать это на многих примерах
Re[27]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 10:36
Оценка:
VGn>1. Соглашение — взаимное правило. Формализация не обязательна. Работает на уровне исполнителя.
VGn>2. Требование — бизнес-сущность. Формальный контракт. Работает на уровне заказчик-исполнитель.
VGn>3. Контракт — общая совокупность ограничений, накладываемых на результат работы. Область действия зависит от контекста.

общий термин для обозначения этих 3 сущностей есть?
Re[3]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.07.09 10:49
Оценка:
Здравствуйте, Voblin, Вы писали:

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


D>>Отсюда можно чего нибудь полезного выудить.

D>>http://commons.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know

V>97... Да, мощно. Как бы не стать той сороконожкой, которая задумалась о порядке перестановки ножек.


А что, нормальная подборка , можно читать на ночь.
Re[32]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.07.09 10:53
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>сложность изучения инкапсуляции выше, чем сложность использования 10 кейзов — потому что сложность изучения инкапсуляции — 6-8 + 3-10*6-8 = 32-80, что явно больше, чем 10


Откуда это взялось ? Почему не (int)((6-8 + 3-10*6-8 + 3 — 8 )/2*0.0001) == 0 ?
Re[32]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.07.09 11:04
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>все огни направлены на уменьшение кода и соответственно на уменьшение кол-ва ошибок

DG>как пример
DG>

DG>25. a) должно быть как можно меньше side-effect-ов

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

n. должно работать хорошо
n+1. если хорошо не получается, то гарантировано лучше, чем плохо
Re[33]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 11:21
Оценка:
DG>>deadlock-и обычно упираются в правильную архитектурную декомпозицию, а под это уже больше половины огней заточено
S>Открою тайну: дедлоки обычно упираются в неверный порядок захвата ресурсов. Про это никаких огней нет; архитектурная декомпозиция к этому никакого отношения не имеет.

что делать вот с этим?
class C1
{
  public C1()
  {
    this.c2 = new C2(this);
  }
  public readonly C2 c2;

  readonly object sync = new object();

  public void F1()
  {
     lock(sync)
     {
       this.X = 5;
       this.Y = 10;
     }
  }
  public int X
  {
    get {lock(sync){return _X;}}
    set {lock(sync){_X = value;}}
  }
  int _X;

  public int Y
  {
     get {lock(sync) {return c2.Y;}}
     set {lock(sync) {c2.Y = value;}}
  }
}
class C2
{
  public C2(C1 c1) {this.C1 = c1;}
  readonly C1 c1;
  readonly object sync = new object();

  public int Y
  {
    get {lock(sync){return _Y;}}
    set {lock(sync){_Y = value;}}
  }
  int _Y;
  
  public void F2()
  {
    lock(sync)
    {
      this.Y = c1.X + 10;
    }
  }
}

deadlock будет происходить очень редко при одновременных вызовах c1.F1() и c1.с2.F2()

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

DG>>все огни направлены на уменьшение кода

S>Это не так. Перечитай еще раз огни и прикинь, какие направлены на уменьшение, какие на увеличение, а какие индифферентны к размеру кода.

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

S>Во-первых, выполнение этого правила ничего не уменьшает. Контрольный вопрос: пусть в коде, вызывающем функцию с side-effects, было 0 ошибок. Сколько ошибок станет в нём после того, как side-effects будут убраны?


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

S>Во-вторых, какое отношение это имеет к приёмке кода заказчиком? Намекну на всякий случай, что заказчика не интересует наличие либо отсутствие побочных эффектов внутри кода. Заказчика интересует наличие заказанных прямых эффектов и отсутствие незаказанных.


его интересует, когда он получит результат.
если в ПП число ошибок после внедрения от времени резко не падает, то получается, что заказчик не получает результата, соответственно заказчика начинает волновать — а почему? и что можно сделать?
а один из побочных эффектов side-эффектов что они часто провоцируют ситуацию — когда от исправления в одном месте, начинает отваливаться что-то другое уже в десяти местах
Re[33]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 11:25
Оценка:
I>Откуда это взялось ? Почему не (int)((6-8 + 3-10*6-8 + 3 — 8 )/2*0.0001) == 0 ?

на это я уже отвечал, см. выше
http://rsdn.ru/forum/philosophy/3466685.aspx
Автор: DarkGray
Дата: 13.07.09
Re[33]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 11:26
Оценка:
I>n. должно работать хорошо
I>n+1. если хорошо не получается, то гарантировано лучше, чем плохо

мысль не понял. переформулируй, пожалуйста.
Re[34]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.07.09 12:18
Оценка:
Здравствуйте, DarkGray, Вы писали:


I>>n. должно работать хорошо

I>>n+1. если хорошо не получается, то гарантировано лучше, чем плохо

DG>мысль не понял. переформулируй, пожалуйста.


Смысла примерно столько же как и в лозунге про сайд-эффект.
Re[7]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 15.07.09 12:42
Оценка:
A>Лучше всего закрепляют материал упавшие ракеты. Рецепт, проверенный поколениями. Вообще, конечно, отличный подход, если у нас есть 2, может быть 3, лишние ракеты.

Булава падает через раз. Имхо есть где развернуться
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[29]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 13:37
Оценка:
VGn>А зачем? Чтобы устроить привычный бардак? Назови, к примеру, шнягой. Потому как общее обозначение этих сущностей именно шнягой и будет.

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

по сути, бардак уже есть при введении определений, т.к. после введения тобой этим терминов возникли следующие вопросы:
1. из-за того, что в п.2 и п.3 явно не упоминается про правило, следует ли что соглашение и контракт не являются правилом?
2. из п.2 и из п.3 следует ли, что требование — тоже самое, что контракт, но формализованный и для области действия заказчик-исполнитель?
3. область действия и уровень это одно и тоже?
4. из-за того, что в п.2 и п.3 явно не упоминается про взаимность, следует ли, что они не взаимные?
Re[31]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 14:07
Оценка:
DG>>я утверждаю, что такое жесткое разделение на менеджмент и программирование выплескивает с водой ребенка, и если интересно могу показать это на многих примерах

I>Покажи.


программирование — в чистом виде — это перекладывание того, что умеет человека на формализованный язык(на язык машины)

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

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

возьму пример у липперта

...
Назначенный мне баг состоял в том, что тестеры обнаружили конкретную пару дат, которые DateDiff вычитал некорректно. Я глянул в исходный код одного из вспомогательных методов, которые DateDiff вызывает в процессе своих вычислений. Для моих свежевыпущенных из колледжа глаз, это смотрелось примерно так:

if (frob(x) > 0 && blarg(y)) return x – y;
else if (frob(x) < blarg(y) && blah_blah(x) > 0 || blah_de_blah_blah_blah(x,y)) return frob(x) – x + y + 1;
else if…

И так семь раз.

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


с точки зрения программирования решение о том, что надо добавить 8 ветку кода — является нормальным
и лишь с той точки зрения — что программировать мы хотим при ограниченных ресурсах (а именно при ограниченных ресурсах своего времени) — появляется задача переписать этот код так, чтобы эта проблема не возникла никогда (больше не потребовала наших ресурсов)
Re[33]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 14:12
Оценка:
DG>>поэтому я не понимаю утверждение: в договоре будет что-то написано — и это есть правильно, и то что мы хотели.
S>Этого утверждения никто не делал.

как тогда понимать твою фразу?

На всякий случай напомню, что контролировать нужно не всё, а выполнение того, что оговорено в контракте.

Re[29]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 14:20
Оценка:
S>По поводу программистской части работы IT высказался вполне определённо — всё сводится к борьбе со сложностью. Я с ним полностью согласен.

есть еще два направления:
1. уменьшению кол-ва потенциальных ошибок (уменьшение мест где потенциально могут быть ошибки)
2. увеличение скорости разработки

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

в том самом примере от Липперта его же именно волновало: что по текущему коду непонятно, есть ли ошибка или нет — и именно это побудило переписать код.
Re[30]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 15.07.09 14:29
Оценка:
DG>по сути, бардак уже есть при введении определений, т.к. после введения тобой этим терминов возникли следующие вопросы:
DG>1. из-за того, что в п.2 и п.3 явно не упоминается про правило, следует ли что соглашение и контракт не являются правилом?
DG>2. из п.2 и из п.3 следует ли, что требование — тоже самое, что контракт, но формализованный и для области действия заказчик-исполнитель?
DG>3. область действия и уровень это одно и тоже?
DG>4. из-за того, что в п.2 и п.3 явно не упоминается про взаимность, следует ли, что они не взаимные?

1. Соглашение может и не быть правилом. Контракт относится к результатам, правило к действиям. Зачем им пересекаться?
3. Уровень — дискретное понятие (роль). Область действия — нет. Здесь я учёл твои высказывания о взаимопроникновении областей ответственности. (предвосхищая вопрос: область действия — на что влияет сущность, область ответственности — за что отвечает и на что обращает внимание субъект. Пересечения есть и могут быть тождественными, но смысл разный.)
2. Да, с учётом 3.
4. Что значит "взаимные"? Зачем заказчику ограничения разработчика? На что их накладывать? (гусары молчать!)
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[34]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 15.07.09 14:29
Оценка:
Здравствуйте, DarkGray, Вы писали:

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

S>>Этого утверждения никто не делал.

DG>как тогда понимать твою фразу?

DG>

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


Подменю товарища
Ничто не идеально. Контракт всегда можно изменить по взаимной договорённости, но игнорировать нельзя. С любой стороны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[31]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 14:33
Оценка:
VGn>4. Что значит "взаимные"? Зачем заказчику ограничения разработчика? На что их накладывать? (гусары молчать!)

ты это меня спрашиваешь? этот термин употребил ты в п.1.

1. Соглашение — взаимное правило. Формализация не обязательна. Работает на уровне исполнителя

Re[32]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 15.07.09 14:46
Оценка:
DG>программирование — в чистом виде — это перекладывание того, что умеет человека на формализованный язык(на язык машины)

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


есть ещё аналитика
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[32]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 15.07.09 14:46
Оценка:
DG>поэтому говорить о том, что одно решение сложнее, чем другое; что решение работает быстро/медленно; что стоит экономить ресурсы — в терминах программирования не получается, т.к. там такая задача даже не ставится.

Нет. Во всех процессах приоритезацией задач занимается в том числе и разработчик. На основании чего ему это делать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[32]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 15.07.09 14:52
Оценка:
Здравствуйте, DarkGray, Вы писали:

VGn>>4. Что значит "взаимные"? Зачем заказчику ограничения разработчика? На что их накладывать? (гусары молчать!)


DG>ты это меня спрашиваешь? этот термин употребил ты в п.1.


DG>

DG>1. Соглашение — взаимное правило. Формализация не обязательна. Работает на уровне исполнителя


Правильно. Соглашение ведь не обязательно накладывается на результаты, как требования и другие контракты.
Но вообще "взаимное правило" здесь просто подразумевает договорённость практически без влияния на интересы сторон.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[33]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 15:18
Оценка:
VGn>Нет. Во всех процессах приоритезацией задач занимается в том числе и разработчик. На основании чего ему это делать?

явно, что на основание базовых знаний менеджмента (например, что важное, срочное и рисковое — должно идти в первую очередь)
программирование на этот вопрос вообще не отвечает.
Re[32]: Огни разработки
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.07.09 18:01
Оценка:
Здравствуйте, DarkGray, Вы писали:


I>>Покажи.


DG>программирование — в чистом виде — это перекладывание того, что умеет человека на формализованный язык(на язык машины)


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


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

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

DG>с точки зрения программирования решение о том, что надо добавить 8 ветку кода — является нормальным

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

Программирование оно всегда в каких то ограничениъ происходит (бюджет, сроки, качество и тд и тд) и по другому никогда не бывает.
Re[33]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 15.07.09 19:22
Оценка:
I>Программирование оно всегда в каких то ограничениъ происходит (бюджет, сроки, качество и тд и тд) и по другому никогда не бывает.

это к Sinclair-у, он утверждает что можно жить без этого.
Re[34]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 02:29
Оценка:
Здравствуйте, DarkGray, Вы писали:

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

S>>Открою тайну: дедлоки обычно упираются в неверный порядок захвата ресурсов. Про это никаких огней нет; архитектурная декомпозиция к этому никакого отношения не имеет.

DG>что делать вот с этим?

DG>deadlock будет происходить очень редко при одновременных вызовах c1.F1() и c1.с2.F2()
1. Воспроизводить deadlock.
2. Чинить.

DG>вопросы:

DG>1. как такое проконтролировать снаружи?
Ну, конкретно данный код проконтролировать тяжело.
DG>2. что именно (какое правило) в этом коде нарушено?
Сходу не скажу. Но мне вообще трудно судить о качестве бессмысленного кода.
DG> а) если ответ "дедлоки обычно упираются в неверный порядок захвата ресурсов", то вопрос все тот же самый, как ты собираешься (даже при наличии исходников) контролировать на примере данного исходника, что нет нарушений этого правила. перебором всех трасс выполнения?
Грубо говоря — да. А что, есть какая-то альтернатива? Пойми, даже если конкретно этот код нарушает какие-то из огней, то не составит проблемы написать другой код — идеально соответствующий огням — и всё еще вызывающий дедлоки

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

DG>если в ПП число ошибок после внедрения от времени резко не падает, то получается, что заказчик не получает результата, соответственно заказчика начинает волновать — а почему? и что можно сделать?
Можно, конечно, в такой ситуации ввести "прямое президентское правление", но это — уже форсмажор. Весь менеджмент рисков построен на том, чтобы такой ситуации избежать вообще — потому что нет никакой гарантии, что твой прямой микроменеджмент хоть что-то исправить. Заказчиков никогда не волнует "а почему". Заказчиков волнует "ок, дайте мне реальную дату готовности".
DG>а один из побочных эффектов side-эффектов что они часто провоцируют ситуацию — когда от исправления в одном месте, начинает отваливаться что-то другое уже в десяти местах
Ты опять смешиваешь программистскую реальность "побочные эффекты затрудняют верификацию программы" с менеджерской "сроки разработки превышены".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 02:30
Оценка:
Здравствуйте, DarkGray, Вы писали:
DG>зачем ты хочешь разделить менеджмент и программирование?
DG>получить упрощение задачи? а ты уверен, что при таком упрощении не потеряешь кучу всего важного?
Уверен. Менеджмент как дисциплина практически не зависит от области деятельности. Программирование как таковое тоже не зависит от того, каким именно способом выполняется менеджмент.
DG>я утверждаю, что такое жесткое разделение на менеджмент и программирование выплескивает с водой ребенка, и если интересно могу показать это на многих примерах
Покажи.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 02:48
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>есть еще два направления:

DG>1. уменьшению кол-ва потенциальных ошибок (уменьшение мест где потенциально могут быть ошибки)
Каждая строка кода — это место, где потенциально может быть ошибка. Каждая лишняя декларация — это место, где потенциально может быть ошибка. Все эти DRY, YAGNI, KISS — именно об этом: меньше строк — меньше мест для ошибок.
DG>2. увеличение скорости разработки
Каждая строка кода — это текст, который надо написать. Меньше строк — меньше работы.
Менеджмент контактирует с программированием исключительно по этим двум направлениям.
DG>и уменьшение сложности часто идет рука об руку с этим направлениями, т.к. уменьшение сложности часто уменьшает кол-во потенциальных ошибок, и увеличивает скорость разработки.
Правильно. В итоге выясняется, что всё, что есть в программировании от менеджмента — это уменьшение сложности. И другие правила второго порядка малости — типа оформления кода так, чтобы его было удобнее читать.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[34]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 16.07.09 07:12
Оценка:
DG>явно, что на основание базовых знаний менеджмента (например, что важное, срочное и рисковое — должно идти в первую очередь)
DG>программирование на этот вопрос вообще не отвечает.

Молодец какой. Сначало понамешал к программированию всяких левых активностей, а теперь наоборот сузил программирование до крайности.
Разберись уже к чему ты хочешь применять "огни" (учитывая, что это не огни менеджмента )
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[30]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 16.07.09 07:12
Оценка:
DG>зачем ты хочешь разделить менеджмент и программирование?

Есть гипотеза, что Хомо Сапиенс сожрал неандертальцев (а не наоборот) именно потому, что имел преимущество в разделении труда.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[35]: Огни разработки
От: Undying Россия  
Дата: 16.07.09 07:26
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Так и понимать. Если в контракте оговорено "поставка исходных кодов, оформленных в соответствии со стандартами качества" — тогда можно и нужно контролировать исходники.


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

ps
Сразу оговорюсь, что предлагаемый DarkGray'ем способ оценки сложности кода как числа вариантов меня не устраивает, т.к. этот способ слишком сложен и схоластичен для реального применения.
Re[35]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.07.09 09:13
Оценка:
S>Грубо говоря — да. А что, есть какая-то альтернатива?

есть, например, такой огонь: не вызывать из под lock-ов чужие методы
и совсем не вызывать из под lock-ов колбаки

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

S>Пойми, даже если конкретно этот код нарушает какие-то из огней, то не составит проблемы написать другой код — идеально соответствующий огням — и всё еще вызывающий дедлоки


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

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

соответственно, правило — не вызывать чужих методов из под локов — это такой же защитный кожух, да — это не серебрянная пуля, но оно сильно уменьшает кол-во ошибок связанных с lock-ами
Re[35]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.07.09 09:20
Оценка:
S>Так и понимать. Если в контракте оговорено "поставка исходных кодов, оформленных в соответствии со стандартами качества" — тогда можно и нужно контролировать исходники.
S>А если оговорено "поставка исполняемых файлов, инструкций и т.п. необходимых для выполнения пользовательских задач в соответствии с п.п. 2.1-2.187", то нужно контролировать выполнение пользовательских задач.

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

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

я утверждаю, что заказчик и разработчик обязаны был думати именно о тех вещах, которые были зафиксированы в модели

ответственность Заказчика:
1. выбрать Разработчика
2. поставить задачу
3. оплатить работу
4. проконтролировать выполнение
5. воспользоваться результатом

ответственность Разработчика
1. разработать продукт


S> При этом совершенно неважно, насколько детально там всё оговорено в пунктах 2.1 — 2.187. Детали соответствия решения задаче можно оговаривать дополнительно и даже устно. Но задним числом начинать докапываться до вещей типа "о-о, мы думали вы сделаете это на ведге, а вы сделали на ASP.NET", или "В этой задаче можно было применить MVC фреймворк, а вы не применили" — нельзя. Вам было всё равно, на чём мы напишем, когда подписывали контракт? Вот и хорошо — пусть будет всё равно и дальше.


если контракт выполняется, то я с тобой согласен.
но если контракт не выполняется (опять же, например, кол-во ошибок не уменьшается) то стоит требовать подписание доп. соглашение, по которому большие возможности контроля переходят к заказчику.
Re[35]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.07.09 09:54
Оценка:
VGn>Молодец какой. Сначало понамешал к программированию всяких левых активностей, а теперь наоборот сузил программирование до крайности.
VGn>Разберись уже к чему ты хочешь применять "огни" (учитывая, что это не огни менеджмента )

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

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

или другими словами:
программирование (из первого поста) — это программирование, как деятельность программиста
программирование (из определения про перевод на язык машины) — это чистая деятельность без вкрапления других деятельностей
Re[18]: Огни разработки
От: Klapaucius  
Дата: 16.07.09 10:05
Оценка:
Здравствуйте, eao197, Вы писали:

K>>Это неверно. Современники оценивали "Выступление стрелковой роты и т.д" (так называемый "Ночной дозор") низко. Позже ее стали оценивать высоко. Теперь ее оценивают скорее низко.

E>Так ведь оценивают же. В отличие о многих современников того же Рембрандта, которые просто канули в лету.

Ну да. Вы, конечно, скипнули мое замечание про канувшего в лету Баха, которого повторно открыли специалисты через 80 лет после смерти.

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

K>>Не до сих пор, а в настоящий момент.
E>Который длится, как минимум, лет пятьдесят.

Не важно, сколько длится. Важно, что в творчестве Рембрандта Ван-Рейна нет ничего определяющего когда кто и как будет оценивать его творчество. Нет никаких гарантий, что через n лет оценка будет пересмотрена. Как она уже пересматривалась множество раз.
Произведение искусства вне контекста культуры не имеет никакой ценности и не производит никакого объективного эффекта. Эстетический эффект существует только в головах и, по большому счету, каждой конкретной головой и определяется. Ценность искусства исключительно субъективна. Программное обеспечение же может производить объективный, наблюдаемый эффект и по этой причине может обладать объективной ценностью.

E>>>Будет ли тоже самое происходить с "дерьмом художника" через 450-500 лет? Если да, значит вы правы. Если нет, значит неправильные направления в искусстве все же есть.

K>>Почему вас так волнует дерьмо художника?
E>Потому что это, на мой взгляд, опровержение вашего тезиса о том, что в искусстве нет неправильных путей.

Можете вы объяснить почему это именно так?

K>>И откуда взялись числа 450-500?

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

Я не спрашивал что это. Я спрашивал откуда взялись эти числа.

K>>Я указываю на принципиальную разницу — суд времени над этим "произведением искусства" свершился в момент аварийного подрыва ракеты. Откладывать его на +бесконечность не пришлось. Пересмотр оценки не предвидится.

E>Здесь нет принципиальной разницы. Различие только во временных масштабах.

Различие между детерминированным свойствами объекта интервалом и интервалом случайным и свойствами объекта не определяющимся принципиальны.
Суда времени для произведения искусства не существует. Есть только перекладывание ответсвенности за ответ на вопрос. Когда кто-то говорит, что время покажет в данном случае, он говорит фактически только то, что сам он оценивать не будет, а оценит какой-то еще не родившийся Вася. Вася, однако, не будь дураком, перекинет отвественность на еще не родившегося Петю.
Описание другого принципиального различия заключающегося в том, что переоценка картины возможна, а переоценка успешности запуска ракеты — нет, вы, естественно, также скипнули.

E>Когда выполнялась приемка ПО Ариан, это ПО объективно доказывало свою состоятельность на имеющихся приемных испытаниях. Прошло какое-то время и бах! Не прокатило.


Это не верно. Это ПО не создается для того, чтобы проходить тесты. Оно создается для запуска ракет. И объективно доказать свою способность управлять ракетой оно может только управляя ракетой.

E>С ошибкой 2000-го года похожая история, только время между приемкой и бабахом чуть побольше было.


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

E>В живописи временные отрезки еще больше. Но сама выбраковка, тем не менее, существует.


Почему больше? И что представляет из себя выбраковка в случае с живописью?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[16]: Огни разработки
От: Klapaucius  
Дата: 16.07.09 10:18
Оценка:
Здравствуйте, eao197, Вы писали:

K>>1) Техники передачи эмоций — это знание того, что человек определенным образом интерпретирует линии определенной кривизны — и такому можно каждого научить, даже аутиста, который интуитивно эмоции не воспринимает.

E>Интересно. Как можно передать эмоцию, которую не воспринимаешь?

Я написал "интуитивно не воспринимает", а не "не воспринимает". Очевидно, что воспринимать можно не интуитивно.

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

E>В том-то и дело. Что выполнив одну и ту же композицию (нарисовав один и тот же портрет с одной и той же точки) два разных художника используют разные техники рисунка (или разные их сочетания). И получат два разных изображения с разным ритмом и настроением. Почему они поступили так, как поступили?

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

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


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

E>На мой взгляд, дело здесь именно в умении, т.е. сочетании опыта, вкуса, знаний и каких-то других факторов (в том чисте и иррациональных).


Ну а какое отношение умение имеет к творчеству?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[31]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.07.09 10:19
Оценка:
S>Покажи.

во-первых, я забыл еще третью важную вещь — это маркетинг

программирование — в чистом виде — это перекладывание того, что умеет человека на формализованный язык(на язык машины)

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

маркетинг — в чистом виде — выяснение того что действительно хочет заказчик(потенциальный заказчик) и за что он хочет заплатить деньги


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

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

to Sinclair: ты согласен с тем, что вот так оно все и происходит, если программист и слышат не хочет о менеджменте и маркетинге?
или будет как-то по другому? если по другому, то как?
Re[19]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 10:27
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Не важно, сколько длится. Важно, что в творчестве Рембрандта Ван-Рейна нет ничего определяющего когда кто и как будет оценивать его творчество. Нет никаких гарантий, что через n лет оценка будет пересмотрена. Как она уже пересматривалась множество раз.


С долгоживущими программами происходит тоже самое. Поэтому я и упоминаю проблему 2000-го года в данном контексте.

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


K>Можете вы объяснить почему это именно так?


Потому что, на мой взгляд, в произведении искусства должны сочетаться как выдающаяся идея, так и исполнительское мастерство автора. В данном случае присутствует только идея, актуальная только на текущем временном этапе. Поэтому данное произведение, опять же по-моему, не должно считаться произведением искусства. А то, что сейчас оно таковым считаеться -- это неправильно.

K>>>И откуда взялись числа 450-500?

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

K>Я не спрашивал что это. Я спрашивал откуда взялись эти числа.


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

K>Суда времени для произведения искусства не существует.


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

E>>В живописи временные отрезки еще больше. Но сама выбраковка, тем не менее, существует.


K>Почему больше? И что представляет из себя выбраковка в случае с живописью?


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 10:47
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>>>1) Техники передачи эмоций — это знание того, что человек определенным образом интерпретирует линии определенной кривизны — и такому можно каждого научить, даже аутиста, который интуитивно эмоции не воспринимает.

E>>Интересно. Как можно передать эмоцию, которую не воспринимаешь?

K>Я написал "интуитивно не воспринимает", а не "не воспринимает". Очевидно, что воспринимать можно не интуитивно.


А это как? Сидит аутист перед натурщиком, а преподаватель ему объясняет -- вот это на самом деле у человека не оскал, а улыбка?

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


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


Искусство, которое включает в себя программирование, -- это за гранью моего понимания. Простите.
"Искусство программирования" в ряду с такими понятиями, как "Военное искусство", "Искусство управления", "Кузнечное искусство", "Искусство штыкового боя" -- это я еще могу себе представить.

E>>На мой взгляд, дело здесь именно в умении, т.е. сочетании опыта, вкуса, знаний и каких-то других факторов (в том чисте и иррациональных).


K>Ну а какое отношение умение имеет к творчеству?


За этим вот сюда: http://www.rsdn.ru/forum/philosophy/3461681.1.aspx
Автор: eao197
Дата: 09.07.09


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[20]: Огни разработки
От: Klapaucius  
Дата: 16.07.09 10:49
Оценка:
Здравствуйте, eao197, Вы писали:

E>С долгоживущими программами происходит тоже самое. Поэтому я и упоминаю проблему 2000-го года в данном контексте.


Ну вот, теперь первый ответ на это возражение уже двумя моими постами выше.

E>Потому что, на мой взгляд, в произведении искусства должны сочетаться как выдающаяся идея,


Согласен. Но оценка идеи зависит от конкретного человека больше, чем от самой идеи.

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


Время съест это мастерство. Многие произведения искусства с нынешней точки зрения мастерством не отличаются.

E>В данном случае присутствует только идея, актуальная только на текущем временном этапе.


О. В какое время эта идея не была актуальна? Проблема этой идеи как раз в том, что она слишком уж актуальна и чертовски стара. Никакого свежего взгляда на мир в ней нет.

E>Поэтому данное произведение, опять же по-моему, не должно считаться произведением искусства. А то, что сейчас оно таковым считаеться -- это неправильно.


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

K>>Я не спрашивал что это. Я спрашивал откуда взялись эти числа.

E>Это я пытался на память угадать, на сколько от нас отстоит эпоха Возрождения.

Поэтому я и написал, что вы путаете суд истории с оценкой в настоящий момент. Живи вы в начале XIX века, сказали бы что нужно 250-300 лет, так?

K>>Суда времени для произведения искусства не существует.

E>У меня прямо противоположное мнение на этот счет. Поскольку есть "произведение искусства" и есть то, что на данный момент считается таковым.

Это и называется мода, которую время от искусства якобы отделяет.

E>>>В живописи временные отрезки еще больше. Но сама выбраковка, тем не менее, существует.


K>>Почему больше? И что представляет из себя выбраковка в случае с живописью?


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


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

E>ширпотреб.


И не какой это не ШИРпотреб. НЕт широкого потребления теперь. УЗпотреб в чистом виде.

E>Ни идеи, ни воплощения.


Ни то ни другое никуда не делось. Просто идея переоценена — так со всеми идеями происходит. А воплощение если было хорошим — оно им останется, пока не появятся лучшие техники воплощения. А если было плохим, то плохим и осталось.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[32]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 16.07.09 10:50
Оценка:
С чего ты взял что разделение труда — это "отдавать на сторону"?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[32]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 10:54
Оценка:
Здравствуйте, DarkGray, Вы писали:
DG>to Sinclair: ты согласен с тем, что вот так оно все и происходит, если программист и слышат не хочет о менеджменте и маркетинге?
DG>или будет как-то по другому? если по другому, то как?
Не согласен. Нет времени детально описывать, почему и как.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[32]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 16.07.09 10:57
Оценка:
DG>соответственно, например, оценка сроков, рисков, требуемых ресурсов, составление плана работ по тому модулю, который непосредственно делает программист, оптимальнее делается самим программистом (если он, конечно, программист, а не кодер).
DG>т.к. задача отчасти профильная (программисту платят именно за то, чтобы он разработал код при заданных ограничениях), нестандартная (код очень разный от задачи к задаче — если это именно программист), требует большого передачи информации (программист должен полностью рассказать, что и как он собирается делать, все подводные камни которые он видит и т.д.)

Так значит всё-таки профильная задача программиста, а не менеджмент?
Или программирование — это не профиль деятельности программиста?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[32]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 16.07.09 10:57
Оценка:
DG>во-первых, я забыл еще третью важную вещь — это маркетинг
DG>

DG>программирование — в чистом виде — это перекладывание того, что умеет человека на формализованный язык(на язык машины)

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

DG>маркетинг — в чистом виде — выяснение того что действительно хочет заказчик(потенциальный заказчик) и за что он хочет заплатить деньги


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


А ещё есть тестер, внедренец, снабженец, бухгалтер, завхоз, отдел кадров, директор и инвестор
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[36]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 16.07.09 10:57
Оценка:
Вот что бывает, если сваливать термины в кучу
Назови эти разные программирования разными словами и не парь уже мозги.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[33]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 16.07.09 11:02
Оценка:
VGn>А ещё есть тестер, внедренец, снабженец, бухгалтер, завхоз, отдел кадров, директор и инвестор

А если вдруг вспомнить что требования надо согласовывать, фиксировать и отслеживать с учётом рисков; вести контроль версий и конфигураций, то аналитик всё-таки тоже был бы не лишним
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[18]: Огни разработки
От: Klapaucius  
Дата: 16.07.09 11:02
Оценка:
Здравствуйте, eao197, Вы писали:

E>А это как? Сидит аутист перед натурщиком, а преподаватель ему объясняет -- вот это на самом деле у человека не оскал, а улыбка?


Я сейчас не вспомню ссылку на литературу. В принципе, при высокофункциональном аутизме аутист может сам разгадывать знаковую систему человеческих эмоций как любую систему кодов. Наблюдая за "диалогами" других или сам в них участвуя. Методом проб и ошибок. Никак не пойму, что вы в этом необычного находите. Никто, например, не понимает азбуку Морзе интуитивно. Но можно выучить и понимать. Преподаватель говорит что ... — это S — чудеса просто!

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

K>>Можно даже допустить, что программирование может включать в себя искусство, но искусство программирование включать не может — поэтому заявления о том, что программирование — это искусство я считаю неверными и даже вредными с практической точки зрения.
E>Искусство, которое включает в себя программирование, -- это за гранью моего понимания. Простите.

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

K>>Ну а какое отношение умение имеет к творчеству?

E>За этим вот сюда: http://www.rsdn.ru/forum/philosophy/3461681.1.aspx
Автор: eao197
Дата: 09.07.09


Я довольно давно обратил ваше внимание на то, что я говорю именно про творчество, а не про умение.
Вот в этом моем сообщении к вам, например.
Автор: Klapaucius
Дата: 10.07.09
Но это ж мои сообщения. Кто их читает?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[37]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.07.09 11:07
Оценка:
S>то программистские мантры ничему не помогут. Есть отдельная наука про выполнение контрактов и контроль выполнения контрактов. Её постулаты никак не зависят от того, что это за контракт — на поставку окорочков или на разработку веб-поисковика.

кстати, вот ты постоянно говоришь, что у менеджера и программиста мантры и огни разные...
ты это утверждаешь, уже "вкусив устриц" (изучив огни менеджмента), или ты это утверждаешь со стороны — ни разу на эти огни менеджмента не смотрев?
Re[21]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 11:07
Оценка:
Здравствуйте, Klapaucius, Вы писали:

E>>В данном случае присутствует только идея, актуальная только на текущем временном этапе.


K>О. В какое время эта идея не была актуальна? Проблема этой идеи как раз в том, что она слишком уж актуальна и чертовски стара. Никакого свежего взгляда на мир в ней нет.


Сильно сомневаюсь, что идея о выдачи дерьма за произведение искусства нашла бы продолжение, скажем, в начале XIX века.

K>Я понял, что это ваше мнение. Но мнение это одно, а способ выбраковки — другое. Вы же понимаете, что использовать вас как эталон при выбраковке произведений искусства не очень хорошая идея?


Я понимаю. Но если мы изначально идем от наличия/отсуствия иррациональности в программировании, то без субъективных оценом все равно не обойтись.

K>Поэтому я и написал, что вы путаете суд истории с оценкой в настоящий момент. Живи вы в начале XIX века, сказали бы что нужно 250-300 лет, так?


Типа того.

K>Вне нашего культурного контекста картины Рембрандта — это слои масляной краски и только.


Позволю себе несогласиться. Мало кому удасться наложить слои масляной краски так искуссно.

E>>ширпотреб.


K>И не какой это не ШИРпотреб. НЕт широкого потребления теперь. УЗпотреб в чистом виде.


В то время производство таких произведений было поставлено на поток. Так что ШИР был.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 16.07.09 11:19
Оценка:
E>Искусство, которое включает в себя программирование, -- это за гранью моего понимания. Простите.
E>"Искусство программирования" в ряду с такими понятиями, как "Военное искусство", "Искусство управления", "Кузнечное искусство", "Искусство штыкового боя" -- это я еще могу себе представить.

Гжель это искусство или индустрия производства посуды?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[19]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 11:19
Оценка:
Здравствуйте, Klapaucius, Вы писали:

E>>А это как? Сидит аутист перед натурщиком, а преподаватель ему объясняет -- вот это на самом деле у человека не оскал, а улыбка?


K>Я сейчас не вспомню ссылку на литературу. В принципе, при высокофункциональном аутизме аутист может сам разгадывать знаковую систему человеческих эмоций как любую систему кодов. Наблюдая за "диалогами" других или сам в них участвуя. Методом проб и ошибок. Никак не пойму, что вы в этом необычного находите. Никто, например, не понимает азбуку Морзе интуитивно. Но можно выучить и понимать. Преподаватель говорит что ... — это S — чудеса просто!


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

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


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


Соревнования демок. Имеют место быть.

K>>>Ну а какое отношение умение имеет к творчеству?

E>>За этим вот сюда: http://www.rsdn.ru/forum/philosophy/3461681.1.aspx
Автор: eao197
Дата: 09.07.09


K>Я довольно давно обратил ваше внимание на то, что я говорю именно про творчество, а не про умение.

K>Вот в этом моем сообщении к вам, например.
Автор: Klapaucius
Дата: 10.07.09
Но это ж мои сообщения. Кто их читает?


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 11:34
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>Гжель это искусство или индустрия производства посуды?


Это село

А вообще, там имеет место и то, и другое.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[38]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 11:35
Оценка:
Здравствуйте, DarkGray, Вы писали:
DG>кстати, вот ты постоянно говоришь, что у менеджера и программиста мантры и огни разные...
DG>ты это утверждаешь, уже "вкусив устриц" (изучив огни менеджмента), или ты это утверждаешь со стороны — ни разу на эти огни менеджмента не смотрев?
Увы — вкусив. И на практике, и в теории.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.07.09 11:40
Оценка:
to Klapaucius и eao197 предлагаю проголосовать за отделение ветки про искусство программирования
вот на этом сообщении:
http://rsdn.ru/forum/philosophy/3458820.aspx
Автор: Klapaucius
Дата: 07.07.09

...
Ага. И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ра
...

Re[39]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.07.09 11:40
Оценка:
S>Увы — вкусив. И на практике, и в теории.

т.е. ты сейчас можешь легко накидать 5-ок различий?
Re[21]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.07.09 11:46
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>to Klapaucius и eao197 предлагаю проголосовать за отделение ветки про искусство программирования

DG>вот на этом сообщении:
DG>http://rsdn.ru/forum/philosophy/3458820.aspx
Автор: Klapaucius
Дата: 07.07.09

DG>

DG>...
DG>Ага. И вершина программирования как искусства — динамическая композиция "Ariane 5 Flight 501" Ра
DG>...


Я за. И выбросить ее в мусор сразу. Чтобы от работы не отвлекала.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.07.09 11:48
Оценка:
E>Я за.

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

ps
остальные кстати могут сделать тоже самое если согласны
Re[40]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 12:12
Оценка:
Здравствуйте, DarkGray, Вы писали:
DG>т.е. ты сейчас можешь легко накидать 5-ок различий?
Между чем и чем?
Ты пойми, что различие ровно одно.
Для программиста главное — борьба со сложностью.
А для менеджера — борьба с непредсказуемостью.

Вот и всё. Все мантры программистов — про первое. Все мантры менеджеров — про второе.
Некоторые иногда пересекаются по форме, оставаясь разными по содержанию. Типа "разделяй и властвуй".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[34]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 16.07.09 14:41
Оценка:
Слон состоит из хобота ушей и бегемота (с)
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[35]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 16.07.09 14:56
Оценка:
VGn>Слон состоит из хобота ушей и бегемота (с)

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

т.е. наивная формулировка лучше, чем отсутствие формулировки вообще, наивная аналогия — лучше чем отсутствие аналогии вообще
Re[42]: Огни разработки
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.07.09 03:26
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>можно какие-нибудь примеры, которые показывают — что в похожих ситуациях программист выберет простоту, а менеджер — предсказуемость

У программиста и менеджера редко бывают похожие ситуации, потому что у них разная работа.
Но, к примеру, если есть допустим некая техническая задача. И есть, допустим, сложный способ, которым её уже решали, и он стоит 200 часов.
И есть простой способ, который должен сэкономить половину, но его еще ни разу не применяли, поэтому хрен знает, сработает он вообще или нет.
Программист будет стараться выбрать способ 2, потому что он ведёт к упрощению. Менеджер будет склоняться к способу 1, потому что для него погрешность оценки ниже.
Максимум, на что он согласится — выделить ограниченный бюджет на прототипирование способа 2, и только после этого одобрит его применение (либо откат к способу 1).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[36]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 17.07.09 07:33
Оценка:
Здравствуйте, DarkGray, Вы писали:

VGn>>Слон состоит из хобота ушей и бегемота (с)


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


DG>т.е. наивная формулировка лучше, чем отсутствие формулировки вообще, наивная аналогия — лучше чем отсутствие аналогии вообще


Сформулирую доступнее:
что делает из тестера программиста, кроме того, что он тоже сидит жопой на стуле, уставившись в монитор?
Каким аспектом отдел кадров относится к маркетингу? (вроде ещё не дошли до работорговли)
и т.д.
Создаётся впечатление что предыдущий твой пост написан в полном соответствии с шаблоном Golden Hammer.
Или просто изо всех сил хочется сопротивляться, вместо того чтобы признать ошибку.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[43]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.07.09 08:15
Оценка:
DG>>можно какие-нибудь примеры, которые показывают — что в похожих ситуациях программист выберет простоту, а менеджер — предсказуемость
S>У программиста и менеджера редко бывают похожие ситуации, потому что у них разная работа.
S>Но, к примеру, если есть допустим некая техническая задача. И есть, допустим, сложный способ, которым её уже решали, и он стоит 200 часов.
S>И есть простой способ, который должен сэкономить половину, но его еще ни разу не применяли, поэтому хрен знает, сработает он вообще или нет.
S>Программист будет стараться выбрать способ 2, потому что он ведёт к упрощению. Менеджер будет склоняться к способу 1, потому что для него погрешность оценки ниже.
S>Максимум, на что он согласится — выделить ограниченный бюджет на прототипирование способа 2, и только после этого одобрит его применение (либо откат к способу 1).

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

то менеджер будет, в массе своей, выбирать первый способ?

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

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

если делать самому — то вся эта некомфортность, неинтересность имеет высокое значение, а если для этого привлекать другого — то то, что другому некомфортно — никого не интересует, а важен лишь результат.
Re[37]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.07.09 08:55
Оценка:
VGn>Каким аспектом отдел кадров относится к маркетингу? (вроде ещё не дошли до работорговли)

мне кажется ты путаешь маркетинг с продажами.

маркетинг — это не продажи.

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

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

HR (или продвинутый отдел кадров) — делает тоже самое, что и маркетинг + менеджмент.
изучает "заказчика"(свою компанию) и переформулирует это в термины вакансии, дальше ищет людей — пытается понять кто они такие и почему они подойдут компании.
Re[38]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 17.07.09 10:45
Оценка:
VGn>>что делает из тестера программиста, кроме того, что он тоже сидит жопой на стуле, уставившись в монитор?

DG>во-первых, я это не говорил.

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

VGn>> что делает из тестера программиста


DG>и еще раз повторю, что не тестер является программистом

DG>а программист является тестировщиком(диагностом)

Это означает, что тестирование это не профессия и давайте на должности тестеров нанимать программистов?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[38]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 17.07.09 10:45
Оценка:
DG>маркетинг — это "перевод" с языка покупателей на язык разработчиков + обратный "перевод" с языка разработчиков на язык покупателей.

Это ты путаешь:
то, что ты описал — это аналитика. Маркетинг с процессом разработки напрямую не связан.
Кстати HR и аналитика — тоже довольно странная смесь.

* «Маркетинг — это вид человеческой деятельности, направленный на удовлетворение нужд и потребностей посредством обмена.» (основатель теории маркетинга Филипп Котлер)[2]

* «Маркетинг — это искусство и наука правильно выбирать целевой рынок, привлекать, сохранять и наращивать количество потребителей посредством создания у покупателя уверенности, что он представляет собой наивысшую ценность для компании», а также «упорядоченный и целенаправленный процесс осознания проблем потребителей и регулирования рыночной деятельности» (Филипп Котлер)[3].

* «Маркетинг — это осуществление бизнес-процессов по направлению потока товаров и услуг от производителя к потребителю.» (Американская ассоциация маркетинга (AMA))[4]

* «Маркетинг — система планирования, ценообразования, продвижения и распространения идей, товаров и услуг для удовлетворения нужд, потребностей и желаний отдельных лиц и организаций; реклама является лишь одним из факторов процесса маркетинга.»[5]

... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[39]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.07.09 10:57
Оценка:
найди десять отличий между

VGn>

VGn> * «Маркетинг — это ... также «упорядоченный и целенаправленный процесс осознания проблем потребителей и регулирования рыночной деятельности» (Филипп Котлер)[3].

и фразой

это "перевод" с языка покупателей на язык разработчиков


и между

VGn> * «Маркетинг — система планирования, ценообразования, продвижения и распространения идей, товаров и услуг для удовлетворения нужд, потребностей и желаний отдельных лиц и организаций; реклама является лишь одним из факторов процесса маркетинга.»[5]

и

обратный "перевод" с языка разработчиков на язык покупателей.

Re[39]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.07.09 11:03
Оценка:
Кстати ты понимаешь что такое "сущность"?

а также что такое:
сущность программирования?
сущность маркетинга?
сущность аналитики?
Re[40]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 17.07.09 12:00
Оценка:
DG>найди десять отличий между

VGn>>

VGn>> * «Маркетинг — это ... также «упорядоченный и целенаправленный процесс осознания проблем потребителей и регулирования рыночной деятельности» (Филипп Котлер)[3].

DG>и фразой
DG>

DG>это "перевод" с языка покупателей на язык разработчиков


DG>и между

DG>

VGn>> * «Маркетинг — система планирования, ценообразования, продвижения и распространения идей, товаров и услуг для удовлетворения нужд, потребностей и желаний отдельных лиц и организаций; реклама является лишь одним из факторов процесса маркетинга.»[5]

DG>и
DG>

DG>обратный "перевод" с языка разработчиков на язык покупателей.


Не вижу ничего общего
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[40]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 17.07.09 12:00
Оценка:
DG>Кстати ты понимаешь что такое "сущность"?

DG>а также что такое:

DG>сущность программирования?
DG>сущность маркетинга?
DG>сущность аналитики?

В данном контексте "естество", ряд основополагающих признаков. А не бегемот
Кстати к чему это?
Не заметил в предыдущих постах слова "сущность".
Уходим от темы?
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[41]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.07.09 12:24
Оценка:
VGn>В данном контексте "естество", ряд основополагающих признаков. А не бегемот

Сущность — то постоянное, что сохраняется в явлении при различных его вариациях, в том числе и временных.


VGn>Кстати к чему это?

VGn>Не заметил в предыдущих постах слова "сущность".

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

а о чем в этом треде пытаешься поговорить ты?
Re[42]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 17.07.09 13:31
Оценка:
VGn>>В данном контексте "естество", ряд основополагающих признаков. А не бегемот

DG>

DG>Сущность — то постоянное, что сохраняется в явлении при различных его вариациях, в том числе и временных.


Ни разу не сталкивался с тем, чтобы программирование называли явлением

DG>а о чем в этом треде пытаешься поговорить ты?


Как и другие твои оппоненты о разделении понятий. А ты петляешь словно заяц, то делая гипер-обобщения, то гипер-детализацию.
Все твои разглагольствования не отменяют наличия в процессах перечисленных мной ролей и связанных с ними активностей, зон ответственности и области действий. Наличие в индустрии соответствующих должностей только подтверждает мои тезисы.
Так что споришь ты не со мной, а с исторически сложившейся объективной реальностью.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[43]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 17.07.09 13:43
Оценка:
VGn>Наличие в индустрии соответствующих должностей только подтверждает мои тезисы.

а что подтверждала еще лет 30 назад должность машинистки, или должность счетовода?
Re[44]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 17.07.09 16:05
Оценка:
VGn>>Наличие в индустрии соответствующих должностей только подтверждает мои тезисы.

DG>а что подтверждала еще лет 30 назад должность машинистки, или должность счетовода?


То, что 30 лет назад были такие роли и активности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[45]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.07.09 11:23
Оценка:
VGn>То, что 30 лет назад были такие роли и активности.

что такое "активность"? термин "деятельность" — который ранее уже звучал и активность — это одно и тоже?
Re[13]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.07.09 11:45
Оценка:
кстати

IT>...

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

вот эти две фразы противоречат друг другу.
Так мы все-таки хотим упростить понимание? или мы хотим все учесть?

При принятия решения какой вариант кода выбрать приходится сравнивать два очень разных кода: в одном применены полиморфизм, 2 стандартных паттерна и 3 if-а, а в другом 5 switch-ей, 3 for-а и 4 явных приведения.
Для того, чтобы это хоть как-то сравнить — нужна хоть какая-то количественная оценка, она не должна быть сложной — потому что все равно часто выбирают, как в том анекдоте "...выслушал всех, и выбрал с самой большой грудью".
Поэтому и предлагается простая количественная оценка сложности — кол-во вариантов которые необходимо рассмотреть.
Re[14]: Огни разработки
От: IT Россия linq2db.com
Дата: 18.07.09 16:36
Оценка:
Здравствуйте, DarkGray, Вы писали:

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

IT>>...
IT>> Это очень ограниченное определение и покрывает в какой-то степени лишь количественную и алгоритмическую сложности.

DG>вот эти две фразы противоречат друг другу.


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

DG>Так мы все-таки хотим упростить понимание? или мы хотим все учесть?


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

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


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

DG>Поэтому и предлагается простая количественная оценка сложности — кол-во вариантов которые необходимо рассмотреть.


Ты мне так и не ответил на один из вопросов — как сравнить количество ифов, безобразное оформление и минимально необходимый порог вхождения для понимания определённого кода?
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.07.09 16:43
Оценка:
IT>Моё определение просто и учитывает всё — сложность — это мера усилий, требуемых для решения поставленной задачи.

и в чем оно измеряется? во времени?
Re[15]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.07.09 16:54
Оценка:
IT>Ты мне так и не ответил на один из вопросов — как сравнить количество ифов, безобразное оформление и минимально необходимый порог вхождения для понимания определённого кода?

посчитать кол-во рассматриваемых вариантов — для первого, второго и третьего.
для иф-ов — кол-во рассматриваемых вариантов 2^n, где n — кол-во if-ов; кол-во может быть уменьшено за счет замены перемножения на сложения для тех if-ов, которые независимы друго от друга
для безобразного оформления — кол-во рассматриваемых вариантов — это сколько вариантов надо рассмотреть, чтобы понять, что оформление неправильное + сколько вариантов надо рассмотреть, чтобы привести к нормальному оформлению
для "минимально необходимый порог вхождения для понимания определённого кода" — кол-во рассматриваемых вариантов необходимых для обучения
Re[15]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.07.09 17:08
Оценка:
IT> ... безобразное оформление ...

кстати как ты определяешь "безобразное оформление"?

ps
в моей концепции это получается просто:
безобразное оформление — это такое оформление, когда есть более лучшее оформление для такого же кода, которое требует рассматривания меньшего кол-ва вариантов

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

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


DG>и в чем оно измеряется? во времени?


В много, мало, больше, меньше.
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Огни разработки
От: IT Россия linq2db.com
Дата: 18.07.09 18:45
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


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


Мда, зря я это начал, вроде бы же уже и так с тобой всё ясно.

DG>для иф-ов — кол-во рассматриваемых вариантов 2^n, где n — кол-во if-ов; кол-во может быть уменьшено за счет замены перемножения на сложения для тех if-ов, которые независимы друго от друга


Получили количество тёплого.

DG>для безобразного оформления — кол-во рассматриваемых вариантов — это сколько вариантов надо рассмотреть, чтобы понять, что оформление неправильное + сколько вариантов надо рассмотреть, чтобы привести к нормальному оформлению


Количество мягкого.

DG>для "минимально необходимый порог вхождения для понимания определённого кода" — кол-во рассматриваемых вариантов необходимых для обучения


И пушистого.

И теперь сравниваем теплое с мягким и пушистым. Неужели тебе это не очевидно?
Если нам не помогут, то мы тоже никого не пощадим.
Re[16]: Огни разработки
От: IT Россия linq2db.com
Дата: 18.07.09 18:51
Оценка:
Здравствуйте, DarkGray, Вы писали:

IT>> ... безобразное оформление ...


DG>кстати как ты определяешь "безобразное оформление"?


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

DG>в моей концепции это получается просто:


Какая там ещё концепция. Это не концепция, это гипотеза, правильность которой ты всё никак не можешь доказать.

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


Количество вариантов чего?

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


И как это вытекает?

И сразу ещё один вопрос. Как ты думаешь, почему сейчас принято скобку под скобкой писать, а 15 лет назад было принято открывающую скобку писать в конце предыдущей строки?
Если нам не помогут, то мы тоже никого не пощадим.
Re[17]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.07.09 19:23
Оценка:
IT>И теперь сравниваем теплое с мягким и пушистым. Неужели тебе это не очевидно?

очевидно, но это не мешает их сравнивать.

так же как не мешает сравнивать, что лучше(ценнее) 10 рублей или 1 доллар?
или что лучше(ценнее) кг яблок или 1 штука квартир?

да, оценка будет относительной, а не абсолютной как для случая, что больше 1 доллар или 10 долларов, но она все равно будет.
Re[17]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.07.09 19:41
Оценка:
IT>Количество вариантов чего?

кол-во вариантов рассмотров.

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


IT>И как это вытекает?


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

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


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

пример старого варианта на котором плохо видно, что оформление ошибочное, и не отражает сути кода
if (bla-bla)
  if (bla-bla) {
    bla-bla
  bla-bla2
}
Re[18]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.07.09 19:56
Оценка:
кстати скобка в конце строки еще может идти с простых интерпретаторов, которые требуют чтобы открывающая скобка была в конце строки, т.к. им так проще разбирать код.
соответственно, в те далекие времена простые интерпретаторы были более распространены, чем сейчас
Re[18]: Огни разработки
От: IT Россия linq2db.com
Дата: 19.07.09 03:36
Оценка:
Здравствуйте, DarkGray, Вы писали:

IT>>И теперь сравниваем теплое с мягким и пушистым. Неужели тебе это не очевидно?


DG>очевидно, но это не мешает их сравнивать.


Пипец!

DG>так же как не мешает сравнивать, что лучше(ценнее) 10 рублей или 1 доллар?

DG>или что лучше(ценнее) кг яблок или 1 штука квартир?

Доллар имеет вполне определённый эквивалент в рублях, а ценность яблок и квартир выражается через одну меру — деньги. А вот теплое и мягкое не имеет функции конвертирования
Если нам не помогут, то мы тоже никого не пощадим.
Re[19]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 19.07.09 08:33
Оценка:
IT>Доллар имеет вполне определённый эквивалент в рублях, а ценность яблок и квартир выражается через одну меру — деньги. А вот теплое и мягкое не имеет функции конвертирования

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

IT> Пипец!


разрыв шаблона? (С)

может ты просто привык там в своей "капиталистической буржундии" сравнивать все одним спосом (с помощью денег), но не привык сравнивать код через кол-во рассмотров?
Re[19]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 19.07.09 09:18
Оценка:
IT>Теперь домашнее задание — как в твои количество просмотров включить возможности hardware и как положение скобки соотносится с количеством просмотров.

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

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

ps
кстати, получается есть еще один фактор — код стал насыщеннее, меньше строк кода стало на единицу функции,
соответственно, еще и это повлияло на уменьшение необходимости впихивать код в как можно меньшее кол-во строк.
Re[20]: Огни разработки
От: IT Россия linq2db.com
Дата: 19.07.09 23:18
Оценка:
Здравствуйте, DarkGray, Вы писали:

IT>>Доллар имеет вполне определённый эквивалент в рублях, а ценность яблок и квартир выражается через одну меру — деньги. А вот теплое и мягкое не имеет функции конвертирования


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

DG>которая кстати тоже будет сильно плавать от контекста

Понял, логика — это не самая сильная твоя сторона. Тогда давай конкретней. Для яблок и квартир есть функция, через которую их можно привести к одной величине — деньгам. А деньги уже можно легко сравнивать.

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

IT>> Пипец!


DG>разрыв шаблона? (С)


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


Я вообще не знаю, что такое количество рассмотров. Раньше у тебя было количество вариантов поведения программы. С трудом, но как-то это представить можно. Количество рассмотров, даже не представляю что это такое. Есть такая картинка из серии визуальных эффектов, одни на ней видят молодую девушку, другие старуху. Интересно сколько нужно рассмотров, чтобы увидеть девушку, а сколько, чтобы старуху?
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Огни разработки
От: IT Россия linq2db.com
Дата: 19.07.09 23:24
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>уже постов 10 говорится, что сравнивать надо рассмотры с рассмотрами.


Это ты совсем недавно придумал. Раньше было количество вариантов поведения.

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


Главное, что нужно добавить в твою формулу — элементарную логику.

DG>Т.е. все-таки скобка под скобкой удобнее.


Я когда-то утверждал обратное?

DG>а почему? можешь объяснить в рамках своей концепции?


Мне не надо это объяснять. Достаточно, что это — удобнее.

DG>потому что это твое субъективное мнение?


Твоё тоже

IT>>Теперь домашнее задание — как в твои количество просмотров включить возможности hardware и как положение скобки соотносится с количеством просмотров. Я это правда не понимаю, смотреть то нужно одинаковое количество раз


DG>человеческий мозг на ряде вещей ведет себя как распараллеливающее устройство (это из когнитивной психологии)


Даже когнитивная психология не помогла ответить тебе на вполне конкретный вопрос.
Если нам не помогут, то мы тоже никого не пощадим.
Re[20]: Огни разработки
От: IT Россия linq2db.com
Дата: 19.07.09 23:27
Оценка:
Здравствуйте, DarkGray, Вы писали:

IT>>Теперь домашнее задание — как в твои количество просмотров включить возможности hardware и как положение скобки соотносится с количеством просмотров.


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

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

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

DG>сейчас же успешно сочетаются обе задачи.

DG>ps

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

Это всё понятно и без когнитивной психологии. Ты конкретно ответь, сколько количеств просмотров/рассмотров/вариантов нужно добавить к сложности восприятия, если мы изучаем код на мониторе с количеством строк равным 25, а сколько, если 50?
Если нам не помогут, то мы тоже никого не пощадим.
Re[46]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 20.07.09 08:16
Оценка:
VGn>>То, что 30 лет назад были такие роли и активности.

DG>что такое "активность"? термин "деятельность" — который ранее уже звучал и активность — это одно и тоже?


Англицизм от Activity. Означает регламентированные действия для роли, а в данном случае — должности. Просто термина "область активности" нет, зато "активность" — устоявшийся термин среди манагеров . По сути наверное да — одно и то же.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[21]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 20.07.09 09:02
Оценка:
IT>Это ты совсем недавно придумал. Раньше было количество вариантов поведения.

ты вообще чужие сообщения читаешь?

это появилось еще 10-го числа

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

http://rsdn.ru/forum/philosophy/3464010.1.aspx
Автор: DarkGray
Дата: 10.07.09


ps
"вариантов рассмотреть", "рассмотренных вариантов" и "рассмотров" — это синонимы. или это не очевидно, и надо разжевывать?
Re[21]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 20.07.09 09:02
Оценка:
IT>Для яблок и квартир есть функция, через которую их можно привести к одной величине — деньгам.

т.е. ты утверждаешь, что эта функция не зависит от контекста, т.е. для всех людей для всех ситуаций она одна и та же?
Re[22]: Огни разработки
От: IT Россия linq2db.com
Дата: 20.07.09 13:53
Оценка:
Здравствуйте, DarkGray, Вы писали:

IT>>Для яблок и квартир есть функция, через которую их можно привести к одной величине — деньгам.


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


У неё много параметров. Она зависит от времени, от места, от состояния рынка и пр. Но главное, что эта функция есть. Я же тебя прошу показать мне такую функцию, продемонстрировать её существование, для твоих тёплого и мягкого.
Если нам не помогут, то мы тоже никого не пощадим.
Re[33]: Огни разработки
От: Silver_s Ниоткуда  
Дата: 30.07.09 19:35
Оценка:
Здравствуйте, SergH, Вы писали:
SH>Здравствуйте, DarkGray, Вы писали:
DG>>сложность изучения инкапсуляции выше, чем сложность использования 10 кейзов — потому что сложность изучения инкапсуляции — 6-8 + 3-10*6-8 = 32-80, что явно больше, чем 10

SH>сорри... Откуда эти числа и эта формула (a + b * c)?

SH>Мне, вообще, кажется, что численные оценки тут невозможны и потому неуместны, но раз ты их даёшь -- возможно ты видишь то, чего не вижу я.

Насколько сложно изучать инкапсуляцию не знаю ... открыл словарь прочитал определение и готово ...
Численные оценки инкапсуляции все же возможны(в принципе) в предельных случаях,некоторые аспкты инкапсуляции. С большей адекватностью результата чем 6-8 + 3-10*6-8 = 32-80.

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

Примеры предельных случаев: Задача написать функцию. На входе картинка .bmp, на выходе текстовая строка написанная на картинке. Необходимо чтобы функция в 90% правильно распознавала картинки, такие как в Web на сайтах где пишут введите тект на картинке(подтвердите что человек а не робот). Заранее не известно на каком сайте будут проверять.

Вот сколько букв в описании, этого наверно достаточно. Инкапсуляция будет 1000...100000, и неизвестно получится ли вобще.

Другой случай 50 строк кода. Но нужно 200 строк текста. Придумать не трудно. Инкапсуляция меньше 1.

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

Если еще десяток трактовок инкапсуляций будет ... то тяжко прийдется. Потом на основе них какой-то объединенный коэфицент вычислять?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.