不止代码-阅读总结

Posted on | Edited on | In | Views:

技术快速成长

典型误区

  1. 拜大牛为师
    原因：大牛很忙(简单问题google)、大牛不多(最终你也只能提升到他的水平)，主要靠自己。
  2. 业务代码一样很牛逼
    原因：业务代码一样有技术含量，这点是肯定的，写业务代码只是这个打怪升级路上的一个挑战而已，而且是比较初级的一个挑战。
    业务代码都写不好的程序员肯定无法成为技术大牛，但只把业务代码写好的程序员也还不能成为技术大牛
  3. 上班太忙没时间自己学习
    原因：我们身边有那么多的大牛也是在中国这个加班严重环境成长起来的。首先我们应该在工作中学习和提升，因为学以致用或者有实例参考，学习的效果是最好的；其次工作后学习不需要大段时间，而是要挤出时间，利用时间碎片来学习。

正确做法

  1. Do more
    熟悉整套业务，不单单是自己负责开发的这一部分。要想有机会，首先你得从人群中冒出来，要想冒出来，你就必须做到与众不同，要做到与众不同，你就要做得更多!

  2. Do better
    你负责的系统和业务，总有不合理和可以改进的地方,只要你去想，其实总能发现可以改进的地方。

  3. Do exercise(光看不练没有用)

    • Learning
      系统化，特别是一些基础性的东西JVM 原理、Java 编程、网络编程，HTTP 协议, 最好看一本书全面了解。 再通过google、视频、博客去有针对性的查找一些有疑问的地方，或者一些技巧。

    • Trying
      尝试搭建一些模拟环境，自己写一些测试程序。

    • Teaching
      讲的时候，需要将一个知识点系统化，也需要考虑各种细节，这会促使我们进一步思考和学习。

      上面都是一些方法论的东西，但真正起决定作用的，其实还是我们对技术的热情和兴趣！

缩小能力差距

知识点浩瀚如海，如何完成真正掌握好的知识点慢慢生长，连接，最终组成一张大网至关重要。

知识+逻辑就基本等于你的能力

知识之间是可以联系起来的并且像一颗大树一样自我生长，但是当你都没理解透彻，自然没法产生联系，也就不能够自我生长了。
好的逻辑又怎么来？ 实践+复盘

知识效率: 纯看理论就能掌握好一门技能，还能举一反三。
工程效率: 大多数普通人都是看点知识，然后结合实践来强化理论，要经过反反复复才能比较好地掌握一个知识。

知识: 通用知识和特定知识
通用知识： 专业领域去到哪个公司都能通用，碰到后要非常饥渴地扑上去掌握他们。
特定知识： 肯定也是需要掌握一些的，特定知识掌握得好的，一般在公司里混得也会比较好。

如何规划自己的职业发展生涯？

大部分同学在面对这些问题时，其实是比较迷茫的，也缺少真正可度量的衡量标准。是否能在短期内获得晋升成了大部分人作为“组织是否认可、自己是否认可”的衡量标准了。

第一阶段：大学毕业3到5年

毕业后的3到5年内主要都是以学习、积累为主，快速地完成这些基础知识的学习，并能在项目中快速地学以致用。大部分人的实际发展轨迹看，这个阶段发展快的人和正常发展速度的人，差别还不是很大。正常发展速度的同学也仅仅比发展速度快的人慢2-3 年而已。

这个阶段，我们能协调好的资源其实就是自己，更多的是一个“个人贡献者”，只要把自己管好了，学习计划执行好了，工作高质量做好了就能得到认可。

第二阶段：大学毕业5到10年

网上广泛讨论的所谓34+ 岁现象。其实，年龄并不是问题的真正原因。真正的原因还是在于自身“竞争力”是否符合这个年龄所应该具备的。到了这个年龄的人，往往已经不是“个人贡献者”了，而是“团队贡献者”

一个管理团队的人，他必须为业务的成功负责。

  1. 能对所负责领域的业务特点、发展趋势、友商竞争分析有很好的洞察？
  2. 服务于特定领域的客户，我们需要能了解我们的客户企业架构、业务知识。
  3. 作为 TL， 是否有必要能将自己对于市场的洞察转换成业务规划，并能向自己的老板（或者投资人）说清楚、讲明白？并争取到老板的同意，包括资金、人力资源等。
  4. 获得老板支持后，就需要开始带着兄弟们干活了。作为带头人，你看我们是否需要能将业务趋势、客户痛点进行业务建模好让团队的PD、技术都能理解？
  5. 做完业务设计后，开始要带着团队做技术方案设计、接口设计以及编码实现等。
  6. 对于一些有国际化要求的公司，还需要再学习英语吧！
  7. 还需要有个好的身体，还需要经常锻炼，学习科学的健身吧，越是忙的时候，越需要锻炼身体！
  8. 你可能会遇到这些困难
    与挑战：团队磨合的挑战、技术方案上的争执、平台优先 or 业务优先的博弈、低落的团队氛围、个人的低谷等等。

