GoF, SOLID Мартина, GRASP Лармана, Шаблоны корпоративных приложений Фаулера.
Ведь если честно все это ужасно, не хватает четкости мышления, систематичности, ясности, местами эти рекомендации просто вредны.
Неужели не придумали ничего лучше на тему, как проектировать качественные программы?
Здравствуйте, HrorH, Вы писали:
HH>Неужели не придумали ничего лучше на тему, как проектировать качественные программы?
Это извечная проблема теории и практики -- в книжках/учебниках все хорошо, а
на практике все гораздо сложнее. Тут многое приходит с опытом, с набиванием шишек,
с рефлексией, т.е. отдавать отчет и осмысливать свои действия. Научиться грамотно
проектировать ПО по книгам вряд ли удастся, к этому надо годами идти и не факт,
что придешь. А так, все вышеперечисленные аббревиатуры и методологии это всего лишь
некий набор рекомендаций, общих решений, знать и понимать которые крайне желательно, но
еще лучше понимать границы их применимости, т.е. опять же практика.
Здравствуйте, HrorH, Вы писали:
HH>Неужели не придумали ничего лучше на тему, как проектировать качественные программы?
Придумали. Думать своей головой, а не копировать бездумно прочитанное в книжках.
То, что в книжках — это так, для вдохновения.
Посмотреть как люди уже решили какие-то задачи и на какие грабли наткнулись.
Здравствуйте, Sharov, Вы писали:
S>Это извечная проблема теории и практики -- в книжках/учебниках все хорошо, а S>на практике все гораздо сложнее. Тут многое приходит с опытом, с набиванием шишек, S>с рефлексией, т.е. отдавать отчет и осмысливать свои действия. Научиться грамотно S>проектировать ПО по книгам вряд ли удастся, к этому надо годами идти и не факт, S>что придешь. А так, все вышеперечисленные аббревиатуры и методологии это всего лишь S>некий набор рекомендаций, общих решений, знать и понимать которые крайне желательно, но S>еще лучше понимать границы их применимости, т.е. опять же практика.
Понятно, что практику никто не отменяет.
Но то что в книжках "все хорошо", это неправда. В лучшем случае в них кое что хорошо.
Поэтому и спрашиваю, может чего-то другое кто-то знает приличное, кроме книг означенных авторов?
Здравствуйте, HrorH, Вы писали:
HH>GoF, SOLID Мартина, GRASP Лармана, Шаблоны корпоративных приложений Фаулера. HH>Ведь если честно все это ужасно, не хватает четкости мышления, систематичности, ясности, местами эти рекомендации просто вредны.
Кому не хватает четкости мышления и остального перечисленного?
HH>Неужели не придумали ничего лучше на тему, как проектировать качественные программы?
Светлая голова, прямые руки и 10+ лет опыта.
Здравствуйте, vmpire, Вы писали:
V>Придумали. Думать своей головой, а не копировать бездумно прочитанное в книжках.
V>То, что в книжках — это так, для вдохновения. V>Посмотреть как люди уже решили какие-то задачи и на какие грабли наткнулись.
Спасибо, КО.
Для вдохновения хочется чего-то более приличного...
HH>Понятно, что практику никто не отменяет. HH>Но то что в книжках "все хорошо", это неправда. В лучшем случае в них кое что хорошо. HH>Поэтому и спрашиваю, может чего-то другое кто-то знает приличное, кроме книг означенных авторов?
Я про контекст, а не про содержание. Рассматриваются типовые примеры, и как правило, не очень
сложные и не очень жизненные.
Здравствуйте, HrorH, Вы писали:
HH>GoF, SOLID Мартина, GRASP Лармана, Шаблоны корпоративных приложений Фаулера. HH>Ведь если честно все это ужасно, не хватает четкости мышления, систематичности, ясности, местами эти рекомендации просто вредны.
Обычно, чёткости мышления не хватает тому, кто начиташись этих книг бежит пременять везед где это не нужно. А так, солди, грасп(Ларман божественнен, имхо), гоф вполне решают те проблемы, которые описаны в паттёрнах. HH>Неужели не придумали ничего лучше на тему, как проектировать качественные программы?
Ну... есть визуальные языки для спец задач. Попробуй испоьлзовать их.
Если наш исходный алгоритм занимал сотню простых и понятных строк, то теперь [соблюдая SRP] мы получим в сумме три, четыре, может быть, пять сотен строк, разнесённых по разным модулям.
Будет ли полученная выгода адекватна усложнению? Ответ очевиден.
наверное раз исходные строки названы "понятными" — в SRP получатся непонятные строки? всякие там "class Foo {" — так непонятно.
ну и тестируемость/удобство внесения изменений это конечно незначительная выгода
Здравствуйте, HrorH, Вы писали:
HH>GoF, SOLID Мартина, GRASP Лармана, Шаблоны корпоративных приложений Фаулера. HH>Ведь если честно все это ужасно, не хватает четкости мышления, систематичности, ясности, местами эти рекомендации просто вредны. HH>Неужели не придумали ничего лучше на тему, как проектировать качественные программы?
Книга Сергея Тарасова "Дефрагментация мозга. Софтостроение изнутри" не даёт особых надежд на это, но какие-то мысли всё-таки пробиваются.
Интересно, а как помогает ТРИЗ и теория систем? Есть какие-нибудь примеры, что какая-то идея из ТРИЗ реально помогла?
Слишком много там все-таки завязано на физику.
А по теории систем что можно почитать?
В основном, то что я читал, это были достаточно общие слова, которые очень сложно увязать с программированием.
Здравствуйте, Sharov, Вы писали:
S>Это извечная проблема теории и практики -- в книжках/учебниках все хорошо, а S>на практике все гораздо сложнее.
Это книги прежде всего написаны исходя из практического опыта при этом людьми с ~20+ лет опыта промышленного программирования. Ну и да — только дураки учатся только на своих ошибках.
Здравствуйте, IncremenTop, Вы писали:
IT>Здравствуйте, Sharov, Вы писали:
S>>Это извечная проблема теории и практики -- в книжках/учебниках все хорошо, а S>>на практике все гораздо сложнее.
IT>Это книги прежде всего написаны исходя из практического опыта при этом людьми с ~20+ лет опыта промышленного программирования. Ну и да — только дураки учатся только на своих ошибках.
Я бы не стал так высоко ценить навыки людей и качество книг.
Во-первых, кроме банды четырех, мало кто занимался научной деятельностью в этом направлении. Большая часть книг это компиляция где-то услышанного, где-то увиденного, где-то просто придуманного.
Во-вторых, паттерны не универсальны. Они сильно зависят от языка, фреймворка, типа приложения и конкретных требований. Эта часть в книгах идет обычно в начала и очень небольшого объема, зачастую читающим просто не усваивается.
В-третьих книги по принципам\паттернам пишутся на основе прошлого опыта и, часто бывает, что отстает на 3-5-7 лет от уровня зрелости индустрии в целом. Кроме того опыт может оказаться просто нерелевантным с учетом новых технологий. Например Linq в C# сделал бесполезным 60% книги фаулера АКПП, а mvc и razor сделал бесполезным еще 20%.
12/27/2013 9:10 AM, HrorH пишет:
> Интересно, а как помогает ТРИЗ и теория систем? Есть какие-нибудь > примеры, что какая-то идея из ТРИЗ реально помогла?
Есть, помогла бывшему совладельцу Научсофта и фанату ТРИЗа в Минске
заработать денег.
Здравствуйте, gandjustas, Вы писали:
G>Во-первых, кроме банды четырех, мало кто занимался научной деятельностью в этом направлении. Большая часть книг это компиляция где-то услышанного, где-то увиденного, где-то просто придуманного.
Если понимать под научной деятельностью исключительно сидение на должности в вузе — то да. Большая часть книг — это синтез практики и теории. Например, Рефакторинг Ф. закономерно опирается на диссеры Опдайка и Робертса, хотя из указанных выше наименее наукообразен.
ИТ переживает такой период, когда многим выгоднее заниматься наукой на "практике".
G>Во-вторых, паттерны не универсальны. Они сильно зависят от языка, фреймворка, типа приложения и конкретных требований. Эта часть в книгах идет обычно в начала и очень небольшого объема, зачастую читающим просто не усваивается.
Если читающий не болеет чукчизмом, то он без труда заметит, что в книгах говорится и об ограничениях, и о том, что примеры являются прежде всего примерами, а не руководством к действию. Но ведь большинство бежит на форум жаловаться на неправильные книги и концепции(!). Наверное, надо это писать очень крупными буквами.
G>В-третьих книги по принципам\паттернам пишутся на основе прошлого опыта и, часто бывает, что отстает на 3-5-7 лет от уровня зрелости индустрии в целом.
Эту индустрию во многом подобные товарищи двигают. Ну и не стоит забывать об актуализации знаний — не только об указанных выше товарищах, хотя и они многие тенденции подмечают и указывают.
Здравствуйте, HrorH, Вы писали:
HH>Интересно, а как помогает ТРИЗ и теория систем? Есть какие-нибудь примеры, что какая-то идея из ТРИЗ реально помогла?
Классическая ТРИЗ действительно предназначена для решения другого класса задач. Это задачи "железячные", связанные с прогнозированием и развитием материальных технических систем. Прямое применение ТРИЗ в программировании невозможно. Знание ТРИЗ лишь поможет подойти к проектированию программных систем более осознанно, т.к. ТРИЗ помогает, что называется, поставить системное мышление.
HH>А по теории систем что можно почитать?
IT>Это книги прежде всего написаны исходя из практического опыта при этом людьми с ~20+ лет опыта промышленного программирования. Ну и да — только дураки учатся только на своих ошибках.
Полностью согласен. Но, во-первых, эти книги написаны опытными разработчиками для неопытных,
во-вторых, двадцатилетний опыт просто так в книгу не запихнешь. Некие общие эвристики, рекомендации и т.п.
А вообще, ради мысленного эксперимента замените "проектировать качественные программы" на "рисовать".
И посмотрите, можно ли научиться рисовать, прочитав множество книжек, изучив (по книгам) множество техник,
но так и не пробуя рисовать, набивать руку?
Если нам не помогут, то мы тоже никого не пощадим.
