1.不加理解复制代码：上线后出现意料不到的bug，并该块代码会很难理解，不易修改。 2.每次都从头开始：使用类库，重构代码，提取公共函数（光提取是不够的，还要根据职责进行相应组织分类）；写博客，有自己的代码库。 3.没自己尝试就开始搜索：不要让自己思维停止挑战，只有多思考才能进步。 [注：并不是要大家不使用搜索引擎，而是要告诉大家要勤思考，对一个问题要自己的想法，可能这个想法会很荒谬，不过没关系，一步一步来，总比止步不前的好；思考和搜索引擎好同时使用，而不是过度依赖搜索] 4.钻牛角尖：遇到一个问题，就一种方法走到黑，没有考虑用别的方法（给自己设置个时间限制，如果一个问题1个小时解决不了，那就要起来喝喝水，重新组织下了，对橡皮鸭或者玩偶描述问题所在，你有时候你就会恍然大悟；如果还是解决不了可以向同事请求帮助，不过之前你要先把问题组织好，有时候我们大半天解决不了的问题，被同事一句话解决了。并不是你的同事水平有多高，而是我们走入思维误区不可自拔）[注：其实这条包含了两条信息，第一：像橡皮鸭描述，这个过程就是重新整理问题的过程，走出误区；第二：向同事求助，帮助自己走出误区，前提要把自己问题要描述清楚，学会如何提问，而不是把大问题抛给别人] 5.忽略警告：对待警告和对错误一样对待，不仅代码干净，而且会避免了一些bug(遇到一些bug,找了半天，发现警告中已经提示)。 6.快速修复而不是永久性解决：容易引入bug,并且代码会很快腐烂，成为以后的烂摊子。 7.没有完全测试就上线：会出现意料之外的bug。测试时候要考虑全面（关键点，边界，还有函数前置条件）[注:代码层面可以使用防御式编程思想，前置条件校验，及时失败，在出现错误地方及时处理，而不是在对数据破坏后才出现莫名其妙的错误] 8.考虑一件事情不够全面，就夸下海口（某个技术点，没有认真去研究，了解，就夸下海口多久能完成或者这个可以实现）：造成自己痛苦的根源，如果研究后，发现并不是想这么简单，造成时间延期；或者根本解决不了当前需求，造成需求重新评审，会自己个人声誉造成伤害，让人觉得你不靠谱或者技术不行。 9.没有认真理解需求，遇到需求有歧义地方没有找相关人员确认：造成测试不通过，项目返工，时间延期；所有你认为该这样的，其实80%都是错误的！不要在理解需求时候带上你认为，然后不去确认就开始编写代码。 10.不添加日志（不要等到上线后，系统异常时候再添加日志，然后重新发布来找bug） 11.涉及到利益方面代码要慎之又慎：使用防御式编程，验证前置条件，出现错误快速失败；关键点打印日志；全面测试，注意边界条件测试，不要依赖测试帮你把安全性bug找出来[注：这个涉及到你的声誉，如果出问题了，那就是大问题] 12.写出质量不高意大利面条式代码： 造成自己噩梦的根源：易出bug,且不好修改，修改同时有会引入其他bug；尤其等上线后发现问题，大家来评审你的代码对你代码无语。 [注：改变这一切，就要考自己努力学习，提高代码质量，参考书籍有：代码整洁之道，代码大全，编写可读的代码艺术，重构改善既有代码设计，程序员修炼之道，重构与模式，敏捷软件开发:原则、模式与实践等，后面博客会有专为一个主题讲解这个内容]
补充： 如何使用技术来避免上述问题 1.前置校验后置校验 使用spring 提供的Assert方法。[注：可以进行再次封装，1，不暴露Assert，可以以后进行替换，2.进行增强，加入自己项目个性校验] 2.异常处理 统一规范的异常处理 目前我使用的是 数据校验全部放在 action层[方便提示，保障传到service层没有异常数据；（校验可以使用开源类库）Service层做断言，其他层如果有异常抛出，由action层【ajax】或者拦截器来出来]， 注：抛出的异常注意封装，让错误离最近的代码。容易排查 3.日志处理 目前使用：log4j。注意关键点步骤日志打印；级别的选择；使用拦截器做参数打印，方便排查错误；根据级别来输出对应的日志文件 4.可配置化 使用枚举，反射，表查询，设计模式等方法实现流程等可配置，而不是使用if else if等硬编码 5.单一职责 不论方法或者一个类，要确保他只且只负责一件事情（同一抽象）【影响该类的变化因子只能一个】 6.做好笔记 任何东西都记录下来，不要怕麻烦，不要以为能查到就不记录，记录过程也是总结的过程，学习的过程！ 7. 刻意练习 如何成为一个高手。 学会学习 进行大量基础训练。 刻意练习 让大脑在学习区，而不是舒适区；学习的本质就是脱离舒适区 及时反馈！！！！！ 学习就是把新东西和原来东西缝在一起；做笔记 注：每学习一个知识点，要写遍笔记。 8.关于命名下篇补充