作为一个团队贡献者，你可能需要具备这些能力，更可悲的时，当毕业10 年后，突然发现自己不具备这个能力时（比如晋升失败时发现了），所以从现在开始给自己制定一个严格的学习计划、严格执行，多实践吧！

技术变化快，如何不被淘汰

写了这么多年的代码，你是否曾经有过这样的迷茫和困惑——技术发展日新月异，奋力追赶的我们，究竟是技术的主人还是技术的奴隶？

人之所以迷茫往往是找不到工作生活的重心，感受不到工作或生活的价值，价值？说的大一点就是我改变了世界，说的小一点就是我的所作所为改善了某些问题。程序员的迷茫面、对技术繁杂的无力感，无法看清从业务到软件架构的价值链条，无法清楚定位自己在分工体系的位置，处理不好自身与技术、业务的关系,很多程序员打心底不喜欢业务，宁愿从事框架工具、技术组件研究的相关事情，阉割了自己能够发现业务价值的能力，而过多关注新技术对职场竞争力的价值。这也就是我们面对繁杂技术，而产生技术学习焦虑症的根本原因。

  1. 业务：指某种有目的的工作或工作项目，业务的目的就是解决人类社会与吃喝住行息息相关的领域问题，赢利点。

  2. 技术: 解决问题的工具和手段。

  3. 软件系统：支撑业务功能、提供服务能力。

反思自己的工作学习是否切实在解决领域的业务问题。

很多面试的候选人在被问及他所开发的系统采用什么架构的问题时，只会罗列出一些技术组件、技术框架等技术要素，这样看来其根本没有理清架构的深层含义。也有一些架构师只专注对底层技术的研究，以为打造一个卓越的系统是非常牛逼的事情，可是他忽略了软件系统的价值是以解决业务问题的能力、支撑业务增长的能力为衡量标准，所以最后生产出了很多对组织，对业务没有帮助的系统。

成本与收益

基于成本与收益的关系去思考自己每一项技能的价值，学习新的有价值的技能，甚至在工作中基于成本与收益的考量选择合适的技术。逻辑不大发生变化的地方，没有必要去做过多的设计，应用各种花俏的设计模式等浪费时间。这样我们才能成为技术的主人。

架构目标需要适应业务的发展

一定要让架构适应当前业务目标，不要过度设计，要审时度势，否则浪费资源，增加成本，合适最重要。

分工

程序员的迷茫因为长期埋没于软件世界的浩大的分工体系中，每个人都只站在自己的立场。我们不能只关注着做为流水工人的价值要求，看不到生态链最顶端的价值。职位越高的人关注的价值也就越高。

从价值出发－找寻学习与工作的新思路

  1. 明确自身的业务相关主体。
  2. 向前一步，为更大的价值负责。
  3. 像架构师一样思考，用价值找寻重心。
  4. 学会连接，构建体系。

如何在阿里技术面试中脱颖而出？

招什么样的人？

  1. 技能： 工作项目经验，以及解决疑难问题的能力，这是最基本的要求，是很好的完成，不是仅仅完成。

  2. 潜力： 对计算机相关的专业的知识体系是不是完整，，基础是不是扎实，平常是不是喜欢钻研，这几年走下来，沉淀的速度如何。过去的优秀经历才能给未来背书。

  3. 软实力： 包含了性格，执行力，领导力等方方面面，它代表了候选人是否能快速融入团队，拿到结果，带领团队攻城拔寨，激励和影响身边的人变得更加优秀等等。 你招的人是不是比团队中同一等级中50% 的同学优秀。

面试的方法

  • 不要问知道性的问题比如问知不知道这个 API 干什么的，怎么调用，这个命令怎么用的，知道性的知识，google一下或者认真看下文档就应该知道。

  • 不要问一些特别复杂的问题比如问一个特别复杂的算法，问一个很抽象的大问题，短时间内很难给予回答。

  • 不要问一些假设性的问题假设你参与了这个项目，你觉得哪几个地方需要优化。

