Огни применяемые в программировании

by Темных Сергей 07.07.2009 5:36:00

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

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

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

Введение

Все начинается с заказчика перед которым стоит задача. Заказчик для решения данной задачи заказывает программный продукт (ПП).

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

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

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

Огни:
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 (Одна точка принятия решения)
    b) В коде явно записано почему программа в текущий момент  ведет себя так, а не иначе
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. кажись сложным, будь простым (число поддерживаемых внешних вариантов должно быть как можно больше, число внутренних вариантов поведения как можно меньше)
20. Согласованность (говоря A, говори и B)
   a) полнота (код, по возможности, должен уметь обрабатывать все варианты входной информации)
   b) Principle of least astonishment (принцип наименьшего удивления)
   c) DWIM
21. there's more than one way to do it
  a) There should be one-- and preferably only one --obvious way to do it.
23. пиши в коде то, что ты действительно хотел сделать, а не что получается записать
   а) пиши логику, а не физику
24. Все строки кода должны постоянно работать/использоваться (иначе их съедает ржа)
  а) Покрывай часто используемыми сценариями(или тестами) весь код 
  b) резерв должен быть горячим, а не холодным
25. Название должно точно отражать содержимое (уже по названию должно быть понятно, что содержится внутри)
   a) должно быть как можно меньше side-effect-ов
26. новое делай снаружи, старое интегрируй внутрь
   а) чем большим количеством что-то используется, тем более оно ядернее и интегрируемее должно быть (и наоборот)
   b) get, don't set - формируй новую реальность, а не меняй имеющуюся
   c) Open for extension, closed for modification
28. Выделяй главное, убирай(скрывай) несущественное
   a) Инкапсуляция
   b) Вводи метафоры и абстракции
29. Скопируй, разберись, сделай лучше

Анти-Огни
1. Предварительное усложнение без четкого ответа "зачем?" корень всех зол (YAGNI, DST — Do Simple Things и DTSTTCPW — Do The Simplest Thing That Could Possibly Work)
 а) premature optimization is the root of all evil
 b) любую проблему можно решить путём введения дополнительного абстрактного слоя (кроме проблемы слишком большого количества абстрактных слоёв).
2. не изобретай велосипед 

Паттерны, которые применяются для достижения вышеперечисленных огней
1. GRASP (англ. General Responsibility Assignment Software Patterns (общие образцы распределения обязанностей)) - паттерны, используемые в объектно-ориентированном проектировании для решения общих задач по назначению обязанностей классам и объектам.

Огни применяемые в разных языках/подходах и т.д.
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
3)ООП
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
4)O'Reilly commons (97 Things Every Programmer Should Know)


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

Текущий рейтинг: 2.6 (5 голосов)

  • Currently 2,6/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Похожие записи

Powered by BlogEngine.NET 1.3.1.0
Theme by Mads Kristensen

Сергей Темных

Модулятор


Calendar

<<  Июнь 2017  >>
повтсрчепясуво
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

View posts in large calendar

Страницы

    Последние комментарии

    Категории

    None


    Disclaimer

    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

    © Copyright 2017

    Sign in