架构师应该遵守的编程原则
　　大家好，我是互联网架构师！
　　程序员拥有一个较好的编程原则能使他的编程能力有大幅的提升，可以使其开发出维护性高、缺陷更少的代码。以下内容梳理自StactOverflow的一个问题：编程时你最先考虑的准则是什么？
　　目录
　　KISS（Keep It Simple Stupid）
　　KISS原则是英语 Keep It Simple, Stupid 的首字母缩略字，是一种归纳过的经验原则。KISS 原则是指在设计当中应当注重简约的原则。总结工程专业人员在设计过程中的经验，大多数系统的设计应保持简洁和单纯，而不掺入非必要的复杂性，这样的系统运作成效会取得最优；因此简单性应该是设计中的关键目标，尽量回避免不必要的复杂性。
　　这个首字母缩略词根据报导，是由洛克希德公司的首席工程师凯利·约翰逊（U-2 、SR-71等的设计者）所创造的。虽然长久以来，它一直是被写为 “Keep it simple, stupid”，但约翰逊将其转化成 “Keep it simple stupid”（无逗号），而且这种写法仍然被许多作者使用。词句中最后的 S并没有任何隐涵工程师是愚蠢的含义，而是恰好相反的要求设计是易使人理解的。
　　说明这个原则最好的实例，是约翰逊向一群设计喷射引擎飞机工程师提供了一些工具，他们所设计的机具，必须可由一名普通机械师只用这些工具修理。因此，“愚蠢”是指被设计的物品在损坏与修复的关联之间，它们的难易程度。这个缩写词已被美国军方，以及软件开发领域的许多人所使用。
　　另外相类似的概念也可作 KISS原则的起源。例如“奥卡姆剃刀”，爱因斯坦的“一切尽可能简单”、达芬奇的“简单是最终的复杂性” 、安德鲁·圣艾修伯里的“完美不是当它不能再添加时，它似乎是在它不能被进一步刮除时实现的”。
　　有两种软件设计方法，一种是尽可能的简单并保证没有什么缺陷。另外一种方式是尽可能的复杂并保障没有什么缺陷。而第一种方式相比第二种更加困难。
　　保持简单（避免复杂）永远是你应该做的第一件事，简单的代码不仅写起来简单、不容易出Bug，还易于维护。简单规则下，还包括：
　　如何把Kiss原则应用到工作中？
　　参考链接：Do The Simplest Thing That Could Possibly Work：
　　DRY（Don’t Repeat Yourself）
　　DRY即Don’t repeat
　　ourself（不要重复你自己，简称DRY），或一个规则，实现一次（One rule, one place）是面向对象编程中的基本原则，程序员的行事准则。旨在软件开发中，减少重复的信息。DRY的原则是“系统中的每一部分，都必须有一个单一的、明确的、权威的代表”，指的是（由人编写而非机器生成的）代码和测试所构成的系统，必须能够表达所应表达的内容，但是不能含有任何重复代码。当DRY原则被成功应用时，一个系统中任何单个元素的修改都不需要与其逻辑无关的其他元素发生改变。此外，与之逻辑上相关的其他元素的变化均为可预见的、均匀的，并如此保持同步。我对DRY的理解：
　　相关规则有：
　　
　　代码复用：
　　YAGNI – You ain’t gonna need it
　　YAGNI 是You Ain’t Gonna Need It（你不会需要它）的简写，是极限编程的关键原则。YAGNI意思非常简单：仅在您真正需要它们时才去做，而不是在您认为或预见将来可能需要它们时就提前做了！
　　您可以将YAGNI视为即时制造的拥护者。在这种情况下，制造业正在编写代码并交付功能。只有当有人真的需求功能存在时，您才可以开始工作并创建它。否则，您将保持自己的懒惰！
　　它为什么如此重要？没有编写的每一行代码都是时间，因此可以节省金钱。但是，甚至更多！它是：
　　而且还包括：
　　它可以防止什么？如今，大多数软件开发都是根据客户的需求进行的。无论您是在产品公司，在提供开发服务的公司还是在其他地方工作。总是会在某处某人想要具有某个功能。是您的客户要求具有某个需求的功能，还是产品经理响应客户的反馈的功能。无论实际驱动者是谁，无论是早晚，这都是实际需求的体现。您正确预见未来功能请求的机会非常低。因此，您很有可能实现某些功能，而不是您的实际利益相关者想要的功能。过早地执行某些操作很可能会导致一切都被丢弃。这是一个没人真正喜欢的场景！然后，有时会发生另一种情况：没有人真正需要该功能！
　　Code For The Maintainer
　　为维护者编写程序。比如让代码有自解释的功能。在你编写代码的时候永远记得将来需要维护他。
　　参考链接：
　　Code For The Maintainer：
　　Be as lazy as possible.
　　人类因“偷懒”而进步。懒惰只是创造了需求。需求本身并不算进步。满足需求形成了进步。
　　偷懒还包括：
　　参考链接：
　　Do The Simplest Thing That Could Possibly Work：
　　
　　Programming is only the road, not the way.
　　编码只是一种实现方式，而不是解决方案。编码只是告诉电脑应该如何去做。要编写高效、可靠的软件需要精通算法、最佳实践等其他与变成相关的内容。
　　编程前需要先了解你要解决的问题是什么。编程只是手段并不是目的。能实现并不代表需要实现。知道什么时候不需要编程或没有必须要去编程。
　　If you are in a hurry, stroll along slowly.
　　If you really are in a hurry, make a detour.
　　如果你很忙，那就放慢速度。如果你真的很忙，那就先放一放。这听起来很愚蠢，但是千万不要让自己陷入会导致后期问题的妥协。如果你正在编写程序的核心部分，尽可能保证精确。如果你在编写离核心代码较远的方法，可以尽可能的加快速度。
　　Know your path, Neo.
　　知道你的实现路径，你需要了解你每天使用的环境、工具及其他依赖的内容，并且把它调试到适合自己的配置。如果你的编程环境真的很好，那么你编程中的基本不需要关心他。如果你需要完成一项任务，最好的方式是不要引进“新的内容”，只有当你完全掌握“新的内容”的时候再去考虑引入。
　　If it wasn’t tested, it is broken.
　　如果没有经过测试的代码都是不能运行的。
　　与程序沟通时分辨原因和结果，与人交流时要分辨事实和观点
　　相关的准则，包括：
　　原文链接：What do you consider the 1st principle(s) of programming?
　　参考链接：Programming Principles 查看全部

　　：网站架构师的主要职责是更加专业的架构
　　网站架构师的工作内容包括产品和页面的架构。所以如果你设计任何产品，就会直接产生相应的页面架构师。至于更加实用的则是更加专业的架构师。产品设计师更多的是产品整体及细节的设计，而网站架构师对网站整体架构一定要有精通的能力。
　　
　　网站架构师的主要职责网站架构师是组建网站的骨架和组织网站的指挥官；他是软件专业设计的高级技术职务。他是团队领导；同时，也是提供企业网站解决方案的对象。网站架构师的工作内容包括网站的策划、规划、网站的搭建、站点优化和网站功能设计；以及网站的拓展策略和网站推广建设等。网站架构师是设计网站系统的架构和目标，并将它设计完成，实施以后，对网站的各项运行进行控制，完成网站的开发，并对服务器的运营进行管理。
　　你和程序猿的工作是一样的，你可以说，架构是一个整体或架构团队的第一步，就比如你团队里要有个前端，要有个后端，要有个产品经理，那架构就是整个团队的一个框架，我个人是觉得网站架构师的工作内容会更多的体现在这一个点，所以，架构设计师以及架构师以上两种的定义也就越来越模糊，本身网站架构师这个岗位就是架构整个网站。
　　
　　当然网站架构师这个职位不是随便谁都可以当的，薪资待遇都是不一样的，其中要求也是不一样的，其中对软件设计能力的要求也是不一样的。架构的好与坏直接决定了网站能否达到良好的交互。网站架构师分很多种，对，我个人认为，所有的分为好与坏都是说架构设计师这个岗位不好的，一个网站的内容架构好与坏会决定你网站的容量的多少，性能的高低以及用户的体验等等，一个网站首页加载不出那么多动态要求的数据，用户怎么能高效、方便的进行交互。
　　其实用户访问后还是去看展示页的内容的，一个好的网站不单单只是架构要好，ui要好，还要有网站的展示页，这样才能吸引用户，才能让用户有体验的好的感觉，才能让用户的体验感提升不少。整个架构设计师以及架构师以上两种的定义也是越来越模糊。架构设计师在一个网站里是个复杂的职位，它又分很多种，有的会自己设计网站的结构，也有架构师指导网站架构师的工作，像现在很多网站架构师基本就是一个架构师主导网站架构工作，但这样的架构设计师很可能就是，软件或数据库技术或网站技术的高手，能搭建起一个完整的架构，主要还是看每个网站情况，像国内的腾讯的网站架构，国外的twitter和facebook这样的大网站都是架构师带领一群架构师一起设计网站。
　　以上是我对网站架构师的看法，下面我再讲讲我对“架构设计师”其实就是产品架构师的看法，这里我先从工作的角度讲，以下。 查看全部

　　网站架构师的工作内容不一样，基本都要配置接口
　　
　　网站架构师的工作内容都不一样，但是，基本都要配置接口，或者定制化服务，带团队做项目。传统的网站架构师，更多的是把应用拆分成很多个独立的进程，对性能、可用性、成本等做权衡，不会面对一个应用上线之后可能带来的各种问题。现在说的网站架构师，其实也有分很多类型。可能你将来可能在amazon、谷歌、腾讯等大公司做负责业务的架构师，可能你也会在某个小公司做负责业务的架构师，可能你在某个中型公司负责进销存、消息中间件等互联网产品架构师，也可能你做的是各种小型的公司架构师，或者做什么事业部架构师等等不管你最后去到哪里做架构师，架构师都需要把自己的产品化、用户化，快速上线，快速收尾、快速维护，对前端、后端等不断进行优化与改进。如果说你以后想要一个产品方向，或者将来想做一个技术方向，不管是大公司，还是小公司，这样都是必要的。
　　
　　从深度上来说，网站架构师更侧重于模块架构。一个网站只有一到三个模块即可。这种架构方式可以提高整个系统的响应速度以及稳定性，能够降低开发的成本。应该说从保守的角度来说，应该优先选择开发模块尽量少的架构。从广度上说，网站架构师更侧重于系统。网站系统是一个庞大的系统，而一个网站系统要实现各种各样的功能、开发各种各样的软件。
　　既然是要对这个庞大的系统进行架构，那就意味着对网站整体有较深入的了解，在不断的提高架构的过程中会使得整个系统逐渐完善。实际架构师通常都会对各种软件架构有比较深入的研究，所以，从广度上来说，应该优先选择广度优先的架构。 查看全部

　　网站架构师的工作内容到底是什么？未来从业方向
　　网站架构师的工作内容到底是什么？现在企业对网站架构师的需求大概有哪些?根据多年来从事网站架构师工作的经验，
　　1、网站架构师主要要负责用户体验和网站结构；
　　2、要具备对前端技术，
　　3、负责互联网网站工程技术，
　　
　　4、负责计算机网站技术开发、设计、和维护；
　　5、负责网站安全问题管理；
　　6、负责不同互联网产品的网站设计、开发、维护、改进，做好网站架构师的技术积累，
　　7、负责整体网站规划；要具备扎实的理论基础和丰富的实践经验。
　　网站建设方面的基础要求1.技术基础知识要强大2.需求分析能力，对网站架构、功能划分、用户体验分析有深刻的认识3.沟通能力和解决问题的能力要强4.文档编写能力要强5.了解一定的大型网站的开发技术，
　　
　　5、css
　　3、javascript等，能运用其对整个网站设计、开发等整个环节进行管理和控制。网站建设方面职业规划能力深入过往的知识，借鉴其成熟网站的设计模式以及开发模式，总结网站设计方面的经验和技巧，发现网站开发技术上的问题和突破口，改进思维观念，不断提高自身的工作能力以及创新能力。通过积累经验学习深入到网站架构、配置、性能优化、集成开发、安全性等方面。
　　平时也会学习新技术，拓展自己的技术路线。未来从业方向网站建设系统架构师主要从事各类网站前端技术以及相关技术的规划、开发及管理工作，主要包括建站、优化、调优、运维、维护、管理，属于互联网公司的核心部门。通过系统架构师的高级岗位来管理团队，给予团队不断提升的机会。全能网站架构师既可以深入技术，又可以深入业务。
　　既懂技术，又懂业务，既懂技术，又懂管理，既懂技术，又懂业务，既懂技术，又懂管理，又懂营销，懂得影响力。进行跨产品线的合作，通过项目管理，协同工作、提升团队的执行力，配合销售，实现网站转型升级。拥有对大型互联网公司非常全面的了解，即使网站架构师分成几个不同的团队来完成网站工作，根据实际情况也可以协调团队工作，配合销售实现网站整体数据量的提升。
　　网站架构师定义-网站架构师是指在网站架构设计、技术开发、后期维护以及数据库设计等网站工作的过程中实现系统自动化运营以及自动部署更新到最终用户终端。-主要负责大型网站的架构设计、技术开发、部署优化以及管理。根据全面的设计规划，根据网站技术方向不断拓展技术实现各项需求，提高网站执行力。掌握专业的互联网网站开发、架构师开发、运维技术知识，搭建企业网站平台、增强。 查看全部

