С моей точки зрения, способность дизайна сложнее получить, чем навыки разработки/кодирования.
Когда вы сталкиваетесь с требованием, как создавать функциональные модули, как правильно построить архитектуру программы?
Кстати, существуют ли какие-то книги?
Я думаю, что ответ заключается в том, что большинство посредственных программистов часто не делают: читайте код других людей и учитесь на нем, анализируйте его сильные и слабые стороны, а также включайте в свои собственные трюки для программ, что вы видите интересным. Есть много хороших техник, которые уже придуманы, наделит ваши навыки кодирования и сэкономит вам много времени.
В проектах с открытым исходным кодом есть много высококачественных кодов.
Я думаю, все сводится к опыту. Возможность чтения набора требований и перевода их в хороший, чистый, поддерживаемый программный дизайн является одной из самых сложных в программировании (imho), и вы не узнаете, что просто прочитав книгу. Это о попытках, ошибках, обучении от этих ошибок и изучении того, какие проекты работали для вас в прошлом или нет.
Для меня это часто помогает действительно потратить время и создать хороший дизайн в UML, например диаграмму классов. Это часто помогает мне идентифицировать и компоненты, которые я могу повторно использовать во всем программном приложении, где я могу использовать определенный шаблон дизайна и т.д.
Несколько книг, которые я могу порекомендовать: Архитектура программного обеспечения на практике, которая является очень хорошей книгой о архитектуре программного обеспечения и Design Patterns от Gang of Four, что является отличной ссылкой для любых шаблонов дизайна, которые вы могли бы использовать.
Вместо того, чтобы говорить "проб и ошибок", скажем, "итерация".
Независимо от того, что вы разрабатываете, просто дайте ему лучший результат с информацией, которую вы знаете, зная, что у вас нет полных знаний. Тогда вы, несомненно, столкнетесь с непредвиденным вопросом, который усложняет ситуацию. Это когда вы должны спросить себя, что пошло не так, и что делать по-другому. Затем вернитесь назад и перепроектируйте/переопределите свое новое понимание. Повторение. Всегда будьте вторым, догадываясь о своем дизайне и оглядываясь вокруг, чтобы получить лучшие решения. Например, "Как реализуется Firefox?" О, я вижу, они не используют всплывающее окно и его намного более чистое ".
Принимая тот факт, что вы допустите ошибки и захотите их исправить, вы уже опережаете пакет.
По мере того, как вы приобретаете опыт, вы повторяете итерации, и время от времени вы будете правы в первый раз - без сомнения, потому что вы можете предвидеть ошибки и их решение из прошлого.
Что касается книг, если я правильно помню, "Inside Steve Brain" говорил о том, как итерация является неотъемлемой частью развития Apple.
Испытание и ошибка - лучший способ увидеть, как ваши собственные проекты могут улучшиться. Всегда ищите лучшее решение. Какие ошибки вы сделали? Какая часть была менее гибкой, чем нужно? Что заставило вас взломать дизайнерское решение, которое вы сделали?
Подумайте о последствиях дизайна, а не о его гибкости и элегантности. Какие компромиссы вы сделали, чтобы сделать это многоразовым? Вы следите за разделение проблем и принцип единой ответственности? Открыть закрытый принцип? Знаете ли вы, что это такое и их последствия?
Также изучите работу экспертов в форме шаблонов проектирования.
Прочитайте Шаблоны проектирования, объясненные Shalloway, прочитайте Начните первый проект шаблоны
Однако помните, что это не волшебные пулевые решения, и все берет с собой. Используйте свое собственное творчество и STAY PRAGMATIC.
Я не верю, что есть замена опыта и таланта, и я никогда не читал книгу о разработке программного обеспечения, которую я мог бы рекомендовать с точки зрения дизайна обучения, несмотря на то, что прочитал немало. Некоторые люди хороши в этом, и становятся лучше, когда они набирают опыт, а некоторые - нет и никогда не учатся. Печально, но верно.
Я думаю, глядя на дизайн некоторых прекрасных проектов с открытым исходным кодом. Изучение кода и поиск дизайна проектов с открытым исходным кодом - лучший способ обучения, на мой взгляд.
Я согласен с большинством предложений до сих пор, все они действительны - читайте код, читайте книги, пробуйте вещи.
Где я видел наибольшую прибыль, как лично, так и в команде - это двукратная атака: 1. Вытащите их из своей зоны комфорта, то есть незнакомого домена или языка, заберите костыли. 2. И, возможно, что более важно, соединить их с тем, кто уже пережил.
У Mentoring есть что предложить, вы можете добраться туда сами, но хороший наставник может сэкономить вам годы боли.
Конечно, опыт - это правильный ответ. Но помимо этого я думаю, что есть что-то, что нужно сказать для понимания моделей в вашем собственном контексте: по мере того, как вы создаете свои приложения, принимайте конструктивные решения, которые придают вам прагматичный смысл. Разумеется, не делайте их, потому что это "лучшая практика", или потому, что вам сказал более опытный программист. Сделайте их, потому что вы понимаете, почему, и это помогает вам (или другим программистам) работать с кодом и лучше понимать его. Я нахожу то же самое с вещами, как дизайн базы данных. Делайте то, что имеет смысл с интуитивной, поддерживающей точки зрения. 7 раз из 8, если вы действительно продумали это (или узнали из разных подводных камней), вы обнаружите, что вы автоматически выполняете какой-либо класс "шаблонов" или практикуете, не предпринимая активных попыток.
Конечно, я не предлагаю, чтобы кто-нибудь работал в вакууме; и что они не активно преследуют и интегрируют шаблоны проектирования, как само собой разумеющееся. Я просто думаю, что понимание их в вашем собственном контексте (и по конкретным, практическим причинам) помогает наиболее демистифицировать вещь. Во всяком случае, это был мой опыт. Книги для чтения всегда кажутся мне учебными. Хороший полезный материал, но маленький картофель рядом с тем, чтобы попасть в отстой. Подумайте о своих решениях и сможете их защищать. Всегда будьте открыты для лучшего способа.