1.1 什么是整洁的代码？
如同优美的散文；
便于他人的阅读；
必须包含测试；
没有重复代码；
尽量少的依赖关系和尽量少的 API；
方法、函数、变量的命名要有意义；
1.2 有意义的命名
通过变量、函数或者类的名称，大概明白它的具体功能；
类名和对象名称应该是名称或名词短语，如：Customer、AdressParser，避免使用Manager、Data、Info模糊广义名；
方法名应该是动词或动词短语，如postPayment、deletePage或get
1.3 函数
最重要原则就是要短小。
（尽量把函数长度控制在 20 行以内，函数内尽量不要有嵌套结构）；
自顶向下读代码
向下规则，让代码拥有自顶向下的阅读顺序，让每个函数后面都跟着下一抽象层级的函数。
最理想的参数数量是零，其次是一，再次是二，有足够的理由才能用三个以上参数——所以无论如何也不要这么做。
从测试的角度来说多参数更会带来很多麻烦。如果函数看来需要两个、三个或三个以上参数，就说明其中一些参数应该封装为类了。参数不多的情况下我们可以把参数的名称加在函数名上。
1.4 注释
糟糕的注释别注释。
如果编程语言足够有表达力，不需要注释；
能用函数或变量标识别注释。
代码修改后，记得查看助手是否需要修改。
1.5 格式
一行代码不要过长，不超过100-120字符。
注意缩进
变量名申明尽可能的靠近其使用位置；本地变量在函数的顶部出现；实体变量应该在类的顶部声明。
某个函数调用另一个函数，就应该将它们放一起，调用者尽量放在被调用者上面。
1.6 类
类要短小
职责单一
类的名称应当描述其权责，如果无法为某个类命以精确的名称，这个类大概就太长了，类名越含混，该类越有可能拥有过多权责；类或模块应有且只有一条加以修改的理由。
内聚性强
方法操作的变量越多，就越黏聚到类上，如果一个类的每个变量都被每个方法所使用，则该类具有最大的内聚性
组织类时考虑代码修改
开放-闭合原则（OCP）：类应当对扩展开放，对修改封闭。
依赖反转原则（Dependency Inversion Principle,DIP）： 如果要设计一个灵活的系统，在源代码层级的依赖关系中就应该多应用抽象类型，而非具体实现。
2.1 自己更专业建议
对自己的软件负责，保证你的软件质量。
尽力让QA找不到问题。
写好单元测试。
坚持学习、善于总结
多练习，多实践
学会与别人合作。
保持谦虚，切记自负。
2.2 养成良好编码习惯
当自己感到疲劳或者心烦意乱时，避免再去大量的编码工作。保持健康的生活习惯，避免熬夜写代码。
2.3 多练习，多实践
自己开源项目或者为别人贡献源代码
学到的新技术解决实际问题。
对于一些优秀实践比如设计模式、设计原创、工程实践，不光要搞懂理论，还要在自己的后续开发中取实际。
2.4 时间管理
提前计划
需要每个人对自己的工作有一个前提的规划。
个人计划
每天早上话10-20分钟做一个整天工作安排，一般确定今天3件工作。
避免频繁的上下文切换，评估优先级，先处理非常紧急的工作。
提前准备，遵循WWGHQ原则。
What：这个会是做什么的？
Why：为什么开/参加这个会？
Goal：这个会议的目标是什么？
How：会议上我们需要讨论什么来达成这个目标？
Question：准备一些会上会问的问题。
控制会议节奏
会议保持紧凑，一般来说控制10人以内，时间少一1个小时。
联系客服
