开发过程的又一次洗礼

其实软件工程这个东西，完全是用开发经验堆积起来的。想想我3年来做项目的感受，确实如此。刚开始的时候，什么体系结构啊，什么什么都没有，只有功能实现。后来到了XX学长那里，开始熟悉MVC，开始接触ASP.NET的各种控件以及OO编码的各种技巧，那可能是一次质的飞跃吧，但是那个时候，对传说中的文档依然是狗屁不通，可能是因为XX学长本来自己开发项目就不用文档，哈 ，或者是那些东西他都不给我看。后来接了一些无关痛痒的小活儿，慢慢开始理解了另一位XXX学长的话，“那些东西都没用，除非你想赚钱”。后来做了目前来看，我最拿得出手的项目--CodeFish。这个东西耗费了整个暑假，成果嘛，还是可以忍的，呵呵。

后来到了群硕实习，慢慢接触些文档，开始慢慢理解了其重要性，说实话，真的是慢慢理解。其实我总觉得，如果真的想要理解一个东西到底多有用，唯一的方法就是，当你受尽折磨，苟延残喘的时候，突然发现，如果有了它，你的项目就活过来了。呵呵，这么说可能有点儿夸张。那这次的感受来看，对于Activity图，就是应验了我上面的话。以前做项目的时候，总是会发现一个潜在的问题，对于一个feature或者说是use case，一般都用文字去描述他的过程，但是问题时总感觉不够清晰，而且很容易漏掉儿什么，当开始设计API的时候，会漏点很多编码点，导致了很多问题。再有，用文字的描述，会让不同的人产生歧义，至少，我感觉不够理想。比如，我是一个team member，当我想了解这个feature是怎么样的work flow的时候，我就去翻出来use case的描述，看啊看，感觉是不够直观。公司一位资深的工程师向我介绍了Activity图的用法，那个瞬间，我感觉，整个开发过程中的死穴被化解了，我找到了一个我真的需要的东西。用Activity图描述use case的过程，清晰，简单，没有歧义，开发人员很容易的抽象中关键编码点，而这些都是我想要的。

最近的项目，涉及到了一种我完全没有见识过的开发理念，用Static Html做detail design。 今天上午的时候，我还觉得这肯定是疯了，不过现在看来，这一部分非常的必要，但我还是坚持，只有Static Html是不够的。当用例清晰的罗列以后，用html搭建页面逻辑，整合所有的需求，用来向customer反馈。这点我非常的同意，但是在这个过程以后，直接进入编码阶段，我觉得不太妥当。我不了解什么是敏捷开发，但是可能感觉有点而那个意思了。项目完全由UX来驱动，从最终用户的角度去推动整个项目。我感觉，就我的能力，凭着一个static html就来构架编码模型，我没有那么高的水平，一定会产生各种问题，更何况还有team的合作问题，可能这种方式需要一个很有经验的构架师来控制吧。个人认为，从用户角度出发搭建页面逻辑是非常必要的，但是同时，我们也需要从开发角度上来进行系统地分析，这可能是两个不同的角度，可以并行，不冲突，而且可以相互补充，促进。

呵呵，不知道大家什么意见呢？