Огни разработки
От: 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
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.