读书-《构建之法》

　　起初我读这本书，就是“读书”，一遍看过去，脑子里就只是被动的接受信息，一点“感觉”都没有，更不用谈提出问题。个人对于这类专业书籍的阅读没有经验（《构建之法》不像是一本课本…也不像平时的一些碎片化阅读的读物…），于是我就用了一种十分笨拙的读书方法——每读一段问自己这段在讲什么，每读小节问自己这节在讲什么，每读一章问自己这章在讲什么。这样阅读，很累，我不得不将每一部分记下来（为了在概括的层面上继续概括），在概括的时候我发现自己又忽略了很多细节，读完一章之后，只能在脑海里留下一句话（很多细节被牺牲掉了…）。比如第一章，我给自己的一句话就是“软件开发就是在各种约束之下做出妥协，并尽全力做到最好”。但实际第一章还包括许多其他一些有关软件工程的知识（软件企业、软件与计算机的区别等等…），但我很难做到总结出一个全面的知识（我在概括的同时也略去了很多）。我在读这本书的第一个问题，实际上是如何真正的去读懂这本书，如果无法理解而只是在表面停留也提不出很多深刻的问题（我很认同一位学长的观点：如何去判断一个人是否读懂一个项目、一本书、一门技术，最关键的点就在于他是否能对其中的内容提出问题）。

      关于第一章的第一个问题，并不是我在读书的时候意识到的（很不幸，无论我怎么做，我也无法在读书时提出一个详细的问题…），而是在阅读其他一些东西时发现了冲突。

在书的P7有这么一段话：

“我们无法想象，某个商用型号的发动机在飞行时发现问题，最初的设计师会自己爬到引擎中敲敲打打，然后钻出来说：‘继续飞吧，我搞定了。’然而，在软件行业中，很多软件工程师往往以这样的行为而自豪。”

      我能从这句话里看出作者不是很提倡软件工程师在进入底层去解决问题的（或者作为一个设计者不应当再去底层的实现再去解决）。实际上，与软件不同的是，飞机是一个更复杂的系统，它所要涉及到的学科相较于软件要多得多，这导致了他们（即飞机的工程师们）很难去做到进入底层去解决那些问题（某些问题往往超出他们的能力范围）。而软件工程师为什么喜欢这样做呢？我认为，这就是软件工程师们去量化自己技术的一种行为（软件工程师们的技术完全可以做到自己“造飞机”）。在平时的工作中，我们很难向他人展示自己的技术细节（在封装完之后别人只在乎我暴露在外的接口能干什么…而不在乎技术实现…）。或者这样说，在下一级窗口看来，只要功能能实现，谁在乎上一级到底里面是什么样呢（当然优化也很重要…）？向其他人展示自己能力的方法也只有那些“解决别人解决不了的问题”的事了（而且往往这些事都是那些很“炫技”的事，显然深入底层的解决问题也属于此类）。当然，如果你不去展示自己的能力，我想对于一个有能力和自尊心的人来讲，那将是一场灾难。这是我自己的一个观点。

      其他有关第一章的问题我觉得大都因为第一章是“概述”的关系，我想在后续的教学中应该都可以得到解答。

      有关第二章，它不像第一章那样信息量巨大，我对这章最初的困惑都是来源于C#和VS，但都影响不大。第二章介绍了身为一个软件工程师应具备的一些东西，学会对自己的模块进行测试、效能分析，对自己的开发过程进行改进。

　　我疑问的是，单元测试为何或者怎么去帮助他人理解我开发的模块的。在我当下的工作中，我需要去理解别人开发的模块，希望借此可以加快自己的进度。然后我还有一个疑问：单元测试是否有必要写的复杂到（或者说具体到）去测试我的模块不能干什么（我在代码清单2-4中看到了类似的代码）。我猜想这算是去测试用户的极端行为（我不知道这种行为的正确称呼），但这些测试都是我们在项目完成后上线前夕进行集中测试时做得事——往往都是直接在前端上进行测试，而不是写单独的测试例。

　　第十六章，讲创新。我觉得在缺乏前面十几章铺垫的情况下（我只按课程要求读了这本书），我读起来就像看故事。讲实话，我提不出什么问题，任何一个论点下都是完美的论述过程来支撑（至少我挑不出刺）。我既没有创新的经历，也没有创新的想法，最多也只可能想做到书中提到的线性创新（实际上我有这样的项目）。我只能说一下我对创新的想法。曾经参加一次学校组织的创新讲堂，由两位来自宾州大学的教授给我们讲创新。他们更多的提到的是思维模式，如何去多角度思考问题，如何培养这种思维模式，如何去发现问题，如何拆分问题去解决问题（这点很受用，我发现在开发时这点很棒）。当然他们讲的也与本书有所重复，例如产品被用户接受的周期和产品研发的周期也有所提及，但他们更加注重思维这方面。而本书十六章在我的理解中似乎更多的是从工程角度、商业角度去阐述如何不仅仅是做到创新，而是做到“Innovate To Win”。虽然同样很受用，但这部分我个人觉得并不是很适合现在的我们阅读，它更适合那些刚刚开始创业的迷茫者。的确，只有活下去才能继续创新，但如果连创新的门都无法进入，那也无从谈起创新了。这部分是我在读完十六章，在写下这篇博文时突然想到的东西。