Огни разработки
От: 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: Огни разработки
От: Qbit86 Кипр
Дата: 07.07.09 08:30
Оценка: 1 (1) +1
Здравствуйте, DarkGray, Вы писали:

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


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

DG> а) Tell, don't ask


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

Ещё есть Принцип Наименьшего Удивления.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Огни разработки
От: Qbit86 Кипр
Дата: 07.07.09 08:32
Оценка: 10 (1)
Здравствуйте, Qbit86, Вы писали:

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


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

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


Эта статья напомнила, что есть еще Закон Деметры или Принцип Наименьшего Знания. Имхо, его тоже стоит вынести отдельным пунктом.
Глаза у меня добрые, но рубашка — смирительная!
Re: «YAGNI разработки»
От: Qbit86 Кипр
Дата: 07.07.09 09:22
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


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

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


Я знаю, в меня сейчас кинут тухлым помидором, но кроме шуток: TIMTOWTDI — there's more than one way to do it. Программирование — это искусство, давайте об этом не забывать.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
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[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[3]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 07.07.09 12:03
Оценка: 24 (1) +1 :))
Здравствуйте, Klapaucius, Вы писали:

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


Ой ли?


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[5]: Огни разработки
От: SergH Россия  
Дата: 07.07.09 12:19
Оценка: 1 (1) :)
Здравствуйте, Klapaucius, Вы писали:

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




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

Но, например, в такой области как архитектура неправильные пути определённо есть. Неправильные дома падают. Это не мешает архитектору одной ногой быть художником. Другой ногой он, конечно, должен быть инженером. А возможно ему ещё третья нога понадобится, из области экономики-логистики.
Делай что должно, и будь что будет
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[3]: Огни разработки
От: dotneter  
Дата: 07.07.09 13:42
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