不要在面试中试图证明别人不如自己，毫无意义，人无完人，总有覆盖不到的地方

  • 应该问已经发生的事，看工作中积累是什么，有多深。

  • 应该问解决问题的思路。

  • 应该少问多听因为大家的知识体系不太一样，成长环境也不同，直接这么问起来很难就找到面试者的优点，所以尽量让应试者自己陈述，然后以学习和交流的心态针对陈述中存疑的地方再进行发问，会更容易让应试者放松，也更容易让应试者更全面的表达自己。

STAR 原则

处境： 在什么样的环境下。

任务: 接到了什么任务。

行动: 具体怎么落地。

结果: 拿到了什么结果。

假的STAR回答

  • 描述含糊不清：

    效果好是哪里好，有什么度量的标准？一致好评的体现是在具体KPI 还是比如团队有个什么奖励之类的。

  • 只表达态度和看法：

    我觉得线上稳定性非常重要，应该重点解决和持续跟进。没有后面具体解决方案，很难让人令人信服。

  • 假设式描述：

    如果我来做这件事情，我会1234 怎么怎么样。如果只是看思路还好，但是如果说的天花乱坠，这个时候要 警惕了，毕竟说和做之前的差异是很大的。

鉴别方式

  • 更多的关心What/How/Why

    做了什么事情，具体做的方案1234 几步，为什么要这么做, 最早肯定什么都没, 每个阶段不太一样，关注的重点也不一样，刨根问题问一问，会了解是不是真的做过这件事情。

  • 细节！细节！细节！

    很多关键节点的细节很重要，比如网络库的优化。选择依据是什么？当时遇到了什么其他的坑没有？你自己的做法有什么缺陷？

其他Tips

  • 你在面试别人，别人也在选择你
  • 为未来招聘而不是现在
  • 面试是一面镜子

技术人如何不断成长？

如果现在是我们去找工作，这个市场或者团队更需要什么样的人？

到底要成为什么样的人? 跟你的职业规划很有关系, 大公司，偏向一专多能的T型人才 , 小公司：更喜欢全栈。是想在大公司成就一番事业，还是出去闯荡，你点的技能树肯定是不一样的。

  • 经验丰富，知识体系完整。

    经验能解决实际的问题，另外知识体系可以让你在遇到新的问题时举一反三。
  • 保持良好的习惯，不忘总结和提升。

    既然我每次面试别人都问你最近有研究什么新的技术或者看到什么有趣的文章没有的，那我自己是不是能这样要求自己呢？不积跬步无以至千里，贵在坚持积累。

使用开源项目的正确姿势，血和泪的总结

DRY，Don’t repeat yourself(不要重复造轮子)

开源项目主要目的是共享，其实就是为了让大家不要重复造轮子，尤其是在互联网这样一个快速发展的领域，速度就是生命，引入开源项目，可以节省大量的人力和时间，大大加快业务的发展速度，何乐而不为呢？

虽然DRY 原则摆在那里，但实际上开源项目反而是最不遵守DRY原则。相似的轮子很多！相似轮子太多，选择就是让人头疼的问题了。不要重复发明轮子，但要找到合适的轮子！，你开的是保时捷，可别找个拖拉机的轮子。

选：如何选择一个开源项目？

  1. 聚焦是否满足业务？

    我们的经验是聚焦于是否满足业务，而不需要过于关注开源方案是否牛逼。

    简单来说：如果你的业务要求1000 TPS，那么一个20000TPS 和50000TPS的方案是没有区别的。有的人可能会担心我TPS不断上涨怎么办？其实不用担心，我们的架构会不断演进的，等到真的需要这么高的时候我们再来架构重构，记住：不要过早优化，过早优化是万恶之源 ——《 UNIX 编程哲学》

  2. 聚焦是否成熟

    千万不要以为作者牛逼就没有bug，Windows、Linux、MySQL 的开发者都是顶级的开发者吧，一样很多bug。不成熟的开源项目应用到生产环境，风险极大。轻则宕机，重则宕机后重启都恢复不了，更严重的是数据丢失都找不回了。

    可以从以下几个方面考察是否成熟：

    • 版本号：一般建议除非特殊情况，否则不要选0.X 版本的，至少选1.X 版本的，版本号越高越好。
    • 使用的公司数量：一般开源项目都会把采用了自己项目的公司列在主页上，公司越大越好，数量越多越好。
    • 社区活跃度：看看社区是否活跃，发帖数、回复数、问题处理速度等。

  3. 聚焦运维能力

    • 开源方案日志是否齐全：有的开源方案日志只有寥寥启动停止几行，出了问题根本无法排查。
    • 开源方案是否有命令行、管理控制台等维护工具，能够看到系统运行时的情况。
    • 开源方案是否有故障检测和恢复的能力，例如告警、倒换等。

