工作三年之后的思想的进步与转变

1.写文档

这真是个头疼的问题，虽然写之前和我说过了那些需要注意的，但在我出错之前是完全不懂告诫我的是什么。结合我自己的情况我希望以下几句话会对你有所帮助。

1.要以客户的角度去看待文档，因为决策者很大一部分不是技术。
2.要写清楚操作步骤，不要用技术语言去写比如“对某某单击触发XX事件，该事件通过http请求干了点啥，我在其中用到了怎么怎么牛逼的技术”，请直接说事情：“这个按钮可以用来干啥”简洁明了，你用黄金镶钻的铲子炒的菜也不一定好吃。
3.要有逻辑顺序，按照我是谁（需求）、我在哪儿（当前现状）、我要干嘛（方案）、为什么干（技术分析）、怎么干（实现步骤）、这么干有啥好处（总结）

2.版本控制，持续化集成

好几次了，因为我们是为自己公司做项目，所以经常有奇思妙想，开发人员较多所以虽然使用了版本控制工具git maven等等，依然出现了某些人忘记提交或者提交时有冲突乱解决的情况

1.代码审查重中之重，要有单独的管理人员每天对项目负责因为不确定什么时候会去做展示。
2.要做好稳定版本，一定要确保有一个可运行的正式版本无重大错误的版本。

3.代码注释

说到这里能被气死，因为写代码总是会复制粘贴，糟糕的注释由此而生，还有有些变量和常量他们的生命周期不同不写清楚注释会出现取值取不到的时序性问题。

1.变量的生命周期，一个变量假如是全局变量，如果不是熟读代码很难搞懂他什么时候赋值，什么时候空值，全靠逻辑和约定，这些如果不写清楚怕是过一段时间自己都忘记了是怎么做的了，当别人继续写的时候他脑子都炸了。
2.写过多线程的知道一旦出现异步请求要么加锁要么写回调保证顺序正确不会出现空值警告所以写代码时能传值就传值不要让一个变量的生命周期特别长不然换一个人非常难理解代码的执行顺序。

4.敏捷开发

虽然名字是敏捷但他给开发过程加了体重，小团队和气自己商量着来很爽，但一旦人数多了就要将同步请求换为异步执行（这里指的是人），我们使用过scrum谈谈使用和感受。

1.使用scrum，在项目开始时由团队在一起理解需求出需求。
2.分析需求将需求转化为方案，根据根据方案制定实现步骤。
3.当上述事情完成之后，估算项目周期然后领任务，时间富裕的情况下我们可以以兴趣为主这样能调动成员积极性还可以增加知识储备，如果不富裕则化身码农搬砖搬快点。
4.开发周期中我们会早晨开简短的立会讲述一下今天顺利的情况下能完成的任务，然后上一天出现的问题可以早晨说出来让大家一起帮助解决，主要是想增加团队融洽性让团队成为团伙！

5.积极向上的意识

这里就不分步骤了，想到什么说什么能理解多少算多少吧。

不要轻易想离职，好多人心浮气躁分不清自己的能量到底有多大，只要你的环境能让你成长工资低点无所谓，因为你如果一两年就跳槽一两年就跳槽，等你想稳定的时候公司可能不敢相信你。
还有好多人拿朋友的狭隘阻碍了自己的人际关系（不要把朋友的敌人当敌人自己去评判一个人的好坏不要道听途说），都是人都有缺点优点，别人棱角对立了并不一定你们两个也是针尖对麦芒，谨记君子之交淡如水。
每个公司都有眼高手低的人，他们不爱帮助别人喜欢抬高自己私心很重，比如做什么事情都去询问你做得怎么样然后他想办法做的比你更好去得到赏识，敬而远之，这种最好是被他坑一次然后长心眼，也不要一毛不拔变成铁公鸡（不要把所有的人都想成坏人）。
公司都喜欢赏识懂得付出的人，只有你展现出了更高的水准才会得到高薪高职位如果你总是有着一种给多少钱干多少事的思想（给我这么点工资凭什么让我干这么多事）你很难让公司或领导主动给你涨薪水并重视你。我在这里着重声明一下每个公司情况不同你首先要确保你的领导不是个混球。