以下是转载的一篇文章，有几个点记忆比拟粗浅
1: 少继承，多组合。
理论我的项目中，各种职业级别不同的同学一起合作批改一个 server 的代码，就会呈现，职级低的同学改哪里都改不对，基本没能力进行批改，高级别的同学能批改对，也不违心大规模批改，整个我的项目变得愈发不合理。对整个继承树没有齐全意识的同学都没有资格进行任何一个对继承树有调整的批改，合作变得举步维艰。代码的批改，都变成了依赖一个高级架构师高强度监控继承体系的变动，低级别同学们束手束脚的后果。组合，就很好的解决了这个问题，把问题一直细分，每个同学都能够很好地攻克本人须要攻克的点，实现一个 package。产品逻辑代码，只须要去组合各个 package，就能达到成果。
2: 重视工程设计，思考本人面对的业务畛域，思考可能的模型边界，模型细节
3: 大道至简。
首先，简略不是面对一个问题，咱们印入眼帘第一映像的解法为简略。我说一句，感受一下。” 把一个事件做进去容易，把事件用最简略无效的办法做进去，是一个很难的事件。” 比方，做一个三方受权，oauth2.0 很简略，所有概念和细节都是紧凑、齐备、易用的。你感觉要设计到 oauth2.0 这个成果很容易么？要做到简略，就要对本人解决的问题有全面的理解，而后须要一直积攒思考，能力做到从各个角度和层级去意识这个问题，打磨出一个艰深、紧凑、齐备的设计，就像 ios 的交互设计。简略不是容易做到的，须要大家在一直的工夫和 code review 过程中去积攒思考，pk 中触发思考，交换中总结思考，能力做得愈发地好，靠近 ’ 大道至简 ’。
4: 可显性。
可显性的规范很简略，大家看一段代码，懂不懂，一下就明确了。然而，如何做好可显性？那就是要谋求正当的函数分组，正当的函数上下级档次，同一档次的代码才会呈现在同一个函数里，谋求通俗易懂的函数分组分层形式，是通往可显性的路线。
5: 出现异常时，马上退出并给出足够错误信息。
6: 对于日志。
沉默是金。除了简略的 stat log，如果你的程序 ’ 发声 ’ 了，那么它抛出的信息就肯定要无效！打印一个 log(‘process fail’)也是毫无价值，到底什么 fail 了？是哪个用户带着什么参数在哪个环节怎么 fail 了？如果发声，就要把必要信息给全。不然就是不发声，示意本人好好地 work 着呢。不发声就是最好的音讯，当初我的 work 一切正常！
对于代码格局标准，100% 严格执行，重大容不得一点沙。
文件绝不能超过 800 行，超过，肯定要思考怎么拆文件。工程思维，就在于拆文件的时候积攒。
函数对决不能超过 80 行，超过，肯定要思考怎么拆函数，思考函数分组，档次。工程思维，就在于拆文件的时候积攒。
代码嵌套档次不能超过 4 层，超过了就得改。多想想能不能 early return。工程思维，就在于拆文件的时候积攒。
举荐的书籍：《unix 编程艺术》