&&

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这个经验数字,不算离谱)
  • 巨大的成功会让人产生定式和偏见

你可能感兴趣的:(&&)