Может стоит перенести в http://wiki.rsdn.ru/ ?
Talk is cheap. Show me the code.
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[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[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: Огни разработки
От: IT Россия linq2db.com
Дата: 07.07.09 15:51
Оценка: +3 :)
Здравствуйте, DarkGray, Вы писали:

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


Печальнее всего то, что знание всех этих принципов никак не защищает от ошибок и глупостей
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
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[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[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[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 мы вносим дополнительное усложнение в код, не получая ничего взамен.

и т.д.

В результате может оказаться, что этот список базвордов можно сократить как минимум вдвое и увидеть где они пересекаются и дополняют друг друга, а где противоречат и почему.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Огни разработки
От: IT Россия linq2db.com
Дата: 07.07.09 18:28
Оценка:
Здравствуйте, SergH, Вы писали:

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


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

именно, это и хочется сделать.
Re[8]: Огни разработки
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 08.07.09 04:03
Оценка:
Здравствуйте, SergH, Вы писали:
SH>Оценивать, возможно ли реализовать этот красивый проект в данных условиях за указанную сумму. Ну или с обратной стороны -- проектировать так, чтобы было возможно.
Ага. Типичный пример — дизайн IKEA. То, что они делают — одновременно и эстетично, и функционально, и рентабельно. Всякий раз фигею с того, как они выбирают размер дощечек для шкафа так, чтобы их можно было сложить в упаковку с плотностью почти что 100%.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
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[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: Огни разработки
От: VsevolodC Россия  
Дата: 08.07.09 07:02
Оценка: +1

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

Фредерик П.Брукс. Мифический человеко-месяц или как создаются программные системы
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: Огни разработки
От: 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[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: Огни разработки
От: 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]: Огни разработки
От: 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[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[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[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>Сформулировано введение, которое показывают откуда берутся огни


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

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

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


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

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

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

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

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

E>Хотя меня греет мысль, что некоторые результаты работы программистов все-таки можно считать искусством в смысле "продукта творческой деятельности".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[4]: Огни разработки
От: IT Россия linq2db.com
Дата: 10.07.09 03:10
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

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


DG>

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


Это всё следствия.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
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
http://files.rsdn.org/43395/hr-kyle-theisen-04.png
Re[11]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.07.09 05:59
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

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

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

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

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

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

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

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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
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[6]: Огни разработки
От: IT Россия linq2db.com
Дата: 10.07.09 13:20
Оценка: 10 (1) +1
Здравствуйте, DarkGray, Вы писали:

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


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


Если кратко, то следствия борьбы со сложностью. Если подробно, то в терминах борьбы со сложностью можно разобрать зачем нужнен и насколько полезен любой из принципов, если это, конечно, интересно.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
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[15]: Огни разработки
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.07.09 13:34
Оценка: +1
Здравствуйте, Klapaucius, Вы писали:

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


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

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

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

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


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

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

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


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

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

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

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


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

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


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

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


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


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

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


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

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

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

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



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

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


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

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

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

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

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

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

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, тоже не имеет никакого отношения.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: Огни разработки
От: IT Россия linq2db.com
Дата: 10.07.09 17:04
Оценка:
Здравствуйте, DarkGray, Вы писали:

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


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


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


Это очень ограниченное определение и покрывает в какой-то степени лишь количественную и алгоритмическую сложности. Например, Singleton сокращает количество вариантов поведения программного решения, но увеличивает сложность модификации кода. Не следование соглашениям об именованиях и отвратительное оформление кода вообще никак не влияют на количество вариантов поведения программного решения, но могут в разы увеличить сложность восприятия кода. Сложность понятие многогранное и неоднозначное и количественно не измеряется.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
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[5]: Огни разработки
От: frogkiller Россия  
Дата: 10.07.09 19:55
Оценка: +1
Здравствуйте, Klapaucius, Вы писали:

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


Засада в том, что ты хочешь только логического объяснения. Ну не получится полностью разложить по полочкам то, что содержит в себе иррациональное. Однако, ты же не станешь отрицать существование красоты только потому, что она не вписыватся в построенную тобой логическую модель мира?
Я не знаю, как это объяснить, кроме как показать и сказать: смотри! Неужели у тебя никогда не возникали моменты, когда ты смотрел в код и видеел, что он просто красив?! — не важно, что он делал и для чего предназначался...
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[2]: Огни разработки
От: frogkiller Россия  
Дата: 10.07.09 20:08
Оценка:
Здравствуйте, DarkGray, Вы писали:

[...]

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

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

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

И второе: никакие другие правила, кроме этих двух, не должны быть абсолютными. Т.е. всё, что ты перечислил далее должно звучать как "хотелось бы, чтобы при этом также выполнялось...", но не более.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
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[3]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 10.07.09 20:56
Оценка: -1 :))
F>У тебя слишком много слов "должен". Получается, что шаг влево, шаг вправо — расстрел.

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

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


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

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


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


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

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


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

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


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

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


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


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

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

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

Всё это очень правильно, но не имеет абсолютно никакого отношения, например, к атомарности. Ты же о ней хотел поговорить в этой теме?
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Огни разработки
От: IT Россия linq2db.com
Дата: 11.07.09 02:38
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

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


Предыдущий шаг был сделан в правильном направлении. Этот куда-то в сторону. Огни разработки и заказчик — это как минимум два разных человека. Твоему заказчику на твои огни наплевать. Если не веришь мне, спроси у него самого.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
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[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:19
Оценка:
IT>Всё это очень правильно, но не имеет абсолютно никакого отношения, например, к атомарности. Ты же о ней хотел поговорить в этой теме?

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

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

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

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

ps
может, конечно, по классификации выдрова, ты и я на разный класс заказчиков работаем:
ты больше на изиотов, я больше на привиред/профессионалов.
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
Оценка:
кстати очень интересно применить вот это

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

к текущему интерфейсу кнопок для вставки тегов в сообщения
http://files.rsdn.org/3655/rsdn-buttons.PNG

допустим я хочу вставить таблицу и ищу подходящий тег.
текущая сложность будет = 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[14]: Огни разработки
От: Юрий Жмеренецкий ICQ 380412032
Дата: 11.07.09 08:47
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

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


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


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


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

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

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

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

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

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

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


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


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

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


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

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


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

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


См. пунк 2.

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


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

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

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

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

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

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

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


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

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


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

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


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

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

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

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

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


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


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

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


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


Ещё раз повторяю. Введённая тобой определение сложности сильно ограничено. А попытка прилепить к ней количественную меру мягко говоря нежизнеспособна.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
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>раз есть ограничение, то покажи его, покажи нежизнеспособность.

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

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

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


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

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


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


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

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


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


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


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


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


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

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

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

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


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


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


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

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


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


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


DG>

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


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

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

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

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


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


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


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

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

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

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


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


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


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

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

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


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

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


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


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


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

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

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

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

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

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

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

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


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


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

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


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


В том то и проблема, что тебе надо время для структурирования. Когда человек хорошо осваивает какой то вопрос, ему не надо время на структутирование.
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>и в чем измеряется сложность обучения? разве не в кол-ве вариантов которые надо зазубрить (запомнить)?


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

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

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

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


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

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


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

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

или для тебя новость, что гвозди тоже учат забивать?...
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>что не так?

О как! Меня радует гибкость твоих суждений. Раньше ты давал немного другое определение, но быстро исправился
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 12.07.09 17:30
Оценка: 1 (1) +1
ГВ>Вообще говоря, это не "огни", а лозунги. ИМХО, руководствоваться ими в практической деятельности

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

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

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

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

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

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

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

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

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

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

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

Re[3]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 12.07.09 17:36
Оценка:
Здравствуйте, DarkGray, Вы писали:


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

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

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

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


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

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

Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
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]: Огни разработки
От: 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[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:11
Оценка: +1
ГВ>Хм. А мне такой пурги не несли. Просто учили правильно забивать гвозди не отбивая пальцев, и обращать внимание на окружающих. Видимо, у нас с тобой разный опыт по этой части.

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

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

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

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

http://www.dropball.ru/gallery/bolt.jpg

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

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

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

DG>т.к. лозунги воздействует не только на разум, но и на эмоции.

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

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


Это из области копания траншей. Если нужно выкопать траншею в два раза длинней, то нужно либо в два раза больше землекопов, либо в два раза больше лозунгов.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
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 Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
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: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: Огни разработки
От: 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[5]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 06:47
Оценка:
Здравствуйте, DarkGray, Вы писали:

ГВ>>Ни там, ни там нет никаких лозунгов. Совсем.


DG>а вот это ТБ или не ТБ?

DG>лозунг или инструкция?

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

DG>http://www.dropball.ru/gallery/bolt.jpg


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 Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 13.07.09 07:01
Оценка:
Здравствуйте, DarkGray, Вы писали:
DG>очень хорошо отзываются.
Ну, я с ними пока не сталкивался, отзывов не имею. Настораживает полное отсутствие на сайте комментариев относительно используемой фурнитуры (хитрецы, которые применяют вместо blum т.н. "офисные направляющие" сразу идут в девнулл). Кроме того, они походу ничего, кроме MDF и ламината, не обещают — что означает хреновые "качество и надёжность". По сравнению, я имею в виду, с пластиком и шпоном.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
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[8]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 08:14
Оценка: 3 (1)
ГВ>Не совсем. Я вообще против "инструкций о том, как писать программу".

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

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

ps
кстати, добавлю, обучение со списком метафор — действительно работает, без него намного хуже, т.к. тогда обучаемый вообще не понимает к чему следует стремится, и на что ориентироваться.
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[9]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 08:41
Оценка: +1
IT>Кратко сложность можно определить как меру усилий, требуемых для решения поставленной задачи. Абсолютной единицы измерений скорее всего нет, иначе всё было бы гораздо проще. Но в абстрактных попугаях, в терминах много, мало, больше, меньше померять можно.

Скорее это тоже следствие. Источником является комбинаторная сложность.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
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[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[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[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[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[23]: Огни разработки
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 13.07.09 09:36
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

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


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


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


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


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

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

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

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

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

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

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

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

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

Ёшкин хвост, но система обучения программированию уже давным-давно есть, зачем подменять её наивными правилами?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
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[29]: PS
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 10:32
Оценка:
Здравствуйте, DarkGray,

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

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

в российской информатике(как учебного предмета) нет никакой системы.
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[20]: Огни разработки
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 13.07.09 10:38
Оценка:
DG>у микрософта довольно хороший код последнее время, и это кстати следствие тех инициатив, которые они внедрили по проверке качества кода.
DG>и кстати они про эти инициативы постоянно всем рассказывают — это к теме интересно или нет заказчикам — как сделано ПО.

ooftopic
Только в этом году работал с кодом Мелкософта. Код у них ОЧЕНЬ разный. В общей массе такое же говно, как и во всех корпоративных продуктах.
Но это не значит, что с ним нельзя работать. Альтернативы обычно намного хуже, если вообще есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[27]: Огни разработки
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 13.07.09 10:44
Оценка: +1 :)
Здравствуйте, DarkGray, Вы писали:
DG>и т.д.
Это — не метафоры и не лозунги. Это неумолимые правила, т.е. предикаты, описывающие корректный русский текст. Дело не в том, что нужно "стараться писать жи/ши с буквой и", а что жы и шы — заведомо неправильные варианты.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[2]: Огни разработки
От: Undying Россия  
Дата: 13.07.09 11:03
Оценка: +1
Здравствуйте, DarkGray, Вы писали:

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


DG>

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


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

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

Под заказчиком понимается не только и не столько тот, кто собственно платит деньги, но и тот кто этим продуктом будет пользоваться. Специально упоминать в цели о сроках и окружении не нужно, т.к. это неотъемлимая часть поставленной задачи.
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[28]: Огни разработки
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 13.07.09 11:26
Оценка: -1 :)
S>Это — не метафоры и не лозунги. Это неумолимые правила, т.е. предикаты, описывающие корректный русский текст. Дело не в том, что нужно "стараться писать жи/ши с буквой и", а что жы и шы — заведомо неправильные варианты.

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

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

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

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


VGn>Не понял.


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

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

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

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


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

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


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

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

Это всё даётся детям в рамках "правописания гласных с шипящими", если не ошибаюсь. А для лучшего запоминания дополнительно приводятся такие игривые оформления правил. И требуют в дальнейшем не запоминать игривые формулировки, а следовать правилам языка.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: Огни разработки
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.07.09 11:42
Оценка: :))
Здравствуйте, FR, Вы писали:

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


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


Ой, что сейчас начнётся...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
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
Оценка: