这次Co-op找了一个小但是却很精的公司做。公司名字叫GGY，有人乱解读为“叽叽歪歪”…………

回正题。这家公司只有一个业务，就是制作维护一个叫做AXIS的软件。目前加拿大几乎所有的中型或者大型的人寿保险公司都采用AXIS做Pricing和Valuation(小公司不用是因为AXIS比较贵……)，美国和很多亚洲的保险公司也用这个软件。我上个term在Manulife的时候用的就是AXIS做valuation。当时觉得这个软件好难用，现在发现AXIS其实很好很强大…………

我在GGY发现了一个奇怪的现象。这家公司是由一堆中年男人和一堆研究生毕业不久的美女组成的。我感觉这种组合相当之暧昧。中间再加上两个co-op学生，实在是奇怪的打紧。

昨天天开始做第一个跟编程有关的任务——修补一个bug。因为之前Peter(公司的前辈，在公司可能有10年了，FSA)，已经把bug是怎么产生的找出来了，所以留给我的任务不多，就是按部就班的修正一下就好。我做的也不慢，到昨天晚上已经把开发版本的代码修改完了。今天上午打算修改一下已经发布的版本，但是被Peter叫住。之后我们进行了一个长度约为一小时的对话。然后我做的东西就被推倒重来了。

返工的原因很有意思——正确的不是最好的。这是个很严重的问题。其实我在大一上CS125的时候就曾经想过这个事情。当时学校检查CS作业的方法比较傻，只是核对输出的结果，算法再烂也没有关系。于是那个时候我做的很多东西确实是对的，但是并不好。我昨天修补bug的方法很快，而且一定是对的(昨晚在公司的cpu farm上测试来着)，从算法层面来讲也不算差。但是有一些严重的问题。第一个问题就是跟原有的代码风格很不一致。这肯定有个人作风的原因，不能讲好坏。但是我写的代码除了我自己之外，没人知道是干什么的。这个就是个很严重的问题。Peter给我做了一下示范，重新修改了代码。修改过后程序看起来统一性强上很多，可读性也强很多。这种Engineering的东西我在学校是没学过的。学校里讲了很多的理论，当然也有实践，但是实践依然是理论层面的实践，而且是每个人自己做自己的；现在跟人合作起来，面对的是很实际的software design的问题。在学校的时候觉得这些东西听起来特白痴，都好似些不言自明的道理，像什么认真写comment啦之类的，但是到了真正工业的应用中，我发现这些东西跟算法一样重要。

第二，细节没能做到最好。一个if statement，后面几个并列的条件，怎么排列，有不同吗？理论层面上，没有。如果bool a = true, bool b = true，bool c = false, 那么if (a&&b&&c)和if (c&&a&&b)有区别吗？运行出来都是false，if下面的代码都不会执行，看起来没区别。但是如果a,b,c需要调用函数来运算，而在80%的情况下c都会是false，那c&&a&&b就会快上很多，因为如果c是false，那a和b就根本不需要被计算。如果这个if statement是在一个loop里面的话，那c&&a&&b就节省了大把的运算时间。这又是一个Engineering层面的问题。Peter跟我说这个细节的时候我感到有些吃惊，觉得是不是太苛刻了。后来想想，为什么AXIS能成为几乎是世界上最好的精算软件，原因很大程度上就在与编程人员认真考虑这些细节，提升了计算速度。

我这回确实是亲身体验到正确的不是最好的，不但不是最好的，而且距离最好还相当的遥远。所以目标一定不能只是正确，要做就还是争取做得好。

今天先乱记到这里。等学到更多东西了再继续拿出来分享。