软件项目全过程(供CTO/技术主管参考)

- 整体项目过程中的流程
    本文不讨论或者只是最简单的讨论各项工作中的细节, 侧重点只是跟开发人员有关的一系列工作
    - 项目立项
        - 需求分析
            - 如何确认技术可实现性
                - 技术点可实现性评估
                    明确哪些技术点可以做, 哪些技术点不可以做. 
                - 效益/可实现性比评估
                    如果存在一些比较困难的技术点, 那么就需要评估性价比, 性价比过低的技术实现, 需要放弃甚至延后. 
                - 规模化评估
                    有一些需求并不存在技术难度, 但是, 存在规模成本, 可能会因为这些需求的加入, 导致产品技术规模急剧增加, 需要具体的指出来. 
            - 如何确定技术方向
                - 寻找同类产品, 评估可能使用的技术手段.
                - 要确认新技术, 评估可能的技术风险.
        - 项目规划
            - 对开发人员自我时间评估
                每个人尽可能的给出假如只是自己一个人来做整个项目, 那么, 可能的时间是多少. 
            - 综合时间评估
                开发人员必须向项目管理者强调整体开发的时间并不是每个人的开发时间的平均整合, 而是存在一个巨大的交流时间差, 以保证开发的安全性. 
            - 具体项目时间规划
                尽可能减少对细节的时间评估, 而重点保留里程碑时间评估. 
            - 对调试/测试时间的争取
                开发并不是直接开发就结束的过程, 调试/测试时间, 必须尽可能跟初期开发时间等同, 甚至超过开发时间. 
    - 产品设计
        - 功能和逻辑设计
            - 开发人员需要监督产品人员是否在偏离需求设计目标
                这是开发人员自我保护的必要条件, 因为开发人员之前做过的技术评估, 很可能会因为产品人员的偏离造成巨大的时间调整.
            - 开发人员需要检查弱逻辑
                很多时候, 产品人员会将工作侧重于强逻辑(或者说是主逻辑), 而忘记了一些相对次要的弱逻辑的可行性, 以至于拿到开发人员手里, 可能做起来会非常困难. 这时候, 开发人员需要尽可能在初期评判弱逻辑的完备性. 
            - 尽可能事先争论
                开发人员相对比较弱势, 很多时候, 拿到设计的时候, 觉得无所谓, 做着做着, 觉得不好做, 就开始争论. 这对项目有妨碍, 尽可能让争论提早发生. 
        - 美术设计
            - 对美术设计提出规范化要求
                美术设计很多时候, 会有偷懒的行为, 导致资源本身的设计和输出没有合理的规范. 增加开发人员和美术人员的沟通成本. 
            - 完整内容/空内容/半内容
                很多美术设计只关注完整内容的实现, 可能会让完整内容显示的特别好, 但是, 空内容就没有照顾到. 当然, 还有一个半内容, 也是需要关注的, 因为内容很少的时候(但不是空), 展示的效果可能会不如满内容那么好看. 
            - 输入的内容有序可靠
                需要开发人员找到一个自我组织资源的形式, 而不是随着美术人员而定. 
    - 项目/应用架构
        - 项目必须有自己的版本分支
            - 当前版本
                当前正在做的版本
            - 维护版本
                为过去的版本做维护, 一般上只有发生重大问题, 才会对维护版本进行管理
            - 未来版本
                涉及到新需求, 尽可能的放到未来版本的设计中去, 而不是实时在当前版本中处理
        - 环境设计必须有分层
            - 正式环境
                开发人员不允许有任何直接权限对正式环境进行处理, 一般都是由运维进行操作. 
            - 测试环境
                提供给测试人员的环境, 一般上数据有比较长时间的保留, 以保证尽可能模仿外网环境. 
            - 开发环境
                提供给开发人员的环境, 上面的数据随时丢失或者错误, 主要就是开发人员自己开发和调试使用. 
        - 服务端的常规结构/模块
            - Log功能
                对常用的操作进行Log登记, 以保证产品在服务端产生异常的时候, 回溯可能错误的发生原因. 
            - 备份功能
                - 数据库备份
                    对系统发生异常时候, 数据的恢复作用. 
                - 代码备份
                    每个发布的版本, 都有一个代码备份包. (目前有Git管理, 这个需求变得不是那么重要了. )
            - 服务发现功能
                针对服务端的服务变更, 能够尽快的处理
            - 备用服务
                加入服务产生临时中断, 能够快速切换备用服务的设计, 一般上, 就是使用服务发现功能来作到即可, 不需要那些过分复杂的设计
            - 公共配置服务
                当涉及到公司多个应用的时候, 多个应用之间有相关性, 尽可能的将一些公共配置提取到应用外层来, 以防止服务和服务之间交错造成的异常. 
            - 用户模块的独立化(*)
                这是为一般企业考虑, 尽可能独立用户模块, 从而保证应用本身的纯净度, 以及多个应用之间可以重复利用已有用户或者打通应用和应用之间关联的办法. 
            - 管道/队列
                管道/队列是一个成本比较低廉的超并发解决方案
        - 接口的注意事项
            - 规范设计
                尽可能的确定一套规范设计, 但不是将规范设计做死.
            - 接口认证/加密设计
                - BasicAuth
                - OAuth
                - HTTPS
            - 接口的时间间隔防护
                - 相同用户发起的低间隔请求
                - 相同IP发起的低间隔请求
                - 用户/IP封杀机制
            - 尽可能使用对象的动态存根, 而不是静态存根
                动态存根比如Token, 静态存根比如UserId
            - 使用JSON
                JSON是目前为止, 在可读性和数据量上面做的最平衡的一套数据表达机制. 
            - 错误的本质
                错误是为了调试, 而不是为了给用户提示. 
            - 分页的逻辑
                动态分页解决的问题, 是为了大规模数据发生时保证数据的完备性. 
            - 文档的简便性大于美观性
        - 文件结构
            - 能用cocoapods依赖, 尽量用cocoapods
            - 能用library依赖, 尽量用library
            - 如果两者都不行, 最后用代码级别依赖
            - 主体逻辑界面全部放在项目目录的最外层或者ViewController目录
                规模较小的界面直接铺陈, 规模较大的界面, 使用ViewController目录
            - 配置文件全部放在Config目录
            - 数据结构和内部逻辑设计全部放在Logic目录
            - 资源文件全部放在Resource目录
            - 第三方代码全部放在ThirdParty目录
            - 自定义界面或自定义控件放在View目录
    - 开发过程
        - 代码规范设计
            针对不同的环境和语言, 设计一套比较直观的代码规范, 从代码的质量上形成一套保证
        - 项目结构规范设计
            项目结构必须统一, 以防止不同开发者做了不同的工作, 从而形成混乱. 
        - 代码职责的设计
            代码必须有必然的职责响应, 而不是试图让一段代码变得万能. 
        - 界面逻辑图的必要性
            开发人员的界面逻辑图, 未必会等同于设计人员的结构图, 如果只是单纯的将设计人员提供的界面结构直接当做开发的界面结构, 肯定会造成一个巨大的陷阱. 
        - 缓存
            - 合理利用缓存, 而不是找最容易上手的方式
                确保文件. 数据库. 内置存储. 等用到最合理的程度
                - 文件
                    - 二进制内容
                    - 需要快速批量管理的对象
                    - 形成后台操作的动作
                - 数据库
                    - 规则化数据
                    - 需要组合查询的对象
                    - 与服务端映射同步的资源
                - 内置存储
                    - 快速存储对象
            - 相关缓存的合并逻辑
                - 两个不同缓存资源的同步化
            - 时间有限性判断
        - 异步事务
            - 异步逻辑线设计
                在每一个逻辑模块中, 都必须明确逻辑线, 不应该边开发代码, 边设计逻辑线. 
        - 工作模块的独立化
            - 模块本身的独立
                - 单一功能原则
                - 流程单向
                - 接口模型统一
                - 单一逻辑
            - 开发者的独立
                - 每个开发者对自己的模块有决定性作用
                - 对其它开发者的模块只有连接代码, 没有逻辑代码
                    连接代码, 指的是指向性或者调用的代码, 逻辑代码是指的参与其它逻辑段复合计算的代码
        - 共同学习
            - 有公共的学习资源交流平台
            - 定期分享
            - 务虚会议并不意味着真的虚
    - 调试/测试工作
        - 代码审查工作
            - 尽可能的利用工具
                有现成的代码审查工具来检查代码比较简单, 不需要花费大量时间, 所有代码全部过一遍. 
            - 每个人对代码规范的重视
                对于不符合规范的代码, 可以提出具体要求, 打回调整. 
            - 定期规范调整
                代码规范本身并不是一个稳定的内容, 需要开发人员协同定期调整, 不要指望一个规范可以用很多年. 定期调整可以既保持整体的稳定性, 也能保持在技术演进中的安全保证. 
        - 测试点列表
            - 将每个功能测试点具体化
                指的是功能测试点明确, 是可以操作的办法, 而不是一个笼统的抽象的描述. 比如: 测试系统的稳定性, 这不是具体化的测试点. 但是, 检查系统重复登录20次会不会出现异常, 这就是一个具体的测试点. 
            - 测试点打钩表
                测试人员会收集一些常规问题, 以及我们产品的针对性问题, 还有就是以往犯过的错误问题, 整理出来一个打钩表. 定期打印出来, 除了自己测试, 也会提供给开发人员. 开发人员在调整自己的问题的时候, 可以顺带针对打钩表检查自己的模块是否正常. 
            - 测试表分列
                - 测试点描述
                    包括测试的要素, 以及测试的方法等等. 
                - 测试备注
                    测试过程或者结果, 需要添加备注描述的, 可以自由添加
                - 测试打钩
                    测试人员之前针对测试结果进行处理的结果
                - 测试打钩附加列
                    留空的打钩列, 打印出来, 随便开发人员自己打钩的. 
    - 上线工作
        - 重复测试
            - 上线前测试
            - 上线后测试
            - 复合测试
                - 用户和用户之间
                - 用户和第三方之间
                - 超量并发操作
        - 上线资源齐全之后再上线
            - 宣传文稿
            - 产品描述文稿
            - 升级文稿
            - 产品图片
            - 宣传图片
            - ICON图片
            - 域名准备
            - 邮箱准备
            - 测试账户准备
            - 网站准备
            - 运营人员信息准备
            - 财务人员信息准备
            - 关键词准备
            - app分析埋点准备
            - 版本调整准备
            - 异常反应处理准备
            - 定价策略准备
        - 产品状态后续监控
    - 运营维护
        - 异常反应链
            - 用户反馈
                根据用户反馈的信息, 收集内容
            - 运营筛选
                运营根据用户的反馈内容, 判断哪些重复, 或者哪些无意义, 然后留下有用的. 再确定是我们的运营机制问题还是应用的问题, 如果是运营机制问题, 由运营自我管理调整, 如果自我调整失效, 则作为下一版本的立项需求. 如果是应用问题, 再汇交给开发团队. 
            - 合并分析
                - 紧急更新
                    当前马上更新, 甚至需要停止老版本的下载.
                - 升级版本
                    下一阶段立即发布一个新版本.
                - 下一版本
                    纳入接下去要开发版本计划.
                - 未来版本
                    纳入未来可以开发的计划.
                - 不处理
                    拒绝开发
            - 将结果放入开发工作计划表
                工作计划表可以是一个简单的TodoList, 文稿, 甚至是聊天群中的一句话. 
        - 运营活动管理
            - 活动情景提供
                运营设计运营活动的时候, 必须提供一个"活动情景"的文稿. 这个文稿, 主要有3部分构成, 1, 活动的功能, 描述以及其目标. 2, 活动的逻辑流程. 3, 活动的情景分析, 提供几个虚拟用户案例, 描述这个活动可能带来的影响.
            - 开发人员内审评定
                - 可实现性
                    开发人员确保这个活动功能是否可以做, 包括技术可行性和资源可行性判断. 
                - 实现性
                    开发人员确保这个活动功能是否去做, 可以做并意味着一定要去做, 因为如果涉及开发时间过长, 或者活动本身对程序稳定性有破坏作用, 那么, 开发人员可以拒绝实现. 
            - 将结果放入开发工作计划表

 

转载于:https://my.oschina.net/wyo/blog/838488