程序中尽量不要用c:/temp作为临时目录
程序中尽量不要用c:/temp作为临时目录，而应该一个代表具体模块的、较特殊的名字作为目录，如c:/tempDirForDownloadShanghai 否则的话，如果大家都不用特殊目录，那它们就会共享c:/temp作为临时目录 1.如果不同模块的临时文件名恰好也相同，文件之间相互覆盖的风险会大很多 2.在清理时也很麻烦，如果要删除模块A的临时文件，要先把它们从所有文件列表中先挑出来再删，不能整个地删
破窗户理论 与 软件质量
摘自《The Pragmatic Programmer》 破窗户理论：一扇破窗户，只要有那么一段时间不修理，就会渐渐的给建筑的居民带来一种废弃感－－种职权部门不关心这座建筑的感觉。于是又一扇窗户破了。人们开始乱扔垃圾。出现了乱涂乱画。严重的结构损坏开始了。在相对较短的一段时间里，建筑的损毁得超出了业主愿意修理的程度，而废弃感变成了现实。 软件项目中也是这样： 如果你发现自己在有好些破窗户的项目里工作，会很容易产生这样的想法：“这些代码的其余部分也是垃圾，我只要照着做就行了”
Build verification test
In software testing, a Build Verification Test (BVT), also known as Build Acceptance Test, is a set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team. The build acceptance test is generally a short set …
web服务器的并发数
从web服务器的角度说，当前的并发数就是 当前这个瞬间，我们的应用使用了多少tcp连接提供服务 apache httpd的mod_status模块可以查看这个值 那什么叫服务器的最大并发数呢？ linux默认可以建立1024个socket，是不是最大并发数就是1024呢？ 这里要考虑一下web应用的健康状态。如果web应用在500连接时就已经慢得像蜗牛，或者频繁给http500错误，那并发500又有什么意义？ 最大并发数应该是指 应用的功能和性能满足需求的前提下，所允许最大连接数。
双方确认接口文档(word)的办法
可以采用这种模式： 1.文章修订记录中有“确认人”、“确认时间”字段，和“修改人”、“修改时间”字段一样重要 2.除了“确认人”和“确认时间”，还可以有一个字段：“此次修改内容的颜色”，若不同的修改同时存在，可以通过颜色来区分。一般情况下，这次修改用“红色”，待确认后改回“黑色”即可；但如果这次用了“红色”，而在这次修改确认之前，又有了新的修改，则新修改可以采用“蓝色”，对方确认了红色修改，则将红色部分改成黑色，对方确认了蓝色修改，则将黑色部分改回黑色，以保证不会混乱 3.一般情况上，在本次确认之前不会提交新的修改，这时只用一种颜色代表新的修改就可以了 4.重要的部分可以用粗体、斜体表示，但不能用颜色表示，以免与“新修改部分”混淆 5.接口模式约定了一定要说到作到，要不然就会造成更大的混乱
应在需求文档里写着：数据保存期限
1.流程数据保存多久 2.业务数据保存多久 需求文档里的保存期限是从业务角度出发，“数据”用需求中的概念来表示 维护文档里的保存期限则从操作角度出发，“数据”指的就是具体的表、具体的文件等
系统日志是不是应分三种？
1.业务用户看的 2.系统管理员看的 3.开发人员看的
最小文档模板 — 需求文档的开头部分
1 引言 本文介绍了XX系统的功能需求。 本文读者为需求人员、软件用户、开发设计人员和测试人员。 1.1 参考资料 《XX系统_术语表》 2 功能简介
最小文档模板 — 设计文档的开头部分
1 引言 本文介绍了XX系统的设计。包括领域建模和一些功能的实现思路。 本文的读者为设计人员、测试人员。 1.1 参考资料 《XX系统_术语表》 《XX系统_需求规格说明书》
讨论：J2EE系统中的“数据文件”应该放在何处？
J2EE系统中的数据文件可以分为两类： 1.编写代码时确定的 静态文件，只能由开发人员手动修改，相对固定。如企业内部网站主页上通过固定超链接引用的“请假单.doc” 2.系统运行时产生的 动态文件。这又可以分为两类： a.文件产生后，需要作为业务数据一直或长时间保存。如 BBS用户发贴时产生的附件文件。此类文件可称作 较持久的业务数据文件 b.文件产生后，即时应用，即时作废。如大流量I/O时为了减少内存消耗而临时存在的缓存文件。此类文件可称作 临时数据文件 这些文件应该放在何处？是否应该和 源程序中的其他物理实体(.class文件,jsp文件l等)杂揉在一起？ 个人认为这受到软构件部署（从开发环境发布到生产环境）和系统分布式运行的制约。以下按文件类别逐一讨论： 1.静态文件。这类文件可以当作代码，和class文件、jsp文件一样，不受部署方式和生产环境 的影响。比如说，部署时可以和class文件一样直接复制，如果系统采用分布式运营，这类文件在各机器上都可以保留相同的副本。因此静态文件可以与源程序杂揉在一起 2.动态文件。 a.较持久的业务数据文件。 I.在开发环境进行单元测试时可能会产生一些业务数据文件，这些文件不适于拷到生产环境，如果这类文件和源程序中的其他实体杂揉在一起，那么部署前就要先拣出来删掉，此举无疑增加了部署的复杂度。因此，此类文件不能和源程序放在同一个目录中。 II.此类文件往往被分布的各个程序共享使用，或者将来可能会被共享（如当前的单台WEB服务器以后可能要做集群）。因此，此类文件在就不应入在系统某一进程专属的机器上，而应放在一个独立于任何进程的机器上，如一个独立的FTP服务器，但这样做的代价是 额外添加了一个服务器的维护量，并影响物理架构 b.即时失效的临时文件 I.若考虑部署方式，应与 持久业务数据文件 的处理相同，即不应与源程序保存在相同目录中 II.若考虑分布式运营，应于此类数据文件为临时文件，不可能为多进程共享，因此与使用它的进程可以放同一台机器上，如c:\temp。不过，如果一个系统中既有持久业务数据文件，又有这种临时文件，为了让运维人员觉得清晰，仍可以考虑采用独立于任何进程的文件服务器。这样做的代价是加大了程序设计的复杂度（远程读写文件的代码比本地读写文件的代码要麻烦一些） 结论： 1.静态文件当作*.class,*.jsp文件处理， 可以与源程序杂揉在一起 2.动态文件 不能与源程序混杂，并视持久程度，决定是否要放在一个 独立于系统各进程的文件服务器中