《软件架构师应该知道的97件事》阅读随想

昨天新书到货《软件架构师应该知道的97件事》，吃完饭的养膘时间大致浏览了一遍，将一些阅读随想放在了推上。今天将这些内容整理于此……

《软件架构师应当知道的97件事》如果用#97TESASK 作为标签，应该没人反对吧？

“架构决定性能“ 如果我的前老板能深刻体会出这句话的含义，也许我就不必花那么多时间来告诉他，其实 erlang也解决不了当时的性能问题。

在读到这句话时，我立刻想起几个月前与我的前老板在技术选型上的一些分歧。系统出现严重的负载问题，我认为是粗劣的架构设 计导致的，而我的老板认为是开发语言动力不足。现在看来，我的想法没错，只是错在没能对项目的方向产生适当的影响。

“一行代码比五百行架构说明更有价值” ，这貌似正是刚刚@jeffz_cn在说的架构师的那个脱离代码的问题的 一个充分的补充。

赵姐夫在我看到这句之前刚刚与人在推上讨论架构师和程序员的区别，有提到脱离代码的架构师是不称职的。这个也说得是这个事 情，空中楼阁总是会摔下来的。

“设立软件架构专业为时尚早” ，呃，貌似兲朝数年前就有架构师什么职业考试了吧？

兲朝的事情，不多说啥了。在我那段瓶颈时期，我考虑了好久是快速考一个架构师的执照，还是正而八经去上个软件工程的硕士。 还好，没选错。虽然多花了不少钱，但是还算值得。

“架构师当聚焦于边界和接口“ 边界啊，为什么我们总是迷失于汪洋大海之中？因为我们是普通程序员，没能找到本应 关注的那些边界。

架构师是画圈的人，程序员是在圈里锄地的人……边界和接口，CMMI里面也用了很大篇幅说这个事情，不仅仅是个技术问题。

“确保简单问题有简单的解” ，金玉良言啊！我已经为此浪费了数年的青春，再浪费下去，恐怕就没机会变老了。

奥卡姆剃刀原则，如果上大学那会有老师哪怕简单说说这个东西，至少少走三个圈的弯路吧！

“起码要有两个可选的解决方案” ，在这次对于GUI开发岗技术选型上充分验证了这句话的正确性，这和“不 要在一棵树上吊死” 似乎是一个道理 。

搞技术毕竟不是领兵打仗，真要搞出背水一战，恐怕结果只能是全军覆没了。

“不要追求’完美’，‘足够好’就行” 恩，我认识几个程序员，坚持“完美”许多年了。呃，顺便提一下，坚持的结 果是尚未有完美的程序出炉。

我们都以为完美主义者是最完美的，结果完美主义者从来都没有拿出那个完美的结果。迭代改进，随景而动——王道！

“选择彼此间可协调工作的框架” ，这个让我想起好几年前跟 FleePHP 的作者展开的那场讨论，无论如何，框架的一致性和可解耦还是相当重要的 。

如果一个超级牛13的框架剥离了内置的数据层后，不论是 View、Controler 还是权限控制都跟抽了骨似的，这个框架还能用吗？Zend Framework 虽然不是个完美的框架，不过从这个框架上所学习到的架构知识是远远超出学习它付出的代价。

大致浏览完了《软件架构师应当知道的97件事》总结发现，诸位大牛无不是在“客户” 、“需求” 、“解 决方案” 、“成本” 、“进度” 、“个人修养” 上 面打转转，这是架构师成功的秘诀吗？

 

原文链接：http://www.mikespook.com/index.php/archives/563

附本书豆瓣链接：http://book.douban.com/subject/4745287/
互动网购买链接：http://www.china-pub.com/196660