我觉得我擅长一点一点地编写代码，但是我的设计确实很烂。问题是，如何改进设计-进而成为更好的设计师？
我认为学校和学院在教导人们如何善于解决数学问题方面做得很好，但让我们承认事实是，大多数在学校创建的应用程序通常大约有1000-2000行长，这意味着这主要是一次学术练习，并不反映现实世界软件的复杂性-数十万至数百万代码行。
在这里，我相信即使是topcoder / project euler之类的项目也不会有太大帮助，它们可能会提高您的数学问题解决能力-但您可能会成为一名学术程序员；对漂亮，干净的东西更感兴趣的人，对大多数应用程序程序员处理的日常琐事和毛茸茸的东西完全不感兴趣。
所以我的问题是如何改进我的设计技巧？也就是说，设计中小型应用程序的能力是否会涉及几千行代码？如何学习设计技巧，以帮助我构建更好的html编辑器套件或某些图形程序（如gimp）？
#1 楼
真正擅长于某件事的唯一方法是尝试，大幅度失败，重试，再失败的次数比以前少一些，并且随着时间的流逝，逐渐积累经验，以识别导致失败的原因，以便以后可以处理潜在的失败情况。在学习您喜欢的第一人称射击游戏中学习弹奏乐器，驾驶汽车或赚取一定的PWN年龄时，就像学习软件开发的任何方面一样。那里并不是真正的捷径，但是您可以做一些事情，以免在获得经验的同时无法解决问题。
确定好导师。没有什么比能够与已经缴纳会费的人谈论您的问题更好的了。指导是帮助快速学习的好方法。
阅读，阅读更多内容，练习所读内容，并在整个职业生涯中重复一遍。我从事这项工作已有20多年了，但我仍然每天都会学习一些新知识。不仅学习前期设计，还学习紧急设计，测试，最佳实践，过程和方法。所有这些因素都会对您的设计如何出现，成型以及更重要的是随着时间的流逝如何产生不同程度的影响。
寻找时间进行修补。您可以通过工作场所参与一个大型项目，也可以自己练习。通过将您的新知识付诸实践，并观察这些事情将如何工作，与您的阅读相结合。这也是与导师进行良好讨论的要素。
参与工作场所以外的技术性工作。这可能是一个项目，也可能是一个论坛。可以让您在同龄人之外的圈子中测试您的理论和想法，以便对事物保持新的视角。
耐心一点。认识到赚钱经历会花费一些时间，并学会接受需要休息一段时间才能了解失败的原因和原因。
评论
+1尝试失败。因为当您不了解为什么会有设计模式时，就无法有效地使用该模式。
– Akcakaya专家
2012年5月24日下午6:12
+1很好的答案，但我发现它有些不完整。我认为，到目前为止，最重要的贡献是对重构有很好的胃口。编写，查看理论的内容（文章，书籍或指导者），重构/重写，回到理论，重构/重写-这将使您有时间专注于结构，同时使用熟悉的代码。成为自己最糟糕的批评家。我还要说，非常重要的一点是，您永远不要因为不断重新审视自己的工作而失去这种胃口。
–vski
2012年5月24日9:06
@vski我可以包括很多概念，但问题是这些概念本身是否会为获得OP认为自己是一名经过改进的设计师所需的经验提供一条合理的途径。在我的回答范围内，我将重构视为一种实践（根据第二点）。练习Clean Code，Test First，BDD和许多其他概念也是如此。我采用的方法是，随着时间的推移，要发展到一定的水平，使设计技能随着所获得的经验和知识的发展和增长而发展，就需要许多技能和经验。 :)
–S.Robins
2012年5月24日上午10:09
+1获得导师。理想情况下，请您的指导者与您一起进行代码审查。当涉及到更好，更清洁的设计时，让其他人阅读和批评您的代码确实可以为您提供帮助。
–狮子座
2012年5月24日14:29
“曾经尝试过。曾经失败过。没关系。再试一次。再次失败。失败更好。” ---塞缪尔·贝克特（Samuel Beckett）。
– Peter K.
13年4月12日在21:13
#2 楼
好吧，这个问题没有金苹果，我觉得这也许是每个编码人员自己都应该找到适合他的方法的原因。无论如何，这是我的看法。您可以阅读有关该主题的书。好书。很棒的书。但是我发现这些书仅对尝试构建和设计应用程序的人有帮助-失败了。
对我而言，这一切都与经验有关。当我还是一名菜鸟时，我读了有关如何设计的书。那时我不太了解其中的内容。当我开始工作并不得不自己设计应用程序时，我的应用程序非常混乱。他们工作了，但是很难维持。然后我又读了那些书-这次我更好地理解了。
现在，我继续犯新错误并从旧错误中吸取教训。
评论
这里有一个很重要的观点值得一提：继续犯新错误；不要继续犯同样的旧错误-向他们学习，做一些新的事情。
–贝文
2012年5月24日下午6:02
#3 楼
停止设计并学习重构代码。通过不断进行积极的重构进行增量开发，将使最终产品比任何前期设计都要干净得多。评论
恕我直言，紧急设计是一件美丽的事情，但如果没有纪律，您就有可能创建“紧急意大利面”。前期设计的问题是，人们将其视为一个全有或全无的主张，当情况恶化时会给它一个不好的代表。这让我想起了Joel的一篇文章，他提到设计很重要。尽管需要足够的前期设计才能有所作为，但又不会浪费您的时间，资源，也看不到有机会通过简洁的代码有机地生成精美的辅助设计。
–S.Robins
2012年5月28日下午14:15
@ S.Robins：我认为OP仍在攻击规模较小的项目，这些项目可以通过TDD和连续重构很好地完成。因此，他可以学习所需的学科，以了解更复杂的项目需要多少设计。
–kevin cline
2012年5月28日20:31
我以为可能是这种情况，但是我觉得有必要添加一个反驳，即“任何前期设计”可能会变得更糟，因为这种情况纯属偶然。但是，我确实同意，构建OP所寻求的必要体验的方法是，在一开始时就不必担心设计和专注于编写精巧，整洁的代码。 :-)
–S.Robins
2012年5月28日23:59
我不同意重构总能带来最佳设计。当然，重构通常使您能够探索和理解问题，但是好的设计并不总是通过重构而逐步出现的。有时，您会看到更好的解决方案，并且意识到您当前的代码与之相距甚远，因此重写比重构快得多。
–乔治
13年4月12日在20:55
我最近有这种经验：我一直在进行重构和重构，并且一次又一次地遇到同样的问题：我正在使用迭代器来编码某些东西，并且代码一直在变得复杂。然后，我决定忘记迭代器，不得不重写许多代码，但是逻辑变得比以前更清晰，更简洁。我不知道您是否称其为“积极的重构”：应用程序的整体结构没有更改，但是一些基本部分被扔掉并从头开始重写。
–乔治
2013年4月12日21:00
#4 楼
当然，请阅读有关模式的知识，但首先要阅读有关反模式的知识。识别反模式很重要，比起为什么应该更容易理解为什么不应该以这种方式来做某事。请参见http://sourcemaking.com/antipatterns/software-development -antipatterns。
编写代码，以便在需求发生变化时可以快速调整代码（这在生产环境中非常常见）。
对添加“只是另外一个小技巧。”在这里再添加一个，在此再添加一个，代码变得不可维护。
重视开放/闭合原则。
编写测试（如TDD）。它们甚至迫使您在真正实现设计之前就仔细考虑您的设计。
浏览开源项目的代码（大小合理的项目）。通常，我曾经惊讶于看到如此多的抽象级别。现在我明白这不是出于艺术目的，而是出于这种目的。
#5 楼
对于良好的设计，我发现非常重要的一个原则是分解：如果一个类太大（超过300至400行代码），则将其分解为较小的类；如果方法太大（例如，超过50行代码），则将其分解；如果项目包含50个以上的类，则将其分解。关键是估计系统的大小并构造几个抽象层（例如，子系统，应用程序，项目，模块，类，方法），允许您将代码分解为可理解的单元，它们之间的关系清晰，几乎没有依赖关系。
评论
尽管您的建议中有一些优点，但代码行并不重要，行为却很重要。如果您的方法做的不只一件事情，可能是时候重构它了。如果那件事只是调用自己执行某件事的方法，然后将它们缝合在一起，那很好。
– jer
13年4月13日在14:36
@jer：当然，这是经验法则。正如您所说，调用100个其他方法的方法只是将事物缝合在一起（它正在调用子功能列表）。我更多地考虑的是包含一些真实逻辑的方法：如果您必须来回滚动很多以了解方法的作用，通常这是一个不好的信号。如果您查看具有很多成员的类定义，那也是同样的事情（并且该类不仅是大量的扁平化属性集合）。
–乔治
13年4月13日14:50
“项目包含50多个类，分解它”并不严重
–动态
13年4月13日在23:58
@ yes123：这是一个想法。这实际上取决于您正在开发什么，使用哪种语言等等。
–乔治
13-4-14在0:28
我认为有必要指出，这对前期设计无济于事（因为您正在重构），但有助于学习可改进未来设计的模式和最佳实践。
– Craig Bovis
13年4月29日在14:54
#6 楼
很难，我们真正要谈论的是一种抽象而不是创建更好的代码的能力，但是有两件事会让您变得更好，而一件事会让您更加快乐：“更好”
A）找到最好的设计师，然后将程序配对/一起进行设计。请他们在解决问题时解释他们的想法，不要满足于“感觉正确”并继续挖掘。这个过程也将有助于“指导”政党
B）想象一下一切都是个人行为者，以及他们之间的对话。每个参与者都应该有一个单一的角色/职责，并且他们各自负责不同的系统。如果该对话有效并且每个演员都感到连贯和凝聚力，那么您就在路上。
和“更快乐”
C）如果您已尽力而为仍然没有发生，那么接受某些人不能做些事情并没有错。您可以编写紧凑，出色的代码，但永远无法设计或架构。所以呢？我不能参加太妃糖的体育运动，我也不好看，而且我的汽车驾驶永远也不会比一般人更好。陶醉并利用您的擅长。
#7 楼
以我的个人经验，阅读他人代码是“灵感”的良好来源。我的意思是尝试理解他人的设计并问自己为什么他/她以这种方式做事？您可以找到很多开放源代码研究项目。
无论如何您都需要练习。
#8 楼
别为恐惧而生活追求简单
听你的用户
尝试很多想法
创建一些东西，然后使其变得更好
致力于增加价值的事物，放弃那些没有价值的事物
评论
“让我们承认一个事实，就是在学校创建的大多数应用程序通常大约有1000到2000行长，这意味着这主要是一次学术练习，并不反映现实世界软件的复杂性。”：我在教书的那儿有两个一个学期软件项目，由十名学生组成的团队在6到8个月的时间内开发了相当复杂的应用程序。另外，许多公司（至少在德国是这样）为想要在完成学业之前进行一些练习的学生提供短期合同。我提出的设计的副本通常比我的同事做的糟-我如何做得更好？以及如何擅长于面向对象的分析和设计（OOAD）？