私以为，作为一名程序员，一定要以写出优美的代码为目标，优美的代码即逻辑实现简洁，代码可读性强，结构设计合理。这也是我对自己的要求，所以每次写之前都会花大量的时间在脑海中反复构思，在编写过程中也不断的重构新代码，当然咯，能力与追求通常都是有差距的，自己写的代码并不像自己想要的那样优美。
为了加强理论基础，最近又开始认真研读uncle bob的《clean code》一书，这次是带着平时的经验看的，所以看的比较细，也比较慢，命名一章讲的内容对于参加工作的同学来讲应该是写代码的常识了，也不赘述了。
结合我平时的工作经验，函数一章的内容中我觉得有三点是非常需要重视的：
1、函数只做一件事
有些新同事会有一个习惯，就是把一个方法写的非常长，很多if else的逻辑都平铺在了一个方法下面，这么做一是读代码的人会很痛苦，可能读了几十行前面的逻辑又不记得了，就得反复上下翻动，很不流畅。二是代码毫无复用性可言，那如果有人想复用上述方法体的逻辑怎么办？有心的同事可能会去好好理解上面的逻辑，然后抽一个公用方法出来，大部分同事可能就直接copy了，否则既要忍受阅读长代码的痛苦，又要担负改坏代码的风险，结果就是造成代码的冗余。这无疑在加速代码的崩坏。
2、无副作用
如果说函数太长只是加速代码崩坏的话，那副作用就是直接给代码增加了一个坏点。副作用最直接的问题是会造成后来者对代码的误解，如果不看有副作用的方法的实现，那很可能后续的代码逻辑的理解都会走偏。另外就是破坏了原有的代码结构，如果有人继续在次基础上开发，那结构会非常混乱，后期无法维护，更严重的是如果有人复用该方法而不知其副作用，甚至会造成严重的bug。这是一定要避免的。很不幸，我以前在编码过程中特别喜欢用副作用，因为特别方便，因为我特别喜欢做一件事的时候顺便做一些相关的事，这样省工夫，效率高，但把这个习惯带进写代码那可能就会变成灾难了，以后会极力避免。
3、输入参数不要作为输出
说实话，这点是我一直没有意识到的一个问题，而且我也颇喜欢这么用，主要原因可能是将上学时使用c语言的习惯带到了java上。众程序员周知，c的指针非常强大，写代码经常会把指针作为参数传来传去，那java虽然没有指针，但是有object啊，传object和传指针我觉得效果是一样的，所以我很喜欢方法里面传对象进去，然后再修改对象的内容，后续继续使用更新后的对象，这就是输入参数作为输出的反面典型，这种情况下好的做法可能是将这个方法集成到这个对象内部，作者说，如果非要输入作为输出，那就输出this。
当然啦，重看这本书还让我意识到应用一些简单设计模式的重要性，缺乏这部分知识，即使写出了一些clean的代码，可能只能达到uncle bob 对于clean code要求的初级阶段，clean code之于我要走的路还很长。
