序：我13年高分考上了厦门大学，当时专业是计算机科学与技术，大一就那么过去了，大家都有的生活；军训、上课、加入学生会、加入各种社团。所有课程中，我最喜欢英语课，因为老师很美，其次就是C语言课程。当时我只记得大家每天私下里聊天的内容就是哪个班的女孩子，哪个老师，周末哪里吃，哪里玩，有一些活跃分子甚至在囤比特币（实时证明他们没错，现在我有两个同学已经靠比特币赚了上百万），而对于我来说，内向，不爱与人沟通，闲暇时间都在学英语，学C语言。当然结果只可能有一个，不合群。上这两门课程，我永远在班级的第一排，第一个到教师，上课座的笔直，笔记记了满满的。在室友、其他同学看来，我唯一的用处就是这两门课的考试，平时的答疑解惑。朋友很少，导致我感觉生活的无趣，终于在14年底，我受不了了，选择了退学。家里人一顿臭骂与说道，跟我说我的未来没有文凭，是多么的昏暗。
退学之后，大概一个月的时间，我接触到了Objective-C这门语言，没错，做苹果APP开发，行业叫做iOS开发工程师。我记得当时的Xcode版本是5.0，相关的资料对于我来说少之又少，于是我选择了培训，地点是在北京。
培训的日子我算是下了这辈子最大的苦，我觉得我要证明给大家看。规定上课时间上午9点到晚上9点，最晚可以在教室留到11点，我的作息时间：早上7点-晚上11点，中午休息1小时，没有周末。我的学习速度超越了班级所有人。我记得培训总共是有3个月的时间，2个月学习加1个月找工作，我大概用1个月时间学完了整个课程（最初是教C语言基础的，耽搁了10天）。这段日子里，学习的同时我学着让自己变的外向，班里的热心肠，甚至隔壁班有问题也会来问我，不论何时何地。我主动与周围的人、寝室的人聊天，说自己的生活（让自己变的外向真的是件特别难的事情，特别特别难，要知道，和每个人相处的方式都有可能不同）。
我大概在1个半月的时候，培训机构的老师帮我包装了简历，就开始出去面试了。第一家面试的公司我记得很清楚（被虐的很惨），叫做云校，在北京-望京SOHO。面试官很温和的问了我一些算法问题，我发现我一个都不会，关于iOS开发的一些Runtime啊之类的我答的还算不错，最终没能被录取。回来之后我想，算法与数据结构是必须品么？带着这个问题，我接着面试，面到了新浪微博大楼对面楼里的一家小公司里，在一系列iOS问题之后，我以为自己要被录取了，没想到面试官讲：同学，快排可以写一下么？今天你的表现真的很棒。我呆住了，当时支支吾吾的说这个我不会，面试官笑着讲没事的（结果还是一样...）。于是，我决定加强自己这一块的知识点，在接下来的半个月时间内，我瘦了10斤。寝室里的泡面味没散过，我买的数据结构书上做满了笔记，leetcode刷了大概有100道题。我记得很清楚，我学习的算法从排序、桶排、快排、深度优先、广度优先一步步的下去。很快，迎来了下一次面试，这次面试的机会来自新浪Sina，是的没错，培训机构的老师帮忙推荐了一下。我记得岗位薪资是14K，对于我来说，从来没有自己赚到过这么多钱。
面试很顺利，部门因为签署了保密协议这里不太方便透露。主要的任务也很明确，就是写一个底层框架中的2个模块，ORM与Network，我记得当时我的老大对框架的要求很高，包括方法命名、大小写，代码的健壮性，单元测试，甚至到了大括号、小括号这中间的空格。我第一次感觉到了正规；比培训机构的老师都专业的多。Network模块包括了从SPDY到15年下半年的HTTP2，整个Networking基础框架都是由我来负责。这其中包括了用于帮助做负载均衡的DNS模块等等。15年下半年，老大突然跟我讲，安卓同样负责这个模块的同事离职了，让我来接手。脑子懵了，安卓？从来没碰过啊。老大丢给我一本绿色的书，疯狂安卓讲义。于是我走上了安卓程序员的道路，但是局限性很大，在这过程中我自学了JAVA语言，自学了安卓开发，但是安卓方面我致命的弱点就是不会界面开发，因为我从来没有写过复杂的界面，即便是我在测试我的Networking框架时候，也只是简单的Button，EditTextView，像什么RecyclerView我从来都没有写过。安卓的风格也很像iOS，包括类名，方法名，我整个按照iOS的思路重构了一遍（后来也是巧了，老大要出一份框架的使用文档，我直接写一份就好了）。这样的日子持续到了15年底。
15年1月27号，我和老大吃饭，我说：老大，这只写一个模块好无聊啊。老大跟我讲，你还年轻，先别急，先干好一件事情。那个时候飘飘然的自己没有听进去挽留，毅然的离开了北京，一次网上面试的机会，来到了深圳。团队当时只有两个人。一个我，另外一个后台（JAVA）。我们要做的事情就是两周之内给客户一个demo展示，要安卓版本的（应为我面试的时候直接讲了我安卓没问题）。这下，我迎来了工作后的第二次懵比，两周时间，我加起来估计只睡了2天不到。我看视频教程学安卓UI怎么写，最开始我都不知道.9是什么玩意。我学会了各种布局方式，学会了适配。觉得安卓跟iOS写UI上的大区别，就是安卓用代码改改一个空间的样式、位置好麻烦。两周交差了，很满意。我们正式接下了客户的一个价值80万的项目。是做一家医院的挂号、在线病历单、药品购买、社区的一个APP。公司也开始正式招人，团队的构成大概是1个iOS，1个安卓，2个后台，1个UI妹子（深圳的妹子感觉肤色很黑）。16年3月到16年9月这段时间里，我的安卓、iOS开发能力也大幅度的上升，经过了这个项目的历练，我感觉蛮不错的，心里很满意。
私下的生活，我也想自己开发自己的APP来玩玩，但是没有后台的支撑，数据智能存放到本地。于是我接触到了LeanCloud（当时还叫AVOSCloud），这家国内的公司真的是很强大（不要脸），只是把国外一个教叫做parse的同样的baas的开源项目改了个名。用的过程中，发现太麻烦了，不自由，而且后续还要收取费用。当然这点费用对于当时18K薪资的我没有任何压力。但是我还是毅然的接触了后台开发。
接触后台开发，16年10月，对我来说，是一个新的起点。我觉得后台开发简直是一门艺术。全盘的逻辑都在掌控之中，我可以做任何想做的事情。我开始学习SpringMVC，学习MyBatis，学习MySQL，17年初，我离开了上一家外包公司。来到了我目前的这家公司。依旧是从0开始，我到公司的时候，只有4个人，我的岗位是后台工程师。于是故事开始了，在这家公司的10个月，我逐渐的成长为团队的核心，并学习机器学习、大数据、容器等等技术，空了就去看infoQ上边大牛发出来的架构PPT，一些大公司的技术方案，看可否和我公司业务结合。这10个月对我来说是质的飞跃，管理+技术，不知不觉得来到了身边。这10个月，也是最苦的10个月，没过过周末，没有过私人时间，没谈过恋爱。每天就是公司的业务，需求，学习视频，架构ppt，总结的笔记，公司的bug。公司的业务也是相当的给力，7000万注册用户，几十万的日活，这家公司，是我的第一家接触管理的公司，团队规模大概在40人。我的管理模式很简单，树状。
不得不说，压力成就一切。
18年，我选择了不安分，投入到了区块链中，不是玩币，而是做链上开发。我用半个月的时间学习了C++，联系了一个好朋友去做区块链的开发。开发的核心很简单，提速。ETH当时的速度，10TX/S，现在我自豪的讲，我们自己研发的区块链可以达到10W tx/s，淘宝据说有50W tx/s吧（这个是道听途说，可能不太准确），在区块链行业内，我们第一次有了排名。是的，就是hyperledger，如果你了解的话，应该听说过这个不错的框架。18年5月，我离开了这里，回到深圳担任另一家做共享概念的公司中当技术合伙人，到现在4个月了，再一次见证了整个团队与产品的从0到1。
这几年，不管是技术还是管理，感触颇多，我的管理经验并不是在BAT，都是在创业公司。对于大多数人来讲，阿里巴巴、百度、腾讯可能不是想象中的那么好，请各位听我一句话，想要去大厂，请放下你的架子，跟你的老板处好关系，保证自己的一小块没问题的前提下，再去看其他的东西。
创业公司与大厂的区别在于：创业公司你可以接触到任何你想接触的事情，甚至是老板的商业思维你都可以去找他聊。大厂就像我再Sina一样，请干好你的本职工作（这个我仅针对程序员而言）。
我的自我介绍就到这里，也就是本文的序言。序言中间很重要的一句话，压力成就一切，我希望读者们可以带着这句话继续读下去。
序言看过后，对本文核心内容应该有所期许，希望本文可以用真实的一些感触，作为中秋祝福，也最为你今后职业规划的引导。
一、了解、体会
跟大家讲一下，做CTO我最注重的几个点与经验：
- 解决技术问题、解决难题、帮助大家提升解决问题的速度、教大家如何解决问题
这一点，很重要，看起来很平常，真做的好，很难。下属碰到问题了怎么办，这个问题他自己困扰了很久不能解决问题，再下去可能会影响进度了！技术老大来了，帮你处理好了问题，继续回去研究其他事情。错误！切记，完成第一点时，请授之以渔而非授鱼。团队成员如果养成遇到难题向上抛出异常的坏习惯，对于今后的团队管理相当不易。所以请把你自己多年的搜索问题答案的经验、方式告诉他。告诉他分析问题的方式、去google查询问题的关键字。碰到问题第一反应是什么，如何寻找问题。
我记得下属自认为曾经解决过的最麻烦的问题，是一个客户端闪退的问题，我们最后使用了兜底方案，用注释代码的方式来寻找哪里出了问题。 注释一些，运行一下，注释掉了大半个工程，才找到一个问题。他是个初学者，我教会了他iOS全局断点，如何调试，图和使用instrument工具对代码进行分析。
授之以渔，让团队成员拥有独立解决问题的能力，是管理整个团队是否轻松的第一大难题，团队创立之处，请多与手下磨合，了解他们的长处、弊端、想法、个人性格。把聊技术当成是家常便饭，在聊天过程中让大家养成交流问题是如何解决的这种话题的好习惯，逐渐要求团队成员独自解决问题。并制定非强硬性KPI考核（这个具体如何考核以及文档下一篇文章我们细说）。
- 技术架构，宏观的架构与微观的架构
如果你接手的项目是从0到1，你可以利用你丰富的项目经验做好初期的技术架构，如果不是呢？请时刻关注公司技术方向的短板。这些短板通常短期内无法发现，但是在公司业务量达到一定程度的时候会突然爆发。OOM、接口响应慢、连接池不够用、服务器压力大等一系列的问题。
请至少按照业务量*10的来架构。这个通常情况下指服务端。对于客户端架构，我的要求很简单，请自动化、组件化、可修复化（自动化与组件化想必大家都知道，后续我们可以持续分享自动化、组件化、自动发布流水线这一整套流程）。
重点在这里：架构要超前，一切都要有备用方案。
- 与我的老板搞好关系、与下属搞好关系、切勿跨层管理
与我的老板搞好关系，为的不是获得更多的利益，而是时刻关心未来公司的方向，所以要与CEO构建一个好的合作关系。从他的业务角度去考虑他提出的需求，并学会如何平衡产品需求，判断产品需求的优先级，重要性。一定要关注那些简单却能带来很大回报的需求点，关注老板对交付的产品的满意度，洞察公司业务发展情况与规模，适当的时候根据未来几个月的规模预测进行架构的提前调整。
与下属搞好关系，为的不是更好的命令他们。带团队，请记住，跟你的直接一层管理员工搞好关系，不管是工作上还是生活上，会对你的管理、成长带来加倍的速度。作为 技术老大的你，很难每个方向都很深入的学习，你管理的第一层员工可以为你带来丰富的知识，跟他们搞好关系，他们会不自觉的把你和一层员工相处的方式带到下一层去。这是最舒服的管理，也是最合适的管理。非必要时期，切勿跨层管理。对你的小组负责人不尊重，对下一层的员工压力大，会适得其反。
- 创造研发团队的文化气息、利用第3点
给工作注入新鲜的东西，不光是技术。创建一个好的研发团队文化，也是件难度不小的事情。研发团队与其他团队的本质不同，研发团队是要一起冲锋打仗互相帮助的，在团队中一定要杜绝内部的矛盾激化与产生。
- 教你的团队成员如何变的开朗、外向、自信是一件很简单的事情，开朗、阳光可以传染，即便是在加班很多的时候，请表现出你作为领导人最自信的一面，与人交谈、沟通切勿带负面情绪或者表情。请再和你成员对视的时候发自内心的微笑。
- 研发团队应当组织的活动：共同健身、共同桌游、KTV每人唱歌、每天下午的眼保健操、每天早上9点半的放声大笑1分钟。让你的团队成员觉得拥有不错的生活环境与成长环境。
- 避免无用功，减少强制加班，培养责任心，学会及时介入开发过程，一切以结果为目标。请帮团队顶住公司的开发压力，即便万分紧急你也要做到有条不紊。请先把重要的事情梳理清楚，最好写成文档，与需求方确认之后，召集一层相关人员参会。工时先让大家来定，在慢慢梳理需求的过程中请分析该需求可能的耗时、需要关联的成员、可能出现的问题、缓冲期。
最重要的一点，以结果无误为最终目标。举例说明：需求A，一个文本编辑器。 预估工时 5 天，缓冲期 1 天，如果第3天的时候，你发现进度没有你想象中的好，请及时介入并问询情况，确保交付无误。
让员工自觉加班而非强制加班的妙招就是沟通艺术，灌输团队合作，灌输责任心。在我的团队里，如果大家都赞成的10天工时，我的团队在7天内保质保量完成了该需求的迭代，接下来的3天，成员可以带电脑自由休息（为了及时处理问题，团队成员均使用笔记本电脑）。如果项目上线后出现问题，下次缩短可休息时间的50%。直到再次保证项目无误上线。
请在意一点：团队共进退。
- 态度
这句话我很喜欢：你对他人的态度，就是设置好了他人如何对待你的底线。我不怕得罪财主，因为只有设置好边界的人才能防止他人心底的恶，才能过滤出人群里的尊重和善意。
对团队成员，你的态度，同样决定了他们对待你的方式。作为团队的负责人，一言一行都在成员的严重。态度，尤为重要。学会控制自己的脾气，把握谈吐的度与方式。
二、打个比方
我最喜欢用一个例子来给创业公司打比方：
CEO 负责思考，是整个团队的 大脑
副总 负责整个团队的具体管理 小脑
业务部门 负责整个公司的业务发展，维护。 大腿（创业公司的底盘，一定要稳，要粗壮）
运营部门 抓住用户核心价值，抚摸用户的内心。 手臂
大牛、精英 负责资源协调，衔接，连接各个部门。骨干
数据部、财务部 负责存放重要数据 隐私部位
技术部 负责公司的业务实现 内脏器官
这样变构成了一个完整的创业公司。每一个点都至关重要，每一个部门都不能出问题。
三、追求、事实
打工也好、创业也好、国内也好、国外也好，这些都是形式，不是内容。内容是什么？内容是你有没有和有想法的人去经历有意义有价值的事情。研发恰好是一个最好的例子，经历互联网正式夕阳、正是大数据、机器学习、区块链刺激的这个年代。为什么不去追逐一下呢？
请在意一点：程序员，请把你的长远目标设为追求自由。
四、干货
很多人都喜欢放点干货在文章的尾部，我在文章的尾部放一些干货：
CTO的项目规划一般都是做什么呢？我觉得主要是规划好下个阶段架构设计的边界。而影响架构边界的，其实就是需求。需求形成了对架构的约束条件，从而也对规划成了边界。那么，有哪些需求呢？可以分为三大类：商业需求、功能需求和质量需求
商业需求一般对整体架构的影响比较大，对整体架构产生限制的商业因素也比较多，在此列举一些比较常见的：
上市时间：上市时间限定了系统从设计、开发、测试到上市的时间边界。之前我跟进过一个垂直于大学生市场的应用，上市时间就要求在新生入学前，不然就会错过推广的最佳时期，预留给开发的时间只有两个月。因此，我们只好大部分重用前个项目的元素，包括重用服务端的一些模块，还包括客户端的架构和界面。当然，一般情况下，预留给开发的时间不会这么短，但也不会特别长。架构师需要根据时间长短，平衡各方面需求，做好架构选型。
成本预算：成本预算就限定了能使用的资源边界。不同架构的开发成本肯定不同，要满足更多功能需求和更多质量需求的架构成本也更高，在预算有限的情况下，只能权衡各种需求，优先满足重要程度高的需求。
人力现状：100人的开发团队和10人的开发团队，软件的架构会有很大不同。另外，开发团队人员所掌握的技术也会对架构选型有影响。例如，团队里还没有人会用React Native，那现阶段就不适合选择React Native作为App架构的技术基础。
与外围系统的集成：当需要与外围系统集成时，需要认真考虑集成方法，尤其是外围系统比较老的时候，集成难度可能更高。另外，外围系统的不可控因素一般也比较多，因此，对架构处理这些不可控风险的要求相对也高。
开放性：封闭的私有系统和开放式系统对架构的要求也不同，一个系统如果选择了开放，那对架构的质量要求更高，对安全性、扩展性、性能等质量属性都应该比封闭时高。
目标市场：目标用户10万、100万、1000万，不同级别的目标市场，架构也是大有不同。另外，大众市场和垂直的专门市场，架构也同样有区别，较大的专门市场一般都采用产品线的规划方案。
多端支持：现在移动端普遍支持Android、iOS、Wechat，管理端通常则支持PC Web，如果管理端也要支持Android、iOS、Wechat，或者移动端和管理端还要再支持WindowsPhone、黑莓，甚至再支持VR，则需要投入更多时间和人力，架构上相应也需要做出调整。
期望的系统生存期：从主观上说，谁都希望自己的系统可以生存很久，但生存期越长，意味着系统的可修改性、可扩展性、可移植性等需要更高。但是，受上市时间、成本预算等因素的制约，再加上软件本身的变化快，所以，客观上，一般也不会期望其生存期太长。当系统不能满足渐增的需求时，基本通过重构来解决。
阶段性计划：每一个大平台系统普遍都是分阶段完成的，因此，前期阶段的架构设计时就需要考虑好重用性、扩展性、伸缩性、移植性等特性。但因为每个阶段经过市场验证后，需求有可能会变化，所以又不能过度设计，否则就会造成设计浪费，还可能加大了后续阶段架构调整的难度。
国际化：如果走国际化路线，那架构上就要考虑好对多国语言的支持。
竞争对手：产品要比竞争对手优秀，那就要在一些关键的功能或质量上超越对方，也意味着在这些方面的架构需要投入更多。
法律法规：比如，对某些关键字要进行过滤屏蔽，这是天朝独有的，大家懂的。
商业需求多种多样，有些需求还可能会相互矛盾，比如，上市时间和成本预算就会和期望的系统生存期可能产生矛盾，期望的生存期越长其成本就会越高，需要投入的时间就会越多，那么，就有可能拖延上市时间。因此，做架构规划时，必须梳理清楚哪些需求是能够被满足的，能被满足的程度如何，需要在各个需求间权衡利弊。另外，商业需求因为是最高层次的需求，因此，相对于功能需求和质量需求，其优先级一般也比较高。
功能需求描述了系统应该提供的服务，包括为用户提供的服务，也包括为其他系统提供的服务。而架构主要就是为功能服务的，而功能需求基本与具体的业务相关。因此，要做好功能需求这块的架构，就必须对该业务领域足够了解，这样才能更好地抽象建模。对功能需求的架构规划，主要就是建立业务领域模型。领域模型定下来后，下个阶段的设计必须与领域模型保持一致。
而对功能需求进行领域建模之前，还需先梳理下需求的优先级。因为受商业需求的影响，功能需求也需要权衡。比如，上市时间紧、成本预算低、人力资源也不是很充足的情况下，功能需求只能少不能多。而需要与外围系统集成的时候，也意味着这部分功能不需要自己实现了；但是，如果外围系统无法完全满足需求时，则还需要自己再实现缺失的需求。因此，现阶段需要满足哪些功能需求？需要满足到什么程度？这两个问题确定了之后才能更有效地进行领域建模。
领域建模主要就是要分析清楚每个领域模型和模型之间的关系。还是直接用一个例子来说明吧。假设现在要做一个支持O2O(Online To Offline)的电商平台，以下是经过梳理后的几个关键的功能需求：
商家可以在平台发布商品，可以是实体类商品，也可以是服务类商品。
实体类商品支持快递，服务类商品只能到商家门店兑换消费。
用户购买实体类商品时需提供收货信息。
用户购买每个商品时对应生成一个订单。
用户购买的是实体类商品时，可以查看商品的物流信息。
用户购买的是服务类商品时，可以用订单的兑换码到商家门店兑换消费。
根据以上需求，可以初步得到相关的领域概念有：商家、商品、实体类商品、服务类商品、物流信息、门店、用户、收货信息、订单、兑换信息。
领域模型确定之后，系统中有多少业务领域、各领域概念之间的关系如何就一清二楚了。
所以我们要尽可能早的画清除自己的全局设想图
质量需求是三类需求中，需求层次最低的，但却是大部分架构师最关注的。纵览那么多架构技术，就会发现，大部分都是为了解决某个或某些质量属性优化的问题
质量属性常见的有以下这些：
性能(Performance)：性能无疑是一个非常重要的特性，尤其在计算资源有限的情况下。但也无需过分追求高性能，从而牺牲其他更重要的特性。
安全性(Security)：安全性一般会和性能相互制约，最明显的例子就是HTTPS，使用HTTPS提高了安全性，但性能就会有所牺牲。很难做到既满足高安全又高性能，因此需要根据具体需求平衡两方面的特性。
可用性(Availability)：也有人称为有效性，一般定义为：可用性 = 系统正常工作时间 / (系统正常工作时间 + 故障维修时间）。此定义就说明了可用性与系统故障有关，故障率高，可用性就低，故障率低，可用性才高。另外，高可用性还说明了系统对故障维修的时间也很短。
易用性(Usability)：易用性很容易和可用性混淆，可用性关注的是系统长时间无故障运行的能力，而易用性关注的则是系统易于使用的能力。
鲁棒性(Robustness)：也称为健壮性、容错性，是指系统在出现了用户非法操作、或软硬件的缺陷导致的异常情况下，系统依然能够正常运行的能力。比如说，系统在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。
可伸缩性(Scalability)：可伸缩性是指当用户量和数据量增加时，系统维持高服务质量的能力。比如，当并发量为1W时，系统响应时间为1秒，那如果并发量增加到100W时，只要通过增加服务器数量，而无需对代码进行修改即可达到系统响应时间依然为1秒，就说明该系统的可伸缩性高。
互操作性(Interoperability)：互操作性反映了本系统与其他系统交换数据和服务的难易程度。
可扩展性(Extensibility)：也称为灵活性，反映了系统应对变化的能力。在软件开发过程中，需求变更是常有的事，尤其在移动互联网时代，变化是非常频繁的，也因此，可扩展性是移动互联网产品重点考虑的质量需求。
可理解性(Understandability)：可理解性是指开发人员通过源代码和相关文档，了解程序功能、结构和运行方式的难易程度。遵从好的开发规范一般都可以提高可理解性。另外，单一职责原则运用得好，也能大大提高可理解性，所谓“简单就是美”，简单才容易理解。
可测试性(Testability)：简单点说，可测试性就是测试和诊断软件错误的难易程度。比如进行单元测试的难易程度。如果程序包含了复杂的处理逻辑、数据结构、模块关系，可测试性的设计更显得尤为重要。
可复用性(Reusability)：可重用性表明了一个软件组件可以在其他程序中使用的难易程度。一般需要将一个组件抽离成通用性的组件时，对可复用性的要求就会比较高。
可移植性(Portability)：可移植性表明了将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。
可维护性(Maintainability)：可维护性是指理解、改正、改动、改进软件的难易程度。我觉得，可维护性是保证一个软件系统能够长期生存的最重要的特性，没有之一。对一个可维护性差的系统，久而久之，不断变得牵一发而动全身，变得不可维护，慢慢只能宣布灭亡。
尤其是创业型的公司，为了快，直接从需求跳到开发，没有架构规划，也没有架构设计。这样的系统，就等于一栋没有打地基的建筑物，其风险自不用说。架构就是软件系统的地基。有一句话说得好，“基础不牢，地动山摇”。
五、结尾
干货里的东西其实蛮枯燥，但是还请大家细细的看一下，毕竟是管理、想问题的一些总结经验之谈。这是本人的第一篇文章，写的乱糟糟的，但是我确实是用心写下了这一万字的文章，对于我来说又是个全新的考验。下一篇我准备着重写一些管理的技巧，还有区块链的一些技术革新的细节、sharding的一些知识我也会慢慢的写成文章给大家阅读。