1、以终为始:价值是一切的起点。

技术的表面上看是职能线,但技术的本质不是完成需求,而是在一起创造价值。有个二八原则,说的是80%需求都没啥用,其实这个数字实际可能更大。因此业务上要从起点考虑。

2、重视数据。

但凡不能被数据考量的,基本都没啥价值。这不是一个绝对的判断,但实际上适合大多数场景。

之前我发现做很多事,看似出不来数据,譬如服务化等。后来仔细想想,做得太早了。指标很难弄出来的技术项目,一般都是形式化、漂亮的,好看不好吃。

3、打不打、打哪里比怎么打更重要。

这句话是英文DO RIGHT THING,RIGHT DO THING的翻译。实际上是在谈选择。WHY、WHAT都没想清楚,一定是在瞎忙。

4、技术方案的前提是问题实际存在,是个问题、是个大问题。

很多技术方案之所以看上去很好看、但不好吃,是因为这个问题是人主观上创造出来的,或者问题不够大、不够疼。

5、业务、技术两条腿走路。

做底层一般都靠技术一条腿,做业务一般都靠业务这条腿。没有业务压力,就容易划水。而业务压力大的,很容易被业务需求爆仓,欠很多技术债。一瘸一拐的走路,最后的结果不是走得慢、而是系统被推倒重建。

6、重视系统运营。雪崩面前没有一片雪花是无辜的。

如果一个团队的系统挂了,这个团队里头的人没有一个是无辜的。一定要有系统运营的思维,还有责任心、Owner感在里头。

7、边干活边优化。

技术和业务的比例一般应该在20%、30%。投入少了就有问题。如果没资源怎么办?

有一个很重要的思维是把一件事做完整、做漂亮,而不是用最快的临时方案交付。把技术成本平摊在日常需求里去,这就像民兵组织一样、散到每个人头上。

8、对于历史包袱要敢于亮剑。胆子要大、心要细。

如果是很有历史的系统,但凡没有演进思维去运营的,一定包袱很重。

这里有一个胆量问题。敢不敢动?收益如果大,别怕改、别怕变化。问题在哪,早一天解决困难少一点,责任、风险总要有人背的。

9、拒绝做重复的事情。重复的事情让机器做。

产品让程序猿干活,程序猿让机器干活。复用这是降低成本十分有用的一个思维。它的困难不在于技术方案有多复杂,而在于有没有这个意识,有没有将事情做得更好的意望。

10、学会用基本原则去构建技术的大厦。

其实软件设计上真正基本的原则没有几条。没有原则,就没有判断。推荐的几个基本原则:高内聚、低耦合,或简单性原则,SOLID原则,还原与整体综合原则等。