Как получить теоретические знания, чтобы иметь возможность описывать то, что я реализую на практике?

Question

[Max Payne]

И так, проблема следующая: я реализовываю некоторый функционал, программы и понимаю что делаю и зачем, как это работает, но у меня абсолютно отсутствуют теоретические знания о том, что я сделал. Допустим, читая о паттернах проектирования, допустим, читая про паттерны проектирования я понимаю - в том функционале я реализовал фабричный метод, в другом шаблонный метод, а в третьем паттерн "состояние", но в момент, когда я пишу код — я абсолютно не думаю об этом, в ООП я абсолютно не думаю о том, что там у меня инкапсуляция, а там наследование — это реализовывается само собой. Но, например, на собеседованиях, когда дяди или тети-hr спрашивают про структуру, про архитектуру — я подсознательно понимаю, что они хотят услышать именно вот эту теорию, что там-то я использовал то-то, а там то-то. Но даже прочитав достаточно много на refactoring.guru — это не даёт именно теоретических результатов, то есть на практике, подсознательно я продолжаю выбирать именно "правильные" подходы, но как они называются и в чём вообще заключается их "правильное" описание понятия не имею.

Как быть?

Comments

[Максим Федоров]

это реализовывается само собой

То есть вам бессмысленно что-либо объяснять, "само собой" -- универсальный рецепт общения с вами, ну такое себе общение.

Фразы, слова, предложения, термины -- придуманы для транспорта смысла. Если не видите смысла, вам его не передать и от вас не получить.

[Евгений Ромашкан]

Читать книги а не хватать информацию урывками в интернете, тогда научитесь чему-нибудь

[Max Payne]

Евгений Ромашкан, в ответе можно написать какие конкретно стоит почитать, это будет хороший ответ.

[Max Payne]

Максим Федоров, а чему из этих двух предложенных пунктов вы МОЖЕТЕ научить?
Личностные оценки автора вопроса в комментариях – не очень ок.

[Максим Федоров]

Max Payne,

Личностные оценки автора

Ну поплескался желчью на 11 раз "я" в тексте, тоже иногда нужно :--)
Удалил личностные выпады, вы правы

[Евгений Ромашкан]

Max Payne, Ок, если интересно, накидаю ответ через пару часиков

Answer 1

[Евгений Ромашкан]

Итак,

какие конкретно стоит почитать

1. Макконнелл, "Совершенный код". Объемная но не особо сложная книжка, можно прочитать не особо то за большее время чем такую-же книжку из художественной лит-ры.
2. Роберт Мартин, Идеальный программист. Есть ещё "Программист прагматик", вроде тоже о чем то подобном. Книжка небольшая, в принципе можно за пару тройку недель прочитать рассуждения Дяди Боба о работе программиста.
3 Роберт Мартин, Чистый Код. Весьма хорошая книжка, очень широко затрагивает тему написания поддерживаемого кода. Важно - особенно в этой книге, но так же и в любой другой - не зацикливайтесь на догмах аля "3 строчки на функцию", не обожествляйте SOLID, а рассматривайте, какие проблемы решают предложенные решения. Советую в каждом случае рассуждать о том, как описываемые вещи влияют на качество кода и архитектуры программы.
4. Роберт Мартин, Чистая Архитектура - относительно новая книжка о том, что всё новое это хорошо забытое старое. Возможно вещи описываются немножко поверхностно, впрочем, углубляться в любом случае нужно самому. Книжка годная, получше объясняет SOLID, затрагивает другие принципы, затрагивает парадигмы, принципы дизайна, архитектуру, объясняет почему то, что многие горе-разработчики нынче зовут ООП им не является. Думаю эту книжку можно даже перенести на первое место.
Дальше уж по ситуации - паттерны GoF, PoEAA, Рефакторинг Фаулера, Кента Бека про тестирование etc.

подсознательно я продолжаю выбирать именно "правильные" подходы,

Боюсь, что вы просто используете те подходы что знаете, а не выбираете исходя из требований и ситуации.
Хотя бы потому что "правильных" подходов не бывает, есть подходящие в данной ситуации, и плохо подходящие, компромиссные и откровенно вредные.

наследование — это реализовывается само собой.

Вот эта фраза явно даёт понять что у вас есть проблемы в дизайне. Наследование это весьма опасная штука, и делать его просто потому что показалось удобным, не задумываясь об LSP, контрактах и инвариантах.. Кхм.. Плохо.

Упомяну один момент: статейки в интернете и даже(о боги) на всеми нами любимом хабре или тостере, как и любые другие источники информации, книги и доклады любимых нами авторов представляют исключительно субъективное мнение автора, и лишь его понимание описываемой темы, сформировавшееся в силу, обычно, неизвестных нам обстоятельств. Они могут нести за собой скрытую сложность, абсолютно не подходить в ситуациях отличных от ситуации автора, и никогда не стоит принимать из за единственно-верную истину. Скорее, за пищу для размышлений и альтернативные подходы к какому-либо делу.

Answer 2

[Saboteur]

И так, проблема следующая: я реализовываю некоторый функционал, программы и понимаю что делаю и зачем, как это работает, но у меня абсолютно отсутствуют теоретические знания о том, что я сделал.

Нет, у вас теоретические знания присутствуют, но отсутствует понимание терминологии.
Если у вас уже есть практика, можно почитать теорию, чтобы понять как называется то, что вы делаете.

Но на самом деле, есть подозрение, что вам просто не хватает эрудиции, чтобы внятно излагать свои мысли. Потому что эрудированный человек может объяснить свои действия и терминами и без терминов (но дольше).

Попробуйте предположить, что у вас есть ученик, который не знает простейщих вещей, и вы для него пишете документацию.
Напишите одну документацию по вашей программе (не для юзера, а для программиста), детальную, художественную. Исправьте ее, улучшите ее. Чтобы это было хотя бы страниц 5-10 текста.
После нескольких итераций, когда вы посчитаете, что ее можно дать почитать новичку, возьмите знакомого и почитайте с ним.
После этого еще пару раз исправьте.

На этом у вас должны появиться навыки пояснения того, что вы делаете.

Comments

[Max Payne]

У меня уже был один раз большой опыт написания работы на страниц 30 по одной из моих программ, но по прошествии уже значительного количества времени я понимаю, что это было скорее объяснение на пальцах и демонстрация как это работает. Может быть потому, что она предназначалась для людей, не особо углубленных в программирование.

Сейчас, понимая это, хочется обрести чуть большее понимание чокудаикак, теоретического процесса что-ли.

[Saboteur]

Max Payne, в том и суть. Напишите для полного новичка, чтобы вам пришлось на низком уровне пояснять все и что такое цикл и так далее.
И суть в том, что не просто написать, а несколько раз "оптимизировать", а потом еще раз "оптимизировать" после того, как ваш документ почитает знакомый и вы поймете как ваш документ видит он (незамыленным глазом автора).