前言

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

真是用不到

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

工作的需求都是实现功能,我一个运维,而且我经历的阶段都在从 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)