最近有幸读到《程序员的修炼之道》这本书，结合自己经历过的项目，总结一下
一：需求的分析和思考
这是一个项目的开端，也是非常重要的一步。相信大家都经历过这种开发过程，一个需求过来了，首先到产品经理手上，然后产品经理噼里啪啦一顿操作，ok，原型图出来了，紧接着UI一顿操作，ok，UI图出来了，然后大家根据原型和UI开始开发，测试，上线。然后，最恼人的地方来了，产品经理突然有一天说这个地方不合理，需要改动，那个地方逻辑有问题，需要改动，然后，返工，重做，大把的时间浪费掉了，最后还弄得自己项目延期，自己背锅，shit！！！那么我们想办法去尽可能避免这个问题，首先，从需求的分析开始，我觉得开发人员，UI，测试，都要去跟着一起思考整个项目的需求，去讨论需求，去思考每一步的逻辑合理性，保证在产品原型出来之前，项目的参与人员都能清清楚楚的知道需求是什么，为什么这么做，是否有第二种方案，两种方案的合理性如何。这样可以在一开始就避免相关人员在不清楚需求的情况下白做工作。同样，需求确定了就是一成不变的吗？当然不是，人的想法是有局限性的，随着我们工作的一步步开展，我们也要去思考项目逻辑的合理性，说不定你会突然发现，这种方案不可取，最后结果可能不尽如人意，那么这时候提出来，大家再进行讨论，制定方案。这样，从开始的需求分析，到工作过程中的思考，也许就可以避免我们最后这种情况的出现，能更快的提升我们的工作效率。
二：代码的规范性
经常啊，一个项目有好几个人共同参与，那么这时候，就要去制定一个代码规范，例如说类和属性的命名规则，到底是使用驼峰还是下划线，命名是否易读，重要代码是否有注释，有解释，代码的管理工具，不管用什么，git也好，svn也好，是否对代码的提交，合并，分支的创建，合并有合适的操作流程，这些一定要注意，特别是项目大了，人多了，这些就显得尤为重要。
三：封装与解耦
我们在写一个项目的时候，特别在项目的框架搭建上面，一定要注意封装与解耦。比如说，项目中那些东西可以抽离出来，做成单独的模块供其他模块使用，最经典的，网络请求部分和架构部分(MVP或MVVM)，常用工具类，这些东西都要进行封装，把这些东西抽离成一个组件，这部分内不涉及任何的业务代码，保证我们换个项目，这些东西都能直接接过去，完全不用或只需进行很小的修改就能使用。同时，在项目结束的时候，我们这个组件到底使用起来怎么样，是否方便，不方便的话怎么去修改去完善，这些都要总结。
四：承认自己的错误不足并学习
没有人能写出完美的代码，没有人能完全预测未来会发生什么，也没有人全知全能。随着一个项目的进行，出错是难免的，可能是我们代码上存在漏洞，导致程序崩溃，可能是开发过程中遇到了不可知的问题，导致项目延期。这时候，我们一定要敢于承认自己的错误，敢于承认自己的不足，并给出解决方案。这才是一个正确的态度，而不是去推诿，去做无谓的解释，那么都没有意义。
还有就是，程序员吗，学习是很重要的，技术在日新月异的发展，这个月我们使用的技术，可能两三个月之后就出现了另一个解决方案，另一个框架去解决这个问题。我们一定要经常性的去学习，去提高自己，但也不要盲目的去相信新技术，这份技术确实比你现在的东西更好，但它真的适合你的项目吗？技术的替换所花费的精力到底值得吗？想明白这些东西之后，再去决定新技术怎样去应用。
还有，没有谁的未来是一成不变完全按照规划来的，我们只能尽可能的提升自己，等到需要我们改变的时候，我们恰好也做好的改变的准备，这就很好了。