软件开发之我的一点想法

1、前期总体规划：
数据库设计、示意图、流程图、用例图、功能列表图等。所有的这些图都是用于辅助开发的，有帮助的就用，没帮助的就不用，而且不能苛求完美。有些问题只有在开发的过程中碰到。更何况开发也不能苛求完美，有些当时自认为正确，但是实际的使用过程中可能会发现当时的想法是错误的，有一个叠代的过程。在开发的过程中尽量多收集相关的程序代码，看看他们的设计思路，从而少走弯路，在模仿的基础上创新是最快最好的方法。

2、开发：以功能点为向导，逐步开发。

3、对于团队，流程很重要：需求和 bug 有 Tapd 跟踪，产品发布按照节奏，需求提出前会和开发反复讨论可行性，有专门的质量跟踪，有专门的用户反馈，每天知道要做什么，也知道明天要做什么。有产品需求，也有开发需求！这个非常重要。很多团队，都是只有产品需求，开发好像牛一样，耕完地就不管了？流程其实没那么复杂，就是各司其责+节奏。

4、开发效率+架构的平衡；并向后展望3个月，或者半年左右，看看架构能不能适应。

5、Bug：

产品开发完成后，必然有 bug 。其实开发人员在工作过程中，是有一定的直觉或者心理预判的，即：某个功能模块的质量如何。 这里面的质量包括：可维护性、扩展性、算法渲染效率，还有就是bug与崩溃率。

功能开发完成后，就要开始守城了。
bug，一部分产生是由于架构带来的，例如比较复杂的架构，会导致复杂的实现细节；
但还有很大部分bug，其实是基于如下三个原因产生的：

A、对于某个api的不了解

B、粗心大意导致的

C、平台兼容性：这些异常情况，一部分靠测试发现，一部分靠用户反馈，还有一部分就靠自己的异常处理try...catch

6、自审
每过一段时间，都要站在高空俯视自己，问问：到底是在承担过去，还是在改变未来。
如果之前程序代码质量不好，后面修改问题的时间就会比较多。到了开发的中期，得多问问自己，你在不停的改正以前的错误，还是在做新的东西。 如果修改错误的时间多一点，那就要注意自己的代码质量了！

7、注释
我很喜欢写注释。有大牛说：代码就是最好的注释。 可惜我还没有达到那个程度。所以，我会把注释写的非常清楚。其一：为了自己以后维护的方便； 其二：为了其他人接手的方便。

这是我在翻译君项目中写注释的方式。1：对于很复杂的逻辑，务必用12345的顺序依次写清楚；2 ：对于函数中的某个参数，需要解释为什么要设置这个参数，尤其是公用工具类里面的函数—说清楚参数的背景含义，可以让其他调用者理解的更加清晰。

8、代码结构
代码结构要清晰。有按照功能划分的，有按照 UI 结构划分的。还有公用工具类，有数据管理，有主逻辑控制。不管用哪种思想，有序的代码结构，可以让每个人感觉很干净。好比日本的收纳整理技巧让很多小资推崇，无非就是干净、整洁、便于管理。
而且，还有一个重要的好处：代码结构表现出来的其实是——程序的一个模块逻辑思想——让大家工作在不同的区域。

9、代码风格
代码风格统一！好比一家人，有叫 Tom 的，有叫安东尼的，还有叫流川枫、石破天、圣杰夫拉斯基，无所适从。理论上，看一个函数，就能从名称上区分哪些是成员变量，哪些是局部变量，哪些是全局静态值。
除了命名统一外，还有一行代码最大的宽度，函数的连续调用长度等，头文件的包含风格，也最好有一个约定。类的出现时间，创建人名，最好也加上，看起来没用，但到了追踪问题时，就能看出时间线的好处。

10、开发效率
开发效率可以用这些方式提升：
A. 构建公用工具类，方便大家使用
B . 使用开源的一些包，例如 ORM 思想的数据库等
C . 可以很快的找到问题。开发中，找 bug 的时间，往往是很多的。我用的方法有3个： 使用 try catch； 拦截所有 crash 到我指定的地方；超多的 Log，Log 有统一的控制开关。
D. 借力：数据上报用灯塔，崩溃上报用 bugly，公司 KM 上很多经验，拿过来用。

11、安装包体积
A、TINY 压缩图片
B、删除无效的资源文件

12、UI渲染效率
UI 是用户的第一感觉；UI 快并稳定，第一感觉就不会差太多；管理好内存，基本管理好了一半 crash；管理好 UI，等于管理了人机交互感受。
UI 上的开发是：渲染效率与渲染效果的平衡。
 

 

 

 

 

欢迎提出您的想法。。。