Почему ООП-программированию я могу научиться, сидя дома с книгами и программируя, а в случае системной инженерии мне необходимы тренинги (по словам ведущих курсы людей)?
Есть небольшая разница между «понять, что такое ООП» и «научиться здраво применять ООП в своём коде». Например, выделяют набор т. н. паттернов проектирования, которые (в контексте ООП) представляют собой типичные и хорошо работающие решения конкретных задач организации кода получше. Их придумали люди, и часто они приходят на ум самостоятельно, но чтобы пришли вовремя сразу все — маловероятно. Это как раз кусок того, что некоторые назовут «системным подходом».
Но я не думаю, что книги по теории систем способны выработать соответствующую интуицию, если её ещё не появилось, и уж тем более они не способны* показать арсенал конкретных приёмов в конкретных областях деятельности, на которых и стоит интуиция и вот это вот самое.
* Потому что пропоненты «теории систем» и определяют её как нечто общее из всех областей. Чего, на самом деле, можно выписать пару страниц, а дальше ничего полезного без снижения уровня общности, ради высоты которого они всё и затеяли, не будет. Человек учится на примерах, абстракции вперёд примеров практически никогда не приносят пользы.
Замечания:
1. Конечно, нет единой универсальной конкретной штуки под названием ООП, у каждого языка программирования конкретная реализация обычно немного своя. В современных языках к классической схеме ООП примыкает много других полезных вещей, влияющих в том числе на практически полезный набор паттернов — одни оказываются ненужными, другие немного модифицируются, возникают новые третьи.
2. То, что некоторые называют альтернативами ООП, тоже, конечно, довольно разнообразно (мультиметоды, опять же, в разных языках немного свои, бывают type classes как в хаскеле (что, по-моему, можно звать в каком-то смысле прямым апгрейдом). И не все из перечисляемых в этом контексте идей прям несочетаемы с идеями ООП. Это к тому, что не надо, увидев критику чего-то, сразу решать, что это, видимо, когда-нибудь уйдёт на свалку — нет, обычно хорошее никуда не девается, просто неудачные части заменяются со временем лучшими.
-- Ср мар 21, 2018 23:49:08 --То это НЛП - нейролингвистическое программирование, или говоря проще вас зомбируют.
НЛП не работает вроде как. Это распиаренная аббревиатура, не более.
-- Ср мар 21, 2018 23:54:54 --Я тоже со стороны IT отчасти интересуюсь. Как создавать архитектуру системы, как её проектировать, как заложить в архитектуру то, что требования могут меняться со временем и т.д.
Итого, рецепт (если это можно назвать рецептом) уже сформулирован:
rockclimber предлагает искать в первую очередь наиболее специфические источники (не обязательно книги, часто это отдельные посты там и сям), ну и общий совет думать перед тем, как делать, лучше с бумажкой и каким-нибудь человеком наполовину в теме, который (вместе с вами — можно и без него, но это хуже) будет спрашивать у вас глупые, но иногда неожиданные вопросы о том, что штука может и должна делать, как она может это делать, какие вещи хороши и какие плохи, что расширяемо, а чему не надо быть таким, чем можно пожертвовать, и о чём не нужно думать прямо сейчас. Третий компонент — уже имеющийся опыт, тут уже ничем конкретным помочь нельзя — только время, задачи и некоторая доля фортуны.
-- Чт мар 22, 2018 00:03:43 --На универсальный совет разве что претендует «старайся меньше делать». Чем больше кода, тем больше с ним возни (как просто чтобы написать, так и в будущем); чем больше зависимостей, тем больше с ними возни (но нельзя их избегать, если альтернатива — велосипед); про преждевременную оптимизацию вы наверняка тоже знаете. Часто бывает хорошо разрабатывать систему так, чтобы разница между соседними рабочими (без очевидных ошибок, в том числе компилирующиеся) версиями была поменьше — начинать со штуки, которая почти ничего не делает, и добавлять по детали (не обязательно конкретной — скажем, сначала добавить блок предоставления глобальных настроек всему остальному коду, сохраняющий и загружающий их вовремя, но ненастоящий — не делающий последнего, а выдающий поначалу константы, и не имеющий конкретных настроек кроме, быть может, одной; потом можно доводить его по частям до ума; вот первый коммит будет большой, следующие с конкретными изменениями будут мельче).
На эти темы, впрочем, как указано выше, есть специализированные посты. И универсальных рецептов, не зависящих от того, что вам предстоит, обычно нет, с этим надо смириться ради светлого будущего сразу.
Это слишком просто. Вот атомная станция...