回溯,软件开发过程中的病态。

2月中我改1591、1597问题.上司当时说很目前很混乱，改好之后应该会好很多。这句话
我时常听到、可能我比较敏感、所以记忆中尤为清晰、应该是第三遍了。工时费和TREE 都听到过。
还有代码猜不透、担心出问题。为什么会产生这样的结果？
我想了很久、得出一个结论:即使不断提高个人能力，这一状况也得不到改善。
会想过去的开发过程，我们做的还很不足、是很底层很底层的开发。如果获得
成功、我觉得那也是在 悬崖上走钢丝、走着走着貌似看起来安全的走到"尽头"了、这可能吗?我一直有这种走钢丝的感觉。其实不论卜卦表达式的修正、
VT5 的TREE、工事费面板、其他一些功能。在老师提出修改之前、我都预感到有一次大的修正。也许天翻地覆。。
我也提到出很多、但深感个人精力有限、总之发现一个说一个吧。
回过头来说、为什么呢？为什么简单的可编程功能、也不涉及高深的算法、却如此困难呢？其实仔细观察不难发现。整个开发过程都存在这样一种现象:
1.提出产品设想、这个时候只知道要做什么
2.提出一个核心切入点。 然后开始了、开始了!!!开始编程了!!!根据这个切入点让程序初具运行能力
3.不断mantis，不断的往上追加功能
4.测试、demo发现重大问题、或者问题不间断。
5.返回、针对问题。进行颠覆性的修改。。。而修改还常常产生BUG 和再加上受限于现有框架、时间、成本限制。
最终给了一个不算美好的产品(中国的软件公司好像都这样。。。)。我自己对此都很不满意，因为可以做到更好。。

6.紧接着上述留下的问题、导致4和5的循环开始了。任务重、时间紧。不断修改。不断破坏。甚至连扫除修改的痕迹的时候都没有。直到看似结束了。然后下一个循环开始了。。。。。

整个步骤完全是病态的、不健康的。 不断的追加功能。就像是有了一个不是地基的地基、然后不断的把水泥块扔上去、想去
造一个楼房、或者说不算大的大厦。最后就是向人的经脉一样、堵塞不通。最后才发现病症、又去大禹治水了。往往已经深陷
泥潭了。。。
整个步骤归结于:开始与混乱。中于混乱、结束于混乱。周而复始。最终都是功能不流畅、用户体验不佳、内部代码看起来是畸形的结构组织

现在回想起、一本关于开发的书。前五章、五分之一的部分在讲软件开发中除了开发以外的内容是多么必要的!!!!

产品设想 之后，大的软件应该形成需求文档、这在现有VT5已经不显得那么重要了，不算好的、基本能用的框架已经形成了。
再改也只能下一版本了。
我们来说功能吧---针对上述问题、其实VT5整体也是这样。在函数级和类级编程。看这样一个普通的编程过程:规格文档、把某一功能
形成完善的、具有指向性的规格说明。 拿到这一规格说明、然后分析数据、前置条件是什么、后置条件是什么、隐藏什么、
功能什么、考虑数据格式、错误处理机制等这样概念、然后伪代码、在此之前千万不能去写代码，最终翻译成编程语言。可以看出即使一个函数就如此严谨、何况更大的发开行为呢?
正是基于完善的规格说明。才有了可靠的设计、产生可靠的程序。打个比方:
就拿J1这样的变量、他到底支不支持Jx。没谱、真的没谱。全看运气。为什么？因为没有基调、没有参照物、没有规格说明。
混乱了？这是必然的结果。编程人员的主观意识决定了最终代码的行为，而人与人的主观意识完全不同、当然猜不透了。
归根就地---缺乏参照物、都在凭空捏造。。捏成什么是什么、最终为了统一又去调试、修改。看、这又回过去了。

规格说明、或者说需求文档。牵涉到用户需求、产品设计、UI设计、技术上的支持...总之方方面面。做多少设计？在哪里做设计。。
这两点我们现在做的也是欠缺。 个人:在这个过程中、我应该处于什么样的角色?