如何使用开源方案？

  1. 深入研究，仔细测试

    很多人用开源项目，其实是完完全全的“拿来主义”，看了几个Demo，把程序跑起来就开始部署到线上应用，这样是不对的。

    可以从如下几方面进行研究和测试：

    • 通读开源项目的设计文档或者白皮书，了解其设计原理
    • 核对每个配置项的作用和影响，识别出关键配置项
    • 进行多种场景的性能测试
    • 进行压力测试，连续跑几天，观察cpu、内存、磁盘io 等指标波动
    • 进行故障测试：kill，断电、拔网线、重启100 次以上、倒换等

  2. 小心应用，灰度发布

    即使你的研究再深入，测试再仔细，也还是要小心为妙，因为再怎么深入的研究，再怎么仔细的测试，都只能降低风险，但不可
    能完全覆盖所有线上场景。

  3. 做好应急，以防万一

    即使我们前面的工作做得非常完善和充分，尤其是刚开始使用一个开源项目，运气不好的话就可能遇到一个之前全世界的使用者从来没遇到的bug。

    对于重要的业务或者数据，使用开源项目时，最好有另外一个比较成熟的方案做备份，尤其是数据存储。例如：如果要用MongoDB 或者Redis，可以用MySQL 做备份存储。这样做虽然复杂度和成本高一些，但关键时刻能够救命！

改：如何基于开源项目做二次开发？

  1. 保持纯洁，加以包装

    当我们发现开源项目有的地方不满足我们的需求的时候，自然会有一种去改改的冲动，但是怎么改是个大学问。

    一种方式是投入几个人从内到外全部改一遍，将其改
    造成完全符合我们业务需求。

    • 投入太大，一般来说，redis 这种级别的开源方案，真要自己改，至少要投入2个人，搞个1个月以上。

    • 失去了跟随原方案演进的能力：改的太多的话，即使原有开源项目继续演进，我们也无法合并了，因为差异太大。

    • 建议是不要改动原系统，而是要开发辅助系统*: 监控，报警，负载均衡，管理等。

      如果实在想改到原有系统，建议是直接给开源项目提需求或者bug
      但弊端就是响应比较缓慢，这个就要看业务紧急程度了，如果实在太急那就只能自己改了，不过不是太急，建议做好备份或者应急手段即可。

  2. 发明你要的轮子

    这点估计让很多人大跌眼镜，怎么讲了半天，最后又回到了“重复发明你要的轮子”呢？
    核心还是一个成本和收益的问题，最主要的问题是：没有完全适合你的轮子！

如何成为一名顶尖的阿里架构师

在技术圈，架构师一方面是已经被说烂的职务。

两种架构师

  1. 兼职架构师

    工作五年以上的童鞋，在小团队或者项目中承担非明确的架构师职责，我们做项目或者产品的关键设计和实施；负责产品基础设施；引入新的理念，框架；解决团队中的复杂问题；在团队成员中享有较高的声誉。

    只有在小部分时间承担了架构师的部分角色。做的绝大部分事情是自己可控的，自己做架构自己做实施或者在小团队中推行。

  2. 专职架构师

    他们不负责具体的业务系统，而又对所有的系统负责， 他们也很少直接负责项目，但是职责却要求他们必须对项目要有提前把控，他们面对的是更大的团队，更大的问题域。

专职架构师的职责

微软对架构师有一个分类：

  • 企业架构师EA(Enterprise Architect)
  • 基础结构架构师IA(Infrastructure Architect)
  • 特定技术架构TSA(Technology-Specific Architect)
  • 解决方案架构师SA (Solution Architect)

“兼职架构师”可能偏重SA ？专职架构师偏向IA+TSA

  1. 职责一：全局的技术规划

    • 架构师最重要的产出是架构，架构就是蓝图，就是阿里常说的一张图。

    • 另外一个重点是全局。全局我的理解是全面+ 格局，全面就是你的技术规划包含各个方面的，在所有的领域都有明确的指引，所以这张图本质是一系列的图的集合；格局上不要只关注短期利益，更多关注长期利益。

  2. 职责二：统一的方法& 规范& 机制

  3. 职责三：完备的基础构建

    础构建的完备程度决定你的团队装备是小米+步枪，还是飞机+ 大炮。完备的基础构建是否全部作为实际架构的职责，可以因情况而定，比如是否有实体的架构组。但是架构对此应当负责。

  4. 职责四：落地的规划才是架构

专职架构师的权利

