1. 接触一个新项目时新建一个「阅读」分支

接手一个已经上线的项目时，为了解架构和业务实现，阅读项目源码是必要的。而很多优秀团队是不需要且不允许写注释的，原因有：

• 如果编码风格足够规范，代码便是说明书，看代码就能懂，注释很多时候是多余的；
• 倒不是完完全全说“彪悍的代码不需要注释”，而可能是对于一个两周更新一次的上线APP来说，写注释和文档意味着要花费更多宝贵的维护时间，所以团队会更倾向于Team Lead花多点时间把控代码质量，并且允许团队成员对代码的命名稍微长点（表达得仔细点）。

对于没有注释或有了注释也不理解业务的项目，可以尝试新开一个“注释”分支，我们可以在上面随意注释、随意标注，作为短时间内的“笔记”分支，有利于快速熟悉新项目。

2. 尽量在正版电子书平台阅读技术书籍

先不讨论电子书与纸质书的主观喜好。从便利性上，有一个iPad或手机，到哪都能看电子书，所做的笔记可以搜索、复制、回顾、同步及分享。电子书是永久、轻薄的，更重要的是我们可以复制出书中想实践的代码示例，而纸质书没有这优势。目前绝大数书都能在亚马逊、多看、微信读书等平台找到。

微信读书书架

3. 配置文件中配置项或依赖包以字典排序的方式排列

之后维护和查找时会比较高效。

排好序的项目依赖包引用列表

4. 项目进入标准化后，视觉设计者应该发展并提出Style Guide（视觉风格指南）

Style Guide指的是整个APP的视觉风格指南，将指定的风格统一管理，方便团队交流与开发。

比如整个APP中，整个APP的文字主题色是#00dc55，我们把它叫做main_blue，在之后的设计稿和交流中，当我们使用这个颜色时，直接称颜色为main_blue就可以了；又比如微信的绿色按钮风格，我们可以封装成一个叫full_green_btn的style变量，日后说某个按钮是full_green_btn风格，直接设置它的style值就可以了。风格一致、命名统一，这便是视觉指南。

对按钮风格的命名

将风格指南做一个查询APP

5. 对整个APP的布局进行优化时，可以对layout文件的大小进行降序排列，从占用空间最大的文件开始优化

很明显，占用空间大的布局文件里，涉及到的xml代码和控件使用会更加的多，优化起来有更大的空间。

文件大小倒序的layout文件列表

6. 使用项目中的单元测试模块快速实现小规模程序的验证和调试

当我们想通过编程来验证一个小程序或想法时，通常是挺麻烦的。如果直接用手头开发的大型IDE（比如AS或VS）新建一个项目，需要很多步骤和初始化工作；如果把要验证的代码写在项目中，项目跑起来可能也过于庞大。

我们可以直接在单元测试模块中新建一个测试方法，在方法里写要跑的代码，然后进行单元测试就可以验证程序了。同样支持调试和断点，代码跑起来也非常快且不影响到项目内容。

单元测试及调试入口

7. 一个功能一个Git分支

在开发过程中，每完成一个功能点就创建一个分支。

这在后期的代码找回和代码管理是非常有效的。比如我们完成登录功能，就新建一个分支，做完后把这个分支提交到github，之后直接去做其它任务（继续创建新的分支，如果新任务需要用到登录功能的代码就基于这个分支创建分支，不依赖登录的代码就基于主分支创建分支）。

在技术老大检查代码时，如果同意合并代码就合并，如果需要修改代码，我们只需要切换到对应的分支并修改代码，随后再次提交。

在功能点明确的情况下，这样任务与代码分明的开发方式是比较高效的。

如何命名分支？

看个人习惯而定，我个人的分支命名习惯是【名字/日期+任务类型_任务简单表达】，其中任务类型是指故事点的类型（featrue、bug、chore）。如命名我做的登录功能分支可以是Leslie/1012feature_userLogin，这样的命名方式包括了作者、日期、任务分类和任务简更描述，日后搜索起来也方便。

缺点

随着时间的推移，做过的任务越来越多，分支就越来越多，一年下来上千个分支是有可能的。但Android Studio貌似不支持批量删除分支。

Android Studio里的分支列表

8. 批量删除Git本地分支

我们可以去删除Git的配置文件。在项目的根目录下，我们可以看到隐藏文件夹.git，里面包含了各种信息。

分支对应的路径

文件夹里的内容

我们把分支的文件批量删除，重启Android Studio，对应的分支便不会出现在Android Studio的分支列表了。

9. 跨项目搬运代码时，尽量不要过早对源码进行重命名

当我们从甲项目搬运大量代码到乙项目时，搬运的代码一定会含有原来项目特定的命名。在搬运工作完成前，不要过早对代码进行重命名，原因是如果过早对代码重命名，之后再次搬运相关代码到新项目时，新项目是无法自动地对对象实现引用的。这时候只能自己手动修改名字，一是低效，二是容易出错。所以，重命名的工作最好在代码搬运工作完成后再做。

10. 前端后端分开工作

移动端依赖的服务器后台在测试和维护时，应该将代码跑在另一个备用服务器，不影响移动端继续开发，等后台完成更新后，再占用短暂的时间停掉正在使用的服务器，把新功能推到正式的后台。即区分QA和Release环境。

11. 做报表时使用PS工具实现比例的计算

Ctrl+R唤出PS的标尺功能

拉取标尺线到需要的边界上，形成了排版区域的区分。

调整图片大小，把宽设置为100个单位

这样做的目的是方便换算。效果如下图，我们可以通过蓝线在标尺上的刻度直接知道这个位置是水平方向的百分之多少的位置。

image.png

12. 做运维部署时，使用流程文档进行操作和部署

不要对自己的思路和记忆力过分自信，配置和部署是非常无聊的事情，如果中间环节出现问题，人可能会变得烦躁，随着思路会被打乱。最稳当的方法是事先写好部署的流程，按着上面的内容和步骤做，如果一步做错了，解决完问题，再从头或继续着做，这样能更好地达到目的。