Здравствуйте, DarkGray, Вы писали:
ГВ>>Надо. Но это отменяет необходимости разобраться. DG>т.е. должна быть не инструкция, а должен быть список вещей, которые программисту необходимо разобрать?
Конечно. И этот список начинается в профильном вузе.
Программист, как и всякий технический специалист, коль скоро мы именно о них, должен понимать, что из чего следует и к каким последствиям приведёт или не приведёт. "От обратного" тут адекватно научить очень сложно. ИМХО, списками наставлений тут не поможешь — сложные проблемы нельзя решить простыми способами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Конечно. И этот список начинается в профильном вузе.
тогда как ты относишься к утверждению:
при становлении программистом стоит разобрать следующий список: ?
Огни:
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. кажись сложным, будь простым (число поддерживаемых внешних вариантов должно быть как можно больше, число внутренних вариантов поведения как можно меньше)
...
и т.д.
E>Просто ради исторической справедливости: так переживал, вероятно, заказчик Mars Surveyor. А Arian 5 была другая причина катастрофы -- там разработчики ПО не знали, чем Arian 5 отличается от Arian 4.
Сработал 10 огонёк. Точнее — антипаттерн "такого быть не может".
Здравствуйте, VGn, Вы писали:
E>>Просто ради исторической справедливости: так переживал, вероятно, заказчик Mars Surveyor. А Arian 5 была другая причина катастрофы -- там разработчики ПО не знали, чем Arian 5 отличается от Arian 4.
VGn>Сработал 10 огонёк. Точнее — антипаттерн "такого быть не может".
Здравствуйте, DarkGray, Вы писали:
ГВ>>Конечно. И этот список начинается в профильном вузе. DG>тогда как ты относишься к утверждению: DG>при становлении программистом стоит разобрать следующий список: ?
[skip]
Негативно. Это полезно уже состоявшимся специалистам, как своеобразная юморная памятка, как сборник пословиц и поговорок, вроде "тестируют программы только не уверенные в себе". Сначала нужно усвоить, что своя голова должна превалировать над мнением окружающих, и в то же время, этих самых окружающих необходимо учитывать при своих действиях.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DG>а всех интересует — кол-во рассматриваемых вариантов, соответственно для этого разработано куча методик, как свести к минимуму кол-во рассматриваемых вариантов; и большинство принципов(или огней в терминологии данного треда) программирования направлено именно на уменьшение рассматриваемых вариантов.
В правильном процессе количество рассматриваемых вариантов ограничивается зонами ответственности (уровнями абстракции).
В коде всё тоже самое (области отвественности кода — тоже важный паттерн), но имхо это вообще не дело заказчика.
ГВ>Негативно. Это полезно уже состоявшимся специалистам, как своеобразная юморная памятка, как сборник пословиц и поговорок, вроде "тестируют программы только не уверенные в себе".
т.е. лучше все капканы и ловушки обходить самому, а не пользоваться чужим опытом?
ГВ>>Негативно. Это полезно уже состоявшимся специалистам, как своеобразная юморная памятка, как сборник пословиц и поговорок, вроде "тестируют программы только не уверенные в себе".
DG>т.е. лучше все капканы и ловушки обходить самому, а не пользоваться чужим опытом?
Ты удивишься, но капканы и ловушки можно обойти только на своём собственном опыте. Чужой опыт — это не больше, чем подсказка, полезная, когда понимаешь 9/10 причинно-следственных связей.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Ты удивишься, но капканы и ловушки можно обойти только на своём собственном опыте.
но писать и считать учат в школе, а не каждый ждет 20 лет, чтобы убедиться, что во взрослой жизни действительно стоит уметь считать и писать...
т.е. твоя позиция имеет право на жизнь, но она активно использовалась в доиндустриальную эру — когда да, каждый раз за разом наступал на одни и те же грабли.
индустриальная эра же началась с того, что появилось книгопечатание и уже каждый мог не с нуля набивать шишки, а легко и активно использовать чужой опыт, и передавать другим свой опыт.
соответственно список огней и есть такой опыт других, который стоит разобрать каждому и интегрировать в свою работу.
L>Ну, как то ты в крайности бросаешься, честное слово.
это полезно, т.к. позволяет проверить утверждение на прочность.
L> Смысл в том, что учиться нужно не по лозунгам.
тут я согласен с ГВ, что учиться надо разбирая чужой опыт, и результат разборов интегрировать в свое мнение.
а лозунг лишь служит названием того, что стоит разобрать.
VGn>В коде всё тоже самое (области отвественности кода — тоже важный паттерн), но имхо это вообще не дело заказчика.
а если под заказчиком понимать команду разработчиков, которая заказала одному из разработчиков этой же команды решить подзадачку
то такому заказчику(команде разработчиков) важно знать как будет выполнена подзадача?
DG>а что кто-то мешает? DG>берешь дебагер, дизассемблер, reflector и вперед. DG>и все "подкапотное" пространство как на ладони. DG>и сразу видно, что кто-то разрабатывает надежно, а кто-то сопливо.
Ну и как там разрабатывают Висту? Надёжно или сопливо?
И что тебе даст ответ на этот вопрос?
Здравствуйте, DarkGray, Вы писали:
ГВ>>Ты удивишься, но капканы и ловушки можно обойти только на своём собственном опыте. DG>но писать и считать учат в школе, а не каждый ждет 20 лет, чтобы убедиться, что во взрослой жизни действительно стоит уметь считать и писать...
Кстати, сколько лет учат считать и писать? И как это делают? Напомнить? И что является целью прораммы среднего образования? Усвоение ряда поговорок про математику?
DG>т.е. твоя позиция имеет право на жизнь, но она активно использовалась в доиндустриальную эру — когда да, каждый раз за разом наступал на одни и те же грабли. DG>индустриальная эра же началась с того, что появилось книгопечатание и уже каждый мог не с нуля набивать шишки, а легко и активно использовать чужой опыт, и передавать другим свой опыт.
Завелась шарманка... Давай ещё сюда любимые коробки передач и сравнение Мерседеса с Виллисом.
DG>соответственно список огней и есть такой опыт других, который стоит разобрать каждому и интегрировать в свою работу.
Уже теплее. Только опять таки, чтобы интегрировать, нужно очень глубоко разобрать такие высказывания. А проще — систематически изложить то, что под этими высказываниями подразумевается. Возвращаемся к необходимости систематического обучения, которому все эти метафоры — параллельны.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
DG>а если под заказчиком понимать команду разработчиков, которая заказала одному из разработчиков этой же команды решить подзадачку DG>то такому заказчику(команде разработчиков) важно знать как будет выполнена подзадача?
VGn>Ну и как там разрабатывают Висту? Надёжно или сопливо?
у микрософта довольно хороший код последнее время, и это кстати следствие тех инициатив, которые они внедрили по проверке качества кода.
и кстати они про эти инициативы постоянно всем рассказывают — это к теме интересно или нет заказчикам — как сделано ПО.
ГВ> А проще — систематически изложить то, что под этими высказываниями подразумевается. Возвращаемся к необходимости систематического обучения, которому все эти метафоры — параллельны.
список метафор — это и есть начало систематического изложения, считай что каждая метафора — это краткий подзаголовок одной или нескольких глав из учебника
ps
это такие же метафоры как в русском:
жи/ши пиши с буквой и
мягкий знак в глаголах проверяется с помощью вопросов что делает/что делать
вводные слова отделяются запятой
и т.д.
