站在巨人肩膀成长
话说一位做程序员有 17 年的朋友， 在像 HP、Amazon 这样的世界级团队，担任架构师有10年，也做过中小企业的技术领导。借CSDN分享一下他的工作感悟，及成功总结，和部分失败的反思，让我们不再踩无谓的坑，站在巨人肩膀成长。
先“提出问题”，然后再“解决问题”
作为程序员，已经习惯于面对问题时，而急于去解决问题，而很少以问题提出者的身份去思考设计方案，很少全面的看待问题。团队项目中常见的典型矛盾，就是产品团队和研发团队之间的矛盾。作为研发团队，常吐槽产品团队的需求不合理、不懂技术等。其实可以试着把自己的工作再往前移一下，不仅仅是去设计架构、实现产品的需求，同时也试着去实现客户的需求，甚至发现潜在的需求。不要头痛医头，脚痛医脚，急于为完成任务，而没有全局看待问题，忽视潜在的问题，导致未来矛盾重重！
而您若变成在设计上提出问题的人，你会发现提出问题的同时，在很多时候也需要同样深入的思考。设计一个好的问题，甚至比解决问题更难。
所以说，要先“提出问题”，然后再“解决问题”！
其实即便是软件开发领域的大神 Frederick P. Brooks Jr.（《人月神话》的作者）也会有同样的感叹。
“The hardest part of design is deciding what to design.”
-- 《The design of design》, by Frederick P. Brooks Jr.
对于“邪念”，勇于说不
由于人性的贪婪，总是有很多“邪念”，或者是人性的惯性，让大脑产生很多错误的，不合时宜的，舒适的，不靠谱的“邪念”。对于软件系统，同样需要想要更多：更多功能、更好的性能、更好的伸缩性、扩展性等等，然而同时也会处于自身的偏好，可能会出现一些自私的设计("邪念")，这是就需要您勇于说不。作为软件架构师，要明白软件架构设计，就是一种取舍或平衡。当大家都在往里面加东西的时候，架构师更应该来做这个说“不”的人。
软件设计和定义过程中存在很多取舍，例如：
- 完善功能和尽早发布的取舍。
- 伸缩性和性能的取舍。
CAP 原则，就是一个很好的取舍指导策略
著名的 CAP 原则，就是一个很好的取舍指导策略。为了更好的取舍，保持架构风格的一致性，在一开始架构师就应该根据系统的实际需求来定义一些取舍的原则，如：
- 数据一致性拥有最高优先级。
- 提前发布核心功能优于完整发布等。
- 非功能性需求决定架构
因为软件是为了满足客户的功能性需求的，所以很多设计人员可能会认为架构是由要实现的功能性需求决定的。但实际上真正决定软件架构的其实是非功能性需求。
架构师要更加关注非功能性需求，常见的非功能性包括：性能，伸缩性，扩展性和可维护性等，甚至还包括团队技术水平和发布时间要求。能实现功能的设计总是有很多，考虑了非功能性需求后才能筛选出最合适的设计。
以上架构模式来自《面向模式的软件架构》的第一卷，这套书多年来一直是架构师的必读经典。面向架构的模式，就是为不同的非功能性需求，提供了很好的参考和指导。图中的 Micro-Kernel 模式，更加关注可扩展性和可用性（错误隔离）。
“简单”并不“容易”
很多架构师都会常常提到保持简单，但是有时候我们会混淆简单和容易。简单和容易在英语里也是两个词“simple”和“easy”。
“Simple can be harder than complex:You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.To be truly simple, you have to go really deep.”
--SteveJobs
真正的一些简单的方法，其实来自于对问题和技术更深入的理解。这些方案往往不是容易获得的、表面上的方法。简单可以说蕴含着一种深入的技巧在其中。
首先我们来回顾一下软件生命周期中各个阶段的成本消耗占比。以下是来一个知名统计机构的分析报告。我们可以看到占比最大的是维护部分，对于这一部分的简化将最具有全局意义。
分享构架师的经验
曾经开发过一个设备管理系统，移动运营商通过这个系统来管理移动设备，实现包括设备的自动注册、固件和软件的同步等管理功能。这些功能，是通过一些管理系统与移动设备间的预定义的交互协议来完成的。
电信专家们会根据业务场景及需求来调整和新增这些交互协议。起初采用了一种容易实现的方式，即团队中的软件工程会根据电信专家的说明，将协议实现为对应代码。
之后很快发现这样的方式，让我们的工作变得没那么简单。
“I believe that the hardest part of software projects, the most common source of project failure, is communication with the customers and users of that software.”
--Martin Fowler
正如软件开发大师 MartinFowler 提到的，“沟通”往往是导致软件项目失败的主要原因。
前面这个项目最大的问题是，在系统上线后的运行维护阶段，电信专家和开发工程师之间会不断就新的协议修改和增加进行持续的沟通，而他们的领域知识和词汇都有很大的差别，这会大大影响沟通的效率。
因此这期间，系统的运行维护（协议的修改）变得十分艰难，不仅协议更新上线时间慢，而且由于软件工程对于电信协议理解程度有限，很多问题，都要在实际上线使用后才能被电信专家发现，导致了很多的交换和反复。
解决问题
针对上面提到的问题，后来我们和电信专家一起，设计了一种协议设计语言（并提供可视化的工具），这种设计语言，使用的电信专家所熟悉的词汇。然后通过一个类似于编译器的程序，将电信专家定义好的协议模型转换为内存中的 Java 结构。
这样整个项目的运行和维护就变得简单高效了，省去了低效的交流和不准确人工转换。
总结
可以看到，一开始按电信专家的说明，直接实现协议是更为容易的办法，但就整个软件生命周期来看却并不是一个简单高效的方法。
永远保持编码的热情
架构师也是程序员，代码是软件的最终实现形态，停止编程会逐渐让你忘记作为程序员的感受，更重要的是忘记其中的“痛”，从而容易产生一些不切实际的设计。
大家可能听说过在 Amazon，高级副总裁级别的 Distinguish Engineer（如：James Gosling，Java 之父），他们每年的编码量也非常大，常在 10 万行以上。
风险优先，绝对不要把风险放到最后
架构设计，很重要的一点，就是识别可能存在的风险，尤其是，非功能性需求实现的风险。
因为这些风险，往往没有功能性需求，这么容易在初期被发现，但修正的代价，通常要比修正功能性需求大非常多，甚至可能导致项目的失败，前面我们也提到了非功能性需求决定了架构，如数据一致性要求、响应延迟要求等。
我们应该通过原型，或在早期的迭代中，确认风险，能够通过合理的架构得以解决。
绝对不要把风险放到最后，就算是一个项目要失败也要让它快速失败，这也是一种敏捷。
从思考“问题”开始，而不是急于着手“技术”
技术人员对于新技术的都有着一种与生俱来的激情，总是乐于去学习新技术，同时也更有激情去使用新技术。
但是这也同样容易导致一个通病，就是“当我们有一个锤子的时候，看什么都是钉子”，使用一些不适合的技术去解决手边的问题，常常会导致简单问题复杂化。
曾经的一个团队维护过这样一个简单的服务，起初就是一个用 MySQL 作数据存储的简单服务，由团队的一个成员来开发和维护。后来，有位成员对当时新出的 DynamoDB 产生了兴趣，并学习了相关知识。
然后就发生下面这样的事：
用 DynamoDB 替换了 MySQL。
很快发现 DynamoDB 并不能很好的支持事务特性，在当时只有一个性能极差的客户端类库来支持事物，由于采用客户端方式，引入了大量的额外交互，导致性能差别达 7 倍之多。
解决问题
这时候，这个同学就采用了，当时在 NoSQL 领域，广泛流行的最终一致技术，通过一个 Pub-Sub 消息队列来实现最终一致（即当某对象的值发生改变后，会产生一个事件，然后关注这一改变的逻辑，就会订阅这个通知，并改变于其相关数据，从而实现不同数据的最终一致）。
接着由于 DynamoDB 无法提供 SQL 那样方便的查询机制，为了实现数据分析，就又引入了 EMR/MapReduceJob。
总结
到此，大家可以看到实现一样的功能，但是复杂性大大增加，维护工作也由一个人变成了一个团队。
过度忙碌使你落后
对于 IT 人而言，忙碌已成为了习惯，加班常挂在嘴边，“996”工作制似乎也变成了公司高效的标志。
而事实上过度的忙碌使你落后。
经常遇见一些朋友，在一个公司没日没夜的干了几年，没有留一点学习时间给自己。几年之后，倒是对公司越来越“忠诚”了，但忙碌的工作，同时也导致了没有时间更新知识，使得自己已经落后了，连跳槽的能力和勇气都失去了。
过度忙碌，会导致没有时间学习和更新自己的知识，尤其在这个高速发展的时代，在工作经历中，发现过度繁忙，通常会带来以下问题：
缺乏学习导致工作能力没有提升，而面对的问题却变得日益复杂。
技术和业务上，没有更大的领先优势，只能被动紧紧追赶。试想一下，要是你都领先同行业五年了，还会在乎，通过加班来早一个月发布吗？
反过来上面这些问题，会导致你更加繁忙，进而更没有时间提高自己的技术技能，很快就形成了一个恶性循环。
练过健身的朋友都知道，光靠锻炼是不行的，营养补充和锻炼同样重要。
个人技术成长其实也一样，实践和学习是一样重要的，当你在一个领域，工作了一段时间以后，工作对你而言就主要是实践了，随着你对该领域的熟悉，能学习的到技术会越来越少。
保证充足的学习时间，不忘初心，保持匠心
所以希望每个技术人员，都要保证充足的学习时间，否则很容易成为井底之蛙，从而避免陷入前面提到的恶性循环；希望借以伟大诗人屈原的诗句和大家共勉：“路漫漫其修远兮，吾将上下而求索“；希望我们大家都可以不忘初心，保持匠心！