忍者必须死？

依壁雕凿的城市？

不看

把“烂”的程度控制住也是很重要的。

@whileFalse “当你系统做到 80%的时候，你发现产品的一个新需求无法实现，因为系统完成度 20%时写的底层架构不支持该操作”，其实这个问题我敢说是基本上就是“预先设计”本身引起的。

或者这么说，如果你的代码一直是完成且仅完成当前的业务需求，那么结果就是你的代码完全贴合业务需求，那么这个时候如果新的需求无法实现，只能说明这个需求本身是错的，你自己会很容易发现这一点。这时候你把问题抛回给提需求的人，他都能够很明白这其中的逻辑冲突。

软件开发中的复杂性我是分为两个部分来看的，一部分是业务逻辑的复杂性，另一部分是代码结构的复杂性，如果完全消除了代码结构的复杂性，那么软件整体的复杂性就跟业务逻辑本身的复杂性趋向于一致。这种情况下，如果新需求无法实现，就只会有一个原因：新业务与旧业务冲突，而不是技术上的问题。反过来，如果业务逻辑确实没有冲突，那么只能说明代码本身对未来的预测与当前业务不符，就是“预先设计”引起的问题。所以我还是拒绝任何程度的预先设计。

另一方面，当“你发现产品的一个新需求无法实现，因为系统完成度 20%时写的底层架构不支持该操作”的时候，如果因为进度或者其它客观原因，暂时没办法花时间和精力去修复，这时候“绕过这个底层问题”也是讲方法的，而不能因为底层已经烂了，上层就随便应付了事。

@whileFalse 我想表达的意思是招式不重要，重要的是解决问题，用最简单的办法解决问题，同时不引入新的问题就行，解决完一系列问题，你说的“设计模式的嵌套”已经自己出来了。

我觉得我们这个圈子里，太多太多人喜欢套用自己先前用过的、或者其它“大公司”分享过的方法 /模式，也就是所谓的“招式”。我更倾向于对每个系统重新做设计。而且我所谓的“设计”并不是扮先知，预言未来的需求和可能遇到的问题。我所谓的“设计”，是在满足且仅满足当前需求的前提下，用最简单的代码来实现需求。对“未来可能”的需求和问题作 0 考虑——就是根本不考虑。未来的东西本来就是不确定的，万一（回顾一下吧，其实是多数时候）你预言错了呢？之前对未来做出的复杂设计就变得一文不值，同时还会是累赘，是负产出。而仅实现当前需求的代码，是最简单也最容易改变的。

设计不是“预知未来”，精良的设计能让改动的成本降到最低，但不可能让你在面对需求的变化时无需改动设计。必须积极地改动设计——在每一次需要改动的时候，不要把这些必须改动的设计积累起来。“拥抱变化”说的是这个。

还是对于“招式”，有件事我们需要明白：方法是用来解决问题的，如果问题不存在，那方法本身根本无意义。

补充一个相关链接 https://www.zhihu.com/question/306481351/answer/562237980

我不知道我是不是废话比较多，其实蛮希望能有朋友能讨论这些东西。谢谢你花时间看完。

@bmos :D 不客气。我之前也是一直对自己的代码不满意。现在虽然也并不是非常满意，但起码方向是清晰的，不像之前那么没底气，写什么系统都 hold 得住，知道自己该如何继续改进。最重要是别放弃这份追求。加油。

抓到了根本，招式都是结果。

@bmos 我觉得完成功能之后，消除重复是首要目标。当你竭尽全力的去寻找消除重复代码的方法的时候，会发现许多面向对象的特性正好可以拿来消除重复；然后会发现设计模式原来是这么回事；会去寻找在当前这个场景下，消除重复最合适的重构手法。所有的面向对象的特性、设计模式和重构手法的应用，全都是最合适的。

但如果一上来就去找设计模式之类的东西，反而会没了方向，学了方法不知道该在哪用。

其实，在“消除重复”之前，还有更根本的东西：“消除重复”的动机是什么？是降低代码结构的复杂性。

前面一直有人在提《代码大全》，《代码大全》里面很重要的一句话大概是这样的（原话不太记得了）“软件开发中的首要目标就是降低复杂性”。而复杂性来源于哪里？一、重复代码；二、糟糕的命名。

我觉得建议看源码的最扯淡，我不知道为什么这种说法能一直流行到现在，我也很好奇这些人在说出这些建议的时候是不是真的清楚自己在说啥。

首先，开源代码本身就良莠不齐，请问如何分辨哪些是优秀的？使用的人多就是优秀的？我觉得很多时候恰恰相反。MooTools 这样优秀的开源库就很少人知道，同时期最流行的却是 jQuery。MooTools 在小众的圈子里一直到存活到 CoffeeScript、TypeScript、ES6、ES7 出现之后，开发人员觉得 MooTools 完成使命，可以退休了，官方才宣布停止维护。

其次，优秀的源代码你看过一遍基本上只会有一种感觉：这代码本来就应该是这么写，理所当然的，看过之后根本不会留下什么印象。而让你留下深刻印象的往往是些炫技的代码，这样的代码又只会把人往坑里带。

https://www.v2ex.com/t/569357#r_7412894

09 年左右大概和楼主有一样的困惑。

天赋和运气都是太高级的决胜因素，菜鸟一般都是拼实力，顶级高手才拼天赋和运气。用知乎的说法“以绝大多数人的努力程度，还轮不到拼天赋”。

买房？生娃？

突然想起曾经跟网友 A 聊天，A 说 B （实习生）在纠结做前端去腾讯还是百度，我跟 A 说我感觉这两家前端好像都没什么拿得出手的东西，A 把我俩聊天记录转给 B 看了一下，然后 B 专门在自己博客里写了篇文章来骂我俩装 B。我实在是无语，一是感叹年轻娃盲目崇拜这些所谓的大公司；二是我只是跟 A 聊天而已，并没打算让 B 知道我俩聊的内容，然后我莫名其妙被骂了一通，当时挺恼火的。

第一句写错了，是 07 年初。

补充一下，“通过所有测试”对不写测试的人来说就是“完成所有功能”，是同一个意思。

07 年底参加工作，Java 两年，剩下的都是 Ruby。不玩什么收徒，感觉很二。

到目前为止能够简单给出的经验就是“对于面向对象编程来说，跟重复代码死磕的程度决定了你的水平”。程序员除了完成功能之外，第二重要的就是消除重复，良好的命名紧随其后。是我自己摸索出来的经验，但意外地发现跟 Kent Beck 的简单设计原则不谋而合：

通过所有测试（ Passes its tests ）
尽可能消除重复 (Minimizes duplication)
尽可能清晰表达 (Maximizes clarity)
更少代码元素 (Has fewer elements)
以上四个原则的重要程度依次降低

在做到前 3 句之前，后面两句可以不管，因为有第 5 句存在。实际上第 4 句在很多情况下是可进可退的，而你能够做到前 3 句的时候自然明白第 4 句在说什么。

可惜的是，现在有许多程序员不知道为什么一边抱着“面向对象是垃圾”、“重复代码可以存在”之类的想法，一边又把代码写得乱七八糟，一复杂就失去控制……随便吧，话就放这，我觉得很多事情看缘分。