- 01.复杂业务写技术方案
- 02.经常回顾并输出
- 03.持续架构演进优化
- 04.高级工程师自问
- 不要上手就写代码。永远不要上手就写代码。这句话我们从小就听——不要上手就写作文，先想好提纲。编程也是如此，除非胸有成竹，否则绝不一码十行。
- 当我们拿到一个需求进行开发的时候，一定要先在大脑中推敲推敲，这个需求的每个方面是否都是完备的，是否有异常流程，这个需求的每个技术点有哪些。
- 这个需求的流程，我是否完全都清楚了，这些东西都想不好，那就不是在编程，而是在写bug，很可能会把后面的开发者「淹没」，造成一场信任危机。
- 遇到难题首先是自己尝试去解决，如果请教别人，学习别人解决问题的思路而非拘泥于解决办法。
- 遇到难点，卡在什么地方？从哪方面着手去解决，方案对比总结？别人解决思路是什么？写技术方案，要从大到小，整体设计思路是什么，核心流程，具体实现步骤等。
- 拥有自己开源或者长期维护并且不断改进的项目。尝试重构自己项目，或者看过去的代码，与今日有何区别，改进再改进。
- 不要太过于浮躁。很多人最喜欢抱怨的就是：“我每天都是在做重复的CRUD工作啊！没啥意思。”、“这个公司的项目不行，没用到某某高大上的技术”......
- 做一个项目，做完了之后就感觉自己就和这个项目没有关系了。项目上学到的一些东西或者可以改进的地方，完全不想花时间总结。以至于，很多年之后，学到的东西还是比较零散的，不成体系。
- 别人询问你“有没有从上个项目学到点什么？”的时候，自己却没法回答。不会进行思考总结，做再多的项目，了解再多的技术又如何？可能就只是表面上好看而已，有些东西永远都成为不了自己的。
- 这个项目是否有不合理的地方：该如何优化？技术上有哪些难点还没有搞清楚？是懂了还是深入理解原理？知其然也会知其所以然吗？怎样才能做的更好？
- 关于代码的思考：代码是否可以更加简单健强？是否可以复用，能否提高效率？代码稳定性是否还有待提升和优化？
- 源代码库的维护：阅读代码理解思路而非复制粘贴代码？日常项目或者开源项目能否借鉴源码好的设计模式或者思路；理清代码整体工作原理，而非拘泥于细节而无法自拔。
- 常规来看，基本就是MVC、MVP、MVVM以及组件化的东西，这些东西说是架构，但本质上就是模块化的变种，这类东西主要是做业务架构，将一个很大的业务划分为很多小业务，每个小业务就是一个模块。
- 另一部分架构内容则是技术架构，一般是分层的，最底层是基础框架，包括网络、存储、日志、图片加载等第三方库；中间层则是上层业务经过抽象后所形成的公共业务层，也可以叫做中台，这一块往往包含账号、支付、客服、地图等相对独立的业务；最上层就是核心业务了。
- 从变动性来说，基础框架变动最低，公共业务层次之，上层业务变动最高。总结来看：移动端架构 = 业务架构（模块化） + 技术架构（分层）
- 很多人（包括我）只知道要做架构设计，但不知道为什么要做，如果非要说，大家估计能总结为如下几点：
- “为了让项目看起来更有技术含量”；“大家都做架构设计，我也得做”；“提高程序性能和可扩展性，降低后续的维护成本”。
- 其实这些目标都比较抽象，不好衡量，做完架构设计后未必能达到预期。举个例子，MVP特别流行，MVP的好处就是降低耦合，降低后续维护成本，但事实上，用了MVP后，代码极度膨胀，新增了很多类，代码可读性也差，很多新人上手困难，在一大堆presenter中迷失了，大家想想，这样做维护成本是否真的降低了？
- 架构设计的目标：架构设计的目标是解决当前项目的痛点，如果当前项目没有痛点，那就先别进行架构设计了。
- 架构设计要以实用为目的，不要光想着造一个世上最牛逼的架构，这样往往是不靠谱的，我们不是救世主。总结下，架构设计有三个基本原则：
- 1、合适优于世界领先。适合自己当前业务的就好，不要总想搞世界领先的架构，比如一个用户量100万的系统，光想着对标微信的架构，那微信日活上亿，适合微信的架构未必适合自己。
- 2、简单优于复杂。如同写代码一样，代码量越少越简单越好，架构设计也是一样，越简单的架构越牛逼。
- 3、演进优于一步到位。可扩展性我们当然要考虑，但是人不是神，无论你怎么去预测未来的系统演进，总是很大可能会失算。所以架构设计优先解决当下的问题，至于后来的问题，到时候再对架构方案进行改进。
- 这三个原则也是有优先级的，具体是：合适优于先进 > 演化优于一步到位 > 简单优于复杂
- 合适也就是适应当前需要是首位的，连当前需求都满足不了谈不到其他。架构整体发展是要不断演进的，在这个大前提下，尽量追求简单，但也有该复杂的时候，就要复杂，比如生物从单细胞一直演化到如今，复杂是避免不了的。
- 程序员是吃青春饭的吗？等我们老了，技术过时了，公司有什么理由不裁掉我们，去雇一些既有活力、薪资要求又低的年轻人呢？
- 这个老生常谈的问题困扰着诸多渐入中年的程序员。会让很多人陷入了年龄感带来的危机之中。
- 作为一名程序员，编码硬实力固然很重要，但很多软技能都能成倍地增加我们的影响力，比如代码审查礼节、如何优雅地遏制项目范围蔓延、如何向其他部门直观的方式解释高技术问题、如何在生产任务爆满和日以继夜的比赛中保持镇定自若等。
- 1.你的代码的可维护性如何？你提出的系统架构可用性如何？你的方法是直观、易理解的吗？是否有其他工程师不停地轻敲你的肩膀，让你解释你代码的每一行都是如何工作的？
- 当你发现自己在复制粘贴很多行代码时，你是否能将这些代码的功能写入可重用的服务中？
- 2.别人能够从你在拉取请求中留下的评论中受益吗？你的反馈意见是有建设性的，还是太过粗糙？
- 当你发现别人的知识存在缺口时，你是只告诉他们“把这条线从 ABC 更改为 XYZ”，还是有能力引导他们认识到自己方法的缺点？
- 3.你如何将非常技术的问题分解为公司其他部门可以理解的简单语言？
- 向市场解释为什么一个功能实际上不可行时，你是否会让大量的工程术语从嘴里溜出来？
- 4.你的写作能力如何？
- 线上沟通时，你是能把自己的意思表达清楚，还是同事仍然需要走到你的办公桌旁，来询问你更多的背景信息？
- 5.你是否会主动提出想法，使你的团队效率更高？
- 当需要改动现有进程时，你是否能够向所有参与方说明收益？你能使所有人都对这一变化感到兴奋吗？你是否可以持续跟进，并确保新流程确实有效？
- 6.你尊重别人的时间吗？
- 当你请求别人帮助时，你能否准确描述你遇到问题？别人是否必须反复问你，才能从你嘴里撬出相关信息？
- 7.在与其他部门一起确定大型项目的范围时，你对要开发的新功能的问题了解得有多深入？
- 在开始编码之前，你是否能够考虑到每个边缘情况？你是否能够及早识别项目范围蔓延并尽早制止，从而使自己免于加班？
- 8.你的多任务处理能力如何？
- 你有养成扎实的记笔记习惯吗？你能安排好一段时间内工作的优先级排序吗？
- 9.领导可以放心地让你去负责面试候选人吗？
- 你是否擅长通过有限的信息来对人员进行分类，并可视化他们和团队的适合程度？
- 10.机会成本是一件必须考虑的事。你在平衡技术债务和推动业务发展方面做得如何？
- 你是否会重构发现的每个微小的编码样式问题？
- 11.你有能力扑灭生产大火吗？
- 你是否会在遇到大麻烦时惊慌、不知所措？你是会在压力之下崩溃，还是会在解决问题的同时保持镇静，并与其他部门进行有效的沟通？
- 高级开发者能在工作中有效地解决问题。他们按时完成任务，减轻公司压力。
- 他们知道如何编写经得起时间考验、可维护的代码。他们对项目的方向可以有准确的把控。
- 他们可以发现当前流程中的缺陷，并使每个人都接受他们的想法以进行改进。他们处事冷静，不会轻易情绪崩溃。
- 因此，许多企业愿意使用一些经验丰富的“老兵”，来保证业务进行顺利。那么你又是否提升了自己的价值优势？
