软件开发必知必会

软件开发必知必会

软件开发流程

需求分析

一个软件没有出现之前，只是有一部分人有一个想法，我需要一个这样的东西（想要一个孩子了）用来管理我的什么什么，这个时候一个想法出现了，就会有这个需求，他会找软件公司需求分析师来商量，这个时候一个软件就怀孕了，相当于开始发育了.需求分析是听完要求以后会将大概的功能描述一下，用Word或者Axure画出一个简单的Demo给用户看，经过几次确认以后需求分析师会最后确认功能是不是完善的，确认了以后进行我们的下一步，概要设计

概要设计

这个功能主要是干嘛的呢？很多的公司觉得没必要，其实是很有必要的，这个就是相当于先规划一下怎么平安度过怀孕期，对于软件来说就是软件的处理逻辑，大概的一个流程是怎么走的，大概需要哪些模块，怎么运行，需要大概多少接口，后期怎么维护等问题，做这些干呢吗？为了下一步-详细设计

详细设计

有人说，详细设计是很麻烦的一步，其实不是很麻烦的一步，我觉得是最难的一步，详细设计主要是用来确认细节的，接口的名字啊，控制器的名字啊，多少个控制器，谁来调用谁，这个不可以有错，因为后期码农是需要看这个开发的，你怎么起名字，他们就怎么写，所以这里出错也就意味着编码的时候也会错，最后会有一份详细设计书出现，这个就是告诉孕妇具体吃什么，怎么吃，多少量。

码农编码

很多人觉得这个就是搬砖，看着设计书就直接写就可以了，理论是这样的，但是为什么还有很多的bug出现呢？很大一部分原因并不是设计的原因（当然也有可能），很大原因是不规范造成的，还有就是是不是一个项目组的人可以协作处理代码，怎么做可可以提高编码的效率，这些问题都是在编码的时候出现的问题。这个是相当于孕妇实施那一套套餐的时候具体是不是按规范来吃的。

程序测试

这一步是里面很重要的一步，测试，我们不可能说写好直接就给用户用了，这个是不现实的，我们需要做的是先给测试部门进行系统的测试，当然这个测试不是按照用户的想法来的，他们会很暴力，举个栗子，一个按钮，正常的用户使用的时候会直接点击一次，看到效果就可以了，但是测试的时候不是，他们会疯狂的点击，知道他们觉得这个世界上不会有人比他们暴力的时候他们会停止，当然这是一个好的测试人员，很多的测试不会是这样的，他们觉得正常使用没问题就是没事的，其实一个软件好不好，很大一部分在于测试人员的测试力度。最后写一份测试报告就可以了。

软件交付

测试结束以后没有任何的问题的话，就可以写安装手册了，这个其实就是用户使用指南。

客户验收

交付后客户简单的测试以后觉得是和自己想的一样的，就收货，交钱.

码农维护

是不是验收以后就没事了呢？当然不是，一个软件很多时候是在用一段时间以后才会出问题的，所以会一直需要人来维护他们，当然不是说只是出问题才会维护的，主要的原因是软件会根据不同的需要更改功能，这样的过程也是维护的过程，QQ已经更新多少代了，是不是，这也是一个维护的过程。

项目重构

这个是一个项目如果出现了新的技术，功能没有改变的时候，为了用户体验，例如之前是SSH写的，但是运行的速度很低，用SpringBoot，大家都在用，用户反映很好，那么这个时候就需要项目重构了，用新的技术将之前的功能重新实现。

基本那就是这些了，另外细心的人也看到了非软件公司是没有详细设计的，这个解释一下，为什么呢？很简单，其实详细设计是和耗费时间的，非软件公司的人不会花费这个时间在设计上，他们就是直接告诉你需求，码农只需要直接编码就可以了，一般这样的对你用什么技术，什么框架是没有要求的。

编码规范

命名风格

• 代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束

• 类名使用 UpperCamelCase 风格，必须遵从驼峰形式

• 代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。

  • 说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即使纯拼音命名方式也要避免采用。

• 方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须遵从驼峰形式。

• 常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。

• 杜绝完全不规范的缩写，避免望文不知义。

• 为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽量完整的单词组合来表达其意。

编码规范

• long 或者 Long 初始赋值时，使用大写的 L，不能是小写的 l，小写容易跟数字 1 混淆，造成误解。
• if/for/while/switch/do 等保留字与括号之间都必须加空格。
• 避免通过一个类的对象引用访问此类的静态变量或静态方法，无谓增加编译器解析成本，直接用类名来访问即可
• 只要重写 equals，就必须重写 hashCode。
• 如果自定义对象做为 Map 的键，那么必须重写 hashCode 和 equals。
• 集合初始化时，指定集合初始值大小。

注释规约

• 类、类属性、类方法的注释必须使用 Javadoc 规范，使用/*内容/格式，不得使用// xxx 方式。
• 所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释、除了返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能。
• 方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释使用/* */注释，注意与代码对齐。
• 所有的枚举类型字段必须要有注释，说明每个数据项的用途。

单元测试

• 好的单元测试必须遵守 AIR 原则。

  • 说明：单元测试在线上运行时，感觉像空气（AIR）一样并不存在，但在测试质量的保障上，却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。

    • A：Automatic（自动化）

    • I：Independent（独立性）

    • R：Repeatable（可重复）

• 单元测试应该是全自动执行的，并且非交互式的。测试框架通常是定期执行的，执行过程必须完全自动化才有意义。输出结果需要人工检查的测试不是一个好的单元测试。单元测试中不准使用 System.out 来进行人肉验证，必须使用 assert 来验证。

• 保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之间决不能互相调用，也不能依赖执行的先后次序。

• 单元测试是可以重复执行的，不能受到外界环境的影响。

• 对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是类级别，一般是方法级别。

安全规约

• 隶属于用户个人的页面或者功能必须进行权限控制校验。
• 用户敏感数据禁止直接展示，必须对展示数据进行脱敏。
• 用户输入的 SQL 参数严格使用参数绑定或者 METADATA 字段值限定，防止 SQL 注入，禁止字符串拼接 SQL 访问数据库。
• 用户请求传入的任何参数必须做有效性验证。
• 禁止向 HTML 页面输出未经安全过滤或未正确转义的用户数据。
• 表单、AJAX 提交必须执行 CSRF 安全过滤。
  • 说明：CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。对于存在CSRF 漏洞的应用/网站，攻击者可以事先构造好 URL，只要受害者用户一访问，后台便在用户不知情情况下对数据库中用户参数进行相应修改。
• 在使用平台资源，譬如短信、邮件、电话、下单、支付，必须实现正确的防重放限制，如数量限制、疲劳度控制、验证码校验，避免被滥刷、资损。

建表规约

• 表达是与否概念的字段，必须使用 is_xxx 的方式命名，数据类型是 unsigned tinyint（ 1 表示是，0 表示否）。
• 表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。
• 表名不使用复数名词
• 禁用保留字，如 desc、range、match、delayed 等，请参考 MySQL 官方保留字。
• 主键索引名为 pk_字段名；唯一索引名为 uk_字段名；普通索引名则为 idx_字段名。说明：pk_ 即 primary key；uk_ 即 unique key；idx_ 即 index 的简称。
• 小数类型为 decimal，禁止使用 float 和 double。
• 如果存储的字符串长度几乎相等，使用 char 定长字符串类型。
• 表的命名最好是加上“业务名称_表的作用”。

工程结构

• 推荐使用图中默认上层依赖于下层，箭头关系表示可直接依赖，如：开放接口层可以依赖于

  Web 层，也可以直接依赖于 Service 层，依此类推：