五天总结--曹实杭

五天总结

       这五天的时间里我并没有写很多的代码。更多的时候是作为一个小领导，给我的"下属"们发号施令，体会到了一些只有是一个团队才会产生的一些问题。

• 代码管理问题：虽然已经有了git这个强大的代码管理工具。但是还是会出现的一些问题，比如在我检查以前写的代码的时候就发现我写的某些代码不见了，当然这种情况也并不是只有我一人。就感觉很烦躁，辛辛苦苦写的代码，可能就因为某些人提交没有拉取代码，然后就被覆盖而消失不见。然后可能又要重写，还好git有回滚功能，但是依旧觉得麻烦，为什么就不能一步到位。所以一定要千叮咛万嘱咐，合并代码之前先拉取代码。

• 对需求的认知问题：最近检查后台的代码，然后就发现，数据库、代码全都有各种问题，完全没有达到当时说好的要求。然后我又要一边改数据库，一遍重写代码。明明当时说的表要那么建立，只要稍有疏忽，可能就会出现另一种？样貌的表来。然后代码自然也就跟着没谱了。有些是数据库表对的，代码依旧、有瑕疵。思考再三，如此的需要重写的代码，还不如不要。第一次认识到需求分析是一件如此重要的事情。如果每个人都对需求有个、大概的了解的话，也不至于做了这么多的无用功。需求分析就像地基，没有好的地基无法做好一个项目。不如说，完整都达不到。

• 写代码的问题：在代码方面，依旧有各种的问题，逻辑漏洞啊什么的，当然，我的代码也有这种问题。虽然可能谁都无法保证100%的毫无问题，但是作为工程师，我们应该确保严谨。但是呢，我们的代码，有些是在确保的路上渐行渐远了。举个例子，在表格中用户名的地方显示的确实一个数字。Are you kidding?，这除了写代码的人谁看得懂啊。一看就是写代码的时候，不做思考。上面提到的需求分析，是在我们写代码之前所做的事情。需求分析需要完全的覆盖整个系统，但是并不包括具体的实现细节。所以在自己写代码的时候，我认为同时也需要花一些精力分析一下，我这里要用到什么？我要怎么写？怎么返回参数？等等问题。不要无脑的就写，别人怎么说，我就怎么写。这样在某种程度上等同于无用功。

       让我映像深刻的问题大概就上面的三种。另外这五天时间里，算是学习了redux吧，但是说实话，那英文文档看得我也是一脸懵逼啊，看了后面的忘了前面的。它是一个状态(state)管理工具，具有三个原则。

• 你需要的全部状态应该存放在一个树状的仓库(store)中;
• 改变状态的唯一方式就是执行一个描述发生了什么的事件(action)，除此之外它是只读的;
• 用来描述状态树是如何被action改变的？还原剂(reducers)。

       在我的理解里，这应该是redux的核心，store统一存储，事件驱动。当然这只是我的见解，我把action类比于普通js中的事件，把reducers类比与事件的处理函数。store的管理具有以下的特点。

• 管理应用的state;
• 通过store.getState()可以获取state;
• 通过store.dispatch(action)来触发state更新;
• 通过store.subscribe(listener)来注册state变化监听器
• 通过createStore(reducer, [initialState])创建

       当然还有一些Middleware中间件，异步的action处理等等，这些我都不知道，ES6语法的箭头函数多来几个连着的也就一脸闷逼，确实不习惯。目前还只是知道有这么个东西。推荐一个介绍的比较好一点的中文版的redux介绍Redux 介绍。

代码

Action

const ADD_TODO = 'ADD_TODO';

function addTodo(text) {
      return {
        type: ADD_TODO,
        text
      }
}

Reducers

import { VisibilityFilters } from './actions'

const initialState = {
      visibilityFilter: VisibilityFilters.SHOW_ALL,
      todos: []
}

function todoApp(state = initialState, action) {
      return state
}

store

import { createStore } from 'redux'
import todoApp from './reducers'

let store = createStore(todoApp);