如果是让当前的我来排的话是两个一个是稳定性另外一个是清晰度。其中代码稳定性是排第一的知道为啥吗因为那是IT团队保命用的。这些年见过太多太多人因为IT故障而不得不走也见过太多太多因为故障整体IT部门的绩效被打得很低很低。因为故障走的角色大的有CTO、技术总监中间有技术经理、技术组长小的就是普通程序员。而技术管理者一走新的管理者入职往往又会带来一波团队调整甚至离职潮。所以在真实的软件开发里稳定性永远是最重要的。但是我这里说的稳定性不是说那段代码能跑就行别动它。而是你应该通过各种技术手段去保证系统长期稳定运行。比如好的架构设计降级异常处理告警限流熔断超时控制灰度发布自动化测试…这些能力很多在平时的确感知不到价值。但真正线上出一次故障你就知道它们为什么存在了。而排第二的是清晰度。什么叫代码的清晰度呢我引用一下软件开发方法学大师 Kent Beck 提供的一个例子input(); process(); output();就这么简单。别人打开你的代码不需要猜就知道程序的关键流程是什么。我一直觉得作为程序员应该以能写出清晰的代码为傲。因为它不仅对自己有利对团队也有利。三个月后你回来改代码最感谢的就是当初那个写得清晰的自己。新人接手也不用一边看代码一边猜作者当时到底在想什么。但是呢写清晰的代码跟会不会设计模式并没有直接关系。真正决定代码是否清晰的我个人觉得更多是下面四件事封装组合分离关注点控制复杂度。把这四件事做好代码自然就会越来越清晰。反过来如果一个方法几百行一个类承担五六种职责到处都是 if-else变量名含糊不清即使把二十多个设计模式都用上代码也不会好到哪里去。所以你就记住两点第一保证系统稳定。第二让代码容易理解。前者决定系统能不能长期稳定地运行后者决定团队能不能长期维护下去。至于设计模式、DDD、微服务、各种架构思想我现在更愿意把它们看成实现这两个目标的工具而不是程序设计本身。真正的程序设计而是为了让软件能够稳定运行并且让后来的人愿意继续维护它。好结尾的话我来一个金句稳定性是保命的清晰度是续命的。
如果是让当前的我来排的话是两个一个是稳定性另外一个是清晰度。其中代码稳定性是排第一的知道为啥吗因为那是IT团队保命用的。这些年见过太多太多人因为IT故障而不得不走也见过太多太多因为故障整体IT部门的绩效被打得很低很低。因为故障走的角色大的有CTO、技术总监中间有技术经理、技术组长小的就是普通程序员。而技术管理者一走新的管理者入职往往又会带来一波团队调整甚至离职潮。所以在真实的软件开发里稳定性永远是最重要的。但是我这里说的稳定性不是说那段代码能跑就行别动它。而是你应该通过各种技术手段去保证系统长期稳定运行。比如好的架构设计降级异常处理告警限流熔断超时控制灰度发布自动化测试…这些能力很多在平时的确感知不到价值。但真正线上出一次故障你就知道它们为什么存在了。而排第二的是清晰度。什么叫代码的清晰度呢我引用一下软件开发方法学大师 Kent Beck 提供的一个例子input(); process(); output();就这么简单。别人打开你的代码不需要猜就知道程序的关键流程是什么。我一直觉得作为程序员应该以能写出清晰的代码为傲。因为它不仅对自己有利对团队也有利。三个月后你回来改代码最感谢的就是当初那个写得清晰的自己。新人接手也不用一边看代码一边猜作者当时到底在想什么。但是呢写清晰的代码跟会不会设计模式并没有直接关系。真正决定代码是否清晰的我个人觉得更多是下面四件事封装组合分离关注点控制复杂度。把这四件事做好代码自然就会越来越清晰。反过来如果一个方法几百行一个类承担五六种职责到处都是 if-else变量名含糊不清即使把二十多个设计模式都用上代码也不会好到哪里去。所以你就记住两点第一保证系统稳定。第二让代码容易理解。前者决定系统能不能长期稳定地运行后者决定团队能不能长期维护下去。至于设计模式、DDD、微服务、各种架构思想我现在更愿意把它们看成实现这两个目标的工具而不是程序设计本身。真正的程序设计而是为了让软件能够稳定运行并且让后来的人愿意继续维护它。好结尾的话我来一个金句稳定性是保命的清晰度是续命的。
