@CoderGeek
谢谢回复～

1.2.3 基本明白了。4.5. 暂时没有概念。我先了解一下。

@NeinChn
谢谢回复。

- 超时
- 吞吐
- 性能
- 扩展性

这几点都没怎么遇见过的。偶尔出现处理方式都很粗暴
比如
- 脚本偶尔出点超时问题，直接无视，重来
- 性能不够直接把源数据拆几份多跑几遍

学到了。

@heiheidewo
谢谢回复～（原来回复不是 markdown 语法）

“单元测试”的没问题了。
“设计文档” 明白什么意思了。仍有一个疑问，写成完整文档的成本是不低的。在设计基本完成之前可能有变动的情况下。有哪些办法可以让自己跟别人审阅所说的模块划分，数据交互这些呢。目前只知道的 UML 一种，想学习一下各位都是怎么做的

@ybw
谢谢回复～

暂时倾向于一种流程是， 需求实现思路 --(丰富细节)-->大纲 --(丰富细节)-->代码

设计文档应该是大纲的形式之一。如果不用设计文档的话，那么写代码之前用什么方式理清框架，以避免比如 djangp model 关系写到一半感觉不对，最后返工这种问题。

个人理思路是用思维导图的形式，但是到代码产品这一块感觉不是很适合

@heiheidewo
谢谢回复～两点问题
**设计文档**
一直没注意过，我查一下实践

**单元测试**
听说推荐先写单元测试,用单元测试理清隔逻辑分支后再回来写文档？

@ungrown 是的。干过这个工作。每日工作就是各个模块发布。但是最终也完全自动化了。粗暴点说，碰见一个问题，加一个 if else。穷举完事。
@uechris 这个看上游具体代码管理工具了。git/svn 之类都有集成工具。没有的化，粗暴版的：自动化工具一分钟触发一次。监测到版本变动就继续往下。 愿意玩的，用爬虫之类的工具解析上游看变更。然后触发自动化构建。

@ungrown 是的。干过这个工作。每日工作就是各个模块发布。但是最终也完全自动化了。粗暴点说，碰见一个问题，加一个 if else。穷举完事。