　　一位工作了 10 年的 Java 高级架构师的技术之路
　　黄勇（博客），从事近十年的 JavaEE 应用开发工作，现任阿里巴巴公司系统架构师。对分布式服务架构与大数据技术有深入研究，具有丰富的 B/S 架构开发经验与项目实战经验，擅长敏捷开发模式。国内开源软件推动者之一，Smart Framework 开源框架创始人。热爱技术交流，乐于分享自己的工作经验。著有《架构探险——从零开始写Java Web框架》一书。
　　我的十年技术之路
　　CSDN：请和大家介绍下你和目前所从事的工作。
　　黄勇：大家好，我是黄勇。
　　我目前从事分布式服务架构的设计与开发工作，在阿里的大数据平台上进行应用程序开发。我们整个系统架构采用了“前后端分离”的思想，前端关注数据展现，后端关注数据生产，通过 REST服务将前后端整合起来，所有的应用都是无状态的，可以做到水平扩展。我们将整个系统拆分成许多“微服务”，服务之间通过统一的接口来调用，每个服务是通过容器技术进行隔离，此外服务可发布到统一的服务管理平台上，可通过该平台监控每个服务的运行状态与生命周期事件，并为服务调用者提供了服务发现的能力，可对服务进行平滑升级。
　　阿里有许多优秀的中间件与基础服务，可以快速帮助我们搭建应用系统，而且这些技术在阿里内部全是开源的，大家可以通过源码和文档学习到很多有价值的经验。阿里也提供了浓厚的技术氛围，每位同学都非常专注于自己的工作领域，大家对工作一丝不苟，相互配合，方向一致。
　　CSDN：你是如何走上技术这条路的？
　　黄勇：2006 年大学毕业，我离开了母校武汉理工大学，在院长薛胜军老师的推荐下，我来到了上海，这个对于我来说非常陌生的地方。我有幸加入了一家名为“动量软件”的创业公司，这家公司的老板曾经是亚信科技的 CTO，他也是普元软件的创始人兼 CTO，他的名字叫黄柳青，他也是薛老师的大学同学。于是就这样，我的老板成为了我的老师，我习惯叫他黄老师，包括公司其他资深的同事也成为了我的老师，因为我很想他们身上学到更多有价值的东西。
　　刚开始工作的时候我学习了什么是云计算？什么是 SaaS、PaaS、IaaS？我们花了三年时间开发了一款名为 ODE 的 PaaS 平台，让用户可以在该平台上量身定制自己的软件，最终为客户提供基于 SaaS 的产品。确实很骄傲，那时我们已经在做云了，只是没想到后来云会在中国得到这么好的市场，可能当时只有黄老师一个人想到了吧。
　　在 2008 年，我为公司拿回了“第一桶金”，这也是我从程序员转向项目经理的里程碑。当时我带领团队远赴深圳，为国信证券公司开发经纪人管理系统，这个项目对于我个人而言却是一笔至高无上的财富，我开始学习如何与人打交道，如何做需求分析，如何将需求转变为技术，如何带领团队小伙伴一起工作。学到了太多太多，但我依然选择在我工作第四个年头里离开了动量软件，我刚加入动量软件的时候，公司只有 5 个人（包括老板和前台），当我离开动量软件的时候，公司已经有 200 人左右了。感谢黄老师！我在他身上学到了很多，他的思想和态度直到今天都还在影响着我。
　　我的第二份工作还是选择了我最熟悉的证券金融行业，同样也是一家创业型公司，在这家公司里我担任了技术经理，管理了整个技术团队，从项目的售前到售后，我都亲自带领团队来完成。虽然在这家公司我只做了两年，但在这短短的时间里，我学会了如何提高开发效率、如何培养技术团队、如何选拔技术人才、如何建立企业文化。但最后我发现了一个问题，越是想做好，越是很难做好，为了做成一件事情需要做很多的尝试，做事情缺乏正确并有效的方法。
　　回想我工作的前六年时间里，我一直都是在创业公司里成长，虽然可以快速学到东西，但似乎很难学到更加规范的做事方法。于是我选择了新的工作机会，来到了 TCL 通讯，这是一家相当大的公司，公司的研发管理流程来源于法国阿里卡特公司。我在公司担任 Java 架构师职位，也算是整个 Java 团队的技术负责人，虽然团队并不是特别地大。我在这家公司做了三年，学到了如何整合现有资源、如何按标准流程去做事、如何设计系统架构、如何进行异地工作、如何跨团队工作、如何用英文来沟通。说实话，当时我没有任何的工作压力，可以按时上下班，从来都不会加班。虽然自己空闲的时间很多，但我并没有选择去浪费时间，而是开始写点技术博客，也正是因为这些技术文章，才改变了我后续的职业发展道路。
　　我清楚的记得，那是在 2013 年 9 月 1 日，我在开源中国（）网站发表了我人生的第一篇博文《Smart Framework：轻量级 Java Web 框架》，这篇文章影响了我后续两年。其实说句心里话，当我第一次写这篇文章时，我心里是没底的，这个框架只是根据自己的理解做出来的一个设想，当时甚至连一行代码都没写过。我的想法是先将这个思想发表出来，让大家讨论起来，我会做一个决策，然后再亲自做具体实现，最后我会将实现过程通过博文的方式展现给大家，后续大家会对我的实现进行点评，我会基于大家的建议进行改善。整个开源过程正好与敏捷的思想是一致的，有效沟通、小步快跑、拥抱变化、不断改进。
　　也许就是我的技术文章吸引了很多广大读者，这里面不排除想邀请我加入的其它公司。我在 2014 年离开了 TCL 通讯，加入了易传媒。为什么我要放弃如此舒适的工作环境，去加入一家还在不断拼搏的企业呢？其实我看到的是未来互联网的发展趋势，广告程序化交易以及广告与大数据的结合，未来最值钱的一定是数据。抱着这样的信心，我加入了易传媒，担任系统架构师职位。当时易传媒正处于技术转型的初期，需要将 .Net 全部迁移到 Java，这件事情对于我而言是非常有挑战的。我的做法是：第一步定义开发规范与流程，第二步培养核心技术人员，第三步分阶段进行改造。仅半年时间，我们所有的产品成功地迁移到了 Java 平台，结果出乎大家的想象。公司市场也非常不错，产品得到了业界的认可，订单数源源不断，大家每天都很忙碌，但却很开心。而易传媒的“易家人”企业文化，让我所感动，不管是核心技术部门还是其它支持性部门，大家就像一家人一样，你的事情就是我的事情。
　　直到 2015 年初，阿里巴巴与易传媒建立了合作关系，两家公司进行了深度合作，易传媒公司与阿里妈妈事业部进行了整合，新阿里妈妈从此诞生了，于是我也成为了阿里巴巴的一员，目前负责阿里妈妈大数据品牌营销产品的系统架构工作。就在两家公司整合的过程中，我完成了人生中的处女作《架构探险 —— 从零开始写 Java Web 框架》这本书，目前该书正在各大网上书店售卖，我真心希望这本书能对一些想成为架构师的程序员们有所帮助，由于我个人水平有限，又是第一次写书，写得不好的地方还请大家多多包涵。
　　CSDN：上面提到，写博客给你带来的收获颇多，能不能分享下技术人如何写博客？又应该以怎样的态度对待？
　　黄勇：我认为技术人员写博客需要注意以下几点：
　　思路要清晰，文章要有明确的大纲与标题。
　　对于实战类型的文章，需要分步骤来描述。
　　多用短句，少用长句，能一句话说明白，就不用两句话。
　　对于不太好理解的内容，最好能打比方来说明。
　　文章末尾需要有总结，用最精辟的语言归纳出这篇文章的主要内容。
　　写博客首先是对自己所学知识的一个总结，此外，也为其他读者提供了很好的教程，知识得到了广播与传递。
　　CSDN：技术一条不归路，选择了这条路是否有过放弃的想法？
　　黄勇：做了十年的技术，我从来都没有放弃过它，相反，我非常热爱它，因为我一直以来都很喜欢学习，希望能学到更多的东西，这样遇到了具体的技术问题，可以随时从自己积累的知识库中找到最佳的解决方案。此外，目前我在公司虽然不怎么写代码了，但我还是会利用自己工作闲暇之余写一点开源项目或者代码框架等。
　　CSDN：你工作过很多大大小小的公司，你认为公司最值钱的东西是什么？
　　黄勇：我认为是实实在在做事情的程序员们。
　　他们虽然工资不高，每天坐在位置上敲着代码，在很多人眼中被称为“屌丝”或“宅男”，但我认为恰恰就是这些人，他们才是公司最有价值的人。
　　他们有自己的理想，希望能够通过自己的努力，从中得到那一点点所谓的成就感；
　　他们需要理解产品经理真正的意图，把想法变成现实，让产品真正落地；
　　他们更容易把握细节，而这些细节往往决定着产品的命运与成败；
　　他们突如其来的跳槽，对我们的项目的交付有直接的影响；
　　他们在一起工作的气氛，能体现技术公司的文化与底蕴。
　　由此看来，对程序员的重视是相当有必要的，我们需要关心每一位程序员的职业发展，让他们在团队里能够充分地发挥出自己的能力。
　　我们也需要对他们倍加关注，挖掘出有能力、肯吃苦、敢担当的人，给他们更多的机会，让他们成为技术领袖。
　　互联网技术公司需要大量这样的程序员：
　　他们是一群有着技术信仰的人，他们是一群热爱编程的人，他们是一群不解决问题睡不好觉的人；
　　他们不是打杂的，不是外包，更不是工具；
　　他们不喜欢被忽悠，不喜欢被冷落，更不喜欢被驱动；
　　他们需要尊重，需要培养，更需要激情！
　　CSDN：你能具体说说程序员需要具备哪些素质吗？
　　黄勇：我个人是这样理解真正的程序员的：
　　深爱技术，一天不写代码手就会痒，就喜欢那种成就感；
　　为了一个问题可以废寝忘食，有时会在梦中都能写代码；
　　代码洁癖症患者，喜欢优雅代码，写代码就像写诗一样；
　　善于分析问题，能快速看清问题的本质，并动手解决它；
　　喜欢研究优秀源码，学习大师的杰作，善于归纳与总结；
　　有自己的开源项目或技术博客，喜欢学习，更喜欢分享；
　　会关注技术圈子的新闻动态，时常会参加线下技术沙龙；
　　知道软件开发不是一个人在战斗，更需要的是团队协作；
　　保持良好健康的心态，用一颗积极向上的心去拥抱变化。
　　CSDN：十年的职场之路坚持不易，能够分享下你的「IT 职场」经验？
　　黄勇：时光飞逝，我事业中第一个十年已然结束了。在这十年里，让我收获了很多，跟大家分享一下我在 IT 职场方面的一些个人经验，不一定对每个人都实用，请大家仅作参考吧。
　　大家既然都是做技术的，那我们不妨先从技术这个话题开始说起吧。我要与大家分享的第一点经验就是：
　　1. 把技术当成工具
　　技术这东西，其实一点都不神秘，它只不过是一个工具，用这个工具可以帮助我们解决实际问题，就这么简单。
　　我们每天在面对技术，市面上也有很多技术，真的没有必要把这些技术都拿过来学习一遍，然后想办法找个场景去应用它。如果真的这样做了，那么只能说明技术不是工具，而是玩具，技术不是这样玩的。
　　我们应该从另一个角度来看待技术，不妨从自己的实际工作环境出发，现在需要什么，我们就学什么，而不要漫无目的的追求一些新技术。当然，对于新技术还是需要有所关注的，至少需要知道这个新技术是干什么用的，而且还要善于总结，将有价值的技术收集起来，以备将来使用，当需要使用的时候再来深入研究。
　　人的精力是有限的，人的生命也是短暂的，要善于利用自己的时间，合理地学习技术。
　　不要把技术看得那么重要，别把它当回事儿，把它当工具就行了，它就像我们写字的笔一样，用铅笔能写字，用钢笔一样能写字。
　　作为一名技术人员，除了学习与应用技术以外，还需要为自己做一个正确的职业规划，清晰认识自己究竟属于哪种技术人才，是技术专家类型的，还是技术管理类型的。路到底该怎么走？需要自己做出决定。
　　在我们职业路线上，最重要的人莫过于老板（我指的老板可以是公司大老板，也可以是自己的顶头上司），对待自己的老板，我也有一些经验：
　　2. 把老板当成情人
　　大家应该非常清楚，情人是需要浪漫的，浪漫是需要惊喜的。老板其实跟情人一样，也是需要惊喜的。我们做下属的，要懂得找到合适的机会给老板带来惊喜。我们跟情人谈情说爱，这是一种很好的沟通方式，可别忽略了跟老板“谈情说爱”，我们需要与老板保持良好的沟通，这种沟通并不仅仅是溜须拍马。
　　讲一个真实的故事吧。记得曾经我的一位同事，技术非常好，做东西非常快，质量也很高，同事们都觉得他是牛人，但他从来都不懂得在老板面前表现自己，老板也只是觉得他是可以做事的，但升职加薪的事情往往总是不会优先考虑他。
　　大家很定会问：怎样在老板面前表现自己呢？其实方法有很多，由于篇幅有限，我先提供三招吧：
　　第一招：在给老板做程序演示的时候，不要只是单纯的演示，不妨先用一个 PPT，简单表达一下自己的解决方案，然后再做演示，这样效果会好很多。老板会认为自己是花了心思的，是想把事情做得更好的。
　　第二招：把自己每天的工作简单记录一下，每周汇总一次，以邮件的形式发送给老板，让老板知道自己每天在做什么。每月写一篇本月工作总结与下月工作计划，同样发邮件给老板。年底可以写一个年终工作总结，打印出来，悄悄地放在老板的桌子上。
　　第三招：借汇报工作为理由，定期请老板出去吃饭，制造面对面单独沟通的机会。在谈话过程中，强调自己愿意帮助老板分担工作压力。
　　对待老板其实很简单，只要能帮他做事，又能让他开心，他基本上就搞定了。老板搞定了，自己的职业发展才会平步青云。但千万别忽略了还有一群人，他们或许是自己的团队战友，或许是自己的竞争对手，没错！他们就是同事。如何处理同事关系呢？以下便是我的经验：
　　3. 把同事当成小孩
　　处理与同事关系，其实比处理与老板关系要稍微复杂一点，因为同事有多种身份，他们可以是队友，也可以是对手。如果大家在一起做同一个项目，那么这样的同事就是队友；如果为了竞争某个项目、岗位、资源，导致同级别的同事之间发生利益上的竞争，那么这样的同事就是对手。
　　对于队友而言，要学会主动给他们提供帮助，让大家能够体会到团队协作的气氛，在一起学习，在一起成长，在一起分享。可以时常跟大家一起聚餐，买点零食让大家品尝。
　　队友关系往往比较好处理，关键在于自己能否真正懂得去分享。很多技术人员，最不愿意的就是分享，因为担心自己花了很多精力学到的知识，分分钟就被别人学会了，自己失去了优势。这种心态最好不要在团队里产生，这样只会让自己变得越来越封闭，越来越渺小，队友们也会逐渐排挤自己。
　　对于对手而言，要想办法让自己成为他的兄弟，告诉他，咱们是兄弟，应该相互帮助。如果有机会，可以在老板面前，当着对手的面，夸奖自己的对手。做出这样的行为，其实并不会让老板觉得自己不如对手，而会让老板认为自己在用心去容纳对手。大家在一起工作，就是一种缘分，都是跟老板打工的，真的没有必要搞得不愉快。
　　其实同事就是自己的小伙伴，不妨把他们当成是单纯可爱的小孩吧，用自己的心去“收买”他们。
　　老板与同事，他们都是公司内部的人，不管怎么说，大家都在同一条船上，大家可以关上门吵一架，只要事情能够解决就行。但对于我们的客户而言，就需要用另外一种方法来处理好关系了。我是这样认为的：
　　4. 把客户当成病人
　　客户有需求，但没有技术，而我们有技术、有经验、有产品，正好可以帮助他们实现需求，从而提高他们的工作效率，这样客户才会心甘情愿地把钱放入我们的口袋。所以，在客户面前，我们要表现出高超的专业精神，不要被客户牵着我们的鼻子走，我们在客户面前就是技术权威，就需要这样的自信。从服装、言行、邮件、文档等各个方面，都要做到专业。
　　我们打算把自己的产品卖给客户的时候，千万不要一上来就对自己的产品夸夸其谈，这往往会让客户感到厌烦。我们不妨先告诉客户，他们已经“生病”了，而且病得不轻，如果不及时用药的话，后果将不堪设想。也就是说，要让客户意识到自己现在所面临的困境，让客户紧张，当他们正在思考如何应对的时候，我们再告诉他们，“药”已经准备好了，可以随时服用。
　　要让客户有种雪中送炭的感觉，这样就对了，他们一定会主动了解我们的产品。我们要做到这一切，必须花精力来分析行业现状，揣测客户老板们每天在想什么。如果有机会进入客户所在的公司工作一段时间，相信自己的感受会更加深入。
　　Java 会在很长的一段时间内是主流
　　CSDN：能否先简答介绍下你的最新力作《架构探险——从零开始写Java Web框架》？面向的群体是怎样的？有什么特别之处？
　　黄勇：建议有一定 Java Web 开发经验的读者阅读这本书，当然，如果大家想通过这本书来学习 Java Web 核心技术也是非常不错的，因为书中会有大量的实例来讲解 Java 必备的基础技能。此外，建议读者们能亲自动手去实践，虽然书中所有的源代码可以自由获取，但我不建议大家只是看看代码是怎么写的，而错过了一次很好的练手机会，因为所有的开发技能都需要不断地练习，孰能生巧，巧能生辉。
　　CSDN：《架构探险——从零开始写Java Web框架》是你撰写的第一技术书，是什么原因促使你写这本的？
　　黄勇：记得那是在 2014 年 11 月底，我有幸结识了电子工业出版社博文视点编辑部的陈晓猛老师。陈老师建议我写一本书，但我当时真的不知道该写什么，我想可能在 Java Web 方面还可以尝试写点东西吧，于是在他的鼓励与帮助下，我就开始写书了。陈老师告诉我，写书其实就像写博客一样，当初我真这么觉得的，可是个人能力和经验还是非常有限，第一次写了 50 页就再也写不下去了，第二次竟然写到了 100 页，最后觉得自己的写作思路有问题，还是放弃了，直到第三次我才把结构梳理清楚，一气呵成地写完了整本书。在这个过程中，是我妻子鼓励并监督着我，那时我们的宝宝刚出生不久，每天在家里哭泣，我妻子把我一个人关在房间里，她独自一人带小孩，并操持着所有的家务，就是为了给我一个安静的环境，让我可以敞开思路，写出更加优秀的作品。在此，请允许我对我妻子说一声：辛苦了！我永远爱你！
　　CSDN：写书不是一件容易的事情，能不能谈谈在这段期间的辛酸和收获？
　　黄勇：虽然写书的过程比较艰辛，但对我个人却有很大的收获：
　　通过写书这件事情，让我学会了坚持，想做一件事情很简单，但想把这件事情做成却没那么容易。
　　通过写书我重新对轻量级 Java Web 框架做更深层次的理解，一个好的框架不是看功能有多强大，而在于它的扩展性有多好。毕竟功能是做不完的，需要有一个“微内核 + 多插件”的思想，核心是非常小的，它仅提供了整个框架的必备功能以及相关的扩展点，然后需要将不同的功能封装在不同的插件中，并为更多其他的开发者提供统一的扩展方式。
　　我希望这本书不再是教会读者如何去使用开源框架，而是让读者学会如何从零开始去编写开源框架，并鼓励读者发挥自己的力量，一起投身到开源社区中。
　　CSDN：为什么开发Java Web都要用框架？
　　黄勇：我个人觉得框架有以下几点作用：
　　让开发更加高效，屏蔽底层技术细节，让开发人员关注在具体业务上。
　　框架实际上也是一种规范，可以让每位开发人员保持同样的编码风格。
　　
　　会使用主流框架的开发人员，在人才市场上比较好获取。
　　CSDN：现在做Java Web开发都用哪些框架呢？
　　黄勇：常用的比如Spring MVC、Struts2 等，国内的 JFinal、Nutz 等也不错，当然Smart 也是一个很好的选择。
　　CSDN：有一定Web前端开发经验的人，很多都会有这么个想法：那些写框架的人好厉害，什么时候我才能写一个自己的框架呢？有时候看看别人的框架代码，又觉得很复杂，对此你有什么建议吗？以及新人学习需要什么基础？有哪些好的方法分享？
　　黄勇：对于接触 Java 不太久的朋友，建议按照以下几个步骤来学习：
　　学习 Java 基础语法与核心技术，包括 Servlet、JSP、JDBC 等。
　　熟练使用流行开源框架，包括Spring、MyBatis 等。
　　研究开源框架源码，并吸取其中优秀的架构。
　　此外，在学习的过程当中，建议做学习笔记，最好能通过博客的方式来记录自己的收获。
　　CSDN：使用 Python、Perl、PHP、Ruby 等脚本语言开发 Web 程序，跟使用 Java 开发 Web 程序相比有什么不同或者优劣？
　　黄勇：前者属于动态语言，无需编译，可通过解释的方式来运行，而且 Java 需要首先通过编译，将源文件转为字节码，且载入 Java 虚拟机才能运行，相对来说，Java 对环境的要求较高，但 Java 具备更强的面向对象能力。此外，Java 还拥有较广的开源社区以及流行的开源中间件。因此，如果是做大型系统，建议使用 Java 来开发，而并非那些脚本语言。
　　CSDN：针对 Web，Java、PHP、Python、.NET 之中未来发展前景最好的会是什么？
　　黄勇：我认为 Java 在未来还会有一段很长的路，需要在语言本身上做到更加轻量级，用最少的代码来实现目标功能；PHP 相对来说会比较平稳，它的特点非常突出，上手快且易于开发 Web 项目；Python仍然不会有太大的用户群体；.NET 加入开源社区太晚，且较 Java 而言并没有太强的优势，可能会走下坡路。
　　CSDN：在软件开发中有很多的设计模式，也有一些很高冷，能否谈谈你对软件设计的理解，以及让一些设计原则接地气？
　　黄勇：了解设计模式的朋友们，想必都听说过“六大设计原则”吧。其实最经典的 23 种设计模式中或多或少地都在使用这些设计原则，也就是说，设计模式是站在设计原则的基础之上的。所以在学习设计模式之前，很有必要对这些设计原则先做一下了解。
　　GoF（四人帮），传说中的四位大神们，他们联手搞出了一套设计模式，堪称 OOD（面向对象设计）的经典之作！震惊了整个软件开发领域。但这四个老家伙非常怪异，总是喜欢显摆一些高深的理论，甚至有时候不说人话，十分让人费解。
　　除了最经典的六大设计原则以外，还有一些其他的设计原则也非常重要。我将尽可能地解释这些晦涩的理论，希望看完之后，会让您对这些设计原则稍微加深一些理解。若有不正确的地方，恳请大家指正！
　　六大设计原则
　　先看一幅图吧：
　　这幅图清晰地表达了六大设计原则，但仅限于它们叫什么名字而已，它们具体是什么意思呢？下面我将从原文、译文、理解、应用，这四个方面分别进行阐述。
　　1. 单一职责原则（Single Responsibility Principle - SRP）
　　原文：There should never be more than one reason for a class to change.
　　译文：永远不应该有多于一个原因来改变某个类。
　　理解：对于一个类而言，应该仅有一个引起它变化的原因。说白了就是，不同的类具备不同的职责，各施其责。这就好比一个团队，大家分工协作，互不影响，各做各的事情。
　　应用：当我们做系统设计时，如果发现有一个类拥有了两种的职责，那就问自己一个问题：可以将这个类分成两个类吗？如果真的有必要，那就分吧。千万不要让一个类干的事情太多！
　　2. 开放封闭原则（Open Closed Principle - OCP）
　　原文：Software entities like classes, modules and functions should be open for extension but closed for modifications.
　　译文：软件实体，如：类、模块与函数，对于扩展应该是开放的，但对于修改应该是封闭的。
　　理解：简言之，对扩展开放，对修改封闭。换句话说，可以去扩展类，但不要去修改类。
　　应用：当需求有改动，要修改代码了，此时您要做的是，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码。当然，如果能够确保对整体架构不会产生任何影响，那么也没必要搞得那么复杂了，直接改这个类吧。
　　3. 里氏替换原则（Liskov Substitution Principle - LSP）
　　原文：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
　　译文：使用基类的指针或引用的函数，必须是在不知情的情况下，能够使用派生类的对象。
　　理解：父类能够替换子类，但子类不一定能替换父类。也就是说，在代码中可以将父类全部替换为子类，程序不会报错，也不会在运行时出现任何异常，但反过来却不一定成立。
　　应用：在继承类时，务必重写（Override）父类中所有的方法，尤其需要注意父类的 protected 方法（它们往往是让您重写的），子类尽量不要暴露自己的 public 方法供外界调用。
　　该原则由麻省理工学院的 Barbara Liskov 女士提出，她是美国第一位获取计算机博士学位的女性，曾经也获得过计算机图灵奖。
　　4. 最少知识原则（Least Knowledge Principle - LKP）
　　原文：Only talk to you immediate friends.
　　译文：只与你最直接的朋友交流。
　　理解：尽量减少对象之间的交互，从而减小类之间的耦合。简言之，一定要做到：低耦合，高内聚。
　　应用：在做系统设计时，不要让一个类依赖于太多的其他类，需尽量减小依赖关系，否则，您死都不知道自己怎么死的。
　　该原则也称为“迪米特法则（Law of Demeter）”，由 Ian Holland 提出。这个人不太愿意和陌生人说话，只和他走得最近的朋友们交流。
　　5. 接口隔离原则（Interface Segregation Principle - ISP）
　　原文：The dependency of one class to another one should depend on the smallest possible interface.
　　译文：一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口。
　　理解：不要对外暴露没有实际意义的接口。也就是说，接口是给别人调用的，那就不要去为难别人了，尽可能保证接口的实用性吧。她好，我也好。
　　应用：当需要对外暴露接口时，需要再三斟酌，如果真的没有必要对外提供的，就删了吧。一旦您提供了，就意味着，您将来要多做一件事情，何苦要给自己找事做呢。
　　6. 依赖倒置原则（Dependence Inversion Principle - DIP）
　　原文：High level modules should not depends upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
　　译文：高层模块不应该依赖于低层模块，它们应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
　　理解：应该面向接口编程，不应该面向实现类编程。面向实现类编程，相当于就是论事，那是正向依赖（正常人思维）；面向接口编程，相当于通过事物表象来看本质，那是反向依赖，即依赖倒置（程序员思维）。
　　应用：并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口来编程吧。
　　将以上六大原则的英文首字母拼在一起就是 SOLID（稳定的），所以也称之为 SOLID 原则。
　　只有满足了这六大原则，才能设计出稳定的软件架构！但它们毕竟只是原则，只是四人帮给我们的建议，有些时候我们还是要学会灵活应变，千万不要生搬硬套，否则只会把简单问题复杂化，切记！
　　补充设计原则
　　1. 组合/聚合复用原则（Composition/Aggregation Reuse Principle - CARP）
　　当要扩展类的功能时，优先考虑使用组合，而不是继承。这条原则在 23 种经典设计模式中频繁使用，如：代理模式、装饰模式、适配器模式等。可见江湖地位非常之高！
　　2. 无环依赖原则（Acyclic Dependencies Principle - ADP）
　　当 A 模块依赖于 B 模块，B 模块依赖于 C 模块，C 依赖于 A 模块，此时将出现循环依赖。在设计中应该避免这个问题，可通过引入“中介者模式”解决该问题。
　　3. 共同封装原则（Common Closure Principle - CCP）
　　应该将易变的类放在同一个包里，将变化隔离出来。该原则是“开放-封闭原则”的延生。
　　4. 共同重用原则（Common Reuse Principle - CRP）
　　如果重用了包中的一个类，那么也就相当于重用了包中的所有类，我们要尽可能减小包的大小。
　　5. 好莱坞原则（Hollywood Principle - HP）
　　好莱坞明星的经纪人一般都很忙，他们不想被打扰，往往会说：Don't call me, I'll call you. 翻译为：不要联系我，我会联系你。对应于软件设计而言，最著名的就是“控制反转”（或称为“依赖注入”），我们不需要在代码中主动的创建对象，而是由容器帮我们来创建并管理这些对象。
　　其他设计原则
　　1. 不要重复你自己（Don't repeat yourself - DRY）
　　不要让重复的代码到处都是，要让它们足够的重用，所以要尽可能地封装。
　　2. 保持它简单与傻瓜（Keep it simple and stupid - KISS）
　　不要让系统变得复杂，界面简洁，功能实用，操作方便，要让它足够的简单，足够的傻瓜。
　　3. 高内聚与低耦合（High Cohesion and Low Coupling - HCLC）
　　模块内部需要做到内聚度高，模块之间需要做到耦合度低。
　　4. 惯例优于配置（Convention over Configuration - COC）
　　尽量让惯例来减少配置，这样才能提高开发效率，尽量做到“零配置”。很多开发框架都是这样做的。
　　5. 命令查询分离（Command Query Separation - CQS）
　　在定义接口时，要做到哪些是命令，哪些是查询，要将它们分离，而不要揉到一起。
　　6. 关注点分离（Separation of Concerns - SOC）
　　将一个复杂的问题分离为多个简单的问题，然后逐个解决这些简单的问题，那么这个复杂的问题就解决了。难就难在如何进行分离。
　　7. 契约式设计（Design by Contract - DBC）
　　模块或系统之间的交互，都是基于契约（接口或抽象）的，而不要依赖于具体实现。该原则建议我们要面向契约编程。
　　8. 你不需要它（You aren't gonna need it - YAGNI）
　　不要一开始就把系统设计得非常复杂，不要陷入“过度设计”的深渊。应该让系统足够的简单，而却又不失扩展性，这是其中的难点。
　　敏捷开发模式的修炼之道
　　CSDN：请问你是如何接触到敏捷开发的？你如何理解敏捷开发？
　　黄勇：曾经我们开发项目都是采用传统的“瀑布式”流程进行开发，即需求、设计、开发、测试、上线等阶段，其中每个阶段都有明确的交付时间点，且每个阶段都依赖于它的上个阶段，一旦需求有变化，就会影响后续的每个阶段，项目管理存在一定的风险。为了避免这个风险，做到更好地拥抱变化，我们尝试使用了敏捷开发方法，最为典型的是 Scrum。我们参考Scrum 的流程结合自身的特点，总结了一套更容易落地的Scrum，后面我会跟大家讲到一些相关细节。
　　我理解的敏捷开发实际上是一个轻量级的项目管理规范，因为我们可以将整个大的需求范围拆分成若干迭代周期，我们为这些迭代周期设置明确的里程碑，且评估完成这些功能需要花费的成本，更重要的是，每次迭代完成以后，我们会对本次迭代进行一个回顾，取其精华，去其糟粕，不断完善，持续改进。
　　CSDN：你认为国内的敏捷开发何时能成为主流？敏捷开发的未来走向是什么？
　　黄勇：我认为敏捷开发现在已经成为了主流，传统开发模式已经出现了明显的缺陷，随着互联网的发展，软件开发的节奏会越来越快，变化也会越来越频繁，需要我们能够快速地发现变化，并进行及时地调整。
　　我认为敏捷开发的未来会变得更好，不仅仅在软件开发行业，而且可能会在其它行业里也会得到应用，因为从客户的角度来看，他们想要的是能通过最短的时间看到自己想要的东西，很多时候不做出一点东西出来，客户是没有任何想法的，所以需要将事情分解成多阶段，迭代完成每个阶段的里程碑，让客户满意，才是企业最大的收获。
　　CSDN：在你的工作生涯中，前期是在创业公司，后来是大公司，有着一套自己的敏捷开发模式，能够谈谈在你现在使用的敏捷开发工具或方法？
　　黄勇：敏捷这个话题大家一直都在谈论，也有很多关于敏捷的工具或方法，我个人比较倾向于 Scrum。我理解的敏捷其实是一种思想，Scrum 是对让这个思想落地的一个参考。也就是说，我们大可不必完全拘泥于 Scrum 定义的规范，只需要参考它并结合自身的条件做适当调整即可。比如说，每日站会这个环节就非常重要，不管是放在每天上午，还是放在每天下午，总之最好要有固定的周期。此外，每次 Sprint（迭代）结束后除了有评审会以外，Scrum Master 不要忘记对本次 Sprint 做一个回顾与总结，哪些是本次迭代中做的好的地方，哪些是做的不好的，再对比上次迭代的的结论，哪些是有改进的，哪些是新的问题。
　　Scrum 提供了三类角色，分别是：Product Owner（一般由产品经理担任）、Scrum Master（一般由开发经理担任）、Scrum Team（包括开发与测试人员），其中，Scrum Master 的角色至关重要，对项目的成败起决定性作用。
　　阿里巴巴也在广泛使用 Scrum 敏捷开发模式，而且整个项目几十人都可以用 Scrum，只是首先需要将整个团队拆分成若干小团队，保证每个小团队按照 Scrum 进行操作，此外，再将每个小团队的 Scrum Master 召集在一起，再做一轮 Scrum，这就是所谓的 Scrum of Scrum。过程稍微复杂一点，但可以将敏捷用于更大的团队规模，并能保证敏捷的效果。
　　CSDN：你认为Scrum Master 的角色至关重要，对项目的成败起决定性作用。那敏捷开发中由产品经理担任Scrum Master会有什么问题？
　　黄勇：我个人不太建议由产品经理来担当Scrum Master，原因如下：
　　Scrum Master 关注的是项目开发视角，而产品经理关注的是产品功能视角，两者关注的视角是不一样的。
　　
　　Scrum Master 需要有一定的技术开发功底，需要对开发工作量进行评估，也需要对技术实现进行评审，可能还会有一定的编码工作，而具有技术功底的产品经理毕竟太少了，即便有的话，可能对技术方面也不会太深入。
　　需要有一个人，他来对整个产品负责，这个人就是Product Owner，该角色最好由产品经理来担任。
　　CSDN：敏捷开发过程中测试团队的职责和产出是什么？
　　黄勇：在敏捷开发过程中，我认为测试团队的职责有以下几点：
　　根据产品需求，定义测试用例。
　　针对测试用例进行功能测试，并将测试的结果反馈给开发人员。
　　负责搭建系统运行所需的环境，包括软件安装、数据初始化等。
　　CSDN：除了Scrum，还有XP、CM、FDD、ASD、DSDM等敏捷开发方法，如何去选择一个合适的敏捷开发工具或者方法呢？
　　黄勇：敏捷开发方法有很多，不仅仅只有Scrum 一种，其实不妨相互借鉴，再结合自身的特点，定义一套适合自己的敏捷开发方法。例如XP 中所提倡的结对编程、持续集成、测试驱动等，这些都是很好的方法，值得借鉴。包括看板也是一个很不错的工具，可以结合Scrum 来工作。
　　CSDN：从博客上，你也研究过「使用看板进行敏捷开发」，能不能分享你的研究成果？
　　黄勇：敏捷开发工具“看板”,该词汇来自于岛国，当我看到看板的英文时，我真的惊呆了，看板竟然就是 Kanban？！
　　我们可以结合 Scrum 与 Kanban，让项目管理更加有效，让资源分配更加合理，让绩效考核更加公平！
　　对于项目经理而言，最担心的就是项目进度不可控，不知道每位开发人员具体的工作进度，有了 Kanban 一切都是那么地清晰。
　　对于开发经理而言，最担心的就是资源分配不合理，忙的人忙死，闲的人闲死，有了 Kanban 一切都是那么地自然。
　　对于开发人员而言，最担心的就是绩效考核不公平，“凭什么我做的比他多，拿的工资却比他少？不公平啊！”有了 Kanban 一切都是那么地公平。
　　可见，项目经理、开发经理、开发人员拥有了 Kanban，也就拥有了和谐与快乐！
　　那么 Kanban 到底是什么呢？我们先来看看这张表格吧：
　　下面我们来理解一下这个表格吧！
　　这个表格有 5 列：Backlog（原始需求）、Selected（被选中的需求）、Develop（开发阶段）、Deploy（部署阶段）、Live（上线阶段）
　　其中 Develop 阶段包括 2 个子阶段：Ongoing（进行中）、Done（已完成）
　　包括 3 中角色：产品经理（红色小人）、开发人员（蓝色小人）、部署人员（绿色小人），其实还有项目经理，只是他/她贯穿于始终，所有就没有画出来了。
　　在 Backlog 中放置了许多小卡片，它们在 Kanban 中被称为 WIP（Work In Process，在制品）。对于产品经理而言，WIP 是需求，而对于开发人员与部署人员而言，WIP 却是任务。
　　实际这些 WIP 卡片上都带有一些文字描述，包括：标题、描述、优先级等信息。
　　需要注意的是，Selected、Develop、Deploy 下方有一个数字，该数字表示此阶段中最多可以放置的 WIP 数量。例如，在 Selected 中最多只能放 2 个 WIP；在 Develop 中（包括它的子阶段）最多只能放置 2 个 WIP。这里的数字只是一个示例，具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”，减 1 表示大家需要协作，例如：4 人的团队，WIP 上限是 7。
　　也许有人会提出，为什么没有 Test 阶段？—— 这个可以有，这里只是一个示例而已，你不妨自行加上去。
　　对于多个项目而言，可以在这张表格中添加更多的泳道（行），每一行相当于一个项目，所有的项目进度清晰明了。
　　好！继续我们的 Kanban，有意思的事情即将发生！
　　产品经理挑选了 2 个 WIP 到 Selected 中，此时，由开发经理决定该任务的技术难度，并由项目经理将任务分配到指定的开发人员，也可将同一个任务分配给两个人，让他们去结对编程。
　　开发人员（架构师与程序员）可对 Selected 中的需求进行工作量评估，可采用投票的方式进行，最终给出一个合理的评估值，整个估算过程，项目经理无需参与，主要是开发人员共同完成。
　　开发经理可以对任务设置一个“分值”，这个分值可直接影响到后续的绩效考核，所以对大家来说，这个分值是公开可见的，谁做的多，谁做得少，一目了 然。当然，开发人员也可以主动承担具有更具挑战的任务（为了锻炼自己，也为了多拿点钱），但任务分配的决定权始终在项目经理手中。
　　现在假设 A、B 两个任务已经分别被不同的开发人员处理了，那么这些任务就应该移动到 Ongoing 中，同时，产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。
　　有人已经把 A 做完了，那么 A 就可以移动到 Done 中了。随后，部署人员就可以开始干活了。
　　部署人员就可以将 A 从 Done 中移动到 Deploy 中，表示部署人员正在做这件事情。同时，做完了 A 任务的开发人员可以再做其它新任务，只需从 Selected 中移动到 Ongoing 中，移动这件事情不是开发人员随意操作的，而是有项目经理负责的。产品经理发现 Selected 中只有一个 D，就可以考虑放入一些新的需求了。
　　此时，部署人员遇到了问题，发现 A 部署的时候总是报错，跑不起来了。同时，其他开发人员也完成了 B 任务。
　　完成了 B 任务的开发人员本来是可以做新需求的，但项目经理发现 Develop 中只能放 2 个任务，所以肯定是后面的阶段出现了问题，导致整个流程受阻了。项目经理可以灵活调度人力资源，集中火力解决现在所遇到的问题。
　　所以项目经理不得不放弃新的任务，去让开发人员去帮助部署人员来解决问题。此时，其他的开发人员还在进行 C 任务。
　　部署的问题还没来得及解决，此时 C 任务也完成了，同时，产品经理也放入了新的 K 需求，确保 Selected 这个水池是装满水的。
　　整个部署问题看起来比较搞人，所有的开发人员全都上阵了，集中更多人的智慧，解决这个棘手的问题。此时，产品经理不能放入更多的需求，由于此时 Selected 已经满额了。其实，开发人员面对太多的需求时，往往都会倍感压力，身心憔悴。
　　看来这个部署问题，确实够折腾的，连产品经理都过来了凑热闹了。但他或许不懂技术，但多个人多个头脑吧，正所谓“当局者迷，旁观者清”，最终经过大家的努力，肯定会攻克这座碉堡！
　　几天之后，Kanban 流程依旧是稳定的，大家分工协作，人力资源合理利用。大家是一个团队，目标就是把项目做好，不会因为自己的事情做完了就闲置了。
　　我们不妨将这张表格贴到墙上去吧！让每个员工都可以看到，让过路的老板们也可以看到我们的辛苦努力，这确实是一种非常好的项目管理方法！
　　CSDN：一个成功的项目，离不开每个人的努力，能够分享下你曾经的项目管理经验？
　　黄勇：给大家提出以下 10 点建议及其目标：
　　Sprint 第一天，需要将目标定义清楚，并让团队所有人都知道「确保建立一致的目标并使之明确」；
　　若出现需求变更，则优先排到下次迭代，特殊情况需特殊处理「确保本次迭代可以按时完工」；
　　Scrum Master 将迭代中的需求分解为任务，每个任务只能有一个任务负责人，且不超过一个人天「确保每日任务可评估」；
　　让 Product Owner 直接与相关开发人员确定需求，Scrum Master 需一同参与「确保需求与实现不会发生偏差」；
　　每日定时站会，时长不超过 15 分钟，规模不要太大「确保任务完成情况与计划保持一致」；
　　每日进行一次代码评审，由 Scrum Master 负责，并在次日将评审结果通知给相关开发人员「确保代码质量不要下降」；
　　各个团队的 Scrum Master 保持每日沟通一次，时间不要超过 15 分钟「确保项目管理不会出现风险」；
　　每次迭代结束，让大家稍微放松一下，可提供一些团队活动，比如聚餐「确保团队能够更加凝聚」；
　　Scrum Master 需要给团队一些承诺，比如项目奖金或特殊福利等「确保团队更加有激情」；
　　对于情绪异常的员工，Scrum Master 需及时与其沟通「确保不要让一个人的情绪影响整个团队」；
　　此外，作为项目管理者，需要不断在团队中加强以下 6 点文化：
　　1. 方向一致
　　2. 当面沟通
　　3. 全情投入
　　4. 充分信任
　　5. 说到做到
　　真正的开源并非只是代码的开源，而是思想的开源
　　CSDN：你在开源方面有着诸多的建树，例如，你是Smart Framework开源框架创始人，你对「开源」怎么看？国内的开源的现在如何，对比国外呢？
　　黄勇：我个人认为，真正的开源并非只是代码的开源，而是思想的开源。在做开源项目之前，建议能将自己的想法共享出来，而不是 埋头闭门造车。我不反对“重造轮子”，因为我们需要更好的轮子，轮子好了车子才能跑得快。凡是有利也有弊，我们也不能盲目地选择开源技术，因为并不是适合 别人的技术就适合自己，而是需要根据自身的需求，选择最适合的开源技术，搭建恰如其分的架构。
　　有大量的新技术，我首先会去关注它，了解它是做什么的，可以解决什么问题，但我一开始绝不会去深入研究它，更不会去看它的源码，因为一旦遇到这方面的需求场景，我就会从这个“知识库”中去寻找最好的解决方案，如果仍然寻找不到最合适的开源技术，我才会尝试自己去实现。
　　CSDN：能够介绍下你写的Smart Framework的轻量级 Java Web 开发框架？
　　黄勇：基于对开源的热爱，以及上述中我的开源态度。我写了一款名为 Smart Framework 的轻量 级 Java Web 开发框架，它基于“微内核 + 多插件”的体系架构，基于 Servlet 3.0 规范，不依赖于 Spring、 Hibernate 等开源框架，提供 IOC、AOP、ORM 等轻量级解决方案，并具备良好的可扩展性，前端直接使 用 HTML + CSS + JS 开发模式，同时也兼容 JSP、JSTL、Tag 等技术，后端提供 REST 服务接口（基于 JSON 格 式），没有任何的 XML 配置文件，真正的零配置。我认为这些特性足以开发一些简单的 Web 应用程序，至于复杂的功能，就留给插件去完善吧。
　　当初写 Smart 的时候并没有想到大家会对这个框架会如此感兴趣，抱着分享的态度，并不想去推广这个产品，仅仅只是想找到能够理解自己开源思想 的同道中人。世事总难料，已经有一些企业和个人开始使用这款框架了，并提供了大量的改造与扩展。我很欣慰，因为我基本上实现了自己的愿望，并希望将来会出 现有更好的 Java Web 框架，丢掉重量级的帽子，披上轻量级的外衣。
　　技术人的归途
　　编者注：在采访期间，小编和一位同是十年工作经验的coder聊天，发现他正陷于转型做管理、深耕技术的泥潭，为此向黄勇老师请教，得出了一个非常不错的中肯建议，也整理在这里，希望对你有所帮助。
　　CSDN：走技术这条路，归途是什么？是否转型又该如何抉择呢？
　　黄勇：至少有好几条路线是可以走的，比如：深入技术、转型做产品、转型做管理等，需要根据自己的特长和性格来选择，做自己喜欢的事情。
　　从技术转管理，对自身的要求比较高，说具体点，需要看自己的情商，为人处世的经验，与人沟通的技巧，自己也需要有足够的胸怀，去包容一些事情，还需要自己有足够的人格魅力去吸引别人，让别人愿意跟着你一起做事。管理有些东西是很难从书本上学到的，但一些经典的管理理论是必须要去学的。
　　相比较而言，继续深入技术或者从技术转产品会容易一些了，因为很多时候都不太需要与人打交道
　　CSDN：关于机遇，是可遇不可求的。比如，当管理，那也是有一定的环境造就，你得有这个机会去试一下，才知道自己是否感兴趣做管理，以及是否适合等。
　　黄勇：没错，机遇太重要了，而且有些时候，机遇是可以考自己的努力去得到的，说到底还是与人沟通，让自己的老板给自己机会，如果现在的公司给不了自己足够的机遇，那么不妨考虑一下外面的机遇。总之，自己需要灵活处理，伴随公司共同成长才是最好的。
　　CSDN：程序员相对比较「直」，也就是有啥说啥，事后或许才发现说了不该说的话，情商不高，如果改善这一情况呢？
　　黄勇：性格比较直，说话容易得罪人，这个很正常了，只不过首先需要向对方阐明自己的观点，是为了把这件事情做好，和对方的目标是一致的，也就是说，首先与对方共同的价值观，然后再说自己的想法，并多听取对方的意见，尽量多和对方保持相同的看法，最后需要注意的是，自己不擅长的方面，尽量多听少说，听也是在学习。
　　在听的过程中，可以表达自己的认识，并询问对方是否这样理解的。
　　CSDN：最后，你是怎么分配一天的时间的？闲暇时，喜欢做些什么来放松自己？
　　黄勇：平时工作我一般都比较忙，会议占据了我大部分时间，在自己仅有的工作时间里我会花更多的时间与团队主管们进行沟通，让大家保持一致的方向，这样每个技术主管也会带出更适合公司文化的团队。总之，技术氛围不是一两天就能形成的，需要长时间的沟通，这个时间对于技术管理人员是必须要付出的。
　　在闲暇之余，我喜欢听音乐，也喜欢和朋友聊天，朋友是自己的一面镜子，可以通过这面镜子来看清自己，其实人这一辈子都是在不断地看清自己，认识自己。
　　写给读者的话：
　　非常感谢读者们能够花自己宝贵的时间来阅读本文，其实我自己也和大家一样，我们都在不断地学习，不断地提高自己，真心希望本文能够帮助大家。此外，我也很期待大家能与我进一步互动，我平时也会在线下组织一些小规模的技术交流活动，希望大家能够相互认识，相互分享，相互帮助。
　　为了营造一个互动友好的学习环境，我给大家创建了一个 Java 读者交流群，这是一个 群，群号是567079416，感兴趣的同学可以识别下面的二维码加一下（点击阅读原文也可以），申请加群理由填写「x年码洞」 查看全部

