<SteveY对Amazon和Google平台的长篇大论>&&<unix设计思想>

SteveY对Amazon和Google平台的长篇大论

http://coolshell.cn/articles/5701.html

unix设计思想

http://coolshell.cn/articles/7236.html

unix设计思想这个虽然刚学习编程的时候就反复听到了，但是真正对我有意义还是尽几年，也就是编程主要挑战从算法转向程序规模。

最近这些感觉也是越发的浓，看到这个文章也眼前一亮。

解耦合和kiss，这个还是指系统设计（或者说大规模程序）上的一些原则，大规模程序的首要挑战（甚至可以说是唯一挑战）就是复杂度。

那么解耦合就是将复杂的，大的东西进行分而治之。

嗯，我认为可以这样来量化程序规模，如果一个模块里面有x，y两个部分，如果是紧耦合，那么规模就是

(x+y)*(x+y)

如果松耦合，则是x*x+y*y

如果可以keep it simple，那么比如是降低了其复杂度，加入简化了%40的复杂度，也就是到了0.36x*x+0.36y*y。

这里的提升是很恐怖的。

当然这个随着规模越大越有效。

之前参加了一个项目，经过多年的代码编写，里面乱的一塌糊涂，就如大家经常听到的，修个bug要费好大力气来理清思路，改了也很容易改出其他bug，加新的feature，那更恐怖，大家形容它为脆弱的平衡，或者如amazon一个程序员描述amazon的代码一样，一个“屎山”。

我们有各种理由来说这样那样的原因，比如说进度。。。

但是我觉得这些都是bullshit，我们为什么要把生命浪费在创造这些shit上呢？

stevey这个文章信息量较大，摘录笔记一些：

• amazon缺少工程标准，缺少招人标准，这个知道该这么做的人多得很，实际能做到的团队对执行力要求颇高的
• amazon会更快更早的推出服务，并不断优化改善，把服务发布看的非常重，包括工程纪律等，这个虽然很好，但是副作用stevey认为也抵消了其好处。像工程纪律这种，会对大规模长期的项目造成好处，并不是立竿见影的一个东西。非工程师很可能认为这个没什么用。这个不能一概而论的说那个应该那个不应该，还是看项目的规模，周期，团队的风格，选择适合自己的方式，就像崇尚进攻的球队就去进攻吧，防守弱点就弱点，最后能赢球就好，不用每个人每个团队都那么追求完美。当然你如果就是要追求完美的话，那么就根据规模和周期，在产品发布和工程纪律等上面做出最佳平衡。
• Jeff Bezos，有几点的确非常的赞
  
• 他（或者他的团队的）远见卓识，在产品感和解决方案上综合实力相当强
• 超强的执行力，
• 就是这样，你需要正确的认识来让其他人认同，再用足够强的执行力来让由于懒惰和习惯（尽管心里能够认同）而不执行的人做正确的事情
• 相比之下，google这方面不够好（stevey这么认为），把握公司方向盘的人没做好，那就没辙了。
• 而且这么样的把几个公司（google，ms，amazon，facebook。。。）一对比，真的挺让人开眼界的，微软这样的公司的眼界让人赏心悦目，看的更广阔更深远
• accessibility是互联网中最重要的事情，如果accessibility不好，最后没人用，那么就相当于你的程序白写了。就跟健康之于财富，xxx牛b feature一样，无论你做了什么超级强的系统设计，巨牛的算法，走过了什么样的心路历程，最后一份完美的代码，没人用，那就突然变得意义索然了。
• “吃自己的狗食”，就是自己做的东西，自己要不停地使用，而且要乐于去使用，这个对于游戏引擎有着巨大的启示（业内这么多年的历史，无数的事实也在佐证这一点。一个游戏引擎的成长，绝对离不开使用它的游戏：
• 大部分程序员不可能想到能覆盖所有情况的东西，必须要在实际使用中去不停地考验，磨练引擎和工具，然后在无数个迭代中才能达到炉火纯青。
• 脱离测试环境去开发复杂系统就是个笑话，对于引擎和工具，测试环境就是一个完整的游戏开发
• 开发的一切，从设计到代码实现都需要大量的测试，其中相当数量的design&art相关的单靠程序员一己之力是想不到的
• 开始没想到的话，放到后面做，要花10倍精力才能做对（10这个经验数字，不算离谱）
• 巨大的成功会让人产生定式和偏见