有人从“架构师的权利和职责”的角度出发推论谁合适做架构师。得出的结论是一个组织的领导者。因为只有他才能调动、协调组织。也有人认为架构师既不能完全负责技术团队，也不能完全游离在技术团队之外。因为负责容易屁股决定脑袋，游离就只能靠个人声望值吃饭了。

专职架构师的考核

实施的一些想法

  • 建立“架构语言”

    有了语言才有沟通协作的基础，所谓的“架构语言”并不是什么新的东西，而是产品的业务架构，用例和领域模型；研发的应用架构，组件和时序图； 运维的部署架构等等。

  • 是建立“认同体”

    无论是通过技术能力、知识传递、领域组织等各种方式
    逐渐形成“认同体”，且在其中形成架构体系对应的人员体系。

  • 永远做服务者

    架构师对应的客户是团队的每一个成员，必须始终保持客户
    第一的心态。架构师存在的目的是成就研发团队每一个同学，我们提供必要的平台、服务和空间，然后彼此成就。

从无到有的是架构；从表到里的是抽象；从粗到细的是设计。

哪些技术好书值得一读再读？这有一份经典书单

喜爱读书，就等于把生活中寂寞无聊的时光换成巨大享受的时刻。有了书，各个领域的智慧，几乎触手可及。我们能有幸站在前辈、巨人的肩膀上，看更远的风景。

  • Effective Software Testing

    对自动化和持续集成的方案研究比较深入，能直面自动化和持续基础现阶段的一些问题，将软件测试的周期提前到需求，设计和开发的阶段。

  • 程序员修炼之道- 从小工到专家

    阐述方法论的书，关于程序员的自我修养，解决问题的方式、态度和哲学，是向高级程序员和专家进阶的思想启蒙书。

  • 设计模式之禅

    对于设计模式，它能够指导我们编写出可维护性好、可扩展性强的代码。

    1. 第一级是杨铁心：即只知道所有设计模式的概念和定义；
    2. 第二级是丘处机，能够写出相关设计模式的demo；
    3. 第三级是梅超风，能够在现实中找出各个设计模式的原型；
    4. 第四级是郭靖，能够在系统中抽象出来设计模式，并且合适地使用，有效隔离变化点。
    5. 第五级是扫地僧，完全忘记设计模式，但写出来都是设计模式。

  • Spoken Language Processing: A Guide to
    Theory, Algorithm and System Development

  • 机器学习导论

    一本很好的机器学习入门级教程，非常适用于高年级的本科生、
    研究生等同学学习机器学习领域的知识。

  • 《Reinforcement Learning: An Introduction》

    本书是强化学习领域的最经典书籍，它既是初学者打好强化学习基础的必读著作，也是强化学习研究者们需要温故而知新的强化学习宝典。

  • Programming Rust

  • Machine Learning: A Probabilistic Perspective

  • Architecture of a Database System

阿里技术大牛最爱的“闲书”，你看过多少？

工作很忙，效率很重要。以下书籍或许能帮助你提高时间利用率，突破事业瓶颈，打开另一番天地。

  • 从优秀到卓越

    优秀或许不难，但是做到卓越，除了能力外更重要的是意志和胸怀，乐观且皮实，聪明而自省。

  • 为什么精英都是时间控

    在阿里，人人都聪明；在阿里，人人都努力！那么，在一群又聪明又努力的人当中， 大家拼的是什么？效率！谁能把24 小时用出48 小时的效率？你应该如何分配一天的时间？什么时间应该高速工作？什么时间又应该安心休息？当专注力下降的时候，如何一键修复？每天高强度的工作，你是不是经常会感觉疲倦和体力不支？

  • 创新者的窘境

    从另外一个角度去审视企业的创新，当一个企业价值网络形成后，对整个组织不同阶层的员工都会产生一定的影响，特别是非高层员工他们会依据自己的理解来决定资源的分配，如何在企业中保持破坏性创新的体系是一个值得思考的问题。

  • 魔鬼经济学

    给你一个非常不同的视角和思考方式看待世界和身边的人。

  • 孙子兵法

    这本书在讲的是战略，而且解释的最通透，最精炼，如果只推荐一本书，我觉得还是这本吧，从道，天，地，将，法的角度来观察战略与兵势，是古今中外通用的道理，这本书属于读一本书可以代表一百本书的典范。

  • 创造自然

  • 浮生六记

    读《浮生六记》，原是冲着“中国文人心目中最完美的女人”去的。
    读完之后，对芸的观感一般，却对作者由衷倾佩。

原书链接：不止代码

转载请注明出处：http://www.wolfnx.com/2019/05/12/Codelife

作者 : wolfnx
邮箱 : wolfnx@outlook.com
邮箱2 : lostnx@gmail.com

Click Me