Стремления (огни) которые применяются в программировании
5. Keep it simple, stupid (acronim KISS)
5. Keep it simple, stupid (acronim KISS)более, чем согласен
В том обсуждении про DRY выяснили, что еще очень важным aka для него является single point of knowledge.
В языках C++ и C# к последнему пункту надо добавить подпункт "безопасность исключений". Почитать по этой теме можно соответствующие разделы книг Саттера.
SOLID, GRASP, CoC?
В языках C++ и C# к последнему пункту надо добавить подпункт "безопасность исключений". Почитать по этой теме можно соответствующие разделы книг Саттера.к последнему - это к которому?
ps
кстати ты, как раз, нарушил принцип - хз как называется - самодостаточности информации что ли
=)
К последнему в той ревизии твоего поста, когда я писал свой =P
К 10му.
К последнему в той ревизии твоего поста, когда я писал свой =P
К 10му.
SOLID, GRASP, CoC?оно?
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
GRASP (англ. General Responsibility Assignment Software Patterns (общие образцы распределения обязанностей - паттерны, используемые в объектно-ориентированном проектировании для решения общих задач по назначению обязанностей классам и объектам.
что это CoC?
13 и 2й пункты посматривают друг на друга с недоверием
CoCне 9й ли это пункт?
Не думаю.
Ну после твоей ссылки уже ясно, что я ошибся.
Почему-то подумал про эти пресловутые coupling и cohesion.
Почему-то подумал про эти пресловутые coupling и cohesion.
В языках C++ и C# к последнему пункту надо добавить подпункт "безопасность исключений". Почитать по этой теме можно соответствующие разделы книг Саттера.в двух словах скажи в чем суть.
Есть три уровня "гарантии" безопасности исключений, каждый класс может предоставлять один из них:
1. Если методы класса выбрасывают исключение, то объект остается в корректном состоянии, т.е. можно дальше с ним работать. Здесь не гарантируется, что объект окажется в предсказуемом состоянии, просто в корректном.
2. Дополнительно ко второму пункту гарантируется, что если было выброшено исключение, то состояние объекта вообще не изменилось по сравнению с тем, каким было непосредственно перед вызовом. Т.е. commit-or-rollback.
3. Самая сильная: методы класса вообще не выбрасывают исключений.
Рекомендуется предоставлять как минимум первую гарантию.
1. Если методы класса выбрасывают исключение, то объект остается в корректном состоянии, т.е. можно дальше с ним работать. Здесь не гарантируется, что объект окажется в предсказуемом состоянии, просто в корректном.
2. Дополнительно ко второму пункту гарантируется, что если было выброшено исключение, то состояние объекта вообще не изменилось по сравнению с тем, каким было непосредственно перед вызовом. Т.е. commit-or-rollback.
3. Самая сильная: методы класса вообще не выбрасывают исключений.
Рекомендуется предоставлять как минимум первую гарантию.
SOLID надо как-то структурированнее написать, чтобы не создавать путаницы в твоем списке, т.е. надо указать, что он объединяет такие-то пункты.
13 и 2й пункты посматривают друг на друга с недовериемв этом как раз и смысл данного действия - наглядно показать, что требований к коду много и бездумно следовать лишь одному требованию - плохо заканчивается.
что как всегда важен баланс.
ps
unit-way(srp например, частично конфликтует с понятностью и оптимальностью работы
читабельность с оптимальностью
скорость разработки с оптимальностью
и т.д.
Одним из правил 15го пункта наверняка является "Tell, don't ask", т.е. надо в основном отдавать приказы другим объектам, а не запрашивать у них параметры для выполнения действий.
upd: хотя лучше это к 9му написать, а то получается дизбаланс, GRASP — это что-то очень большое, а это правило очень сжато. К 9му пункту относится напрямую.
upd: хотя лучше это к 9му написать, а то получается дизбаланс, GRASP — это что-то очень большое, а это правило очень сжато. К 9му пункту относится напрямую.
SOLID надо как-то структурированнее написать, чтобы не создавать путаницы в твоем списке, т.е. надо указать, что он объединяет такие-то пункты.время будет - структурирую, пока все валом записываю
Одним из правил 15го пункта наверняка является "Tell, don't ask", т.е. надо в основном отдавать приказы другим объектам, а не запрашивать у них параметры для выполнения действий.запишу, но смотри тогда 17-пункт (get, don't set)
Еще надо будет стараться к каждому пункту давать ссылки на статьи и со временем менять на наиболее удачные. В принципе можно сделать обсуждаемый тред, внутрь копировать статьи и в первом посте сделать оглавление. Ну это если ты хочешь создать действительно очень крутой и полезный тред.
Еще надо будет стараться к каждому пункту давать ссылки на статьи и со временем менять на наиболее удачныесогласен
В принципе можно сделать обсуждаемый тред, внутрь копировать статьи и в первом посте сделать оглавление. Ну это если ты хочешь создать действительно очень крутой и полезный тред.тут проблема в том, что тред - это разговор, который повторно тяжело читать.
поэтому, имхо, обсуждение должно быть с временным хранением. поговорите - выяснили какие-то позиции зафиксировали их где-то отдельно, а само обсуждение ушло в архив.
т.е. оставаться должно только резюме, а разговоры уходить в архив.
Ты же модератор 
20. полнота (код, по возможности, должен уметь обрабатывать все варианты входной информации)
unix-way (оно же single responsibility principle)откуда взялось что это "оно же"?
откуда взялось что это "оно же"?один из основных принципов unix-way: Пусть каждая программа делает одну вещь, но хорошо
srp - тоже самое, только слово программа заменена на слово объект: пусть каждый объект делает одну вещь, но хорошо
21. there's more than one way to do it
добавлю:
Должна оставаться возможность рефакторинга.
Этому критерию не удовлетворяют
1. нетипизированные решения
2. визардоподобные решения
Должна оставаться возможность рефакторинга.
Этому критерию не удовлетворяют
1. нетипизированные решения
2. визардоподобные решения
один из основных принципов unix-wayвот именно, только один из.
Пусть каждая программа делает одну вещь, но хорошо
srp - тоже самое, только слово программа заменена на слово объект: пусть каждый объект делает одну вещь, но хорошо
Общее, несомненно, есть, но в литераторе я не встречал отождествления SRP с unix way. SRP был всегда сам по себе.
Должна оставаться возможность рефакторинга.в смысле автоматизированного или автоматического рефакторинга?
но в литераторе я не встречалкруто! мы первые! это разве плохо?
ps
т.е. я в том смысле, что я не понимаю довод: а вот в инете пишут другое, или а вот в литературе это не пишут.
в смысле автоматизированного или автоматического рефакторинга?скажем так, должны работать известные техники рефакторинга. Часто эти техники входят в набор автоматического рефакторинга.
записал так:
22. стуктура кода должна быть формализованной (достаточно понятной для автоматики)
а) должна оставаться возможность автоматического\автоматизированного рефакторинга
ps
я постоянно подчеркиваю - автоматизированный, потому что для рефакторинга человеком следующая конструкция не представляет проблемы при изменении имени метода с MyCoolMethod на MySuperCoolMethod:
22. стуктура кода должна быть формализованной (достаточно понятной для автоматики)
а) должна оставаться возможность автоматического\автоматизированного рефакторинга
ps
я постоянно подчеркиваю - автоматизированный, потому что для рефакторинга человеком следующая конструкция не представляет проблемы при изменении имени метода с MyCoolMethod на MySuperCoolMethod:
var x = Get;
x.GetType.GetMethod("MyCoolMethod").Invoke(x, 1);
если под автоматикой понимать и просто проверку ошибок на этапе компиляции, то — да, с формулировкой согласен.
"Не плодить сущностей без необходимости." (Бритва Оккама)
Надо бы одним из первых пунктов упомянуть
.
Надо бы одним из первых пунктов упомянуть
.Это не из той оперы.
Это не из той оперы.как раз из той, вот часто отказывается от формулировки необходимости введения нескольких сущностей
у нас в конторе чувак написал несложный инсталятор с кучей потоков, нахрена никто так и не разобрался
как раз из тойЛадно, в любом случае там есть KISS, а DRY запрещает добавлять еще это твое правило.
в любом случае там есть KISSok
Столько умных слов написали, и никто не упомянул про банальное тестирование?..
Столько умных слов написали, и никто не упомянул про банальное тестирование?..прототипирование - это кстати не из той же оперы?
Вспомнился совет Саттера: «Remember to distinguish between «protecting against Murphy versus protecting against Machiavelli» — that is, protecting against things going wrong on their own versus a malicious programmer going to great lengths trying to break your code.»
В основном, конечно, относится к языкам типа C++, а не к управляемым. Можно добавить как подпункт к KISS.
В основном, конечно, относится к языкам типа C++, а не к управляемым. Можно добавить как подпункт к KISS.
Keep It Sage, Smartass!
21. there's more than one way to do it
21a. There should be one-- and preferably only one --obvious way to do it.
и вообще,
>>> import this
21a. There should be one-- and preferably only one --obvious way to do it.согласен, добавил
соответственно. также добавил (чтобы было в одном месте): огни из python, и огни из unix
Огни которые применяются в разных языках/подходах и т.д.
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 (из-за кавычки ссылка нормально в форум не вставляется)
копия также будет жить в http://blog.metatech.ru/post/ogni-razrabotki.aspx
если будете ставить ссылку на этот текст, то лучше ставьте на http://blog.metatech.ru/post/ogni-razrabotki.aspx там можно хотя бы комментарии из инета добавлять, в отличии от данного форума.
Когда отсутствует способность мыслить, надо зубрить, да.
Тут кстати ссылка на этологию в стиле Ерсуб, но можно и без неё.
---
"...Это не количество прочитанных книг, а количество понятых."
Тут кстати ссылка на этологию в стиле Ерсуб, но можно и без неё.
---
"...Это не количество прочитанных книг, а количество понятых."
У тебя же самого есть цитата "люди недалекие осуждают то, что выходит за рамки их понимания", вот она сейчас была бы в тему.
23. пиши в коде то, что ты действительно хотел сделать, а не что получается записать
а) пиши логику, а не физику
а) пиши логику, а не физику
Столько умных слов написали, и никто не упомянул про банальное тестирование?..прототипирование похоже да не отсюда, а отсюда следующее.
24. Все строки кода должны постоянно работать/использоваться (иначе их съедает ржа)
а) Покрывай тестами(или часто используемыми сценариями) весь код
25. Название должно точно отражать содержимое (уже по названию должно быть понятно, что содержится внутри)
а) Программа должна работать
а) Программа должна работать
25. b) должно быть как можно меньше side-effect-ов
Я-то как раз понимаю ограничения этих принципов.
Есть, по меньшей мере, два, которые неверны или очень натянуты.
---
"Неопределённая вера порождает дилетантские души.
А дилетантизм --- преступление перед обществом."
Есть, по меньшей мере, два, которые неверны или очень натянуты.
---
"Неопределённая вера порождает дилетантские души.
А дилетантизм --- преступление перед обществом."
Ещё одно подоспело.
---
"Неопределённая вера порождает дилетантские души.
А дилетантизм --- преступление перед обществом."
---
"Неопределённая вера порождает дилетантские души.
А дилетантизм --- преступление перед обществом."
Одним из правил 15го пункта наверняка является "Tell, don't ask", т.е. надо в основном отдавать приказы другим объектам, а не запрашивать у них параметры для выполнения действий.почитал http://www.pragprog.com/articles/tell-dont-ask
upd: хотя лучше это к 9му написать
почему к 9 (связность и связанность а не к 8 (атомарность)?
речь же идет о том, что не надо разбивать операцию на несколько взаимодействий, а нужно формулировать операцию так, чтобы она была одним действием(одним взаимодействием)
ps
кстати по твоему комментарию "т.е. надо в основном отдавать приказы другим объектам, а не запрашивать у них параметры для выполнения действий." я сначала совсем не правильно понял о чем правило.
24. Все строки кода должны постоянно работать/использоваться (иначе их съедает ржа)24 b) резерв должен быть горячим, а не холодным
а) Покрывай тестами(или часто используемыми сценариями) весь код
26. новое делай снаружи, старое интегрируй внутрь
26. новое делай снаружи, старое интегрируй внутрь26 а) чем большим количеством что-то используется, тем более оно ядернее и интегрируемее должно быть (и наоборот)
26. новое делай снаружи, старое интегрируй внутрьинтересно, когда новое переходит в старое?
Очевидно когда начинает считаться тем, что "внутри"
интересно, когда новое переходит в старое?
чем большим количеством что-то используется, тем более оно ядернее и интегрируемее должно быть (и наоборот)
YAGNI — You Ain't Gonna Need It.
DWIM — Do What I Mean.
DST — Do Simple Things и DTSTTCPW — Do The Simplest Thing That Could Possibly Work.
Вообще, рекомендую последний сайт.
DWIM — Do What I Mean.
DST — Do Simple Things и DTSTTCPW — Do The Simplest Thing That Could Possibly Work.
Вообще, рекомендую последний сайт.
YAGNI — You Ain't Gonna Need It.у меня пока получается, что yagni, dst и dtsttcpw - это фактически все одно и тоже
DWIM — Do What I Mean.
DST — Do Simple Things и DTSTTCPW — Do The Simplest Thing That Could Possibly Work.
Анти-Огниа dwim - это часть согласованности
1. Предварительное усложнение без четкого ответа "зачем?" корень всех зол (YAGNI, DST — Do Simple Things и DTSTTCPW — Do The Simplest Thing That Could Possibly Work)
а) premature optimization is the root of all evil
b) любую проблему можно решить путём введения дополнительного абстрактного слоя (кроме проблемы слишком большого количества абстрактных слоёв).
20. Согласованность (говоря A, говори и B)
a) полнота (код, по возможности, должен уметь обрабатывать все варианты входной информации)
b) Principle of least astonishment
c) DWIM
Кстати, с сегодняшнего дня я с тобой согласен в том, что SRP необязателен , более важно четко описывать все responsibilites.
, более важно четко описывать все responsibilites.перед огнями появилось вот такое введение
цель, которая ставится перед кодом можно сформулировать следующим образом:
цель - код должен решать поставленную нами задачу за конкретный срок в том окружении, которое есть; и быть готовым к переформулировке или корректировке задачи по ходу (примечание: время на разработку и модификацию кода входит в срок)
такая формулировка цели приводит нас к следующим требованиям на код:
требования:
1. Код должен решать поставленную задачу
a) правильно
b) быстро
с) с минимальными затратами ресурсов
d) целиком
* порядок именно такой (т.е. лучше правильно, чем быстро; лучше быстро, чем оптимально и т.д.)
3. Код должен легко использоваться
4. Код должен быть готовым к любым условиям использования
а) Код должен легко повторно использоваться
b) Код должен вести себя адекватно даже в непредвиденной ситуации
5. Код должен быстро разрабатываться
6. Код должен легко модифицироваться
a) Код должен читаться (легко пониматься) человеком и компьютером
b) Код должен быть достаточно формализован (должна оставаться возможность автоматического\автоматизированного рефакторинга)
если ориентироваться на следующие огни, то добиться вышеуказанных требований будет проще
огни
....
более важно четко описывать все responsibilites.где описывать?
где описывать?в названии, и списком методов.
ps
25. Название должно точно отражать содержимое (уже по названию должно быть понятно, что содержится внутри)
описывать где-то в другом месте противоречит
6.b) Код должен быть достаточно формализован (должна оставаться возможность автоматического\автоматизированного рефакторинга)
где описывать?Ладно, описывать по-разному можно, главное, скажем, понимать, или точнее следить за тем, чтобы этот список обязанностей случайно не раздувался.
Оставить комментарий
Dasar
хочется собрать в одном месте, какие концепции(стремления) применяются в программировании (или про что надо помнить при программировании)пока не могу сформулировать что такое именно стремление, попробую по ходу.
но в итоге хочется получить "картинку": меж каких огней находится разработчик для того, чтобы выполнить свою задачу хорошо.
навскидку:
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. структура кода должна быть формализованной (достаточно понятной для автоматики)
а) должна оставаться возможность автоматического\автоматизированного рефакторинга
23. пиши в коде то, что ты действительно хотел сделать, а не что получается записать
а) пиши логику, а не физику
24. Все строки кода должны постоянно работать/использоваться (иначе их съедает ржа)
а) Покрывай тестами(или часто используемыми сценариями) весь код
25. Название должно точно отражать содержимое (уже по названию должно быть понятно, что содержится внутри)
а) Программа должна работать
26. новое делай снаружи, старое интегрируй внутрь
а) чем большим количеством что-то используется, тем более оно ядернее и интегрируемее должно быть (и наоборот)
Огни которые применяются в разных языках/подходах и т.д.
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 (из-за кавычки ссылка нормально в форум не вставляется)
ps
копия будет жить на http://blog.metatech.ru/post/ogni-razrabotki.aspx
если будете ставить ссылку на этот текст, то лучше ставьте на http://blog.metatech.ru/post/ogni-razrabotki.aspx там можно хотя бы комментарии из инета добавлять, в отличии от данного форума.
зы
время будет - добавлю и структурирую, пока все валом записываю