今天来写一下开发过程中的感受。
1.不要以为自己测试完，没问题，就完事了。
有的时候自己测试和用户使用时看待问题的角度是不同的。也可能自己写的时候根本就没有明白业务逻辑，不明白需求。
2.整理思路的时间应该大于开发的时间。
之前有工作几年的领导说过这句话。当时只是觉得有道理，其实没有真正的明白。也就像现在我写在这个，别人看了也不一定明白。整理思路绝不只是自己设计自己的程序。而是一个不断交流，先整体，再逐步细化的过程。
3.不明白的一定要问。
这里不是说有问题，有 bug 解决不了就去问。而是说对于业务场景，对于需求，有疑问要去弄清楚。其实有疑问的地方，只是暴露出来的，自己不懂的地方，往往还有很多潜在的问题。甚至有些自己以为没问题的地方，往往起着重要作用。
当然有些 bug 解决不了，一般不建议去问别人。但不是绝对的，往往寻求建议的时候，他可能会帮你发现其他的问题。如果伤透脑筋都无法解决，这一点都不可怕，也不丢人。可怕的是你研究了很长时间没有意义的问题，方向都不对，就只是浪费时间了。
所以说这就区别于那些不很难，但需要细心的问题，和那些自己懒得思考去解决的问题。以及抱怨搜索引擎找不到，但也不是解决不了的问题。这些问题的特别点就是：一问别人，可能马上就说出来正确的方法。
4.不要怕改代码，也不要乱改代码。
不要怕改代码就是，有的甚至可能说自己不在项目直接改，我新建个项目吧，后面没问题了，一合并，版本冲突，方法不存在，参数不对，然后就只解决冲突了。不要怕改就因为有 GitLab，SVN，Github，Gitee 这些东西。不要乱改是说有时候不同框架版本结构不一样，有时候因为不会用他这个，我用其他的吧，我觉得没啥问题。然后发现，原来写好的代码，编译过不去了，改吧，好不容易编译过去了，这调用，那依赖，报错不停。
所以先学习是必须的，不要一不会了，就想办法用自己会的方法去实现。
5.不要侥幸心理
最常见的空指针异常，有些人可能遇到并不多。最起码一次处理，两个结果要考虑，也可能多个。前台来个参数，直接要进数据库吗。前台不是控制了吗，这话可不要说。
再比如说，一次数据库 create 操作，sql 执行时，部分异常，但不影响增删改查，最起码要看看异常，去解决一下吧。首先要删掉那个表，仔细一看，唯一约束没加上，肯定要去改 sql 尝试。这不是较真，这是基本要求。
6.找出别人的优点
不要觉得，大家工作做的工作都差不多，说不定别人完成的又轻松又快又准确
7.差距往往都是跳跃式的显示出来的
比如同样的高中考入不同的大学，同样的大学进入不同的企业。如果自己选择安逸，没人可以救你。
8.做自己
如果有人某一个方面做的没你好，工资一样，不要心里不平衡，只管努力，记住：眼光要长远，你的目标不是他
