从一个函数怎么写到降低公司成本

​ 昨天下班前和mentor聊了近两个小时，从一个函数到底该怎么写，到究竟什么时候才应该拆一个函数出来，再到公司管理，代码修改成本，感觉学到了挺多东西，也有很多个人的感悟。

​ 一件事情有很多种解决方式，但是总有一个最好的解决方式，但这个解决方式未必是在一开始就能够知道的。在一个行业久了之后，会有自己的经验，或许可以预测出接下来客户或产品会提什么进一步的需求，从而可以为代码的修改留足“空间”，降低未来的成本。但是每个程序员之间的经验并不完全相同，也并不是所有的程序员都会有为代码的修改留足”空间“的意识，所以代码也有好坏之分。

​ 比较理想的情况是，公司里每个人都能意识到下一步的修改，都不写🔟山代码，从而在代码报错时，可以很快地定位错误，在bug修改和产品迭代时，可以尽可能少地影响原来的代码，在其他人来接手代码时，可以很快明白代码要表达的意思，这些都可以降低工作的世间，从而降低公司的成本。就算不为公司考虑，自己在忙一件事的时候，突然遇到另一个紧急任务，也并非不常见，如果能够让自己很快地改完一个bug，增加一个需求的代码，就算遇到了另一个紧急任务，也有充足的时间去应对。再说了，空下时间摸摸鱼不也挺爽的吗，反正能在ddl内完成任务。

​ 而更严重的一种情况是，代码的写法之间，出错的概率不同。比如普通的for循环和foreach的写法之间，显然是后者更加安全，因为后者不需要控制循环的起始点等容易出错的点。后端的出错，会导致：客户有段时间不能正常使用产品，从而受到亏损，一线和产品收到客户的反馈，需要进行汇报问题和安抚客户，这需要占用时间，前端需要首先排查问题，需要占用时间，然后发现不是前端的问题，然后后端才去排查问题，然后因为代码太烂，修bug修了好长时间。公司里的一线、产品、前端、后端都额外付出了时间，从而提高了公司成本（不只是工资，还有员工身上的福利，实际上也可以看作按时间计费的），还降低了客户的信任，而这都是因为后端代码的问题导致的，作为一个公司的管理者，会不会考虑开掉这个后端呢？

​ 我个人觉得，代码质量对刚入行的程序员尤为重要。因为当入行一定时间之后，代码习惯形成了，就比较难再进行修改了。并且，在实际开发环境中，限定时间成本的情况下，一个程序员是否有时间去考虑代码质量呢？应该还是比较困难的吧。