课堂作业02——读架构漫谈后感

    对于桌子的问题，作者采用“名”和“相”来描述一样东西，也就是阐述了它的作用以及由此得来的名字，自此其他人也就会明白这到底是什么样的一个东西。这里我了解到每个人对同一问题的看法不同，正所谓一千个读者就有一千个哈姆雷特。在软件测试课上，老师放了一张“找不同”的图片给我们，并说同学之间不许交流。最初我看出有8处不同，其他同学也喊着“6处，7处，8处…”，老师叫了几个同学起来说自己看出来哪几个，随着他们的回答，我的答案增至9个、10个，最终结果也就是10个。

    思想不同导致看待问题的角度不同，但无论怎么看问题都要看清问题的本质。就像土豆的笑话，女主人以他的角度提出问题，其实更像是一个解决方案；男主人接收到下达的问题，却没能正确解决这一问题。原因在于两个人都没有看清或表达出问题的本质。

    或许我们的软件测试课上，同学之间沟通一下是可以更好地解决问题的，但并不是所以的问题都可以沟通解决。因为要改进沟通，这也是一个大问题。搞明白目标问题“是谁的问题，是什么问题”，当然也是需要沟通的。为了帮助自己更快的搞明白，首先要做的事是问正确的问题。架构师应该问的第一个正确的问题就是：目标问题是谁的问题，即问题的主体是什么。

     对于架构的切分调整，都是对相关人的利益的调整。如果对于利益相关者的利益分析不够透彻，会导致架构无法落地，因为没有人愿意去损坏自己的利益。一旦强制去执行，人心就开始溃散。这个也不一定是坏事，只要满足原则就能够很好的建立一个新的次序和新的利益关系，保持组织的良性发展，长久来看是对所有人的利益都有益的，虽然短期内有对某些既得利益者会有损害。

      软件一直以来的动力，始终都是来模拟人和这个社会的，旨在把人类的生活模拟化，提供更低成本，高效率的新的生活。现在我们的生活已经离不开各种各样的软件了。在制作软件的过程中软件工程师是实现模拟过程的关键人物，他承担着不同角色的各种作用，说上通天文下晓地理可能夸张了，但也要学识足够渊博。然而这样的人实在是太少了，这就出现了把原来一个人的连续工作，拆分成了不同角色的人的连续配合，这演化成了不同的软件开发的模式，比如说边做边改模型、瀑布模型、迭代模型、快速原型模型、螺旋模型、敏捷软件开发等。然后慢慢演变出专门为别人开发软件的软件公司。

     系统架构师需要权利，有权利的架构师更容易指导工作。

     架构师引导产品开发工作的方式是提供系统架构文档，要写好这一文档也是不小的挑战。在系统架构文档中描述用例时，对于假设、前置条件和后置条件的把握有时是个难点，这需要自己有很清晰的思路和做深入的思考。如果一个人在工作中，只是致力于完成自己的工作，以做好自己的工作为主要目标，那么最多只能成为一个工匠，无法成为一个架构师。

     架构师所在的团队也是很重要的。一个成熟、稳定的产品研发管理团队有助于系统架构师快速地明确自己的工作职责和帮助建立起所需的人际关系。反之，如果没有这样一个团队，由于系统架构师的经验不足而容易出现一些扯皮现象而影响工作的开展。

     但团队成员之间的合作不协调的问题在软件开发中仍然十分普遍，从现在来看，这个问题在同学之间的合作中就已经开始显现出来，这个问题的根源是软件开发团队成员的个性特点不同。从事软件开发的人员大都具有比较高的学历和很好的教育经历，这有可能会使得他们不愿相信团队中的其他成员，导致彼此之间缺乏有效的沟通和交流。一个高效的团队内部必须要有频繁的沟通，个人要及时获取团队项目的进度和团队的资源文档信息，这样可以实时修正自己的工作方向。同时，要对团队的其他成员高度信任，彼此相互尊重。