In my point of view, design ability is harder to get than development/coding skills.
在我看来,设计能力比开发/编码技能更难获得。
When confronting a requirement , how to design the function modules, how to construct the program architecture properly?
在面对需求时,如何设计功能模块,如何正确构建程序架构?
By the way, are there some books related?
顺便问一下,有些书有关系吗?
8 个解决方案
#1
I think the answer is what most mediocre programmers often don't do: read other people's code and learn from it, analyze its strengths and weaknesses, and also incorporate in your own programming tricks bag what you see interesting. There are many good techniques that are already invented, will empower your coding skills and save you lots of time.
我认为答案是大多数平庸的程序员经常不做的事情:阅读其他人的代码并从中学习,分析它的优点和缺点,并在你自己的编程技巧中加入你看到的有趣内容。有许多已经发明的好技术,可以增强您的编码技能并节省大量时间。
There are many high quality code out there in open source projects to research.
在开源项目中有许多高质量的代码用于研究。
#2
I think it all comes down to experience. Being able to read a set of requirements and translate them into a good, clean, maintainable software design is one of the hardest thing in programming (imho) and you do not learn that just by reading a book. It's about trying, making mistakes, learning from those mistakes, and learning what designs have worked for you in the past or haven't.
我认为这一切都取决于经验。能够阅读一系列要求并将其转换为良好,干净,可维护的软件设计是编程中最困难的事情之一(imho),而您只是通过阅读书籍才能学到这一点。这是关于尝试,犯错误,从错误中吸取教训,以及了解过去曾经为您设计过的设计,或者没有。
For me, it often helps to really take my time and create a good design in UML, for example a class diagram. It often helps me identify and components that I can reuse throughout the software application, where I can use a certain design pattern, etcetera.
对我来说,通常需要花时间在UML中创建一个好的设计,例如类图。它通常可以帮助我识别和组件,我可以在整个软件应用程序中重复使用,我可以使用某种设计模式等等。
A few books I can recommend: Software Architecture in Practice, which is a very good book about software architecture, and Design Patterns by the Gang of Four, which is a great reference for any design patterns you might use.
我可以推荐一些书:实践中的软件架构,这是一本关于软件架构的非常好的书,以及Gang of Four的设计模式,它是您可能使用的任何设计模式的绝佳参考。
#3
Instead of saying "trial and error", let's say "iteration".
我们不是说“试错”,而是说“迭代”。
Whatever you're designing, just give it your best shot with the information you have, knowing you don't have complete knowledge. Then you will undoubtedly run into an unforeseen issue that complicates things. This is when you have to ask yourself what went wrong and what to do differently. Then go back and redesign/reimplement with your new understanding. Repeat. Always be second guessing your design and be looking around you for better solutions. For example, "How does Firefox implement find? Oh, I see, they don't use a popup window, and its much cleaner."
无论您正在设计什么,只要知道您没有完整的知识,就可以使用您拥有的信息尽情享受。那么你无疑会遇到一个使事情复杂化的无法预料的问题。这是你必须问自己出了什么问题以及做些什么不同的事情。然后返回并重新设计/重新实现您的新理解。重复。永远是第二次猜测你的设计,并寻找更好的解决方案。例如,“Firefox如何实现查找?哦,我知道,他们不使用弹出窗口,而且它更干净。”
By accepting the fact that you will make mistakes and are willing to fix them, you're already way ahead of the pack.
通过接受你会犯错误并愿意修复它们的事实,你已经领先于其他人。
As you gain experience, you're iterations will become longer, and once in a while you'll get things right the first time -- no doubt because you can foresee mistakes and their solution from the past.
当你获得经验时,你的迭代会变得更长,偶尔你会在第一时间把事情弄清楚 - 毫无疑问,因为你可以预见错误和他们过去的解决方案。
As far as books are concerned, if I remember correctly, "Inside Steve's Brain" talked about how iteration is intrinsic to Apple's development.
就书籍而言,如果我没记错的话,“Inside Steve's Brain”谈到迭代是苹果公司发展所固有的。
#4
Trial and error is the best way to see how your own designs can improve. Always look for a better solution. What mistakes did you make? What part was less flexible than it needed to be? What caused you to have to hack around a design decision you made?
试用和错误是了解您自己的设计如何改进的最佳方式。一直在寻找更好的解决方案。你犯了什么错误?哪个部分不够灵活?是什么导致你不得不围绕你做出的设计决定?
Think about the implications of the design rather than purely it's flexibility and elegance. What trade offs have you made in order to make this reusable? Are you following the seperation of concerns and the single responsibility principle? Open closed principle? Do you know what these are and their implications?
想想设计的含义,而不仅仅是它的灵活性和优雅。为了使这种可重复使用,您做了哪些权衡?您是否遵循关注点和单一责任原则?开放封闭原则?你知道这些是什么及其影响吗?
Also study the work of experts in the form of design patterns.
还以设计模式的形式研究专家的工作。
Read Design Patterns Explained by Shalloway, Read Head first design patterns
阅读设计模式由Shalloway解释,阅读首先设计模式
However remember that these aren't magic bullet solutions and take everything with a pinch of salt. Use your own creativity and STAY PRAGMATIC.
但是请记住,这些不是魔术子弹解决方案,只需要少量盐就可以了。使用自己的创造力和STAY PRAGMATIC。
#5
I don't believe there is any substitute for experience and talent, and I've never read a book on software design that I could recommend from the point of view of teaching design, despite having read quite a few. Some people are good at it, and get better as they gain experience, and some are not, and never seem to learn. Sad, but true.
我不相信有任何经验和才能的替代品,我从来没有读过一本关于软件设计的书,我从教学设计的角度推荐,尽管已经阅读了不少。有些人擅长它,并且随着他们获得经验而变得更好,而有些人则没有,也似乎从未学习过。伤心,但也是如此。
#6
I think by looking the design of some great open source projects available .Reading the Code and looking the design of opensource projects is the best way of learning designing in my opinion.
我认为通过查看一些优秀的开源项目的设计。在我看来,阅读代码并查看开源项目的设计是学习设计的最佳方式。
#7
I agree with most suggestions so far, they are all valid - read code, read books, try stuff.
我同意到目前为止的大多数建议,它们都是有效的 - 阅读代码,阅读书籍,尝试一些东西。
Where I have seen the biggest gains, both personally and in team members is a two-fold attack: 1. Get them out of their comfort zone - i.e. an unfamiliar domain or language, take away the crutches. 2. And, probably more importantly, pair them with someone who is already experienced.
我已经看到了最大的收获,个人和团队成员都是双重攻击:1。让他们离开他们的舒适区 - 即一个不熟悉的领域或语言,带走拐杖。而且,更重要的是,可以将他们与已经有经验的人配对。
Mentoring has a lot to offer, you can get there yourself, but a good mentor can save you years of pain.
指导有很多东西,你可以自己去那里,但一个好的导师可以为你节省多年的痛苦。
#8
Certainly, experience is the right answer. But beyond that, I think there's something to be said for understanding patterns in your own context: As you're building your applications, make design decisions that make pragmatic sense to you. To wit, don't do them because it's 'best practice', or because a more experienced programmer told you to. Do them because you understand the Why and it helps you (or other programmers) work with the code and understand it better. I find the same is true with things like database design. Do what makes sense from an intuitive, maintenance standpoint. 7 times out of 8, if you've really thought it through (or learned from various pitfalls), you'll find you're automatically doing some class of 'pattern' or practice without actively trying to.
当然,经验是正确的答案。但除此之外,我认为在您自己的环境中理解模式还有一些事项要做:在构建应用程序时,做出对您有实际意义的设计决策。也就是说,不要这样做,因为这是“最佳实践”,或者是因为一位经验丰富的程序员告诉你的。做它们是因为你理解了为什么它可以帮助你(或其他程序员)使用代码并更好地理解它。我发现数据库设计之类的东西也是如此。从直观的维护角度做有意义的事情。 8次中有7次,如果你真的想过它(或者从各种陷阱中学到的东西),你会发现你自动做了一些“模式”或练习而没有积极尝试。
Of course, I'm not suggesting anyone work in a vacuum; nor that they don't actively pursue and integrate design patterns as a matter of course. I just think that understanding them in your own context (and for specific, practical reasons) is what helps the most to demystify the thing. That's been my experience, anyway. Reading books always feels like learning-lite to me. Good helpful stuff, but small potatoes next to getting in the slop. Think your decisions through and be able to defend them. Always be open to a better way.
当然,我并不是说任何人都在真空中工作;当然,他们也没有积极地追求和整合设计模式。我只是认为在你自己的背景下理解它们(并且出于特定的,实际的原因)是最有助于揭开神秘面纱的东西。无论如何,那是我的经历。阅读书籍对我来说总是像学习一样。好有用的东西,但小土豆旁边进入斜坡。通过思考你的决定,并能够为他们辩护。始终以更好的方式开放。
#1
I think the answer is what most mediocre programmers often don't do: read other people's code and learn from it, analyze its strengths and weaknesses, and also incorporate in your own programming tricks bag what you see interesting. There are many good techniques that are already invented, will empower your coding skills and save you lots of time.
我认为答案是大多数平庸的程序员经常不做的事情:阅读其他人的代码并从中学习,分析它的优点和缺点,并在你自己的编程技巧中加入你看到的有趣内容。有许多已经发明的好技术,可以增强您的编码技能并节省大量时间。
There are many high quality code out there in open source projects to research.
在开源项目中有许多高质量的代码用于研究。
#2
I think it all comes down to experience. Being able to read a set of requirements and translate them into a good, clean, maintainable software design is one of the hardest thing in programming (imho) and you do not learn that just by reading a book. It's about trying, making mistakes, learning from those mistakes, and learning what designs have worked for you in the past or haven't.
我认为这一切都取决于经验。能够阅读一系列要求并将其转换为良好,干净,可维护的软件设计是编程中最困难的事情之一(imho),而您只是通过阅读书籍才能学到这一点。这是关于尝试,犯错误,从错误中吸取教训,以及了解过去曾经为您设计过的设计,或者没有。
For me, it often helps to really take my time and create a good design in UML, for example a class diagram. It often helps me identify and components that I can reuse throughout the software application, where I can use a certain design pattern, etcetera.
对我来说,通常需要花时间在UML中创建一个好的设计,例如类图。它通常可以帮助我识别和组件,我可以在整个软件应用程序中重复使用,我可以使用某种设计模式等等。
A few books I can recommend: Software Architecture in Practice, which is a very good book about software architecture, and Design Patterns by the Gang of Four, which is a great reference for any design patterns you might use.
我可以推荐一些书:实践中的软件架构,这是一本关于软件架构的非常好的书,以及Gang of Four的设计模式,它是您可能使用的任何设计模式的绝佳参考。
#3
Instead of saying "trial and error", let's say "iteration".
我们不是说“试错”,而是说“迭代”。
Whatever you're designing, just give it your best shot with the information you have, knowing you don't have complete knowledge. Then you will undoubtedly run into an unforeseen issue that complicates things. This is when you have to ask yourself what went wrong and what to do differently. Then go back and redesign/reimplement with your new understanding. Repeat. Always be second guessing your design and be looking around you for better solutions. For example, "How does Firefox implement find? Oh, I see, they don't use a popup window, and its much cleaner."
无论您正在设计什么,只要知道您没有完整的知识,就可以使用您拥有的信息尽情享受。那么你无疑会遇到一个使事情复杂化的无法预料的问题。这是你必须问自己出了什么问题以及做些什么不同的事情。然后返回并重新设计/重新实现您的新理解。重复。永远是第二次猜测你的设计,并寻找更好的解决方案。例如,“Firefox如何实现查找?哦,我知道,他们不使用弹出窗口,而且它更干净。”
By accepting the fact that you will make mistakes and are willing to fix them, you're already way ahead of the pack.
通过接受你会犯错误并愿意修复它们的事实,你已经领先于其他人。
As you gain experience, you're iterations will become longer, and once in a while you'll get things right the first time -- no doubt because you can foresee mistakes and their solution from the past.
当你获得经验时,你的迭代会变得更长,偶尔你会在第一时间把事情弄清楚 - 毫无疑问,因为你可以预见错误和他们过去的解决方案。
As far as books are concerned, if I remember correctly, "Inside Steve's Brain" talked about how iteration is intrinsic to Apple's development.
就书籍而言,如果我没记错的话,“Inside Steve's Brain”谈到迭代是苹果公司发展所固有的。
#4
Trial and error is the best way to see how your own designs can improve. Always look for a better solution. What mistakes did you make? What part was less flexible than it needed to be? What caused you to have to hack around a design decision you made?
试用和错误是了解您自己的设计如何改进的最佳方式。一直在寻找更好的解决方案。你犯了什么错误?哪个部分不够灵活?是什么导致你不得不围绕你做出的设计决定?
Think about the implications of the design rather than purely it's flexibility and elegance. What trade offs have you made in order to make this reusable? Are you following the seperation of concerns and the single responsibility principle? Open closed principle? Do you know what these are and their implications?
想想设计的含义,而不仅仅是它的灵活性和优雅。为了使这种可重复使用,您做了哪些权衡?您是否遵循关注点和单一责任原则?开放封闭原则?你知道这些是什么及其影响吗?
Also study the work of experts in the form of design patterns.
还以设计模式的形式研究专家的工作。
Read Design Patterns Explained by Shalloway, Read Head first design patterns
阅读设计模式由Shalloway解释,阅读首先设计模式
However remember that these aren't magic bullet solutions and take everything with a pinch of salt. Use your own creativity and STAY PRAGMATIC.
但是请记住,这些不是魔术子弹解决方案,只需要少量盐就可以了。使用自己的创造力和STAY PRAGMATIC。
#5
I don't believe there is any substitute for experience and talent, and I've never read a book on software design that I could recommend from the point of view of teaching design, despite having read quite a few. Some people are good at it, and get better as they gain experience, and some are not, and never seem to learn. Sad, but true.
我不相信有任何经验和才能的替代品,我从来没有读过一本关于软件设计的书,我从教学设计的角度推荐,尽管已经阅读了不少。有些人擅长它,并且随着他们获得经验而变得更好,而有些人则没有,也似乎从未学习过。伤心,但也是如此。
#6
I think by looking the design of some great open source projects available .Reading the Code and looking the design of opensource projects is the best way of learning designing in my opinion.
我认为通过查看一些优秀的开源项目的设计。在我看来,阅读代码并查看开源项目的设计是学习设计的最佳方式。
#7
I agree with most suggestions so far, they are all valid - read code, read books, try stuff.
我同意到目前为止的大多数建议,它们都是有效的 - 阅读代码,阅读书籍,尝试一些东西。
Where I have seen the biggest gains, both personally and in team members is a two-fold attack: 1. Get them out of their comfort zone - i.e. an unfamiliar domain or language, take away the crutches. 2. And, probably more importantly, pair them with someone who is already experienced.
我已经看到了最大的收获,个人和团队成员都是双重攻击:1。让他们离开他们的舒适区 - 即一个不熟悉的领域或语言,带走拐杖。而且,更重要的是,可以将他们与已经有经验的人配对。
Mentoring has a lot to offer, you can get there yourself, but a good mentor can save you years of pain.
指导有很多东西,你可以自己去那里,但一个好的导师可以为你节省多年的痛苦。
#8
Certainly, experience is the right answer. But beyond that, I think there's something to be said for understanding patterns in your own context: As you're building your applications, make design decisions that make pragmatic sense to you. To wit, don't do them because it's 'best practice', or because a more experienced programmer told you to. Do them because you understand the Why and it helps you (or other programmers) work with the code and understand it better. I find the same is true with things like database design. Do what makes sense from an intuitive, maintenance standpoint. 7 times out of 8, if you've really thought it through (or learned from various pitfalls), you'll find you're automatically doing some class of 'pattern' or practice without actively trying to.
当然,经验是正确的答案。但除此之外,我认为在您自己的环境中理解模式还有一些事项要做:在构建应用程序时,做出对您有实际意义的设计决策。也就是说,不要这样做,因为这是“最佳实践”,或者是因为一位经验丰富的程序员告诉你的。做它们是因为你理解了为什么它可以帮助你(或其他程序员)使用代码并更好地理解它。我发现数据库设计之类的东西也是如此。从直观的维护角度做有意义的事情。 8次中有7次,如果你真的想过它(或者从各种陷阱中学到的东西),你会发现你自动做了一些“模式”或练习而没有积极尝试。
Of course, I'm not suggesting anyone work in a vacuum; nor that they don't actively pursue and integrate design patterns as a matter of course. I just think that understanding them in your own context (and for specific, practical reasons) is what helps the most to demystify the thing. That's been my experience, anyway. Reading books always feels like learning-lite to me. Good helpful stuff, but small potatoes next to getting in the slop. Think your decisions through and be able to defend them. Always be open to a better way.
当然,我并不是说任何人都在真空中工作;当然,他们也没有积极地追求和整合设计模式。我只是认为在你自己的背景下理解它们(并且出于特定的,实际的原因)是最有助于揭开神秘面纱的东西。无论如何,那是我的经历。阅读书籍对我来说总是像学习一样。好有用的东西,但小土豆旁边进入斜坡。通过思考你的决定,并能够为他们辩护。始终以更好的方式开放。