前言
昨天，有提到自己根本不会写代码，所以今天即使再忙，忙于业务，被压力驱动着，但是最后我还是想要看完一些新的知识，总结一些新的知识，提升自己。
看了几页《人生护城河》，很多东西都没有记住，也没有能力去理解。但是，我好像大概明白这么一件事情。
做一件事情的时候，聪明的人考虑未来三到五年，厉害的人考虑五到十年，真正厉害的人考虑未来十到二十年。
现在在敲的代码，在十年后可能不值一文，但是思考这件事情永远都不会过时。
坏味道
有了之前的一些困惑，所以今天把深藏在书堆里面的书籍翻了出来，看到几个概念，在自己好几年的编程生涯中，越来越能够体会到了。
首先，判断是不是好代码，我们一般会存在一种直觉来判断，而不是通过逻辑来判断。下面也只是尽可能将直觉总结为逻辑。提供一些可供思考的方向，不能够生搬硬套。
过长的函数
越是长的函数越是让人头皮发麻。越是长的函数越是难以理解。书中提到一条原则真的深得我心。每当你想要写一些注释的时候，那么你可能将发现了一个新的函数。也就是说我们应该用一个好的函数的命名来表达一段代码的作用。甚至在《重构》这本书中还提到即使注释下面只有一行代码，那么也应该把这行代码提炼到一个函数中。只要函数名称能够解释其用途，那么我们就该毫不犹豫地去做。
那么什么是合适的时机呢？
- 一个就是上面提到函数中有注释的地方
- 条件表达式和循环也常常是提炼的信息。其实就是将
if里面的执行逻辑和else里面的执行逻辑提炼成为一个函数。作者称之为分解条件表达式 Decompose Conditional。如果是循环直接把循环和里面的逻辑都抽成一个函数。
过长的参数列
刚开始在上海实习的时候，我写代码的时候就经常在纠结于前端传递给后端的参数应该用对象来接受还是用参数列表来接受。
现在我不再纠结于这一点上面了。应为在《重构》的开头其实我能够感觉到一件事情就是代码有好有坏，但是代码的好坏要靠直觉来进行判断，没有绝对判断逻辑。
过长的参数列传递，可能会导致当需要修改的时候，需要将所有的对象调用该函数的部分都需要再修改一遍。如果存在过长的参数列就可以使用Preserve Whole Object制造出一个参数对象来，也可以称之为查询对象。
但是，事情也不是绝对的。这个可能导致依赖关系过于严重。比如调用以对象为参数的函数时，需要将依赖这个对象，就会在上层函数中多一个构造这个对象的过程。如果不想要构造一个复杂的对象，那么可以考虑将对象结构，使用参数传递。当然，另外一种方式是使用build的方式来对构造对象，不需要写很多很多行set方法。
工作压力有点大，每天只有一点点学习时间。但是，我相信这一点不同，将会在之后的一年中带给我们复利级别的变化。
关于写作
以后这里每天都会写一篇文章，题材不限，内容不限，字数不限。尽量把自己每天的思考都放入其中。
如果这篇文章给你带来了一些帮助，可以动动手指点个赞，顺便关注一波就更好了。
如果上面都没有，那么写下读完之后最想说的话？有效的反馈和你的鼓励是对我最大的帮助。
另外打算把博客给重新捡起来了。欢迎大家来访问吃西瓜。
我是shane。今天是2019年8月28日。百天写作计划的第三十五天，35/100。
