这两周比较惊讶的发现，团队里的小伙伴们都开始主动去用配置化、标准化的思路做事了，很高兴。

比起HOW、我更愿意讲WHAT，今天我主要想讲开发在意识和思路上的一些东西，花10分钟列十条吧。

 

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

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

 

2、重视数据。

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

 

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

 

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

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

 

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

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

 

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

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

 

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

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

 

7、边干活边优化。

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

 

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

 

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

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

 

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

 

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

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

 

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

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

 

ps：腐化是一点点从内部开始的，作业交的越来越迟。从周六到周七、周一、周二。

 

---

=>更多文章请参考：《中国互联网业务研发体系架构指南》

https://blog.csdn.net/Ture010Love/article/details/104381157

=>更多行业权威架构案例、领域标准及技术趋势请关注微信公众号 '软件真理与光'：