读《设计原本》

FrederickP.Brooks.Jr.的这本书是我们从事IT的人都应该读读的书，虽然做软件随着历史变得越来越专业，但是对于从事软件编写的我们来说，历史会交给我们技巧的演变。

Brooks之前的《人月神话》我还没有读，不过透过一些简介，以及《设计原本》描述的细节不难推测出《人月神话》是一本教导IT如何高效率的编写出高质量的代码并且能够满足用户的要求。

做为IBM出身的大牛，在一个巨型公司工作了几乎半辈子，他身上会或多或少的沾染上大公司的通病。但是这不影响他在设计硬件和软件方面的权威。时代在发展，软件开发也从个人到团队到小团队的演变，但是一些共通的比如设计，会一直如影随行。对我们设计人员来说，最希望的就是一旦设计确定，就不会在变动了。但是在现实生活中这是不可能的。有客户的关系，有设计公司领导的关系，有设计人员的关系，有实施人员的关系，甚至一个扫地的阿姨都能改变设计的正确方向。这在作者的理解是要设计一个理性模型，但是这个理性模型可能有很多约束，包括已知的和未知的。这个理性模型有长处也有缺点。它可以有明确的分工，细致的设计，能够很好的预测软件的开发时间和消耗。但是需求是不断变化的。对于现在的我来说，需求基本上变动不大，约束明确，结果明确，我在项目中可以事先设计好功能的实现。满足Brooks的开发完整性就好。对于优美的软件，Brooks提到优美的框架是设计的目标和实现后的结果是一致的，并且附带代码简洁、功能明确的优点。

Brooks对与团队的协作，以及分布式的团队协作有深入探讨，毕竟在IBM做一个项目需要世界不同地点，不同时区的同事共通努力，团队协作是历史发展的产物，功能越来越庞大，需求越来越细化，都决定了大部分的开发者不能精通各个方面，每个细节都有相应领域的执牛耳者，这就决定了团队协作越来越重要。爱迪生可以一人发明很多东西，现在建造一架飞机需要各个团队成员通力合作。对于分布式的团队开发，Brooks提到了各种沟通手段，但是Brooks还是极力推荐团队成员面对面的沟通，这带来的结果不仅仅是技术和问题的交流更加流畅。对于文档书写，Brooks也是相当在意的。Brooks觉得好的文档书写是优美架构的一部分。在我们公司的开发理念就是，尽量把时间用到设计与开发上。我觉得和公司的规模，以及人员流动也有关系。这种现象在现在的小公司或许非常普遍。这也许是未来的一种趋势。[我觉得未来的公司都是越来越细化，应该是一个小而精的时代]。但是协作确实我们必要的。

Brooks非常重视人才的培养，Brooks再说中说过，他在IBM做过最正确的事就是把一位同事送到高校深造，而这位同事开发出的关系数据库一直到现在还是IBM的摇钱树。人才的培养不仅是培养他人，也包含培养自己，我们可以从以前优秀的设计中吸取精华，研习来提高自己的设计。而这恰恰是现在每个从事IT的设计人员所欠缺的。我们在设计建筑时，会去教堂，会去设计优美的建筑参观。去研究他的历史，他的架构，他的施工。对于软件开发，我们也需要这样的培训。

设计是预先思考的解决方法，他的优雅或臃肿，他的可扩展或固定。都是我们在设计时的经验总结。Brooks对于优秀的设计师是通过设计经验而取得进步还是生而就为设计坚定的选择了经验决定。经验是我们在设计过程中实实在在的碰到了问题并解决了，我们为什么使用这种方法而舍弃另外的方法都是我们在当时的约束以及当时的资源决定的。