本周工作思考
- 关于软件价值\设计价值\代码价值\时间价值的简单思考
- 优化点或者bug改的多了很容易让开发者进入“就事论事”的思考方式，认为这个有bug了，就改这个地方，软件从构成上来说是一行行代码，一个个组件或者模块，实际上软件一个极其的复杂的系统，规避复杂的思路不应该是不动其他地方，不往深里改，正确的思路在理解软件系统运行方式的基础上找到最正确的方法，这个最正确是从整个系统来说的，对系统的长期运行、扩展、性能来说最合适的， 而不能站在某个优化点或者某个bug上来说。以我的经验，从任何单个优化点或bug问题本身来说，稍有经验的开发人员都能给出至少5种不同的修改方法，但是如果从维护整个系统健康的角度来说，正确的方法比较有限，一般能够想到2种就很不错了，再加上时间、成本、研发能力之类的约束，对一个问题能找到一个完全正确方法并且能执行，其实是不太容易的。所以有时候我们会陷入一种技术决策纠结，对待一个bug，我是用简单的不太正确的方法改呢，还是用正确但是有些困难的方法改呢？我相信每开发人员每天都会都会碰到这类问题，我也是一样，有时候在这个上面花的时间比实际写代码的时候多。我也在不断思考这类问题到底该如何回答，到目前为止，我也没有思考清楚这个问题该如何解答，如果从代码修改上的“政治正确”上来说，那肯定要选择最后一个，要困难但是正确的，实际如果要细细思考，答案远没有那么简单，不过以我的思考和实践来说，要回到系统设计本身来说，这个出问题的背后的设计到底是解决了什么问题，针对这个问题，现在解决方式能不能促进这个问题的解决呢？如果能促进这个问题解决，那能不能推进这个设计的优化呢？如果能促进这个设计的优化，那能不能改善这块代码的质量呢？如何能改善这块代码的质量，那能不能花更少的时间呢？这个思考模型是从大到小的逐层深入的思考，依次是软件价值，设计价值，代码价值，时间价值，从这四个价值上判断修改思路是否合适。
- 软件价值，设计价值，代码价值，时间价值构成了我对一个技术决策的价值观的判断，软件价值代表了给用户解决的问题，可以一定程度上体现商业价值，设计价值是对软件运行的保证和守护，代码价值则代表了技术本身的价值，时间价值则代码完成这件是要花费的实实在在的成本，在公司里我们所在的一切首先是指向商业价值，如果一件事情从各个角度看都没有直接的或者间接的关系，或者价值传导链很长，那这件事存在的合理性就很值得质疑了。同样的当一个系统具有软件价值，但是不太有设计价值时，那么这个软件的运行，扩展，迭代，维护都会面临巨大的挑战和负向的风险，这种情况会非常影响软件价值的实现，甚至会反噬软件价值，代码价值的实现则会增强设计价值，不合适的代码会影响架构的实现，进行影响到设计价值。
- 很多bug和优化点的实现方式主要在代码价值这，如果实现方式是可以实现设计增值，那种方式才是最正确的方式，可以简单概括成一个有意思的公式
修改一个bug的方法的收益价值 = （软件价值＾3 * 设计价值＾2 * 代码价值）/ 时间价值＾2, 如果有伙伴真的碰到了一个纠结的技术问题，难于决策，可以尝试这种思路，假设每个价值单位 都是正整数，按照这个公式算就会发现，很多看起来“政治正确”的方法，因为增加了时间价值，所以收益价值小于正常改的情况，因为时间价值2次方的关系，但是如果对软件价值有增加的话，会极大的增加整个收益价值，当时时间价值是否要二次方关系，要看开发者所在岗位的成本价值。