虽然专业是软件工程，但技术都是靠平时看书自学的。在学习软件工程、设计模式等较抽象的技术时，如果遇到晦涩的“教科书”时肯定是一头雾水；运气好遇到好书，那就有机会赞叹一下作者的理解能力，感受一下设计中的艺术。但如果没有实践，即便是好书也很难在记忆中留下持久深刻的印象。
于是乎，在学校里我就尽可能地去争取接触各种项目的机会。但学校里的项目情况毕竟与书上引用的行业情况不同，往往项目需求的提出就不是很规范，怎么才能在后续的设计中应用各种工程规范、设计艺术呢……
暑假的时候应聘参与了学校科研所的一个项目，虽然我是专注于Java方向而与要求C++开发的需求不同，但我看中了这个项目应该是比较规范的，至少招人就“一本正经”的，嘿嘿。果然，从第一次会议开始就很有味，一个需求就反复讨论了好久，还有每周的汇报……于是我就照着当时正热的《Thinking in UML》一步步来了次RUP，感觉很好。所以即使后来聘期结束了，我还是随叫随到，感谢卢老！（卢老人也好，带我一起吃了好多次大餐~我就爱吃……）
但学校中最多的项目还是那种只有一个概念，具体要实现哪些需求还得看前一阶段工作完成的程度而定，而且能不能实现也是未知数。于是开发的过程往往就是，实现了一个功能，添加需求，再实现一个功能……如此迭代。但这种迭代又不是软件工程上讲的迭代开发，在实现前一个需求时，对后一个需求是完全未知的，即使理论上可以预估到，凭借我们的经验也没能力预估到，这还怎么搞软件工程呢……
对于这类项目，我觉得只能练练手各种设计模式。在最近的一个服务编排项目的后期，由于各种需求差不多都定了，需要扩展的地方也都提了，功能也都实现过了，我就完全专注于练习应用各种设计模式了。打开Rose重新设计；拆开“函数式”代码改成“面向对象”的；遍历那些“繁重”的代码块，对着模式书查找适合的模式……于是看到大堆大堆的代码被“叉掉”，心疼啊~虽然知道OCP原则，但原本的那些代码实在“丑”得不忍心留了……
呵呵，这也算是一种实践吧，校园项目开发的实践。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
