写代码要有自己的原则，工作要有自己的方向。明确自己的原则方向后，就不会经常纠结事情该如何选择了。抽点儿时间整理一下之前的笔记吧。
注释
项目中，同样意思的名字一定要统一。
接口要尽量写上注释，实在想偷懒，也只能是那种函数很简单，名字很明确，没有什么歧义的接口，比如getter,setter。看别人的代码时就深有体会，毕竟咱还是对中文反应比较快，函数名字写的再好，也比不上中文几个字儿来的直接。（几周后，咱也就成了别人）
函数
函数名要明确 操作和操作对象，为的就是下次看的时候，不必再去看实现细节。
不要动不动就想封装，简单逻辑总归还是直白的一串下来比较清晰，省的下次再看的时候还要跳转。
重复用到的逻辑，一定要封装起来。
复杂逻辑一定要单独封装，比如某个计算公式，否则哪天策划改起公式来，可能你找这个公式的起点终点都得找半天。
函数太长了也很难阅读，读了后面忘了前面，所以这时候也只好拆几个函数出来。但是最好能注释清楚，否则不停的跳转，于是又回到原点了。
用配置表代替swith（if else）。
保持函数单一原则，灵活组合。需要组合的，比如那种非常长的界面参数可以用链式调用，甚至为了优化，可以在一堆链式调用设置参数后，来个.end()或者叫init()吧，最后才真正只能界面的刷新。例如，view.SetXXX().SetXXX().Init()
函数功能要单一。一个方法，一个作用！在概念上，他只做一件事情，尽量不要用标记位当函数参数（isXXX）。因为一旦出现这种标记位，说明函数中会因为这个标记位而做不同的操作，那可能意味着这个函数就要兼顾很多事情了。于是当你想要修改其中某个分支的功能时，是不是还得担心是不是会改到其他分支的功能？
互相调用的函数，应该放的近一点。按照从上往下读的习惯，调用者放上面，被调用者放下面。
尽量不要依赖数组需要去取值，否则多了以后，对序号能把自己对晕了，跟那种超长的函数参数一个道理。
工作处事
工作上的回答要简洁，有逻辑。别人只关心结果，不需要说太多细节，除非对方要求。
不要问别人懂不懂，不懂别人自然会问。
先想清楚，别急着说话。
接受一个功能，要尽量考虑完整。
组织内部的团建要尽量参加，积累人脉，多加微信多联系。
保持和同行业同事的频繁交流。
如果发现某个同事会自己不会的技能，一定要抓住机会偷师。
要时不时的总结！！！
好文
编写业务逻辑代码-清晰可维护是很重要的
[探索]在开发中尽量提高代码的复用性
GitHub上简洁代码的总结
王垠《编程的智慧》总结
新入职的程序员如何更快的融入项目当中？
自下向上的编写容易阅读的代码