很遗憾的，最近在讨论问题的时候又引起了误会（因为是误会，所以已经化解了），从这里我想谈谈软件实现的一种思路问题。
在软件前期原型法包括界面原型和技术原型都是可选的技术，其中，软件原型主要解决界面式样和简单业务流程的；技术原型主要是证明给客户“我能做”或者解决/测试某种新的设计或者技术的。有时候，我们未必使用完整的重型软件过程（特别对于非商业项目或者小型项目），甚至没有提到原型法，但原型法也是可以使用的，对于负责任的分析设计人员来说这种做法相当常见。
在我的S-Brave中就存在这样的原型法实践需要，主要解决技术和思路验证问题。
在S-Brave系统的设想里面，有若干技术难点成为了我实现S-Brave系统的拦路虎，这些技术包括对Java源代码或者class文件包的分析（形式包括jar或者直接文件目录，对于复杂类包括内部类、多接口实现、多层次继承等是下一步需要解决的更细的问题）、对象的模型/图形化表示（包括之间连线和模型移动问题等）。这些技术如果不加以解决，实际上，我没有办法进行下一步的工作，自然我也不知道我的想法是否正确。尽管我可以自己花时间和精力去消灭这些拦路虎，但实际上这个成本是不值得的。我必须解决这些技术难点但为何他们又不是值得的呢（另外的说法就是这个不是我的重点）？
这是因为，尽管S-Brave项目是一个技术性的基础项目，class/代码分析和对象模型化是比较复杂也必须要首先解决的技术问题，但这些都不是我的设想的最终目标：我不是以解决这些技术问题为出发点，而是我要实现一个简单的在我的X-Brave基础上的新系统，这才是我的目的！更重要的，这个想法还需要检验看看是否正确和可行（包括广义成本考虑），在这个时候，在中间环节技术细节上纠缠是不值得不划算的，这就是为何我多次请教/探讨/询问甚至希望得到现成技术的根本原因。
这就是在一种非客户提出或者为了客户方便的技术典型的原型法。这种思路可以极大的节省成本开销，并且保证系统实现的有效性。
欢迎您在您的系统中也采用类似的技术原型法：关注重点，分离最终目标和中间技术难点的最佳实践之一。
