很惭愧到现在才开始阅读代码大全，这个还是在微博上看到有人说起码代码大全应该读一遍才适合做同事的。于是下定决心读一下。

本科就见过《代码大全》真本书了，厚厚的一本书，然后望文生义地觉得这本估计就是算法小抄了，以至于后来在实验室之后也没有再去看了。知道上个礼拜，才开始觉得应该读一下。一翻书才发现我操这是一本软件工程的书啊，这中文书名真是害死人！！！

最近才看完第2部分：创建高质量的代码部分。

Lay the Foundation

第一部分主要讲的是软件构建的基础，分为4个章节，从软件构建的基础知识、到软件构建中的专业术语、
编写代码之前应该做什么事情、到准备开始动手开干。软件构建的基础知识我记得在本科毕业的时候想要进实验室曾经给自己下的一个任务，可是这么多年过去了，直到最近读这本书才想起来。比较系统的了解还是在进入公司之后，在看公司的一些文档才有了一个大致的了解。

在实验室的时候，需求基本上都是小boss来谈，而且就实验室的项目来言，感觉都是课程大作业类型的。项目都是属于快速交付类型，就是一边编码一边调试一边上线，需求也总是变化，一个项目经常做上好几年，可能都博士毕业了项目还没结束。如果遇到那种 科研类型 的项目还好，反正也没人用，只要按照合同来一步步做，最后糊弄过熟悉的专家就行了（突然想起来，上次实验室的“双态云”还被专家认可为国际领先！！！）。另一种就是有实际用户的项目，这种项目非常吃力，只要一进实验室分配到这种项目，未来三年五年就是做这种了。我11年的时候就一个人驻地开发了3个月，经常直接在用户旁边根据用户的需求来改。这有个好处就是能贴近用户的需求，但是也模糊了个别用户与通用的界限，同时纵容用户也导致一些伪需求的出现。

后来进了公司之后，发现公司里有点过了，可能为了明确责任吧，经常一个需求讨论挺久的。由于我所在的部门不是产品部门，这些其实也接触较少，唉，这涉及到另外一个话题了。现在有时候在后悔当初来这个岗位的决定，其实不太适合我，虽然我有信心做好，但会浪费很多时间。希望这段时间不是被我浪费，而是作为成为认真成长的一个阶段吧。

最近在开发 Grinder 的一个插件，用来控制并发的，蛮简单的一个，过程设计之类的就放在另外一个地方吧，反正这个挺简单的。

TODO

*[科研类型]: 合作骗钱