设计做多少 受限于 团队规模。四个人、做VT5项目的设计、细致到某一细小功能这不现实、真要这么做VT5甚至看不到代码了(果断项目失败)、
这也是为什么至今看不到VT5整体规格说明。不难看出来、我们团队还是人太少了。所以有些方面注定无法尽善尽美。
商业开发、做百分之30的核心设计、后续的百分之70在开发中不断迭代；生命攸关的、使命攸关的则反之。而excel核心设计短短一个下午达到百分之30、这一定不现实!!!!!!
其实不在多少、而在于这个设计、这个文档的形成是否在整体框架上 定下了基调、具有很强烈的指导性和扩展性、为后续开发提供了坚定的基础。。显然现有的
VT5达不到这个水平。而是想到什么做什么、又变成了继续堆水泥块式的开发了。。所以很难从VT5上找出统一概念完整性，甚至编程风格都是糟糟的。难以给人畅通无比的感觉。
当然、这也受限于之前我的技术能力。

在哪里做设计。其实这是一个话题。拿卜卦来说吧、初期的excel确定是我和吉老师两个人定下来了。其实在这里我们已经错了。卜卦有两个用户群、
一个是用户、一个是excel编写者。决策的重要角色应该反过来。因为日方是离用户群最近的地方、无论是excel编写、还是卜卦使用的用户。用户离日方最近、我则遥不可及了。
日方透彻的理解他们的用户需要什么、用户体验有着什么样的准则；excel则更近了、近到直接提出使用规则。而我们的讨论、当时是完全抛弃了使用者、采取通知的方式。
这完全错误。谁能保证百分之百让编写者满意、毕竟我们不是他。也许他有更好的创意。所以、设计应该在日方来做、离最近的用户群来做。
过程中我只能做技术支持这样的角色。我关注的是构建、而无法触及前端的、需求设计。毕竟在用户群在日本(还比如阅历、这方面知识、特殊的老年人群这都是因素，
或者我站在编程的容易程度去考虑、而不考虑使用的方便性)、哪怕提出、也只是参照常规的一些、现有的观念而已。回过头来说、
上述例子洽洽也印证了:检索面板和工时费的这两个事件。。。上述过程最终得到了excel格式定义、表达式语法规则、使用说明。等相关规格说明性的文档。开发过程
参考这些可做开发中的设计、形成可靠的代码。基于这些以后也有论证、这都是为整个可靠的编程过程提供保障。代码不会去猜、因为有文档。减少担心、因为已经降低了修改频率、
还有参照物做为依据。不用发现病症、再去治疗。因为有指向性的说明。可以避免很多诸如此类的病症。再举个例子、比如LOG。很简单明了的事情、但编程初期没想到、为什么？编程去了、
压根没去想---人力的有限性。如果有这样一个规格文档、或者编写者提出了这么一条要求、更甚着提出对LOG 的要求。编程初期就考虑为编写者提供参考信息、效果会不会好很多？
最起码不会急急忙忙的亡羊补牢、可能还面临着补的不好危险。比如日方罢工四天、如果有这样一个文档、提供可靠的依旧、是否会降低这种消耗？
最起码不会回过头大改一番、也许参考文档可以修正小的BUG也难说。当然这一假设抛出中日两方节假日的关系来说。

我们来假设这样一种开发过程:

1.产品设想

2.产生核心百分之30需求，产生文档

3.完成百分之30需求设计到 规格说明的翻译,

4.编程设计/实现       #3和4其实基本上是一起的。

5.发布、或者内部代码审核、或者内部测试。总之:以某种手段验证前期的工作。

6.上阶段工作结束、产生新的需求。在百分之30的主干线上、去统一设计【很重要!！！！】、思考。产生百分之60的需求

.....

迭代、不断迭代、不断不断的迭代。。

这正式敏捷开发的中的步骤。。我们做不到极其正规、但可以近似正规。令人难过的是我们连去做都没有做。总是做成糟糟的样子。

 

话题往外了引申、规格的建立。必然增加时间成本的开销，相应的减少构建时间。就必然、有一套机制去管理时间、也必须建立相关制度。这又牵扯到团队规模、公司规模。等等一系列问题。。
上述的概论都是偶然性的问题、且都被前人所解决。为什么我们做的不够好？为什么出力了却没有事半功倍?反而拖泥带水、不断返工？不尽然是 软件开发是困难的。这值得深思。。。。
总之:好好学习、天天向上吧!