软件测试到了后期，出现了一个奇怪的BUG。几经查找，是因为对DB中某条数据的状态Flag判断不够，从代码中反映为只有IF而没有ELSE，这样反映到系统中就出现了意想不到的效果。一般来说，出现过两次的问题就值得总结一番了，这就引出了本节文字。
开发软件项目要接触到很多与状态有关的东西，如状态迁移。举例如：计划书状态(临时，草稿，校核，审查，审定，批准，发布，归档，作废)。暂时想到了这么多，状态单步变换尚可轻易把握，但状态可能会跳级变换及回退。这些变换主要集中在业务端，对数据表的状态字段操作应该是简单统一。假设有三级计划，各级计划有不同的状态，并且各级计划的状态相互影响，够复杂的。从设计者的角度来说，希望用尽量简单的方法实现现实的功能。但由于现实世界的复杂性，即使用最简单的方法实现也不是想象的那么容易。所以，对状态应有足够的重视。
涉及到编程，尤其是WEB系统。单兵作战的市场已难以存在，每个项目将消耗很大的人力资源。状态的问题是一个长期的问题，从分析，设计，编码，测试。套用一句俗语：状态无处不在。如果系统分析，将业务理清楚，将状态写清楚。如果详细设计，将处理表述完整，把状态的方方面面用各种图表列详细。如果编码，将状态的准确含义弄明白，将状态与各方面(业务,DB)的联系弄明白，对状态的处理在代码中显出条理来。如果测试，更要深刻理解现实需求的东西，应该行的要行，不应该行的一定不能行。
是否有过这种情况，一张表格在开发过程中被频频使用，且不时翻出来作为开发依据，成为珍贵的参考资料？状态迁移图是一种常见的图。还有一种二维表很有用，例如状态／动作的有效性检查。总之，在软件实现的各个阶段，要尽早地对状态结下天罗地网。
