随笔，顺便纪念下第一份比较正式的实习

在G公司干了三个月的实习辞掉了。

现在回忆那段日子，觉得自己写的代码挺垃圾的。大多数都没有考虑设计模式，最后写出来的封装性很差，而且组件和组件耦合度非常高，分层架构也只是表面上的分层，组件重用很困难。

究其原因，可能是因为开发的schedule比较紧，而且自己安排时间的能力也不够，所以经常指定plan的时候不清楚需要多久能完，而拿到schedule之后又特别紧张，草草设计匆忙编码，到后来就算有富裕时间，也没有时间和胆量做重构。

也许也是因为大家对代码的看法不同吧。在这个工作环境，头儿很重视文档，认为文档跟上了就okay了，而不是太注重架构。以至于给我一种：啊，只要实现了就行了的感觉，到时候有文档，就算你人走了看着文档也能怎样怎样。可实际情况就是，垃圾的架构会造成后期代码维护的成本无限制增加甚至无法维护，而文档再全，也于事无补。不是说你能看懂我写的和我的思路就okay了，而是就算这是你自己写的，当你想增加一个功能或者改变一点儿需求的时候，也要花上很大的时间和精力——OO都白O了～

静下心来总结了一下我写过的代码，以及同事写的一部分代码，发现里面几乎把所有典型的反模式都实现了遍，这真是一种讽刺。

这两天我老在想，为什么会出现这种情况呢。后来仔细分析了下，发现可能是由于领导层对技术的把握能力欠缺所致。到目前为止，我有两个比较典型的雇主，他们对技术都有一定的了解，但是深度却有所欠缺。这大概就像一个刚学会MFC的人，有一种天下应用我都能写出来的豪迈气魄一样。他们大概有一个想法，认为，一个应用，最重要的是创意和idea，而实现是次要的，因为有了这个想法，实现还能实现不了么，也许他们脑子里甚至会有一个实现的概要甚至憋两三天能给出一份系统设计。这样的想法直接后果就是，疯狂围绕着实现来安排开发。至于性能、可扩展性、可移植性、稳定性、安全性，都成了次要的。甚至于，在极端紧迫的schedule下允许开发者硬编码，更别提什么设计模式的合理运用以及反设计模式的避免了。有段时间我甚至一度怀疑有些人压根就不知道什么是设计模式或者只是知道个名字。

我不否认，创意的重要性。不过这是建立在已经拥有一个强大而完善的技术团队的前提下。而这样的技术团队，绝不是一个什么都知道点儿的顾问加几个coding很厉害的人，也许再加一些coding劳力就够了的。起码，得有一个真的懂架构和设计的人存在。

任何一本关于设计模式的书或者反设计模式的书都在强调一些观点。

就我的理解来看，这就好像，我们已经有了会基本功的民工了，但是怎样盖起一个东西出来呢？

如果只是盖一个厕所，那么大家想怎么盖都可以，哪怕一块砖一块砖的往上码，也出不了什么问题。但是如果要盖的是一栋摩天大厦，那么可就不是想怎样来都可以的了。如果没有足够的架构和设计模式方面的知识，那么搞不好根本就盖不起来。

现在的问题就是，我们能很容易的盖出一个厕所了，却以为就能盖摩天楼了，虽然本质上来说，它们都是『盖』出来的吧。

从这个角度来说，这个技术团队还停留在CMMI L1的层面上。

另外的另外，我发现在开发过程中，不光是我，还有同事，或多或少会有一点儿自我显呗的习惯。比如使用一些奇异的类库，或者使用一些自以为不错的设计方式，又或者，用一种大家很少见的方式完成编码。而最关键的是，产物实际上却是很糟糕的，也许是性能上，也许是架构上，也许根本就是典型的反设计模式。

这就好像，拿着篮球，把球场上所有的防守队员都慌趴在地，然后面对空无一人的篮筐，把球上在了蓝脖子上一样让人无奈——已经忘记了过人技巧是为了什么而存在的了。

有时候我会看到一些编码，真的很让人惊叹，为何能写的如此的好，而有些则相反，让人觉得无比的反胃。我猜这三个月，我写了很多让人反胃的代码。好在，有这么一段时间，可以让我好好反思一下。到底发生了什么，而我又能从中学到什么……

 

p.s. 写这篇blog没有针对什么人的意思，只是觉得，这三个月的实习生活怎样说也要留下点儿文字纪念一下，而不是如同浪花一样，拍在岸滩上了无痕迹。结果到头来我还是学不会鼓吹祖国形势一片大好啊～