转载：https://blog.csdn.net/Ture010Love/article/details/105876269?spm=1001.2014.3001.5501
这两周比较惊讶的发现，团队里的小伙伴们都开始主动去用配置化、标准化的思路做事了，很高兴。
比起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原则，还原与整体综合原则等。
————————————————
版权声明：本文为CSDN博主「软件真理与光」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Ture010Love/article/details/105876269