1. 软件设计原则
抽象化与逐步求精：抽象的过程是从特殊到一般的过程. 上层概念是下层概念的抽象,下层概念是上层概念的精化和细化。
逐步求精：把问题的求解过程分解成若干步骤或阶段，每步都比上步更精化,更接近问题的解法
模块化:即把软件按照规定原则,划分为一个个较小的,相互独立的但又相互关联的部件。
信息隐藏:每个模块的实现细节对于其它模块来说应该是隐蔽的
模块独立:模块完成独立的功能并且与其他模块的接口简单符合信息隐蔽和信息局部化原则,模块间关联和依赖程度尽可能小
2. 软件生存周期
计算机系统工程：包括计算机硬件、软件，以及使用计算机系统的人。数据库、文档、规程等系统元素
需求分析
主要解决“做什么”的问题
设计
主要解决“怎样做”的问题
编码
代码实现
测试
发现并纠正软件错误
编写单元测试用例，尽量覆盖每一个场景
运行与维护
在软件交付使用后对系统进行纠错和完善的过程。
3. 代码规范
遵循相关技术的最佳实践要求
如Java的《阿里Java开发手册》、python的《Python PEP8 编码规范》
版本控制
统一开发环境和版本，统一开发工具和版本 使用Git控制代码版本的迭代
编码控制
编码统一（utf-8）
4. 编写README
为什么要写README文件
目的是能简要描述该项目的信息，让读者快速了解这个项目。
它需要说明以下几个事项
软件定位，软件的基本功能
运行代码的方法：安装环境，启动命令等
简要的使用说明
代码目录结构说明，更详细点可以说明软件的基本原理
常见问题说明
包含的内容
项目和所有子模块和库的名称（对于新用户，有时不同命名会导致混乱）
对所有项目，和所有子模块和库的描述
如何使用 5-line code（如果是一个库）
版权和许可信息（或阅读许可证）
抓取文档指令
安装、配置和运行程序的指导
抓取最新代码和构建它们的说明（或快速概述和「阅读 Install」）
作者列表或「Read AUTHORS」
提交bug，功能要求，提交补丁，加入邮件列表，得到通知，或加入用户或开发开发区群的介绍
其他联系信息（电子邮件地址，网站，公司名称，地址等）
一个简短的历史记录（更改，替换或者其他）
法律声明
5. 其他注意点
- 没有版本控制，代码库和开发环境混乱
- 到处都用全局变量，可变范围太大，会导致程序后期不好维护
- 不做压力测试，到实际环境中往往就会出现更多的跟环境和性能相关的问题
- 没有很好的bug管理规范和系统，往往用word、email、excel等文本方式来管理bug
6. 管理方面
- 项目内部定期开会，负责人检查各成员任务完成情况，解决遇到的问题，分配新的任务，务必保证每周要有进度。
- 组内分工要合理，以MVC为例，谁负责M，谁负责V，谁负责C
- 内部沟通的及时性，有问题及时向负责人反映，避免到期任务没完成的各种借口
7. 软件效果
往俗的说五点：管用、好看、省事、便利、好使
