|
总的来说这本书还不错，我在豆瓣笔记上说是程序员架构入门的最佳实践。本书最后的几个例子都充分证明这一点，做什么该如何做为何这么做是否必要这么做等等问题扩展开来谈。 你之所以时时在寻求跨界，其实是源自你假设了“存在界线”，这就如同全栈的含义其实是“没有栈”，而当有人信心满满地要“成为全栈工程师”时，他的眼里便又有个“这个栈”的存在。 架构师需要超越自己与别人的所见，因为你观察与架构的对象称为“系统”，你看到系统多少的真相，决定了你用怎样的影像去表现它，并进而推进与实现这种影像，亦即是架构。 所以架构中最难超越的并不是某个大师或前辈，而是你以及你为自己所作的设定。 你的软件系统有良好定义的结构吗？ 团队里每个人都以一致的方式实现特性吗？ 代码库的质量水平一致吗？ 对于如何构建软件，团队有共同的愿景吗？ 团队里每个人都得到了足够的技术指导吗？ 有适当的技术领导力吗？ 技术选择其实就是风险管理，当复杂度或不确定性高的时候降低风险，有利可图时再冒点险。所有的技术决策，在做出选择时都要把全部因素考虑在内，这些技术决策也需要评审和评估。这可能包括一个软件系统所有的主要结构单元，下至在开发过程中引入的库和框架。 不要把全部时间都用于编码 因为技术不是一个实现细节，你需要理解为自己的决定所做的取舍。 软件架构师应该写代码吗？我直截了当地回答：“理论上，是的。”更完整的答案可以在这本书里面找到。为什么？因为技术不是一个实现细节，你需要理解为自己的决定所做的取舍。 软件架构师被看作是首席设计师，是把项目的每件事凝聚在一起的人。 我们生活在“互联网时代”。除非我们这个行业发展到软件的构建方式和预测工程项目相同，否则团队中有人一直跟随技术的发展，有能力做出如何设计软件的正确决策，还是很重要的。 和其他可选技术相比，我们所选的是否最合适？ 对该系统的设计和构建，还有哪些选择？ 是否应该采用一种通用的架构模式？ 我们是否明白所做决策的利弊？ 我们照顾到了品质属性的需求吗？ 如何证明这种架构行之有效？ 作为领导，让团队保持积极是你的责任，你的角色在整个团队中不应被低估。 99.9%（“三个9”）的正常运行时间意味着留给计划维护、升级和意外故障的时间每天只有1分多钟。 编码标准和规范：“我们将采用内部的[Java|C#|其他]语言编码规范，这可以在我们公司wiki找到。” 自动化单元测试：“我们的目标是核心库的自动化单元测试达到80%的代码覆盖率，无论代码开发是先测试还是后测试。” 静态分析工具：“所有的生产和测试代码在提交到源代码管理之前，必须通过[Checkstyle|FxCop|其他]定义的规则。” 一天结束时，不论是否与性能、可伸缩性、可维护性、找到有合适经验的人的能力等方面相关，你做出的每一个技术决策都有权衡。 如果你不明白选择X技术而非Y的权衡，那就不应该做决策。设计软件系统的人要懂技术，这很重要。这就是为什么软件架构师应该是建造大师。 但如果要向别人解释系统如何工作，你会一来就说代码吗？ 非正规的框线草图提供灵活性的代价就是一致性，因为你创造了你自己的标记，而不是使用UML等的标准。 忘了昂贵的工具吧。很多时候，你需要的只是一张白纸、挂图或白板，特别是当你有一组人想要以协作的方式承担设计过程。 代码会讲故事，但不会讲述完整的故事。 代码库也没有什么不同。尽管我们可以花很长一段时间绘图和描述每一段代码，但这样做真的价值不大。我们真正需要的是列出兴趣点，这样就能集中精力去理解软件的主要元素而无需陷入所有的细节。 把这个辅助文档当作一个指南，它应该给人们上手提供足够的信息，帮助他们加快探索的过程。 能讲述产品如何工作、如何演化。 系统实际上做什么是否清楚？ 哪些特性、功能、用例、用户故事等对架构是重要的，原因是否清楚？ 重要的用户是谁（角色、参与者、人物等）以及系统如何满足他们的需求是否清楚？ 上述已用于塑造和定义架构是否清楚？ 概括来说，架构就是结构和愿景，这个过程的关键在于理解重要设计决策。 敏捷和架构并不冲突。与其盲目听从别人的指点，软件团队更应剔除炒作，理解技术领导力的方式，在其独特的环境下量化所需的预先设计。 对于预先架构和设计，我的方法是要做到“恰如其分”。 在我看来，软件架构最大的问题是它在与软件行业每天创造的新事物竞争。 人们用于学习的时间和精力有限，但没时间通常不是团队不理解软件架构是什么的原因。 |
|
|
