前言

这篇文章主要是说我为什么算法能力不太行

真是用不到

我之前还买了极客时间的算法课，学了好几个月，最后发现工作中真的用不到，而且真的很费时间，一段时间不练就又忘了。

工作的需求都是实现功能，我一个运维，而且我经历的阶段都在从 0 到 1，从 1 到 10 这个阶段，基本不需要开发一个系统解决问题，如果有人说有什么需求必须要开发什么的，我们这特殊，我觉得就我知道的情况来讲，这种特殊情况基本不存在的，说出这话的人大概率对需求的理解停留在很表面的层次，就是不理解认真听，但不要照着做的意义，就是来了需求就直接想着怎么更好的实现，而不是仔细探究这个需求是否合理，这个需求究竟为什么会产生。

还有就是开发一个系统解决问题，大部分的需求都有开源的解决方案的，如果没有，那大概率是这个需求是不合理的。还有一个说法是说，如果一个解决方案很难找到，那么大概率是这个需求本身就是错的。

当我们开发一个系统去解决问题的时候，可能这个系统带来的问题比解决的问题还要多，这是我的真实经历，大部分时候都是来个人搞一套，换个新人，又要推翻重来，就我们现在情况来讲维护别人的代码，基本是地狱级难度。

我处理问题的时候，技术从来没成为瓶颈

就是真遇到算法类的问题，找人请教就行了

就我真实的水平，可以看看我的博客，工作中需要写代码的地方真的不多

好代码怎么写

我觉得比起花在算法上的时间，还不如把这些时间用在怎么写好代码上，比如高内聚低耦合的代码怎么写，怎么提高代码的可读性，我之前花了几个月的时间学习了 TDD （测试驱动开发），我真的觉得挺有用的，虽然我只停留的很初级的阶段，但我认可 TDD。我觉得一个代码好不好，就对照老马的重构第二版就行了，没有代码坏味道就算是好代码，这里在列举一下编程九戒的要求

• 方法只使用一级缩进（One level of indentation per method）
• 拒绝使用else关键字（Don’t use the ELSE keyword）
• 封装所有的原生类型和字符串（Wrap all primitives and Strings）
• 一行代码只有一个“.”运算符（One dot per line）
• 不要使用缩写（ Don’t abbreviate）
• 保持实体对象简单清晰（Keep all entities small）
• 任何类中的实例变量都不要超过两个（No classes with more than two instance variables）
• 使用一流的集合（First class collections）
• 不使用任何Getter/Setter/Property（No getters/setters/properties）

标签：需求,为什么,代码,per,算法,开发,解决问题,不会
来源： https://www.cnblogs.com/WisWang/p/15877659.html