　　对呀，我就是认定架构师都是不干活，只会画PPT的！
　　这是去年在部门内部做的一个面向后台开发新同学的课程，因为其他BG一些同学要求分享，所以发一下。
　　其实内容都是些常见开源组件的high level描述，比如flask, express框架，中间件的演化，micro service的概念，一些对nosql/column based db的概念介绍，docker的一些简单概念等等。从单个概念来说，这只是一些科普。
　　但是为什么当时要开这门课呢？重点是我发现很多新入职的后台开发同学并不太清楚自己做的东西在现代互联网整体架构中处于一个什么样的角色，而在IEG内部则因为游戏开发和互联网开发的一些历史性差异，有些概念并不清晰。
　　拿中间件来说，很多web application不用啥中间件一样可以跑很好，那么是不是都要上redis？到底解决什么问题？中间件又存在什么问题？中台和中间件又是个什么关系？如果开个mq就是中间件，微服务又是要做啥？
　　如果能从这十多年来互联网应用的整个tech stack变化去看待backend architecture的一些改变，应该是一件有趣也有意思的事情。这是当时写这个ppt开课的初衷。
　　我不敢说我在这个ppt里面的一些私货概念就是对的，但是也算是个人这么多年的一些认知理解，抛砖引玉吧。
　　强调一点，这个ppt的初衷是希望从近十多年来不同时代不同热点下技术栈的变化来看看我们是如何从最早的php/asp/jspmysql这样的两层架构，一个阶段一个阶段演变到现在繁复的大数据、机器学习、消息驱动、微服务架构这样的体系，然后在针对其中比较重要的几个方面来给新入门后台开发的同学起个“提纲目录”的作用。如果要对每个方面都深入去谈，那肯定不是一两页PPT就能做到的事情。
　　下面我们开始。首先看第一页如下图：什么是System Design?什么是架构设计？为什么要谈架构设计？
　　之所以抛出这个问题，是因为平时常常听到两个互相矛盾的说法：一方面很多人爱说“架构师都是不干活夸夸其谈”，另一方面又有很多人苦恼限于日常业务需求开发，无法或者没有机会去从整体架构思考，不知道怎么成长为架构师。
　　上面ppt中很有趣的是第一句英文，翻译过来恰好可以反映了论坛上经常有人问的“如何学习架构”的问题：很多leader一来就是扔几本书（书名）给新同学，期望他们读完书就马上升级。。。这种一般都只会带来失望。
　　何为架构师？不写代码只画PPT？
　　不是的，架构师的基本职责是要在项目早期就能设计好基本的框架，这个框架能够确保团队成员顺利coding满足近期内业务需求的变化，又能为进一步的发展留出空间（所谓scalability），这即是所谓技术选型。如何确保选型正确？对于简单的应用，或者没有新意完全是实践过多次的相同方案，确实靠几页PPT足矣。但是对于新的领域新的复杂需求，这个需求未必都是业务需求，也包括根据团队自身特点（人员太多、太少、某些环节成员不熟悉需要剥离开）来进行新的设计，对现有技术重新分解组合，这时候就需要架构师自己编码实现原型并验证思路正确性。
　　要达到这样的目标难不难？难！但是现在不是2000年了，是2019年了，大量的框架(framework)、开源工具和各种best practice，其实都是在帮我们解决这件事情。而这些框架并不是凭空而来，而是在这十多年互联网的演化中因为要解决各种具体业务难点而一点一点积累进化而来。无论是从mysql到mongodb到cassandra到time series db，或者从memcached到redis，从lucene到solr到elasticsearch，从离线批处理到hadoop到storm到spark到flink，技术不是突然出现的，总是站在前人的肩膀上不断演变的。而要能在浩如烟海的现代互联网技术栈中选择合适的来组装自己的方案，则需要对技术的来源和历史有一定的了解。否则就会出现一些新人张口ELK，闭口tensorflow，然后一个简单的异步消息处理就会让他们张口结舌的现象。
　　20多年前的经典著作DesignPatterns中讲过学习设计模式的意义，放在这里非常经典：学习设计模式并不是要你学习一种新的技术或者编程语言，而是建立一种交流的共同语言和词汇，在方案设计时方便沟通，同时也帮助人们从更抽象的层次去分析问题本质，而不被一些实现的细枝末节所困扰。同时，当我们能把很多问题抽象出来之后，也能帮我们更深入更好地去了解现有系统-------这些意义，对于今天的后端系统设计来说，也仍然是正确的。
　　下图是我们要谈的几个主要方面。
　　
　　上面的几个主题中，第一个后台架构的演化是自己从业十多年来，体会到的互联网技术架构的整体变迁。然后分成后台前端应用框架、middleware和存储三大块谈一下，最后两节微服务和docker则是给刚进入后台开发的同学做一些概念普及。其中个人觉得最有趣的，是第一部分后台架构的演化和第三部分的中间件，因为这两者是很好地反映了过去十多年互联网发展期间技术栈的变化，从LAMP到MEAN Stack，从各种繁复的中间层到渐渐统一的消息驱动+流处理，每个阶段的业界热点都相当有代表性。
　　当然，不是说web框架、数据存储就不是热点了，姑且不说这几年web前端的复杂化，光后端应用框架，node的express，python的django/flask，go在国内的盛行，都是相当有趣的。在数据存储领域，列存储和时序数据随着物联网的发展也是备受重视。但是篇幅所限，在这个课程中这些话题也就只能一带而过，因为这些与其说是技术的演变过程，不如说是不同的技术选型和方向了，比如说Mysql适合OLTP（Online Transaction Processing），而Cassandra/Hbase等则适合OLAP(Online Analyical Processing)，并不能说后者就优于前者。
　　下面我们先来看后台架构的演化
　　
　　严格说这是个很大的标题，从2000年到现在的故事太多了，我这里只能尽力而为从个人体验来分析。
　　首先是2008年以前，我把它称为网站时代。为什么这么说？因为那时候的后台开发就是写网站，而且通常是页面代码和后台数据逻辑一起写。你只要能写JSP/PHP/ASP来读写Mysql或者SQL Server，基本就能保证一份不错的工作了。
　　
　　要强调一下，这种简单的两层结构并不能说就是落后。在现在各个企业、公司以及小团队的大量web应用包括移动App的后端服务中，采用这种架构的不在少数，尤其是很多公司、学校、企业的内部服务，用这种架构已经足够了。
　　注意一个时间节点：2008。
　　当然，这个节点是我YY的。这个节点可以是2007，或者2006。这个时间段发生了两个影响到现在的事情：google上市，facebook开始推开
　　我个人相信前者上市加上它发表的那三篇大数据paper影响了后来业界的技术方向，后者的火热则造成了社交成为业务热点。偏偏社交网站对大数据处理有着天然的需求，技术的积累和业务的需求就这么阴差阳错完美结合了起来，直接影响了大海那边后面的科技发展。
　　同时在中国，那个时候却是网络游戏MMO的黄金年代，对单机单服高并发实时交互的需求，远远压过了对海量数据data mining的需要，在这个时间点，中美两边的互联网科技树发生了比较大的分叉。这倒是并没有优劣之说，只是业务场景的重要性导致了技能树的侧重。直到今天，单机(包括简单的多服务器方案)高并发、高QPS仍然也是国内业界所追求的目标，而在美国那边，这只是一个业务指标而已，更看重的是如何进行水平扩展(horizontal scaling)和分散压力。
　　国内和美国的科技树回到一条线上，大数据的业务需求和相关技术发展紧密结合起来，可能要到2014年左右，随着互联网创业的盛行，O2O业务对大数据实时处理、机器学习推荐提出了真正的需求时，才是国内业界首次出现技术驱动业务，算法驱动产品的现象，重新和美国湾区那边站在了一条线上，而这则是后话了。
　　
　　到了2010年前后，facebook在全球已经是现象级产品，当时微软直接放弃了windows live，就是为了避免在社交领域硬怼facebook。八卦一下当时在美国湾区那边聚餐的时候，如果谁说他是facebook的，那基本就是全场羡慕的焦点。
　　facebook的崛起也带动了其他大量的社交网站开始出现，社交网站最大的特点就是频繁的用户搜索、推荐，当用户上亿的时候，这就是前面传统的两层架构无法处理的问题了。因此这就带动了中间件的发展。实际上在国外很少有人用中间件或者middelware这个词，更多是探讨如何把各种service集成在一起，像国内这样强行分成frontend/middleware/storage的概念是没听人这么谈过的，后面中间件再说这问题。当时的一个惯例是用php做所谓的胶水语言(glue language)，然后通过hessian这些协议工具来把其他java服务连接到一起。与此同时，为了提高访问速度，降低后端查询压力，memcached/redis也开始大量使用。基于lucene的搜索（2010左右很多是自行开发）或者solr也被用在用户搜索、推荐以及type ahead这些场景中。
　　我记忆中在2012年之前消息队列的使用还不是太频繁，不像后来这么重要。当时常见的应该就是beanstalkd/rabbitmq, zeromq其实我在湾区那边很少听人用，倒是后来回国后看到国内用的人还不少。Kafka在2011年已经出现了，有少部分公司开始用，不过还不是主流。
　　
　　2013年之后就是大数据+云的时代了，如果大家回想一下，基本上国内也是差不多在2014年左右开始叫出了云+大数据的口号（2013年国内还在手游狂潮中...）。不谈国外，在中国那段时间就是互联网创业的时代，从千团大战到手游爆发到15年开始的O2O，业务的发展也带动了技术栈的飞速进步。左上角大致上也写了这个时代互联网业界的主要技术热点，实际上这也就是现在的热点。无论国内国外，绝大部分公司还并没有离开云+大数据这个时代。无论是大数据的实时处理、数据挖掘、推荐系统、Docker化，包括A/B测试，这些都是很多企业还正在努力全面解决的问题。
　　但是在少数站在业界技术顶端或者没有历史技术包袱的新兴公司，从某个角度上来说，他们已经开始在往下一个时代前进：机器学习AI驱动的时代
　　
　　2018年开始，实际上可能是2017年中开始，AI驱动成了各大公司口号。上图是facebook和uber的机器学习平台使用情况，基本上已经全部进入业务核心。当然并不是说所有公司企业都要AI驱动，显然最近发生的波音737事件就说明该用传统的就该传统，别啥都往并不成熟的AI上堆。但另一方面，很多新兴公司的业务本身就是基于大数据或者算法的，因此他们在这个领域也往往走得比较激进。由于这个AI驱动还并没有一个很明确的定义和概念，还处于一种早期萌芽的阶段，在这里也就不多YY了。
　　互联网后台架构发展的简单过程就在这里讲得差不多了，然后我们快速谈一下web开发框架。
　　
　　首先在前面我提到，在后端架构中其实也有所谓的frontend(前台）开发存在，一般来说这是指响应用户请求，实现具体业务逻辑的业务逻辑层。当然这么定义略微粗糙了些，很多中间存储、消息服务也会封装一些业务相关逻辑。总之web开发框架往往就是为了更方便地实现这些业务逻辑而存在的。
　　前文提到在一段较长时间内，国内的技术热点是单机高并发高QPS，因此很多那个时代走过来的人会本能地质疑web框架的性能，而更偏好TCP长链接甚至UDP协议。然而这往往是自寻烦恼，因为除开特别的强实时系统，无论是休闲手游、视频点播还是信息流，都已经是基于HTTP的了。
　　
　　上图所提到的两个问题中，我想强调的是第一点：所有的业务，在能满足需求的情况下，首选HTTP协议进行数据交互。准确点说，首选JSON，使用web API。
　　Why? 这就是上图第一个问题所回答的：无状态、易调试易修改、一般没有80端口限制。
　　最为诟病的无非是性能，然而实际上对非实时应用，晚个半秒一秒不应该是大问题，要考虑的是水平扩展scalability，不是实时响应（因为前提就是非实时应用）；其次实在不行你还有websocket可以用。
　　
　　这一部分是简单列举了一下不同框架的使用，可以看出不同框架的概念其实差不多。重点是要注意到middleware这个说法在web framework和后端架构中的意义不同。在web framework中是指具体处理GET/POST这些请求之前的一个通用处理（往往是链式调用），比如可以把鉴权、一些日志处理和请求记录放在这里。但在后端架构设计中的middleware则是指类似消息队列、缓存这些在最终数据库之前的中间服务组件。
　　
　　最后这里是想说web framework并不是包治百病，实际上那只是提供了基础功能的一个library，作为开发者则更多需要考虑如何定义配置文件，一些敏感参数如token、密码怎么传进来，开发环境和生产环境的配置如何自动切换，单元测试怎么搞，代码目录怎么组织。有时候我们可以用一些比如Yeoman之类的scaffold工具来自动生成项目代码框架，或者类似django这种也可能自动生成基本目录结构。
　　下面进入Middleware环节。again，强调一下这里只是根据个人经验和感受谈谈演化过程。
　　
　　
　　这一页只是大致讲一下怎么定义中间件middleware。说句题外话，在美国湾区那边提这个概念的很少，而阿里又特别喜欢说中间件，两者相互的交流非常头痛。湾区那边不少google、facebook还有pinterest/uber这些的朋友好几次都在群里问说啥叫中间件。
　　中间件这个概念很含糊，应该是阿里提出来的，对应于middleware（不过似乎也不是完全对应），可能是因为早期java的EJB那些概念里面比较强调middleware这一点吧（个人猜的）。大致上，如果我们把web后端分为直接处理用户请求的frontend，最后对数据进行持久存储(persistant storage)这两块，那么中间对数据的所有处理环节都可以视为middleware。
　　
　　和中间件对应的另一个阿里发明的概念是中台。近一年多阿里的中台概念都相当引人注意，这里对中台不做太多描述。总体来说中台更多是偏向业务和组织架构划分，不能说是一个技术概念，也不是面向开发人员的。而中间件middleware是标准的技术组件服务。
　　那么我们自然会有一个问题：为什么要用中间件？
　　
　　谈到为什么要用middlware，这里用推荐系统举例。
　　推荐系统，对数据少用户少的情况下，简单的mysql即可，比如早期论坛的什么top 10热门话题啊，最多回复的话题啊，都可以视为简单的推荐，数据量又不大的情况下，直接select就可以了。
　　如果是用户推荐的话，用户量不大的情况下，也可以如法炮制，选择同一区域（城市）年龄相当的异性，最后随机挑几个给你，相信世纪佳缘之类的交友网站早期实现也就是类似的模式。
　　
　　那么，如果用户量多了呢？每次都去搜数据库，同时在线用户又多，那对数据库的压力就巨大了。这时候就是引入缓存，memcached、redis就出现了。
　　简单的做法就是把搜索条件作为key，把结果作为value存入缓存。打个比方你可以把key存为 20:40:beijing:male (20到40岁之间北京的男性），然后把第一次搜索的结果全部打乱shuffle后，存前1000个，10分钟过期，再有人用类似条件搜索，就直接把缓存数据随机挑几个返回。放心，一般来说不会有人10分钟就把1000个用户的资料都看完了，中间偶有重复也没人在意（用世纪佳缘、百合网啥的时候看到过重复的吧）。
　　不过话又说回来，现代数据库，尤其是类似mongodb/es这些大量占用内存的nosql，已经对经常查询的数据做了缓存，在这之上再加cache，未必真的很有效，这需要case by case去分析了，总之盲目加cache也并不推荐。
　　加缓存是为了解决访问速度，减轻数据库压力，但是并不提高推荐精准度。如果我们要提高推荐效果呢？在2015年之前机器学习还没那么普及成熟的时候，我们怎么搞呢？
　　
　　提高推荐效果，在机器学习之前有两种做法：
　　- 引入基于lucene的搜索引擎，在搜索的同时通过定制方案实现scoring，比如我可以利用lucene对用户的年龄、性别、地址等进行indexing，但是再返回结果时我再根据用户和查询者两人的具体信息进行关联，自定义返回的score（可以视为推荐相关系数）
　　- 采用离线批处理。固然可以用hadoop，但是就太杀鸡用牛刀了。常见的是定时批处理任务，按某种规则划分用户群体，对每个群体再做全量计算后把推荐结果写入缓存。这种可以做很繁复准确的计算，虽然慢，但效果往往不错。这种做法也常用在手机游戏的PvP对战列表里面。
　　这些处理方法对社交网络/手游这类型的其实已经足够了，但是新的业务是不断出现的。随着uber/滴滴/饿了么/美团这些需要实时处理数据的app崛起，作为一个司机，并不想你上线后过几分钟才有客人来吧，你希望你开到一个热点区域，一开机就马上接单。
　　
　　所以这种对数据进行实时（近实时）处理的需求也带动了后端体系的大发展，kafka/spark等等流处理大行其道。这时候的后端体系就渐渐引入了消息驱动的模式，所谓消息驱动，就是对新的生产数据会有多个消费者，有的是满足实时计算的需求（比如司机信息需要立刻能够被快速检索到，又不能每次都做全量indexing，就需要用到spark），有的只是为了数据分析，写入类似cassandra这些数据库里，还有的可能是为了生成定时报表，写入到mysql。
　　大数据的处理一直是业界热点领域。记得2015年硅谷一个朋友就是从一家小公司做php跳去另一家物联网公司做spark相关的工作，之前还很担心玩不转，搞了两年就俨然业界大佬被oracle挖去负责云平台～～～
　　anyway，这时候对后端体系的要求是一方面能快速满足实时需求，另一方面又能满足各种耗时长的数据分析、data lake存储等等，以及当时渐渐普及的机器学习模型（当时2015年初和几个朋友搞startup，其中一个是walmart lab的机器学习专家，上来就一堆模型，啥数据和用户都还没有就把模型摆上来了，后来搞得非常头痛。当时没有keras/pytorch/tf这些，那堆模型是真心搞不太懂，但是又不敢扔，要靠那东西去包装拿投资的。。。）
　　但是我们再看上面的图，是不是感觉比较乱呢？各种系统的数据写来写去，是不是有点messy？当公司团队增多，系统复杂度越来越高的时候，我们该怎么梳理？
　　
　　到了2017之后，前面千奇百怪的后端体系基本上都趋同了。kafka的实时消息队列，spark的流处理（当然现在也可以换成flink，不过大部分应该还是spark），然后后端的存储，基于hive的数据分析查询，然后根据业务的模型训练平台。各个公司反正都差不多这一套，在具体细节上根据业务有所差异，或者有些实力强大的公司会把中间一些环节替换成自己的实现，不过不管怎么千变万化，整体思路基本都一致了。
　　这里可以看到机器学习和AI模型的引入。个人认为，machine learning的很大一个好处，是简化业务逻辑，简化后台流程，不然一套业务一套实现，各种数据和业务规则很难用一个整体的技术平台来完成。相比前面一页的后台架构，这一页要清晰许多，而且是一个DAG有向无环图的形式，数据流向很明确。我们在下面再来说这个机器学习对业务数据流程的简化。
　　
　　在传统后端系统中，业务逻辑其实和数据是客观分离的，逻辑规则和数据之间并不存在客观联系，而是人为主观加入，并没形成闭环，如上图左上所示。而基于机器学习的平台，这个闭环就形成了，从业务数据->AI模型->业务逻辑->影响用户行为->新的业务数据这个流程是自给自足的。这在很多推荐系统中表现得很明显，通过用户行为数据训练模型，模型对页面信息流进行调整，从而影响用户行为，然后用新的用户行为数据再次调整模型。而在机器学习之前，这些观察工作是交给运营人员去手工猜测调整。
　　上图右边谈的是机器学习相关后台架构和传统web后台的一些差别，重点是耗时太长，必须异步处理。因此消息驱动机制对机器学习后台是一个必须的设计。
　　这页是一些个人的感受，现代的后端数据处理越来越偏向于DAG的形态，Spark不说了，DAG是最大特色；神经网络本身也可以看作是一个DAG（RNN其实也可以看作无数个单向DNN的组合）；tensorflow也是强调其Graph是DAG，另外编程模式上，Reactive编程也很受追捧。
　　其实DAG的形态重点强调的就是数据本身是immutable（不可修改），只能transform后成为新的数据进入下一环。这个思维其实可以贯穿到现代后台系统设计的每个环节，比如trakcing、analytics、数据表设计、microservice等等，但具体实施还是要case by case了。
　　无论如何，数据，数据的跟踪tracking，数据的流向，是现代后台系统的核心问题，只有data flow和data pipeline清晰了，整个后台架构才会清楚。
　　数据库是个非常复杂的领域，在下面对几个基本常用的概念做一些介绍。注意一点是graph database在这里没有提到，因为日常使用较少，相对来说facebook提出的GraphQL倒是个有趣的概念，但也只是在传统db上的一个概念封装。
　　
　　
　　上图是2018年12月初热门数据库的排名，我们可以看到关系数据库RDBMS和NOSQL数据库基本上平分秋色。而NOSQL中实际上又可以分为key-value storage（包括文档型）及column based DB.
　　mysql这个没啥好讲，大概提一下就是。有趣的是曾经看到一篇文章是aws CTO谈的一些内容，其中印象深刻是：如果你的用户还不到100万，就别折腾了，无脑使用mysql吧）
　　在2015年之前的一个趋势是不少公司使用mysql作为数据存储，但是把indexing放在外部去做。这个思路最早似乎是friendster提出的，后来uber也模仿这种做法设计了自己的数据库schemaless。然而随着postgreSQL的普及(postgreSQL支持对json的索引)，这种做法是否还有意义就值得商榷了。
　　
　　nosql最早的使用就是key-value的查找，典型的就是redis。实际上后来的像mongo这些documentbased db也是类似的key value，只是它对document中的内容又做了一次index (inverted index)，用空间换时间来提供查找数据，这也是cs不变的思维。
　　mongo/elasticsearch收到热捧主要是因为它们的schemaless属性，也就是不需要提前定义数据格式，只要是json就存，还都能根据每个field搜索，这非常方便程序员快速出demo。但是实际上数据量大之后还是要规范数据结构，定义需要indexing的field的。
　　
　　这里提一个比较好玩的开源project nodebb, 这是个node.js开发的论坛系统。在我前几年看到这个的时候它其实只支持redis，然后当时因为一个项目把它改造了让他支持mysql。去年再看的时候发现它同时支持了redis/postres/mongo，如果对比一下同样的功能他如何在这三种db实现的，相信会很有帮助。
　　稍微谈谈列存储。常见mysql你在select的时候其实往往会把整行都读出来，再在其中挑那么一两个你需要的属性，非常浪费。而mongo这些文件型db，又不支持常见SQL。而列存储DB的好处就是快，不用把一行所有信息读出来，只是按列读取你需要的，对现在的大数据分析特别是OLAP(Online Analytical Processing)来说特别重要。然而据另外的说法，实际上像casssandra/hbase这些并不是真正的列存储，而只是借用了一些概念。这个我也没深入去了解，有兴趣的同学可以自己研究研究。
　　
　　列存储的一个重要领域是时序数据库，物联网用得多。其特色是大量写入，只增不改（不修改数据），但是读的次数相对于很少（想想物联网的特点，随时有数据写入，但是你不会随时都在看你家小米电器的状态。。。）
　　注意说write/read是正交的。这意思是每次写入是一次一行，而读是按列，加上又不会修改数据，因此各自都能保持极快的速度
　　下面简单谈一下微服务，大部分直接看PPT就可以了，有几页略微谈一下个人思考。
　　
　　
　　
　　
　　
　　上面这页说说，其实微服务所谓的服务发现/name service不要被忽悠觉得是多神奇的东西。最简单的Nginx/Apache这些都能做（域名转向，proxy），或者你要写个name : address的对应关系到db里面也完全可以，再配一个定时healthcheck的服务，最简单的服务发现也就行了。
　　高级点用到zookeeper/etcd等等，或者SpringCloud全家桶，那只是简化配置，原理都一样。从开发角度来看，微服务的开发并不是难点，难点是微服务的配置和部署。最近一段时间微服务部署也是业界热点，除了全家桶形态的SpringCloud，也可以看看lstio这些开源工具。
　　上图主要大致对比一下，看看从早期的Spring到现在Spring Cloud的变化。想来用过Java Tomcat的朋友都能体会Java这一套Config based development的繁琐，开发的精力很多不是在业务代码上，往往会化不少精力去折腾配置文件。当然，Spring Cloud在这方面简化了不少，不过个人还是不太喜欢java，搞很多复杂的设计模式，封装了又封装。
　　
　　这里要说并不是微服务解决一切，热门的Python Django尽管有restful-framework，但是它实际上是一个典型的Monolithic体系。对很多核心业务，其实未必要拆开成微服务。
　　这两者是互补关系，不是替代关系。
　　下面的docker我就不仔细谈了，PPT基本表达了我想表述的概念，主要意思是
　　-docker能够简化部署，简化开发，能够在某种程度上让开发环境和产品环境尽量接近
　　- 不要担心docker的性能，它不是虚拟机，可以看作在server上运行的一个process。
　　
　　
　　上图是描述docker之前开发人员的常见开发环境，首先在自己机器上装一大堆服务，像mysql, redis, tomcat啥的。也有直接在远程服务器安装环境后，多人共同登录远端开发，各自使用一个端口避免冲突…. 实际上这种土法炼钢的形态，在2019年的今天仍然在国内非常普及。
　　这种形态的后果就是在最后发布到生产环境时，不同开发人员会经历长时间的“联调”，各种端口、权限、脚本、环境设置在生产环境再来一遍…这也是过去运维人员的主要工作。
　　
　　上一页提到的问题，并不是一定要docker来解决。在这之前，虚拟机VM的出现，以及vagrant这样的工具，都让开发环境的搭建多少轻松了一些。不过思路仍然是把VM作为一个独立服务器使用，只是因为快照、镜像和辅助工具，让环境的配置、统一和迁移更加简单快捷。
　　
　　上图是对比程序运行在物理服务器、VM及docker时的资源共享情况，可以看到运行在Docker的应用，并没有比并发运行在物理服务器上占用更多资源。
　　下图是简单的docker使用，不做赘述。
　　
　　这一页主要是强调Docker并不等同于虚拟机。虚拟机所占资源是独享的，比如你启动一个VM，分配2G内存，那么这个VM里不管是否运行程序都会占用2G内存。然而如果你启动一个Docker，里面运行一个简单web服务，在不强制指定内存占用情况下，如果没有请求进入，没有额外占用内存，那么这个docker服务对整机的内存占用几乎为0（当然仍然存在一些开销，但主要是根据该程序自身的运行状况而定）。
　　
　　最后Kubernetes这里大概说说host-pod-container的关系，一个host可以是物理机或者vm，pod不是一个docker，而是可以看作有一个ip的...（不知道怎么形容），总之一个pod可以包括多个container(docker)，pod之中的container可以共享该pod的资源（ip，storage等）。不过现实中似乎大多是一个pod对一个container。
　　对互联网一些热门概念和演变过程的一个很简略的描述就到这里了，谢谢。
　　————e n d————
　　本期专题推荐
　　手
　　专
　　题
　　写
　　【手写专题】师长说：想要进阶架构师，不仅仅只是懂得框架原理。下面，就让师长手把手带你手写SpringMVC、Spring、Mybatis、秒杀架构、RPC等框架，让你提升架构思维，真正吃透！
　　↓↓↓↓↓点击标题即可跳转↓↓↓↓↓
　　跳转前别忘了先在本篇文章留言，在看
　　其余的微服务、分布式、高并发、JVM调优等20大进阶架构师专题请关注公众号【Java进阶架构师】后在菜单栏查看。
　　看到这里，说明你喜欢本文
　　你的转发，是对我最大的鼓励！在看亦是支持↓ 查看全部

　　架构师的核心工作内容解析
　　
　　
　　
　　
　　公众号回复'架构'获取架构师电子书及视频课程
　　
　　
　　前期思考
　　很多软件开发同学的职业规划都是架构师，试想这样一个场景，如果公司安排你做架构师，让你在项目开发前期进行了一些架构设计。
　　架构师的核心工作就是做好软件架构设计，软件设计是软件开发过程中一个重要的环节。
　　以上这些诉求可以说是软件开发管理与技术的核心诉求，这些问题搞定了，软件的开发过程和结果也就得到了保障。
　　核心关键点两个客观存在
　　我们再来看看，解决这些问题你需要理解的核心关键点，也就是说究竟如何做软件设计，解决方法就是软件建模，就是软件的抽象模型，这些模型之上配上文字说明，就形成了软件的设计文档。
　　模型是对客观存在的抽象，在软件开发中有两个客观存在：
　　一个是我们要解决的领域问题，比如我们要开发一个电子商务网站，那么客观的领域问题就是如何做生意，卖家如何管理商品，管理订单服务用户，买家如何挑选商品，如何下单，如何支付等等，对于这些客观领域问题的抽象就是各种功能及其关系，各种模型对象及其关系，各种业务处理流程。
　　另一个客观存在就是最终开发出来的软件系统，这个软件系统也是客观存在的。
　　所以这两方面的客观存在的抽象就是我们的软件模型。
　　一方面，我们要对领域问题和软件系统进行分析，设计抽象，另一方面，我们根据抽象出来的模型，进行软件开发，这就是软件开发的主要过程。
　　
　　而对领域问题和软件系统进行分析，设计抽象，这个过程我们称它为软件建模与设计。
　　UML工具
　　软件建模工具很多，目前主要是统一建模语言UML。
　　所谓的建模，就是对领域问题和软件系统进行抽象设计，一个工具完成前述软件开发过程中的两个客观存在的建模。
　　而所谓的语言，一则用于沟通，满足设计阶段和各个相关方沟通的目的，一则用于思考，即使软件开发过程中不需要跟其他人沟通，或者还没有到了沟通的时候，依然可以使用UML建模，帮助自己进行设计思考。
　　此外，语言还有个特点，就是有方言，就我观察不同公司，不同团队，都有自己的特点，并不需要拘泥于以往那样规范和语法，只要不引起歧义，在使用过程中对语法元素适当变通，这是UML的最佳实践。
　　软件建模与设计过程又可以拆分成需求分析，概要设计，详细设计三个阶段，而软件建模的主要工具是UML，下面我们看一下使用方法包含了哪些软件模型，常用的有7种。
　　7种软件模型
　　下面我们讨论这7种模型图，如何在三个阶段使用。
　　类图
　　
　　类图是最常见的UML图形，用来描述类的特性和类之间的静态关系，一个类包含三个部分，类的名称，类的属性列表，类的方法列表之间有6种静态关系关联，关联，依赖，聚合，组合，继承，泛化，而相关的一组类及其关系，用一张图画出来就是类图，类图主要是在详细设计阶段化，如果内图已经设计出来了，那么开发工程师只需要按照内图实现代码就可以了，只要类的方法逻辑不是太复杂，不同的工程是实现出来的代码几乎是一样的，从而保证软件的规范统一。
　　实践中通常不需要把一个软件所有的类都画出来，把核心的有代表性的，有一定技术难度的内画出来，一般就可以了，除了在详细设计阶段画类图，在需求分析阶段，也可以将关键的领域模型对象图，用例图画出来，这个阶段，关注的是领域对象的识别及其关系，所以通常用简化的类图来描述。
　　序列图
　　
　　序列图描述类之间的关系，描述参与者自己的动态调用关系，每个参与者有一条垂直向下的生命线，用虚线表示，而参与者之间的消息，也从上到下表示其调用的前后顺序关系。
　　每个生命线都有个结果，只有在参与者活动的时候才是激活的，序列图通常用于描述对象之间的交互，这个对象可以是类对象，也可以是更大粒度的参与者，比如组件，比如服务器，比如子系统。总之，只要描述不同参与者之间的交互的，都可以使用序列图，也就是说，在软件设计的各个阶段，都可以画序列图。
　　组件图
　　
　　组件是更大粒度的设计元素，一个组件中通常包含多个类，组件图有时候和包的用途比较接近，组件可以描述逻辑上的组件，也可以描述物理上的组件，比如一个JAR，一个DLL的，因此组件图更灵活一点，实践中，用组件图而不是包图进行模块设计更常见一些。
　　组件图描述中间之间的静态关系，主要是依赖关系，如果想要描述组件之间的动态调用关系，可以使用组件序列图，以组建作为参与者，描述组件之间的消息调用关系，因为组件的力度比较粗，通常用于描述设计软件的模块及其之间的关系，需要在设计早期阶段就画出来。
　　部署图
　　
　　他是描述软件系统的最终部署情况，需要部署多少台服务器？关键组件都部署在哪些服务器上？部署图呈现的是系统最终物理呈现的蓝图。
　　因此，部署图是整个软件设计模型中比较宏观的一张图，在设计早期就需要画的一张模型图。根据部署，各方可以讨论是否对这个方案认可，只有对部署图达成共识，才能够继续后面的细节设计，部署图主要用在概要设计阶段。
　　用例图
　　
　　主要在需求分析阶段，通过反映用户和软件系统之间的交互，描述软件的功能需求，图中小人物被称为角色，角色可以是人，也可以是其他的系统，系统的功能可能会很复杂，所以一个用例图，可能只包含其中一小部分功能，这些功能被一个巨型框框起来，这个巨型框被称为用力的边界，框里的椭圆，表示一个一个的功能，功能之间可以调用依赖，也可以进行功能扩展，因为用例图中功能描述比较简单，通常还需要对用例图配以文字说明，形成需求文档。
　　状态图
　　
　　用来展示单个对象生命周期的状态变更，业务系统中，很多重要的领域对象对于比较复杂的状态变迁，比如账号，有创业状态，激活状态，冻结状态，欠费状态等等各种状态，因此，用户订单商品红包这些常见的领域模型，都有多种状态，这些状态的变迁描述，可以在用例图中用文字描述，随着角色的各种操作而改变，但是这种描述方式，状态散落在各处，做开发的时候容易搞错，就是产品经理自己在设计的时候，也容易搞错对象的状态变迁，状态图可以很好的解决这一问题。
　　一张状态图描述一个对象生命周期的各种状态及其变迁的关系。
　　活动图
　　
　　主要用来描述过程逻辑，业务流程。UML中没有流程图，很多时候人们用活动图代替流程图，活动图和早期流程图的图形元素也很接近.
　　实心圆代表流程开始，空心圆代表流程结束，圆角矩形表示活动，菱形表示分支判断，此外，引入了一个重要的概念，泳道。可以根据活动的范围，将活动根据领域，系统角色的，划分到不同的泳道中，使流程边界更加清晰明了。
　　总结
　　模型图本身并不复杂，几分钟的时间就可以学习一个模型图的画法。难的是如何在合适的场合下用正确的UML模型，表达自己的设计意图，从而形成一套完整的软件模型，进而组织起一个言之有物，层次分明，可以指导开发，在团队内部达成共识的设计文档。
　　我们从软件设计的不同阶段这一维度重新梳理一下，如何使用正确的模型进行软件建模。
　　需求分析
　　在需求分析阶段，主要是通过用例图描述系统的功能与使用场景；对于关键的业务流程，可以通过活动图描述。如果在需求阶段，就提出要和现有的某些子系统整合，可以通过时序图，描述新系统和原来的子系统的调用关系。
　　核心领域对象，可以通过简化的类图进行模型领域抽象，并描述核心领域对象之间的关系。
　　如果某些对象内部有复杂的状态变化，比如用户，订单这些，可以用状态图进行描述。
　　概要设计
　　在概要设计阶段，通过部署图，描述系统最终的物理蓝图，通过组件图以及组件时序图，设计软件主要模块及其关系，还可以通过组建活动图，描述组件之间的流程逻辑。
　　详细设计
　　在详细设计阶段，主要输出的就是类图和类的时序图，直到最终的代码开发，如果某个类方法内部，有比较复杂的逻辑，那么可以画方法的活动图进行描述，UML的工具可以是很复杂的，收费的，比如EA这样的大型软件工具。也可以使用processon在线的免费的工具。对于一般的开发者，建议从简单的用起，因为那个建模可以很复杂，也可以很简单，简单掌握类图，时序图，组件图，部署图，用例图，状态图，活动图。在7种模型图，灵活的在需求分析，概要设计详细设计阶段，根据场景的不同，绘制对应的模型图，可以实实在在的做好软件建模，搞好系统设计，作为一个掌控局面，引领技术团队的架构师。 查看全部

　　网站架构设计-通俗易懂的--网站设计网站
　　网站架构师的工作内容基本是抽象出整个项目的架构，比如整个项目的基础数据是什么，业务系统是如何被连接起来，这是系统设计的问题，而这些架构细节在网站各个子系统所需要做的工作基本都一样。那么架构师到底是做什么呢？我认为架构师是搭建整个系统的平台，跟业务系统的老板直接对接，包括其他线上系统的合作建设，整个用户的登录，认证等问题。
　　每个个体需要的都是配置文件，参数，修改等等。大家有兴趣可以看一下我的知乎专栏网站架构设计网站架构设计-通俗易懂的网站架构知识。
　　设计好，根据需求编写出可实现的内容，并高效的保证两个核心要素：结构的逻辑可复用，数据库的物理可连接。
　　真正的架构设计师一般一级项目会要求3年经验，二级项目会要求2年经验。很多高级技术总监都有2年经验，所以大约六七年经验可以，一般经验越多，思维会越细，当然见过还要加强理论学习，网站平台架构设计算比较理论的了，个人觉得底层需要掌握的是应用架构设计基础，面向对象设计原理和数据库设计，如果遇到实际项目就要了解项目业务需求，边边角角的要懂。个人见解，表达的不是很好。
　　之前遇到一个seo朋友的资深经理，不过他就是干网站架构设计出身的，还听说过一种说法，一个架构设计经理根本不需要真正的产品经理的情况下，根据网站的需求文档来划分服务器架构就可以了。 查看全部

　　牛逼，团队工作的神器开源了！
　　大家好，我是顶级架构师。
　　今天，推荐一个在线团队协作工具。我第一次使用就有点上头，爱不释手，必须要推荐给大家。
　　上次是谁要的在线团队协作工具啊，我帮你找到了。
　　这是我目前见过最好的在线团队协作工具。功能完整，代码结构清晰。值得推荐。 项目介绍
　　<p data-tool="mdnice编辑器" mp-original-font-size="16" mp-original-line-height="28" style="margin: 0px;padding: 1em 0px 8px;outline: 0px;max-width: 100%;box-sizing: border-box !important;word-wrap: break-word !important;clear: both;min-height: 1em;font-size: 16px;font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;letter-spacing: 0.544px;color: rgb(74, 74, 74);line-height: 28px;visibility: visible;">最近我在逛网站的时候发现一个不错的开源项目，我觉得不错，值得拿出来和大家分享下。
　　一款轻量级的在线团队协作工具，提供各类文档工具、在线思维导图、在线流程图、项目管理、任务分发，知识库管理等工具。扩展：接私活儿
　　简单和大家说下项目的技术选型：技术选型
　　后端框架：Laravel7 + LaravelS
　　前端框架：Vue 2.0 + Iview UI
　　通讯框架：Swoole
　　主题样式：Kooteam
　　第一点：待办四象限：突出事情优先级，帮助员工合理安排时间，提高工作效率，相信很多公司都可以用到。
　　
　　牛逼啊！接私活必备的 N 个开源项目！</p>
　　
　　第二点：在线流程图：在线流程图工具，使用十分方便
　　
　　第三点：在线思维导图：梳理思路，优化工作流程。另外，搜索公众号Linux就该这样学后台回复“猴子”，获取一份惊喜礼包。
　　
　　第四点：项目管理：自定义项目看板，可视化任务安排
　　
　　第五点：在线知识库：在线流程图，在线文档，以及可视化的目录编排，文档管理无忧
　　
　　最后，有需要学习这个项目的朋友，大家可以直接查阅开源项目地址：
　　团队神器，怎么领取？
　　<p mp-original-font-size="16" mp-original-line-height="26" style="margin: 1px 0px;padding: 8px 0px;outline: 0px;max-width: 100%;box-sizing: border-box !important;word-wrap: break-word !important;clear: both;min-height: 1em;letter-spacing: 0.544px;caret-color: rgb(0, 0, 0);color: rgb(0, 0, 0);font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 16px;text-align: center;line-height: 26px;word-break: normal !important;">神器获取
　　
　　牛逼啊！接私活必备的 N 个开源项目！</p>
　　扫码下方二维码，后台回复【团队】即可获取所有神器
　　
　　欢迎有需要的同学试试，如果本文对您有帮助，也请帮忙点个赞 + 在看啦！❤️
　　<p data-tool="mdnice编辑器" mp-original-font-size="16" mp-original-line-height="28" style="margin: 0px;padding: 1em 0px 8px;outline: 0px;max-width: 100%;box-sizing: border-box !important;word-wrap: break-word !important;clear: both;min-height: 1em;font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, "PingFang SC", Cambria, Cochin, Georgia, Times, "Times New Roman", serif;font-size: 16px;letter-spacing: 0.544px;color: rgb(74, 74, 74);line-height: 28px;">在 GitHub猿 还有更多优质项目系统学习资源，欢迎分享给其他同学吧！</p>
　　欢迎大家进行观点的探讨和碰撞，各抒己见。如果你有疑问，也可以找我沟通和交流。
　　最后给读者整理了一份BAT大厂面试真题，需要的可扫码回复“面试题”即可获取。
　　
　　
　　公众号后台回复架构或者架构整洁有惊喜礼包！顶级架构师交流群
　　「顶级架构师」建立了读者架构师交流群，大家可以添加小编微信进行加群。欢迎有想法、乐于分享的朋友们一起交流学习。
　　
　　扫描添加好友邀你进架构师群，加我时注明【姓名+公司+职位】 查看全部

　　generaladj：网站架构设计和网站设计原则一样的？
　　网站架构师的工作内容并不大，主要是负责整个网站的架构，在网站架构完成之后，还需要对网站的性能，访问效率等等进行一些调优，保证网站运营能正常运行，避免出现性能异常。
　　不论是前端架构师还是后端架构师，基本就是负责搭建前端或后端的用户体验，组织跟进前端后端开发进度等工作。
　　就是负责公司某一业务系统的架构和设计
　　一般是用户体验设计师这样的角色，负责把产品规划分解到一个一个小的功能。好多外企常用这个来区分产品设计师和用户体验设计师。
　　generaladj：全方位的，覆盖方方面面的predominance：一个团队只负责某一个方面，如最常见的pm（projectmanager），一个项目中常常会包含产品经理、项目经理等多个职位。一般的，这样的团队会有一个director，即pm总监。相对应的在线对等的是产品经理（productmanager）,产品经理（productmanager）是产品发展的执行者，在产品规划、产品设计及执行过程中，负责对产品的功能与形态进行产品规划与设计、对用户体验进行反馈与修正、对市场行情进行分析。高级版本的产品经理还包括项目经理，但是，至少从职位来说，产品经理并不属于产品总监。
　　网站架构师，是网站架构工程师通过构思、设计网站的整体布局及完善网站的功能，做出合理规划来完成网站，还要保证网站是用户使用的可用性和安全性等。通过网站架构设计工程师完成网站架构设计。网站架构设计和网站设计原则一样，都是以人为出发点。一切不以用户的活动为依据的设计，都是耍流氓。说白了就是卖自己公司的产品，不管你卖得是不是好，反正是你公司的！。 查看全部

　　架构师职业加点攻略
　　不同的过程在原理上是相通的，如果你目前只是一个程序员，那么经过无数的经验值的提升，最终都会实现蜕变，成为一名架构师。从小白玩家到最后的架构师的成长之中，漫长而又艰辛，如何将自己有限的精力投入在职业技能的加点分布上呢？
　　技能一：写得一手好代码
　　这一点毋庸置疑，如果不是写过N年代码的优秀程序员，一定不是好的架构师。“架构师”这是一个听上去比较虚的职位，它的主要价值在于“落地”的过程中，而不是“指点江山”。eBay的架构师总结架构师在项目中的职责：
　　1）产品团队要做一个产品，架构师要帮助团队把技术可行性，技术方案权衡取舍一一剖析清楚；
　　2）技术方案权衡取舍出来了，架构师要设计整体的技术实现步骤，这个过程一定是和团队其他成员一起完成的，常见的实践是，1到2个核心成员出一个初稿，然后大家讨论完善；
　　3）技术实现步骤出来了，架构师要和开发团队一起，进行编码，可能架构师不一定细究到任何细节，常见的实践是，系统最困难最核心最关键的部分往往由架构师亲自操刀；
　　4）系统初版实现了，架构师要和开发团队、测试团队、运维团队一起，完成各类测试，协助解决最困难的bug，和团队一同完成线上部署、并一同排除上线初期系统的故障；
　　在项目的过程中，架构师至少一半以上的时间是和开发团队一起进行的，好的架构师不能将实施细节抛之脑后，更直白一些，他要通过撰写代码的方式来指导团队其他成员理解和实现架构中的细节。
　　反面的例子是，项目失败后，架构师反馈“团队的技术能力不够”，团队反馈“这是一个一行代码也不会写的大忽悠”。
　　技能二：抽象思维能力
　　“逻辑思维，抽象思维”比“编码的时间”对架构师而言更为重要，如果你不能让某个非IT人员明白某个概念在说什么，这个架构师注定也是失败的（沟通能力非常重要，详见第六点）。
　　逻辑思维不用展开多说，程序员的代码都是逻辑，如果XXX就YYY，如果AAA就BBB，缺乏良好的逻辑思维能力基本不可能成为好的架构师，甚至好的程序员。
　　抽象思维又分两点，一个是将实在的事物概念化，一个是将模糊的感觉数量化。一个苹果，抽象为质量、大小、颜色、形状、味道等，这是概念化，是架构师的必备思维。至于质量、大小、颜色、形状、味道如何转变成数字来描述，这也是架构师必备的思维。
　　有了上述两点，架构师能将一个“虚”的架构概念描述清楚。
　　技能三：技术前瞻性
　　架构师与技术高手的区别在于，架构师不仅局限于如何调用、如何并发等架构细节（技术高手对这些也非常熟练），还跳出三界，考虑未来问题和潜在风险的应对之道。
　　要培养自己的技术前瞻性，首要是学好英语（不多解释了，希望未来最先进的技术都首先从国内诞生），看懂外文技术文章，能与业界专家沟通交流，学习别人的实践方案。
　　反面的例子是，成天将技术前言的名词挂在嘴边，大谈“云计算，SaaS”这些东西，天天吹水，而落不了地（有可能他自己也搞不清概念如何落地）。
　　技术前瞻性还提现在对新技术的选型上，哪些东西适合自己团队，哪些不适合。学习成本、维护成本、硬件成本、潜在风险等等都是架构师需要考虑的。
　　技能四：分析能力
　　看到问题的本质，是架构师必须具备的素质。
　　架构师要有将“业务需求”转化为“技术需求”的能力，这是一个本质的挖掘。例如，业务层面看到的是一个“电子商务网站系统”，架构师看到的是一个多人在线，并发交易，需要保证数据一致性的站点、服务、数据系统，功能、性能、扩展性、维护性、安全性、可用性这些字眼会惯性的蹦到架构师的脑子里。
　　架构师之所以是架构师，他在庞大系统的面前，仍然能够敏锐发现其底层之真实，这就需要，他有多年多领域知识和经验的沉淀。
　　技能五：全面的知识库
　　架构师作为一名技术领袖，需要通过散发知识的光芒来温暖开发团队，如果只一个领域内的知识烂熟于胸，那也仅仅是一名技术高手。要想更进一步，需要对APP层面、服务层面、数据层面均要了解（系统分层），要对研发、测试、运维、安全也要有所了解（职能），上要对接口，下要对原理（接口与实现）都有所了解，甚至，要在多个业务领域都有所涉猎。
　　初级架构师所害怕的，是跳出自己的“独门绝技”，在一定程度上说，在一定深度之内成为一个“杂家”也没什么不好。
　　技能六：沟通能力
　　架构师和项目经理，对沟通能力的要求都很高，很多互联网公司甚至直接由架构师担任项目经理的角色。这两个角色其实还是有所偏重的，项目经理更倾向于与客户的交流，跨团队的协作与交流，架构师主要偏向技术团队内部的沟通与交流，纯技术上的沟通。
　　如何成为一名“善于沟通”的架构师呢？在目标清晰的前提下，首先做到平和，不能将自己所在象牙塔上，颐指气使的发号施令，这样的态度必然遭恨，大家都是技术人员，只是分工不同，为何要受你的气呢？其次，架构师要有一定的绘图能力。人对图形的理解远大于对文字的理解，一个层次图，一块小白板，几只笔，真的这么容易把问题描述清楚么？
　　技能七：对工具的运用能力
　　架构师作为初创团队的核心成员，要有一种对于各种工具特别熟悉的能力。由于开发工具的多样性和复杂性，针对不同的开发任务的特点和特性，采用不同的开发工具，是架构师的工作内容中必不可少的一环。
　　架构师要紧跟技术潮流，了解技术的发展和趋势，利用新技术、新方法来提升团队的生产力，将技术转化为收益。虽然从技术的层面上说，很多解决方案放之四海而皆准。但是，从提高开发生产率角度来说，善用第三方的开发工具对架构师来讲非常重要。国内有很多这样的开发者工具，七牛便是其中之一。在架构师的团队里，七牛所起到的作用是帮助开发者解决数据管理的一站式难题，像数据托管、数据分发以及数据处理等。此外，还有面向开发者的云端软件协作开发平台Coding以及帮助开发者快速实现移动应用的开发、测试、发布、管理和运营的APICloud等等。
　　一个好的开发工具，能让开发效率事半功倍。
　　注：本文转载自《互联网架构师必备技能》，小编略有编辑。 查看全部

　　.NET云原生架构师训练营讲什么，怎么讲，讲多久
　　
　　-------请观众看视频介绍 --------
　　---------以下是文字版内容 ---------
　　大家好，我是刘腾飞。前一段时间，我通过朋友圈的一篇文章这样的一种方式启动了我的.net云原生架构师训练营。
　　到现在为止，已经有这个超过15位的同学已经加入了，那么在这些同学当中呢，他们有的是直接就报名加入，有的也有着一些疑问，在经过问答之后报名加入。
　　那么我相信还有很一些同学，对这个训练营是有兴趣的，可能内心也是存在着一些疑问。所以我就通过一个视频，这样的方式来给大家解答一下。主要回答以下四个问题
　　为什么要开这样的训练营？
　　这个事情得从我之前已经给大家分享过的三个系列视频来说起，因为最近5年我一直担任管理者角色，我们会做很多的招聘。所以对企业的这个用人需求非常的了解。我前面一段时间自己创业，也更加深刻的体会到了企业对人才的需求和重要性。
　　
　　所以这三个视频呢，其实是从这个基础篇到实战篇，再到一个高可用运维篇这样的三个系列。它是体系化的，也是偏实际应用的，这样对企业来讲更有用。
　　
　　我们在基础篇，主要是给大家做了一些 core核心模块的加深，包括像这个管道、认证，然后还有配置依赖注入这样的一些核心模块。也提供了一些示例实践。
　　在分布式项目实战系列中，是一个完事的 core微服务项目的实践。我们从介绍了docker、gitlabci、identitysever4、ddd和CQRS、网关ocelot、服务注册 与发现等等。也给大家提供了一个完整的示例。
　　在运维篇中主要是对K8S做了一个全面的剖析和应用，只有将K8S利用起来，才能在最低成本内发挥微服务的优势 。
　　
　　注重实际效果落地
　　然后我们发现，结果也仍然只有10%的人完成了全部的学习，有超过60%的同学只完成了一半。那些全部完成的同学已经开始在企业中自己开始应用微服务。本着 “要让大家实实在在学到真本事” 的理念，我也在思考如何进行改进，让更多的人能够实实在在地、系统性地掌握我想给大家传播的一些知识和技能（同是也是当前企业非常需要的）
　　包括像之前群里的一些同学，有的都报了某客时间上的很多的课程，包括了这像这个算法训练营啊，前端训练营啊，架构师训练营等等。但还是说这个最终的效果不是很好，那么我总结下来觉得是大部分线上的一些课程是理论讲的多，实践做的少。
　　另外一个是自己做作业比较多，但是辅导比较少。
　　这样的一个情况就导致大家看完这些东西之后呢，好像是明白了，但是自己要是用起来呢，可能又感觉完全又用不起来。或者说串不起来。
　　实实在在学到真本事
　　所以我想通过重新打造一个这样的训练营课程，目标只有一个。让你学完之后，可以在企业内独立承担需求分析、软件设计和架构方面的工作，以及能够推动整个项目或者产品的落地 。
　　训练营包括哪些内容？
　　要达到上述目标是一件很难的事情，我自己前前后后可以说是花了近十年的时间。中间走过不少的弯路。
　　就大部分的技术其实都是我都是自学的。那花的时间很多，自学是每个人都应该拥有的能力并且很重要，但是呢，再通过适当的这个老师的帮助下呢，其实是可以大大加快这个过程。能够用适当的钱换回自己的时间还是很划算的一件事情。
　　另外一个呢，就是前人的经验很重要。我个人说的好听点的，是有自己的想法喜欢自己拿主意。说的不好听，一点的就是不太愿意去听别人的这个意见。更不用说主动去请教别人，对于我来讲，自己花一天时间来解决，或者是找人来咨询一下，一个小时之内解决这两种方式，我可能会选择前面那一种。但其实没有必要哈，人生苦短，不要为难自己适当的听取别人的意见和咨询有相似经验的人，对自己来讲是一件快速少走弯路的一件事情。
　　山外有山，人外有人。我最早在2014年左右呢，在博客园上写了一些比较受欢迎的关于.net的一些文章，自认为在.NET这个领域做开发上来讲，还是有一点点小小的成就但那个时候呢，我还没有一些分布式非常大型的，这样的一些场景的实践和应用。身边也缺少这样的环境，所以我也没有再去主动的去探索和深入的研究。直到两年后加入到另外一家互联网公司，才开始进入这个领域。所以对我来讲，这两年是浪费的。
　　我们可能在某些领域有着一定的这个成就，但是但是别忘了一直要不断的保持向更高范围更大的的领域继续去了解深入，这样才能保持我们永远的一个非常有竞争力的一个状态。
　　所以我给自己的这个训练营总结起来有3个特点，都是从坑里趟出来的。
　　架构师的分类
　　从架构师的工作内容上来划分可以分为三类：
　　系统架构师
　　从系统的维度，负责整体系统的架构设计，主要是基础服务和各系统间协调上，着眼全局不太注重某个应用本身架构，比如关注服务器负载，可靠性，伸缩，扩展，数据库切分，缓存应用等方面的基础架构设计。
　　应用架构师
　　从应用程序的维度，负责某个应用的技术架构，主要偏业务系统，关注理解业务，梳理模型，设计模式，接口，数据交互等方面。
　　业务架构师
　　从业务流程的维度，关注某一个行业、业务的领域分析，获取领域模型，最终获得系统的模型。也可以叫业务领域专家、行业专家、产品咨询师、资深顾问。
　　基础架构、前端架构、后端架构是从职责上的分类。
　　系统架构+应用架构
　　通常我们说的架构师是系统架构师和应用架构师的结合，也是我们训练营的关注点。
　　
　　当然，上3层靠个人修养，我们会补充一些关于商业与产品的基本知识，提供给大家团队作战的练习场。重点关注在技术能力层，也是架构师的根基所在 。
　　模块
　　大概内容
　　包含实践
　　架构师与云原生
　　商业与产品
　　架构师职责
　　架构师基础能力
　　云原生、云原生应用、云原生架构是什么？
　　真实产品的案例分析
　　该产品的云原生实现方案
　　基础巩固
　　配置
　　日志
　　依赖注入
　　中间件管道
　　终结点
　　路由
　　认证
　　MVC
　　授权
　　EF Core
　　Identity Server
　　Mongo/RabbitMQ in C#
　　每个技术点的深入练习
　　框架设计与实现
　　面向对象分析与设计
　　设计原则与模式
　　单元测试
　　ASP.NET Core框架源码解析
　　ABP框架的源码解析与应用
　　23种设计模式的代码实现餐厅案例
　　为代码实现添加单元测试
　　实现框架（统一认证授权中心、多租户系统 )
　　开放平台OpenAPI 实现
　　持续交付2.0
　　Scrum &精益产品开发徭in
　　CI与自动化
　　DevOps& 持续交付
　　分组进行产品流程开发管理
　　Git Flow CI流水线搭建
　　单体架构
　　DDD/CQRS/与模块化
　　MySQL/Redis/MongoDB/
　　EventBus-Local
　　配置管理
　　日志
　　监控告警
　　产品模块化/服务开发
　　单体系统的运维
　　分布式架构
　　大型网站应用/分布式理论
　　MySQL/Redis/MongoDB/ElasticSearch/ 高可用集群
　　将产品模块改造为微服务
　　运维
　　微服务高可用架构及运维
　　Kubernetes云原生
　　将产品以微服务分布式的方式部署运维
　　上课形式是什么样的？
　　在上面的课程内容中，大家已经看到，每一个模块都包含大量的练习。我相信只有通过大量的练习大才可以在短时间内突破对新技术、新知识的加深理解 ，从了解到掌握，从知道到会用。
　　
　　我们通过被动学习与主动学习多种方式结合来最大化转化学习效果。
　　被动
　　视频讲解
　　所有的知识模块都会先通过理论讲解的方式来进行，同时配套分模块的练习环节
　　鼓励大家在这里多思考 ，多提问。
　　主动+被动
　　实习
　　对视频讲解理论点的作业进行练习
　　老师会对作业中遇到的问题进行答疑和辅助
　　主动+被动
　　小组讨论
　　在一些需求分析和软件设计的部份，通过引导大家自行进行设计
　　并以小组形式进行竞演，老师评点再进行改进的方式进行。
　　被动
　　直播编码
　　有一些项目实战的内容是通过直播写代码的方式来进行的，需要大家先看，看完自己再结合主动练习自己进行实现
　　主动+被 动
　　项目实践
　　结合对需求的分析，和自己完成的设计来实现编码 。
　　老师会对作业中遇到的问题进行答疑和辅助
　　主动
　　教导他人
　　每个小组内会有能力比较强的同学，可以尝试从帮助他人的方式中进行步巩固自己的能力，以及培养自己技术领导力的感觉。
　　注：所有的直播都会有录播，可以自行进行复习和重看 。
　　时间规划
　　启动时间：人数满40人之后即刻开班。
　　上课时间：
　　双休日
　　2小时，小时
　　分成两段，一段2小时，一段3小时。
　　前期主要以理论讲解+作业Demo为主
　　后期以项目编码实践等
　　重要的内容放在周未
　　工作日
　　主要是以跟进大家的作业练习，解决大家作业中出现的一些常见问题，结合大家对于理论知识和练习的理解程度进一步加深巩固。
　　截止时间：
　　这个训练营暂时没有明确的截止时间，预计大致的时间是半年到一年。重点是团队最后整体把项目开发完成。中间如果有遇到一些知识点普通吸收的比较慢，会拆开再进行加深讲解。
　　有意请联系小编微信geffzhang，我为你牵线腾飞。 查看全部

　　一位10年Java工作经验的架构师聊Java和工作经验
　　从事近十年的 JavaEE 应用开发工作，现任阿里巴巴公司系统架构师。对分布式服务架构与大数据技术有深入研究，具有丰富的 B/S 架构开发经验与项目实战经验，擅长敏捷开发模式。国内开源软件推动者之一，Smart Framework 开源框架创始人。热爱技术交流，乐于分享自己的工作经验。著有《架构探险——从零开始写Java Web框架》一书。
　　我的十年技术之路
　　和大家介绍下我目前所从事的工作。
　　我目前从事分布式服务架构的设计与开发工作，在阿里的大数据平台上进行应用程序开发。我们整个系统架构采用了“前后端分离”的思想，前端关注数据展现，后端关注数据生产，通过 REST服务将前后端整合起来，所有的应用都是无状态的，可以做到水平扩展。我们将整个系统拆分成许多“微服务”，服务之间通过统一的接口来调用，每个服务是通过容器技术进行隔离，此外服务可发布到统一的服务管理平台上，可通过该平台监控每个服务的运行状态与生命周期事件，并为服务调用者提供了服务发现的能力，可对服务进行平滑升级。
　　阿里有许多优秀的中间件与基础服务，可以快速帮助我们搭建应用系统，而且这些技术在阿里内部全是开源的，大家可以通过源码和文档学习到很多有价值的经验。阿里也提供了浓厚的技术氛围，每位同学都非常专注于自己的工作领域，大家对工作一丝不苟，相互配合，方向一致。
　　我是如何走上技术这条路的？
　　2006 年大学毕业，我离开了母校武汉理工大学，在院长薛胜军老师的推荐下，我来到了上海，这个对于我来说非常陌生的地方。我有幸加入了一家名为“动量软件”的创业公司，这家公司的老板曾经是亚信科技的 CTO，他也是普元软件的创始人兼 CTO，他的名字叫黄柳青，他也是薛老师的大学同学。于是就这样，我的老板成为了我的老师，我习惯叫他黄老师，包括公司其他资深的同事也成为了我的老师，因为我很想他们身上学到更多有价值的东西。
　　刚开始工作的时候我学习了什么是云计算？什么是 SaaS、PaaS、IaaS？我们花了三年时间开发了一款名为 ODE 的 PaaS 平台，让用户可以在该平台上量身定制自己的软件，最终为客户提供基于 SaaS 的产品。确实很骄傲，那时我们已经在做云了，只是没想到后来云会在中国得到这么好的市场，可能当时只有黄老师一个人想到了吧。
　　在 2008 年，我为公司拿回了“第一桶金”，这也是我从程序员转向项目经理的里程碑。当时我带领团队远赴深圳，为国信证券公司开发经纪人管理系统，这个项目对于我个人而言却是一笔至高无上的财富，我开始学习如何与人打交道，如何做需求分析，如何将需求转变为技术，如何带领团队小伙伴一起工作。学到了太多太多，但我依然选择在我工作第四个年头里离开了动量软件，我刚加入动量软件的时候，公司只有 5 个人（包括老板和前台），当我离开动量软件的时候，公司已经有 200 人左右了。感谢黄老师！我在他身上学到了很多，他的思想和态度直到今天都还在影响着我。
　　我的第二份工作还是选择了我最熟悉的证券金融行业，同样也是一家创业型公司，在这家公司里我担任了技术经理，管理了整个技术团队，从项目的售前到售后，我都亲自带领团队来完成。虽然在这家公司我只做了两年，但在这短短的时间里，我学会了如何提高开发效率、如何培养技术团队、如何选拔技术人才、如何建立企业文化。但最后我发现了一个问题，越是想做好，越是很难做好，为了做成一件事情需要做很多的尝试，做事情缺乏正确并有效的方法。
　　回想我工作的前六年时间里，我一直都是在创业公司里成长，虽然可以快速学到东西，但似乎很难学到更加规范的做事方法。于是我选择了新的工作机会，来到了 TCL 通讯，这是一家相当大的公司，公司的研发管理流程来源于法国阿里卡特公司。我在公司担任 Java 架构师职位，也算是整个 Java 团队的技术负责人，虽然团队并不是特别地大。我在这家公司做了三年，学到了如何整合现有资源、如何按标准流程去做事、如何设计系统架构、如何进行异地工作、如何跨团队工作、如何用英文来沟通。说实话，当时我没有任何的工作压力，可以按时上下班，从来都不会加班。虽然自己空闲的时间很多，但我并没有选择去浪费时间，而是开始写点技术博客，也正是因为这些技术文章，才改变了我后续的职业发展道路。
　　我清楚的记得，那是在 2013 年 9 月 1 日，我在开源中国网站发表了我人生的第一篇博文，这篇文章影响了我后续两年。其实说句心里话，当我第一次写这篇文章时，我心里是没底的，这个框架只是根据自己的理解做出来的一个设想，当时甚至连一行代码都没写过。我的想法是先将这个思想发表出来，让大家讨论起来，我会做一个决策，然后再亲自做具体实现，最后我会将实现过程通过博文的方式展现给大家，后续大家会对我的实现进行点评，我会基于大家的建议进行改善。整个开源过程正好与敏捷的思想是一致的，有效沟通、小步快跑、拥抱变化、不断改进。
　　也许就是我的技术文章吸引了很多广大读者，这里面不排除想邀请我加入的其它公司。我在 2014 年离开了 TCL 通讯，加入了易传媒。为什么我要放弃如此舒适的工作环境，去加入一家还在不断拼搏的企业呢？其实我看到的是未来互联网的发展趋势，广告程序化交易以及广告与大数据的结合，未来最值钱的一定是数据。抱着这样的信心，我加入了易传媒，担任系统架构师职位。当时易传媒正处于技术转型的初期，需要将 .Net 全部迁移到 Java，这件事情对于我而言是非常有挑战的。我的做法是：第一步定义开发规范与流程，第二步培养核心技术人员，第三步分阶段进行改造。仅半年时间，我们所有的产品成功地迁移到了 Java 平台，结果出乎大家的想象。公司市场也非常不错，产品得到了业界的认可，订单数源源不断，大家每天都很忙碌，但却很开心。而易传媒的“易家人”企业文化，让我所感动，不管是核心技术部门还是其它支持性部门，大家就像一家人一样，你的事情就是我的事情。
　　直到 2015 年初，阿里巴巴与易传媒建立了合作关系，两家公司进行了深度合作，易传媒公司与阿里妈妈事业部进行了整合，新阿里妈妈从此诞生了，于是我也成为了阿里巴巴的一员，目前负责阿里妈妈大数据品牌营销产品的系统架构工作。就在两家公司整合的过程中，我完成了人生中的处女作《架构探险 —— 从零开始写 Java Web 框架》这本书，目前该书正在各大网上书店售卖，我真心希望这本书能对一些想成为架构师的程序员们有所帮助，由于我个人水平有限，又是第一次写书，写得不好的地方还请大家多多包涵。
　　上面提到，写博客给我带来的收获颇多，那么我来分享下技术人如何写博客，又应该以怎样的态度对待。
　　我认为技术人员写博客需要注意以下几点：
　　思路要清晰，文章要有明确的大纲与标题。
　　对于实战类型的文章，需要分步骤来描述。
　　多用短句，少用长句，能一句话说明白，就不用两句话。
　　对于不太好理解的内容，最好能打比方来说明。
　　文章末尾需要有总结，用最精辟的语言归纳出这篇文章的主要内容。
　　写博客首先是对自己所学知识的一个总结，此外，也为其他读者提供了很好的教程，知识得到了广播与传递。
　　技术一条不归路，选择了这条路从未有过放弃的想法。
　　做了十年的技术，我从来都没有放弃过它，相反，我非常热爱它，因为我一直以来都很喜欢学习，希望能学到更多的东西，这样遇到了具体的技术问题，可以随时从自己积累的知识库中找到最佳的解决方案。此外，目前我在公司虽然不怎么写代码了，但我还是会利用自己工作闲暇之余写一点开源项目或者代码框架等。
　　工作过很多大大小小的公司，那么公司最值钱的东西是什么呢？
　　我认为是实实在在做事情的程序员们。
　　他们虽然工资不高，每天坐在位置上敲着代码，在很多人眼中被称为“屌丝”或“宅男”，但我认为恰恰就是这些人，他们才是公司最有价值的人。
　　由此看来，对程序员的重视是相当有必要的，我们需要关心每一位程序员的职业发展，让他们在团队里能够充分地发挥出自己的能力。
　　我们也需要对他们倍加关注，挖掘出有能力、肯吃苦、敢担当的人，给他们更多的机会，让他们成为技术领袖。
　　互联网技术公司需要大量这样的程序员：
　　具体说说程序员需要具备哪些素质。
　　我个人是这样理解真正的程序员的：
　　深爱技术，一天不写代码手就会痒，就喜欢那种成就感；
　　为了一个问题可以废寝忘食，有时会在梦中都能写代码；
　　代码洁癖症患者，喜欢优雅代码，写代码就像写诗一样；
　　善于分析问题，能快速看清问题的本质，并动手解决它；
　　喜欢研究优秀源码，学习大师的杰作，善于归纳与总结；
　　有自己的开源项目或技术博客，喜欢学习，更喜欢分享；
　　会关注技术圈子的新闻动态，时常会参加线下技术沙龙；
　　知道软件开发不是一个人在战斗，更需要的是团队协作；
　　保持良好健康的心态，用一颗积极向上的心去拥抱变化。
　　十年的职场之路坚持不易，分享下我的「IT 职场」经验。
　　时光飞逝，我事业中第一个十年已然结束了。在这十年里，让我收获了很多，跟大家分享一下我在 IT 职场方面的一些个人经验，不一定对每个人都实用，请大家仅作参考吧。
　　大家既然都是做技术的，那我们不妨先从技术这个话题开始说起吧。我要与大家分享的第一点经验就是：
　　1. 把技术当成工具
　　技术这东西，其实一点都不神秘，它只不过是一个工具，用这个工具可以帮助我们解决实际问题，就这么简单。
　　我们每天在面对技术，市面上也有很多技术，真的没有必要把这些技术都拿过来学习一遍，然后想办法找个场景去应用它。如果真的这样做了，那么只能说明技术不是工具，而是玩具，技术不是这样玩的。
　　我们应该从另一个角度来看待技术，不妨从自己的实际工作环境出发，现在需要什么，我们就学什么，而不要漫无目的的追求一些新技术。当然，对于新技术还是需要有所关注的，至少需要知道这个新技术是干什么用的，而且还要善于总结，将有价值的技术收集起来，以备将来使用，当需要使用的时候再来深入研究。
　　人的精力是有限的，人的生命也是短暂的，要善于利用自己的时间，合理地学习技术。
　　不要把技术看得那么重要，别把它当回事儿，把它当工具就行了，它就像我们写字的笔一样，用铅笔能写字，用钢笔一样能写字。
　　作为一名技术人员，除了学习与应用技术以外，还需要为自己做一个正确的职业规划，清晰认识自己究竟属于哪种技术人才，是技术专家类型的，还是技术管理类型的。路到底该怎么走？需要自己做出决定。
　　在我们职业路线上，最重要的人莫过于老板（我指的老板可以是公司大老板，也可以是自己的顶头上司），对待自己的老板，我也有一些经验：
　　2. 把老板当成情人
　　大家应该非常清楚，情人是需要浪漫的，浪漫是需要惊喜的。老板其实跟情人一样，也是需要惊喜的。我们做下属的，要懂得找到合适的机会给老板带来惊喜。我们跟情人谈情说爱，这是一种很好的沟通方式，可别忽略了跟老板“谈情说爱”，我们需要与老板保持良好的沟通，这种沟通并不仅仅是溜须拍马。
　　讲一个真实的故事吧。记得曾经我的一位同事，技术非常好，做东西非常快，质量也很高，同事们都觉得他是牛人，但他从来都不懂得在老板面前表现自己，老板也只是觉得他是可以做事的，但升职加薪的事情往往总是不会优先考虑他。
　　大家很定会问：怎样在老板面前表现自己呢？其实方法有很多，由于篇幅有限，我先提供三招吧：
　　对待老板其实很简单，只要能帮他做事，又能让他开心，他基本上就搞定了。老板搞定了，自己的职业发展才会平步青云。但千万别忽略了还有一群人，他们或许是自己的团队战友，或许是自己的竞争对手，没错！他们就是同事。如何处理同事关系呢？以下便是我的经验：
　　3. 把同事当成小孩
　　处理与同事关系，其实比处理与老板关系要稍微复杂一点，因为同事有多种身份，他们可以是队友，也可以是对手。如果大家在一起做同一个项目，那么这样的同事就是队友；如果为了竞争某个项目、岗位、资源，导致同级别的同事之间发生利益上的竞争，那么这样的同事就是对手。
　　对于队友而言，要学会主动给他们提供帮助，让大家能够体会到团队协作的气氛，在一起学习，在一起成长，在一起分享。可以时常跟大家一起聚餐，买点零食让大家品尝。
　　队友关系往往比较好处理，关键在于自己能否真正懂得去分享。很多技术人员，最不愿意的就是分享，因为担心自己花了很多精力学到的知识，分分钟就被别人学会了，自己失去了优势。这种心态最好不要在团队里产生，这样只会让自己变得越来越封闭，越来越渺小，队友们也会逐渐排挤自己。
　　对于对手而言，要想办法让自己成为他的兄弟，告诉他，咱们是兄弟，应该相互帮助。如果有机会，可以在老板面前，当着对手的面，夸奖自己的对手。做出这样的行为，其实并不会让老板觉得自己不如对手，而会让老板认为自己在用心去容纳对手。大家在一起工作，就是一种缘分，都是跟老板打工的，真的没有必要搞得不愉快。
　　其实同事就是自己的小伙伴，不妨把他们当成是单纯可爱的小孩吧，用自己的心去“收买”他们。
　　老板与同事，他们都是公司内部的人，不管怎么说，大家都在同一条船上，大家可以关上门吵一架，只要事情能够解决就行。但对于我们的客户而言，就需要用另外一种方法来处理好关系了。我是这样认为的：
　　4. 把客户当成病人
　　客户有需求，但没有技术，而我们有技术、有经验、有产品，正好可以帮助他们实现需求，从而提高他们的工作效率，这样客户才会心甘情愿地把钱放入我们的口袋。所以，在客户面前，我们要表现出高超的专业精神，不要被客户牵着我们的鼻子走，我们在客户面前就是技术权威，就需要这样的自信。从服装、言行、邮件、文档等各个方面，都要做到专业。
　　我们打算把自己的产品卖给客户的时候，千万不要一上来就对自己的产品夸夸其谈，这往往会让客户感到厌烦。我们不妨先告诉客户，他们已经“生病”了，而且病得不轻，如果不及时用药的话，后果将不堪设想。也就是说，要让客户意识到自己现在所面临的困境，让客户紧张，当他们正在思考如何应对的时候，我们再告诉他们，“药”已经准备好了，可以随时服用。
　　要让客户有种雪中送炭的感觉，这样就对了，他们一定会主动了解我们的产品。我们要做到这一切，必须花精力来分析行业现状，揣测客户老板们每天在想什么。如果有机会进入客户所在的公司工作一段时间，相信自己的感受会更加深入。
　　Java 会在很长的一段时间内是主流
　　为什么开发Java Web都要用框架？
　　我个人觉得框架有以下几点作用：
　　让开发更加高效，屏蔽底层技术细节，让开发人员关注在具体业务上。
　　框架实际上也是一种规范，可以让每位开发人员保持同样的编码风格。
　　会使用主流框架的开发人员，在人才市场上比较好获取。
　　现在做Java Web开发都用哪些框架呢？
　　常用的比如Spring MVC、Struts2 等，国内的 JFinal、Nutz 等也不错，当然Smart 也是一个很好的选择。
　　有一定Web前端开发经验的人，很多都会有这么个想法：那些写框架的人好厉害，什么时候我才能写一个自己的框架呢？有时候看看别人的框架代码，又觉得很复杂，对此我有一些建议以及新人学习需要什么基础？分享一些好的方法。
　　对于接触 Java 不太久的朋友，建议按照以下几个步骤来学习：
　　学习 Java 基础语法与核心技术，包括 Servlet、JSP、JDBC 等。
　　熟练使用流行开源框架，包括Spring、MyBatis 等。
　　研究开源框架源码，并吸取其中优秀的架构。
　　此外，在学习的过程当中，建议做学习笔记，最好能通过博客的方式来记录自己的收获。
　　使用 Python、Perl、PHP、Ruby 等脚本语言开发 Web 程序，跟使用 Java 开发 Web 程序相比有什么不同或者优劣？
　　前者属于动态语言，无需编译，可通过解释的方式来运行，而且 Java 需要首先通过编译，将源文件转为字节码，且载入 Java 虚拟机才能运行，相对来说，Java 对环境的要求较高，但 Java 具备更强的面向对象能力。此外，Java 还拥有较广的开源社区以及流行的开源中间件。因此，如果是做大型系统，建议使用 Java 来开发，而并非那些脚本语言。
　　针对 Web，Java、PHP、Python、.NET 之中未来发展前景最好的会是什么？
　　我认为 Java 在未来还会有一段很长的路，需要在语言本身上做到更加轻量级，用最少的代码来实现目标功能；PHP 相对来说会比较平稳，它的特点非常突出，上手快且易于开发 Web 项目；Python仍然不会有太大的用户群体；.NET 加入开源社区太晚，且较 Java 而言并没有太强的优势，可能会走下坡路。
　　在软件开发中有很多的设计模式，也有一些很高冷，谈谈我对软件设计的理解，以及让一些设计原则接地气。
　　了解设计模式的朋友们，想必都听说过“六大设计原则”吧。其实最经典的 23 种设计模式中或多或少地都在使用这些设计原则，也就是说，设计模式是站在设计原则的基础之上的。所以在学习设计模式之前，很有必要对这些设计原则先做一下了解。
　　GoF（四人帮），传说中的四位大神们，他们联手搞出了一套设计模式，堪称 OOD（面向对象设计）的经典之作！震惊了整个软件开发领域。但这四个老家伙非常怪异，总是喜欢显摆一些高深的理论，甚至有时候不说人话，十分让人费解。
　　除了最经典的六大设计原则以外，还有一些其他的设计原则也非常重要。我将尽可能地解释这些晦涩的理论，希望看完之后，会让您对这些设计原则稍微加深一些理解。若有不正确的地方，恳请大家指正！
　　先看一幅图吧：
　　
　　这幅图清晰地表达了六大设计原则，但仅限于它们叫什么名字而已，它们具体是什么意思呢？下面我将从原文、译文、理解、应用，这四个方面分别进行阐述。
　　1. 单一职责原则（Single Responsibility Principle - SRP）
　　原文：There should never be more than one reason for a class to change.
　　译文：永远不应该有多于一个原因来改变某个类。
　　理解：对于一个类而言，应该仅有一个引起它变化的原因。说白了就是，不同的类具备不同的职责，各施其责。这就好比一个团队，大家分工协作，互不影响，各做各的事情。
　　应用：当我们做系统设计时，如果发现有一个类拥有了两种的职责，那就问自己一个问题：可以将这个类分成两个类吗？如果真的有必要，那就分吧。千万不要让一个类干的事情太多！
　　2. 开放封闭原则（Open Closed Principle - OCP）
　　原文：Software entities like classes, modules and functions should be open for extension but closed for modifications.
　　译文：软件实体，如：类、模块与函数，对于扩展应该是开放的，但对于修改应该是封闭的。
　　理解：简言之，对扩展开放，对修改封闭。换句话说，可以去扩展类，但不要去修改类。
　　应用：当需求有改动，要修改代码了，此时您要做的是，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码。当然，如果能够确保对整体架构不会产生任何影响，那么也没必要搞得那么复杂了，直接改这个类吧。
　　3. 里氏替换原则（Liskov Substitution Principle - LSP）
　　原文：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
　　译文：使用基类的指针或引用的函数，必须是在不知情的情况下，能够使用派生类的对象。
　　理解：父类能够替换子类，但子类不一定能替换父类。也就是说，在代码中可以将父类全部替换为子类，程序不会报错，也不会在运行时出现任何异常，但反过来却不一定成立。
　　应用：在继承类时，务必重写（Override）父类中所有的方法，尤其需要注意父类的 protected 方法（它们往往是让您重写的），子类尽量不要暴露自己的 public 方法供外界调用。
　　该原则由麻省理工学院的 Barbara Liskov 女士提出，她是美国第一位获取计算机博士学位的女性，曾经也获得过计算机图灵奖。
　　4. 最少知识原则（Least Knowledge Principle - LKP）
　　原文：Only talk to you immediate friends.
　　译文：只与你最直接的朋友交流。
　　理解：尽量减少对象之间的交互，从而减小类之间的耦合。简言之，一定要做到：低耦合，高内聚。
　　应用：在做系统设计时，不要让一个类依赖于太多的其他类，需尽量减小依赖关系，否则，您死都不知道自己怎么死的。
　　该原则也称为“迪米特法则（Law of Demeter）”，由 Ian Holland 提出。这个人不太愿意和陌生人说话，只和他走得最近的朋友们交流。
　　5. 接口隔离原则（Interface Segregation Principle - ISP）
　　原文：The dependency of one class to another one should depend on the smallest possible interface.
　　译文：一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口。
　　理解：不要对外暴露没有实际意义的接口。也就是说，接口是给别人调用的，那就不要去为难别人了，尽可能保证接口的实用性吧。她好，我也好。
　　应用：当需要对外暴露接口时，需要再三斟酌，如果真的没有必要对外提供的，就删了吧。一旦您提供了，就意味着，您将来要多做一件事情，何苦要给自己找事做呢。
　　6. 依赖倒置原则（Dependence Inversion Principle - DIP）
　　原文：High level modules should not depends upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
　　译文：高层模块不应该依赖于低层模块，它们应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
　　理解：应该面向接口编程，不应该面向实现类编程。面向实现类编程，相当于就是论事，那是正向依赖（正常人思维）；面向接口编程，相当于通过事物表象来看本质，那是反向依赖，即依赖倒置（程序员思维）。
　　应用：并不是说，所有的类都要有一个对应的接口，而是说，如果有接口，那就尽量使用接口来编程吧。
　　将以上六大原则的英文首字母拼在一起就是 SOLID（稳定的），所以也称之为 SOLID 原则。
　　只有满足了这六大原则，才能设计出稳定的软件架构！但它们毕竟只是原则，只是四人帮给我们的建议，有些时候我们还是要学会灵活应变，千万不要生搬硬套，否则只会把简单问题复杂化，切记！
　　1. 组合/聚合复用原则（Composition/Aggregation Reuse Principle - CARP）
　　当要扩展类的功能时，优先考虑使用组合，而不是继承。这条原则在 23 种经典设计模式中频繁使用，如：代理模式、装饰模式、适配器模式等。可见江湖地位非常之高！
　　2. 无环依赖原则（Acyclic Dependencies Principle - ADP）
　　当 A 模块依赖于 B 模块，B 模块依赖于 C 模块，C 依赖于 A 模块，此时将出现循环依赖。在设计中应该避免这个问题，可通过引入“中介者模式”解决该问题。
　　3. 共同封装原则（Common Closure Principle - CCP）
　　应该将易变的类放在同一个包里，将变化隔离出来。该原则是“开放-封闭原则”的延生。
　　4. 共同重用原则（Common Reuse Principle - CRP）
　　如果重用了包中的一个类，那么也就相当于重用了包中的所有类，我们要尽可能减小包的大小。
　　5. 好莱坞原则（Hollywood Principle - HP）
　　好莱坞明星的经纪人一般都很忙，他们不想被打扰，往往会说：Don't call me, I'll call you. 翻译为：不要联系我，我会联系你。对应于软件设计而言，最著名的就是“控制反转”（或称为“依赖注入”），我们不需要在代码中主动的创建对象，而是由容器帮我们来创建并管理这些对象。
　　1. 不要重复你自己（Don't repeat yourself - DRY）
　　不要让重复的代码到处都是，要让它们足够的重用，所以要尽可能地封装。
　　2. 保持它简单与傻瓜（Keep it simple and stupid - KISS）
　　不要让系统变得复杂，界面简洁，功能实用，操作方便，要让它足够的简单，足够的傻瓜。
　　3. 高内聚与低耦合（High Cohesion and Low Coupling - HCLC）
　　模块内部需要做到内聚度高，模块之间需要做到耦合度低。
　　4. 惯例优于配置（Convention over Configuration - COC）
　　尽量让惯例来减少配置，这样才能提高开发效率，尽量做到“零配置”。很多开发框架都是这样做的。
　　5. 命令查询分离（Command Query Separation - CQS）
　　在定义接口时，要做到哪些是命令，哪些是查询，要将它们分离，而不要揉到一起。
　　6. 关注点分离（Separation of Concerns - SOC）
　　将一个复杂的问题分离为多个简单的问题，然后逐个解决这些简单的问题，那么这个复杂的问题就解决了。难就难在如何进行分离。
　　7. 契约式设计（Design by Contract - DBC）
　　模块或系统之间的交互，都是基于契约（接口或抽象）的，而不要依赖于具体实现。该原则建议我们要面向契约编程。
　　8. 你不需要它（You aren't gonna need it - YAGNI）
　　不要一开始就把系统设计得非常复杂，不要陷入“过度设计”的深渊。应该让系统足够的简单，而却又不失扩展性，这是其中的难点。
　　一个成功的项目，离不开每个人的努力，分享下我曾经的项目管理经验。
　　给大家提出以下 10 点建议及其目标：
　　Sprint 第一天，需要将目标定义清楚，并让团队所有人都知道「确保建立一致的目标并使之明确」；
　　若出现需求变更，则优先排到下次迭代，特殊情况需特殊处理「确保本次迭代可以按时完工」；
　　Scrum Master 将迭代中的需求分解为任务，每个任务只能有一个任务负责人，且不超过一个人天「确保每日任务可评估」；
　　让 Product Owner 直接与相关开发人员确定需求，Scrum Master 需一同参与「确保需求与实现不会发生偏差」；
　　每日定时站会，时长不超过 15 分钟，规模不要太大「确保任务完成情况与计划保持一致」；
　　每日进行一次代码评审，由 Scrum Master 负责，并在次日将评审结果通知给相关开发人员「确保代码质量不要下降」；
　　各个团队的 Scrum Master 保持每日沟通一次，时间不要超过 15 分钟「确保项目管理不会出现风险」；
　　每次迭代结束，让大家稍微放松一下，可提供一些团队活动，比如聚餐「确保团队能够更加凝聚」；
　　Scrum Master 需要给团队一些承诺，比如项目奖金或特殊福利等「确保团队更加有激情」；
　　对于情绪异常的员工，Scrum Master 需及时与其沟通「确保不要让一个人的情绪影响整个团队」；
　　此外，作为项目管理者，需要不断在团队中加强以下 5 点文化：
　　方向一致
　　当面沟通
　　全情投入
　　充分信任
　　说到做到
　　真正的开源并非只是代码的开源，而是思想的开源
　　谈谈我对「开源」的看法，国内的开源的现在如何，对比国外呢？
　　我个人认为，真正的开源并非只是代码的开源，而是思想的开源。在做开源项目之前，建议能将自己的想法共享出来，而不是 埋头闭门造车。我不反对“重造轮子”，因为我们需要更好的轮子，轮子好了车子才能跑得快。凡是有利也有弊，我们也不能盲目地选择开源技术，因为并不是适合 别人的技术就适合自己，而是需要根据自身的需求，选择最适合的开源技术，搭建恰如其分的架构。
　　有大量的新技术，我首先会去关注它，了解它是做什么的，可以解决什么问题，但我一开始绝不会去深入研究它，更不会去看它的源码，因为一旦遇到这方面的需求场景，我就会从这个“知识库”中去寻找最好的解决方案，如果仍然寻找不到最合适的开源技术，我才会尝试自己去实现。
　　技术人的归途
　　走技术这条路，归途是什么？是否转型又该如何抉择呢？
　　至少有好几条路线是可以走的，比如：深入技术、转型做产品、转型做管理等，需要根据自己的特长和性格来选择，做自己喜欢的事情。
　　从技术转管理，对自身的要求比较高，说具体点，需要看自己的情商，为人处世的经验，与人沟通的技巧，自己也需要有足够的胸怀，去包容一些事情，还需要自己有足够的人格魅力去吸引别人，让别人愿意跟着你一起做事。管理有些东西是很难从书本上学到的，但一些经典的管理理论是必须要去学的。
　　相比较而言，继续深入技术或者从技术转产品会容易一些了，因为很多时候都不太需要与人打交道。 查看全部

　　网站架构师的工作内容(网络架构师将网站的结构概念化，并精确地计划如何将不同的组件连接在一起)
　　网络架构师将 网站 的结构概念化，并精确规划不同组件将如何连接在一起。典型的 Web 架构师的职责比简单地编写超文本标记语言 (HTML) 或操作图形网页创建程序更全面。Web 架构师需要具备良好的内容管理、搜索引擎优化 (SEO)、用户友好的导航实践以及如何实现各种 网站 目标的工作知识。Web 架构师的工作还可能需要创建和管理连接到给定 网站 的数据库，以及上传各种类型的文档供用户下载和阅读
　　
　　了解 HTML 等编码语言是成为 Web 架构师的重要组成部分。电子商务需要优秀网站设计师的专业知识来产生流量和收入。这些类型的 网站 通常有多个页面、链接和媒体，例如图像和视频。这些 网站 最常见的陷阱之一是组织规划不善。用户发现 网站 导航令人困惑或耗时，并且通常不太可能返回。熟练的 Web 架构师希望防止的其他问题包括断开的链接和无法正确加载的媒体。
　　
　　Web 架构师将 网站 的结构概念化，并准确计划不同组件如何链接在一起。一些入门级 Web 架构师通常需要四年制大学学位和相关的软件认证。网络架构师的热门学位课程是计算机科学、信息学或商业信息技术。建议至少精通一种网络脚本语言和一种高级编程语言。此外，Web 架构师需要具备处理网站构建阶段的所有方面网站架构师的实际工作在初始规划完成后开始的技能。企业网站的最初目的通常是网站所有者的想法和架构师的意见。很多企业主对网站地图的结构没有具体的背景知识，但是他们通常对自己的新网站有一个很好的想法，那就是制定网站的目标和列出的内容要求，网络架构师开始在组织结构图的帮助下规划细节。除了网络编程之外，Web 架构师还可以在编写第一行代码之前为 网站 创建详细的可视化。他们使用这些图表来说明每个站点组件如何在逻辑上连接到其他组件。根据内容的复杂性，Web 架构图可以遵循平面或多维层次结构。设计图完成后，Web 架构师通常需要将它们呈现给业务所有者和 Web 设计师团队。但他们通常对他们的新网站 有一个好主意，即制定网站 目标并列出内容要求，网络架构师在组织结构图的帮助下开始计划细节。除了网络编程之外，Web 架构师还可以在编写第一行代码之前为 网站 创建详细的可视化。他们使用这些图表来说明每个站点组件如何在逻辑上连接到其他组件。根据内容的复杂性，Web 架构图可以遵循平面或多维层次结构。设计图完成后，Web 架构师通常需要将它们呈现给业务所有者和 Web 设计师团队。但他们通常对他们的新网站 有一个好主意，即制定网站 目标并列出内容要求，网络架构师在组织结构图的帮助下开始计划细节。除了网络编程之外，Web 架构师还可以在编写第一行代码之前为 网站 创建详细的可视化。他们使用这些图表来说明每个站点组件如何在逻辑上连接到其他组件。根据内容的复杂性，Web 架构图可以遵循平面或多维层次结构。设计图完成后，Web 架构师通常需要将它们呈现给业务所有者和 Web 设计师团队。网络架构师在组织结构图的帮助下开始规划细节。除了网络编程之外，Web 架构师还可以在编写第一行代码之前为 网站 创建详细的可视化。他们使用这些图表来说明每个站点组件如何在逻辑上连接到其他组件。根据内容的复杂性，Web 架构图可以遵循平面或多维层次结构。设计图完成后，Web 架构师通常需要将它们呈现给业务所有者和 Web 设计师团队。网络架构师在组织结构图的帮助下开始规划细节。除了网络编程之外，Web 架构师还可以在编写第一行代码之前为 网站 创建详细的可视化。他们使用这些图表来说明每个站点组件如何在逻辑上连接到其他组件。根据内容的复杂性，Web 架构图可以遵循平面或多维层次结构。设计图完成后，Web 架构师通常需要将它们呈现给业务所有者和 Web 设计师团队。他们使用这些图表来说明每个站点组件如何在逻辑上连接到其他组件。根据内容的复杂性，Web 架构图可以遵循平面或多维层次结构。设计图完成后，Web 架构师通常需要将它们呈现给业务所有者和 Web 设计师团队。他们使用这些图表来说明每个站点组件如何在逻辑上连接到其他组件。根据内容的复杂性，Web 架构图可以遵循平面或多维层次结构。设计图完成后，Web 架构师通常需要将它们呈现给业务所有者和 Web 设计师团队。 查看全部

　　网站架构师的工作内容(网站架构师旳旳工作内容与经验(一)(图))
　　网站建筑师的工作内容和经历
　　由于国内外软件土壤的巨大差异，一些适用于国外的理论在中国未必适用，而国内的一些资料往往直接在国外资料的基础上转移使用，这也直接导致了国外的软件架构师。在国内变得不满意。今天这篇文章的内容是基于一些培训资料和基础网站建筑师的工作内容和经验
　　由于国内外软件土壤的巨大差异，一些适用于国外的理论在中国未必适用，而国内的一些资料往往直接在国外资料的基础上转移使用，这也直接导致了国外的软件架构师。在国内变得不满意。今天的作文内容是根据一些培训资料，加上自己的思考，总结出适合国情的软件架构师的职责范围。
　　1、需求整改分析
　　有人认为架构师是在需求规范完成之后才参与，但我认为架构师应该从项目一开始就参与。原因有很多：一方面，第一手资料至少丢失了，架构师能更好的把握需求；另一方面，分析师在与客户沟通时，往往不会进一步探究需求，因为有很多客户有隐藏的需求。他们自己可能没有意识到，但架构师可以依靠他们敏感的软件意识来发现这些需求并减少后续变量；第三，分析师经常离开开发团队，盲目接受客户需求，而架构师却能清晰地把握现有需求。研发团队能做什么，不能做什么，
　　2.系统分解
　　架构师采集信息后，需要将客户需求转化为软件需求，同步需要补充非业务需求，如健壮性、可扩展性等。如何识别和解决客户需求与软件需求，如何有效把握客户需求与软件需求的区别，是系统分解的核心。这是建筑师最受考验的地方，只有建筑师参与工作。
　　三、技术选型
　　这一步取决于软件需求来决定项目应该使用哪些架构、开发模型和依赖项选项。比如多层架构还是分布式架构，瀑布模型还是RUP，MySQL还是SQL Server，是否使用公司库，是否使用ORM。但是，建筑师应该为项目的技术选择提供多种不同的方案，并为每个不同的方案提供具体的文档，用于讨论每个方案的优缺点和可行性。项目经理或领导者使用这些文件进行最终的技术选择。
　　4. 系统设计
　　根据软件需求和技术选择，架构师和软件工程师需要将软件需求落实到软件特定的设计声明中。架构师负责分解软件需求，将其重新组织成子项目、子系统、组件和模块，以及它们之间的逻辑关系，从而形成 查看全部

　　网站架构师的工作内容(大型的网站制作公司网站架构师来说（一）)
　　说到网站架构，对于大型的网站建设项目，网站架构师往往是开发管理的协调者。网站架构师不仅要了解客户的需求，还要根据客户的要求设计网站的整个框架。而且，例如，要了解技术，很多时候它既是销售又是技术。
　　开发前的沟通协调
　　往往一个好的网站架构师来自技术，不懂技术，所以谈不上架构设计。往往我们要结合一些技术来实现网站的整体功能和具体功能的实现。这一切都与特定的架构方面有关。很多人认为建筑师是高高在上，在象牙塔里给开发商发号施令的人？事实上，事实并非如此。在很多情况下，架构师需要每天与开发人员在一起，一起编写代码、一起工作、一起交流。深入了解整个网站 生产开发过程中遇到的问题，并与团队协调解决这些问题。
　　启蒙与判断
　　在构建快速开发框架的过程中，开发者在开发过程中经常会遇到一些问题，比如一些设计中的冲突，而设计师在自己设计的时候也常常有自己的一些看法。这个时候，网站架构师应该根据设计师很多有意义的改进的意见来做出判断，不能随意、完全按照自己的想法去做。需要分析开发者的建议是否合理，是否还有改进的余地。只有开明的架构师才能设计出好的系统和好的基础组件。对于某些事情，我们必须做适当的筛选，架构师必须有这样的果断。
　　所以对于一个大型的网站制作公司来说，网站架构师扮演着非常重要的角色，可以说是一个项目的核心。
　　本文由()原创编辑转载，转载请注明。 查看全部

　　网站架构师的工作内容(1.确定主题选择主题应该是小而精，目标定位要小)
　　1.确保选题题目要小而精，目标定位要小，内容要精准。不要试图做一个包罗万象的网站，这样往往会失去网站的本色，同时也会带来高强度的劳动，难以及时更新网站。一定要记住，在互联网上只有第一，没有第二。2.选择域名 在互联网世界中，域名就是网站的名字。一个好记、好记的域名会给个人网站加分。当个人网站在用户中积累了一定的知名度，域名的价值就会体现出来。3.学习网页设计和开发技术对于...
　　
　　大家好，我是建筑师，一个会写代码，会背诗的建筑师。今天就讲讲个人网站开发过程（网站开发工作流程图），希望可以帮助大家提高！！！
　　1.确定主题
　　选题要小而精，针对性要小，内容要精准。不要试图做一个包罗万象的网站，这样往往会失去网站的本色，同时也会带来高强度的劳动，难以及时更新网站。一定要记住，在互联网上只有第一，没有第二。
　　2.选择域名
　　在 Internet 世界中，域名是 网站 的名称。一个好记、好记的域名会给个人网站加分。当个人网站在用户中积累了一定的知名度，域名的价值就会体现出来。
　　3.学习网页设计和开发技术
　　对于一些常用的脚本程序如asp、cgi、php也应该有一定的了解，还要熟悉图形处理工具和动画工具以及矢量图绘制工具的使用，能够了解各种基本的使用方法图形和图像动画工具，熟悉ftp工具的使用并具备相应的软件、硬件和网络知识。
　　4.选择服务器技术
　　5.网站规划
　　它相当于一个工作计划。在你开始之前，制定一个好的计划，你会少走弯路。
　　列和节的安排：构造一个网站就像写一篇论文。首先，必须列出大纲，使主题和层次清晰。
　　目录结构：网站实际上是文件的集合。如何规划这些文件就是目录的排列。对于网站本身的维护，未来内容的扩展和移植有着重要的影响。
　　链接结构：页面之间链接的拓扑结构。
　　网站风格设计：指网站整体形象给浏览者的综合感受。
　　设计网站标志（标志）
　　确定 网站 颜色方案
　　确定网站字体和样式
　　设计网站口号
　　6.数据结构规划
　　选择网站需要支持的数据库大小，服务器可以支持的数据库，然后选择网站应该使用的数据库类型。数据库结构和字段设计要严谨。
　　7.准备网站内容
　　从根本上说，网站内容仍然主导网站流量，而基于内容仍然是个人网站成功的关键。
　　8.程序开发
　　网站的开发应该是先写后台程序，方便后面的工作。前台只是数据展示的过程，没有复杂的逻辑处理。
　　9.测试网站
　　网站测试是必不可少的。
　　10.发布网站
　　11.网站促销
　　个人 网站 推广可以通过以下方式进行：
　　1）.搜索引擎注册在搜索目录登录技巧
　　2）.广告交易技巧
　　3）.目标邮件推广
　　12.网站运维
　　当网站达到一定程度，钱就必须提上日程。一般来说，个人网站获取资金通常有以下两种渠道：
　　1.出售网站广告位
　　2.使用较大的 网站。通过与大型网站合作，可以获得资金，也可以维护个人网站的日常运营。
　　我想你会喜欢： 查看全部

　　网站架构师的工作内容(“构架师”想呼唤一下，让架构师复活吧！)
　　2021-10-10
　　在csdn上看到朋友的一篇文章文章，标题是《架构师已死》，结合最近的工作，想打个电话，让架构师起死回生！
　　0. 序列
　　我不方便说我工作的公司就是那个公司，但是后面提到的公司就是我工作的公司。下面提到的项目只谈一些与本文相关的内容，不会谈具体内容。
　　我作为一个网站开发人员来到这家公司，我的工作是做一些网站系统，我的第一个项目是一个用于内部共享图像的图像管理系统。与这个项目相关的是一个内容管理系统cms，该系统之前已经完成。图片管理系统需要使用cms用户的数据登录，然后需要根据这些数据进行授权。另外，还有一个与本项目无关的系统，就是公司内部的考勤统计系统。我正在做的这个项目与考勤系统没有直接关系。
　　在我与负责的产品经理讨论需求后，一位领导告诉我如何与 cms 系统交互。想不到，我需要直接连接cms的数据库，才能完成图片管理系统的用户登录。特征。显然这是不正确的。用户登录的过程可能会做很多事情，可能需要记录登录日志，可能需要更新用户登录次数等等。这样我连接对方的数据库，重写登录逻辑是很不合适的，所以问下是否可以通过cms系统提供登录Web服务，可以通过图片调用管理系统在这里，可惜领导和我没太注意这个问题。领导说，这种功能封装，后面容易讲。由于我是新人，不方便争辩，因为如果我争辩，肯定会给cms的团队带来一定的工作量。图片管理系统的另一点还涉及到权限的管理，这也是cms中已有的功能，而且由于图片管理系统新增了几个角色，所以需要在这个系统中实现。显然，这也是不合适的。两次也属于同一个逻辑实现。另外，由于考勤统计系统也有公司所有员工的用户信息，下面是现有系统的侧面结构图。不方便争辩，因为如果我争辩，肯定会给从事cms的团队带来一定的工作量。图片管理系统的另一点还涉及到权限的管理，这也是cms中已有的功能，而且由于图片管理系统新增了几个角色，所以需要在这个系统中实现。显然，这也是不合适的。两次也属于同一个逻辑实现。另外，由于考勤统计系统也有公司所有员工的用户信息，下面是现有系统的侧面结构图。不方便争辩，因为如果我争辩，肯定会给从事cms的团队带来一定的工作量。图片管理系统的另一点还涉及到权限的管理，这也是cms中已有的功能，而且由于图片管理系统新增了几个角色，所以需要在这个系统中实现。显然，这也是不合适的。两次也属于同一个逻辑实现。另外，由于考勤统计系统也有公司所有员工的用户信息，下面是现有系统的侧面结构图。这也是cms中已有的功能，由于图片管理系统新增了几个角色，需要在本系统中实现。显然，这也是不合适的。两次也属于同一个逻辑实现。另外，由于考勤统计系统也有公司所有员工的用户信息，下面是现有系统的侧面结构图。这也是cms中已有的功能，由于图片管理系统新增了几个角色，需要在本系统中实现。显然，这也是不合适的。两次也属于同一个逻辑实现。另外，由于考勤统计系统也有公司所有员工的用户信息，下面是现有系统的侧面结构图。
　　
　　这种结构导致一些重复的逻辑和数据，以及各个系统之间的病态耦合关系，给维护带来很大的困难，也会给后期开发的系统加分不少。工作量大。
　　上面的图片管理系统只是我做的一个小东西，很快迎来了第二个项目，也就是网站的一个频道，就像新浪有宽带、新闻等等，我做的就是这些这。我们公司业务很多，所以模块很多。我所做的将参考许多其他模块。如何引用其他模块成为一个问题。这里（我公司）采用了几种方法1）直接读取对方的数据库2）直接引用对方的dll，3）调用数据库中的存储过程。有很多方法，但没有一个是美丽的。代码可以很美，整个系统的架构也可以很美！所以我哭了：起死回生，建筑师！
　　1. 架构师应该做什么
　　带着上面的问题，我忍不住想叫系统架构师现身。在《架构师已死》一文中，一位正在接受采访的朋友曾经提到架构师的工作是选择一个项目是使用structs还是spring结构来开发。结果博主证明了选择这个问题比编码容易，所以这不是架构师的工作。建筑师的工作应该是比较艰巨的工作。架构师要熟悉公司的所有项目，并能在一定程度上预见未来的系统，从而调整各个系统之间的关系，使各个子系统形成一个完美的架构体，可以影响各个系统。其他稳定或独立运行；在软件工程方面，
　　我们还与传统的建筑工程进行了类比。系统架构师的工作不是某个建筑设计师的工作，而是整个城市布局的设计师。建筑师必须了解每栋建筑、每一个菜市场、每家医院的结构和功能以及它们之间的关系，以及一些外部因素，然后才能决定如何建设一个美丽、健康、宜人的城市。
　　2. 拥有架构师能给我们带来什么好处
　　做架构师的工作可以让我们的程序更加稳定，因为程序子系统之间的结构是稳定的。它可以减少我们维护的工作量。一个好的架构师永远不会让重复的逻辑和数据出现在系统中，这势必会减少系统的开发工作；架构师还可以让构建新系统的工作变得更轻松，因为架构师会为我们抽象出底层模块，并在各个程序之间共享。
　　本文第一个案例由架构师设计如下：
　　
　　架构师设计了一个用户管理系统模块，为其他三个模块提供用户管理服务。涉及用户的操作统一在用户管理系统中，包括用户注册和权限管理。这样，当开发一个新系统时，就不需要做系统登录和用户授权模块了。这种结构更好吗？
　　3. 建筑师需要什么能力
　　架构师首先要懂编码，这是设计的前提；那么他们还需要懂设计，能够设计出完美的系统；那么他们还需要有看大局的能力；具有出色的协调能力，可以看出架构师的工作包括可能涉及多个项目，这需要多个项目团队甚至客户之间的协调。
　　文中给出的例子都比较简单，但真正的架构师不能只处理这么简单的问题，必须考虑很多因素。
　　随附的：
　　csdn“建筑师死了”
　　分类：
　　技术要点：
　　相关文章： 查看全部

　　网站架构师的工作内容(最新精品资料整理推荐(二)：更新于二〇…)
　　………………………………………………………… 推荐最新资讯………………………………………………
　　………………………………………………………… 推荐最新资讯………………………………………………
　　最新优质资讯推荐，20日更新…………………………………………………………最新资讯推荐…………………………………… …………
　　………………………………………………………… 推荐最新资讯………………………………………………
　　最新质量信息推荐，2021年1月22日更新2021年1月22日星期五21:07:38
　　最新质量信息推荐，2021年1月22日更新2021年1月22日星期五21:07:38
　　………………………………………………………… 推荐最新资讯………………………………………………
　　最新质量信息推荐，2021年1月22日更新2021年1月22日星期五21:07:38
　　网站建筑师的工作内容和经历
　　由于国内外软件土壤的巨大差异，一些适合国外的理论在中国未必行得通，而国内的一些资料往往直接在国外资料的基础上转移使用，这也直接导致国外软件架构师在中国. 变得水土不服。今天这篇随笔的内容是在一些培训资料的基础上，加上自己的思考，总结出适合国情的软件架构师的职责范围。
　　1.需求分析
　　有人认为架构师是在需求规范完成后才参与进来的，但我认为架构师需要从项目一开始就参与进来。原因有很多：第一，第一手信息丢失最少，架构师能更好的把握需求；其次，分析师在与客户沟通时，往往不会深入挖掘需求，因为有很多隐藏的需求是客户自己看不到的。架构师可以依靠他们敏感的软件感知来发现这些需求并减少未来的变量。第三，分析师经常离开开发团队，盲目接受客户需求，而架构师却能清晰掌握现有的研发团队。能做什么不能做什么，提前预知风险，
　　2.系统分解
　　架构师采集信息后，需要将用户需求转化为软件需求，同时补充非业务需求，如健壮性、可扩展性等。如何区分和解决用户需求与软件需求，如何有效把握用户需求与软件需求的区别，是系统分解的核心。这里是建筑师最受考验的地方，也是只有建筑师才能参与的工作。
　　三、技术选型
　　这一步取决于软件需求来决定项目应该使用哪些架构、开发模型和依赖项选项。比如是使用多层架构还是分布式架构，是使用瀑布模型还是RUP，是使用MySQL还是SQL Server，是否使用企业库，是否使用ORM。但架构师应为项目的技术选型提供多种不同的方案，并为每个不同的方案提供详细的描述文件，说明每个方案的优缺点、可行性等内容。项目经理或领导者使用这些文件进行最终的技术选择。
　　4. 系统设计
　　根据软件需求和技术选择，架构师需要与软件工程师一起将软件需求落实到软件详细设计规范中。架构师负责对软件需求进行分解，将其重新组织成子项目、子系统、组件和模块，以及它们之间的逻辑关系，从而形成不同的逻辑组件，最终确定各个子系统和组件之间的接口。这些被用作进一步分工的基础。与系统分解一样，系统设计也是考验架构师能力的重要职责。
　　五、培训指导
　　…………………………………………………… 推荐最新资讯………… 查看全部

　　网站架构师的工作内容(网站架构师的工作内容，设计企业网站的架构流程)
　　网站架构师的工作内容，设计企业网站的架构流程，配置整站的访问流量，满足网站架构师各个角色对用户体验、性能的要求，让网站架构满足用户需求、网站性能优化满足用户需求。有的公司有网站架构师这个岗位，当然主要也是属于网站架构师这个大分类，侧重于分析企业网站的性能瓶颈，设计企业网站主站架构，后续通过对各子网站整体布局的优化来满足用户体验。
　　让网站架构经过这一轮分析设计后满足用户需求。因此如果你有网站架构师的工作经验的话，个人建议你找一个软件公司或者高校，让他们推荐一个靠谱的公司和职位给你。但是，请不要把软件公司和高校认为不靠谱的公司，他们也是技术出身，对于这方面是知道的，只是因为利益问题作出的最有利用价值的选择。因此，找什么公司这个，还是看你个人的了解情况和对于未来的职业规划。
　　总之，如果想做一个好的网站架构师，重要的是要会忽悠。这类人虽然天赋一般，但是技术也稍微过关，认识的设计都是有这个业务需求的，只是没有相应的技术性人才。而且一个好的架构师一定是一个实用的人，而不是在堆砌所谓的技术。
　　我真没想过以这个回答作为开始回答这个问题，在一个以销售为主导的公司带你其实跟我所面临的一个就业风险差不多，我在以销售为主导的创业公司做hr，还挺担心我自己在想到待遇以及自己的技术看中那个方面的时候是否在跑偏了，但是我有没有同样的风险给别人带来风险。根据我的同学，我的同事基本上都经历过这种事情，找了一个还过得去的地方然后又各种为他人打工的，因为收入真的不能保证，除非那个公司足够大，也愿意给你高薪。
　　我觉得有很多原因都是这样，公司眼里自己找来的员工，不一定能给他们带来资金回报也或者更多，换句话说是公司觉得自己公司的产品应该没法吸引到最好的人才。有时候公司觉得自己产品足够好了，可以获得资金回报，自己有自己的人才市场。可以给优秀的人才更多机会，至于你和公司的基础如何，机会看你自己把握的。人家去找一个总要求比自己要求高一点的公司。
　　这是人之常情，只能说公司要求太高，你自己不合适而已。能不能进去，看你和公司的契合度。机会只留给有准备的人。你自己的能力才是优先级最高的。 查看全部