精华内容
下载资源
问答
  • 来源|阿里巴巴云原生公众号 经常去 GitHub 看 trending 开源项目源码,明明都看得懂,为什么感觉对技术提升不明显? B 站热门教程都了,极客时间也氪金了,听的时候觉得头头是道,到自己写的时候却写不出来? ...

    来源|阿里巴巴云原生公众号

    • 经常去 GitHub 看 trending 开源项目源码,明明都看得懂,为什么感觉对技术提升不明显?

    • B 站热门教程都学了,极客时间也氪金了,听的时候觉得头头是道,到自己写的时候却写不出来?

    这大概就是传说中的“听过很多道理,却依然写不好代码”。知行不能合一,一直以来都是技术人成长过程中的通病

    阿里云资深技术专家儒枭曾经在内网发布过一篇技术人成长的文章 -《我看技术人的成长路径》,受到了数万阿里人的认可,他总结了技术人成长的 721 原则:70% 做中学,20% 向他人学习,10% 自学。但大部分技术人的学习似乎都倒过来 follow 了 127 原则。即便是知道“在做中学(Learning by doing)”的重要性,但面对像 K8s 这样有着陡峭的学习曲线和复杂的环境搭建的新技术,对绝大部分开发者来说都是在线劝退

    阿里云知行动手实验室正式开放公测

    1.gif

    在 2020 年 12 月 16 日,云原生生态大会上,etcd 作者、CNCF 技术监督委员会委员、阿里云资深技术专家李响正式发布了阿里云知行动手实验室 start.aliyun.com

    它解决了开发者学习新技术最后一公里的问题,开发者可以在浏览器中直接利用阿里云提供真实环境来学习新技术。和传统的学习方式比有以下优势:

    • 沉浸式、可交互学习体验

    知行动手实验室集代码、shell 命令行、文档三个窗口于一个浏览器页面,通过鼠标点击即可完成命令执行、代码修改等操作,无需打开 N 个窗口、来回复制粘贴。

    2.gif

    • 免费云资源

    实验室以及使用到的各种云资源都是免费的,无需担心任何费用的问题。单个实验环境可以免费使用一小时,实验结束后资源自动释放。

    • 零门槛应用创建

    知行动手实验室直接屏蔽了环境准备的复杂性,让开发者可以专注于学习、预研新技术新产品本身。点击鼠标,参与实验才是最佳的打开方式。

    目前支持的实验场景

    公测期间,知行动手实验室以 Spring Cloud Alibaba 实现的微服务场景为主,提供了较完整的微服务实验。主要包括了:Nacos Config 分布式配置、Nacos Discovery 服务注册&发现、Dubbo Spring Cloud 分布式调用,以及Sentinel 限流熔断、Seata 分布式事务、RocketMQ 消息等。基本涵盖了微服务开发的主要模块。

    3.png

    后续计划

    后续,我们会继续丰富知行动手实验室支持的实验场景,主要包括主流开源项目以及热门云服务体验实验。

    • 在微服务领域,除了将支持 Dubbo 这样主流的微服务框,我们会深入微服务内部,支持微服务架构核心模式的周边,包括测试、部署、集成、调试等实验场景。

    • 在容器调度领域,将支持 Kubernetes 相关的实验场景。

    • 在 AI 领域,将支持 Flink 等热门开源项目的实验场景。

    未来我们还会开放自定义实验接入功能,让广大开发者可以将自己的场景放到知行动手实验室来。

    立即体验

    欢迎登陆 start.aliyun.com ,一起在实践中精进。

    展开全文
  • 来源|阿里巴巴云原生公众号 导读:数据结构、算法、设计模式被认为程序员必修的三大内功,你对设计模式有什么理解?你是什么时候意识到自己需要好好学习设计模式的?本文将分享作者多年编程道路上的一些思考和...

    yeshi-kangrang-P-2CxtQvUQY-unsplash.jpg

    作者 | 杨长元
    来源|阿里巴巴云原生公众号

    导读:数据结构、算法、设计模式被认为是程序员必修的三大内功,你对设计模式有什么理解?你是什么时候意识到自己需要好好学习设计模式的?本文将分享作者多年编程道路上的一些思考和心得,以及对如何提升设计能力的几点建议。

    当我做完设计相关的培训分享过后,有同学来问我:如何才能快速提升自己的设计能力?我觉得这个问题非常有代表性,代表了一大波程序猿在艰辛的修炼路上的心声。现将我对这个问题的思考、心得体会分享出来,供大家参考,也欢迎提出不同的意见与看法,共同探讨。

    编码历练

    代码行经验是个非常重要的东西,当你还没有 1 万行代码经验的时候,你来问如何提升设计能力的问题,我只能告诉你不要太纠结,理论看看就好,老老实实写代码吧。

    据说,一个程序员平均每天码代码的速度是 200~300 行,你可能会说,我一天怎么也要写上 1000 行吧,别忘了,当你码完代码后,你还需要测试、调试、优化、BUG Fix,这些时间你没法一直码代码的。

    编码规范就不多说了,如果你的代码还是杂乱无章的状态,就先别谈什么设计与架构了,我会觉得有点扯淡。

    另外,作为代码洁癖患者,推荐大家不要把代码写完后,批量格式化处理,或者手工再去整理代码,而是每敲一个字符上去,它都是符合规范的。习惯真的很重要,有时在招聘面试的时候,我真想添加一个环节,现场编写程序完成一个简单但容易出错的任务。

    理论学习

    简单说就是看书,看博客,你所能得到的资源,质量高的就行。例如:《重构 - 改善既有代码的设计》、《敏捷软件开发:原则、模式与实践》、《UML 和模式应用》、“面向对象设计原则”(五大原则)、《设计模式》等。

    《设计模式》这本书是很古老的一本书了,只有短短 200 页,但是,这是最难看懂的一本书,一个月都可能看不完(看小说的话,200 页 3 个小时也许就看完了吧),而且就算看完了,也不会全看懂,很可能看懂不超过 30%。看不懂没关系,看了就行,不用太纠结,这不能说明什么问题。

    另外,我想说一下,多线程技术是程序员必须掌握的,而且需要理解透彻,现在的高级技术例如 GCD,会掩盖你对多线程理解不足的问题,因为使用实在太简单了。别说你没写过多线程依然完成了复杂的项目,更别说你随手写出的多线程代码好像也没出什么问题啊,把你的代码给我,我写个 Demo 让它出错乃至崩溃,如果我做不到,恭喜你。

    实践

    现在,你已经具备了一定的编码经验,而且已经学习了足够的理论知识,接下来就是真正练手的时候了。好好反复思考你学习的这些理论知识,要如何运用到项目中去,身体力行的去实践,一定要把那些理论搞清楚,用于指导你的实践,收起从前的自信,首先否定自己以前的做法,保证每次做出的东西相比以前是有进步有改进的。

    重温理论

    你已经能看到自己的进步了,发现比以前做的更好了,但是总感觉还不够,好像有瓶颈似的,恭喜你,我已经能看到你未来的潜力了。

    重新拿起书本,重温一遍之前看的似懂非懂的东西,你会发现之前没弄懂的东西,现在豁然开朗了,不再是那种难于理解的晦涩感了。就算是以前你觉得已经弄懂的,也再看一遍,通常会有新的收获。

    再实践

    这个阶段,你已经掌握了较多的东西了,不但实践经验丰富,各种理论也能手到擒来了,但是你发现你的设计依然不够专业。而且你回过头去看你以前写的代码,你会惊讶:天啊,这是谁写的代码,怎么能这样干!然后。。。我就不多说了,你已经进入了自省的阶段,掌握了适合自己的学习方法,再要学习什么新东西,都不再是个事。

    总结

    先别太得意(不信?那你去做一堂讲座看看),你需要总结了,总结自己的学习方法,总结项目经验,总结设计理论知识。

    如果你能有自己独到的理解,而不是停留在只会使用成熟的设计模式什么的,能根据自己的经验教训总结一些设计原则出来,那自然是极好的。

    分享

    分享是最好的学习催化剂,当你要准备一场培训分享的时候,你会发现你先前以为已经理解的东西其实并没有真正理解透彻,因为你无法把它讲清楚,实际上就是研究不够,这时会迫使你去重新深入学习,融汇贯通,然后你才敢走上讲台。否则当别人提问的时候,你根本回答不上来。

    以上,便是我认为的程序员修炼道路的必经阶段。

    然后,我再说说其他对提升非常重要的几点:

    1. 养成先设计,再编码的习惯

    几乎所有的程序员,一开始都不太愿意写文档,也不太愿意去精心设计,拿到需求总是忍不住那双躁动的手,总觉得敲在键盘上,一行一行的代码飙出来,才有成就感,才是正确的工作姿势。

    没讨论清楚不要编码,不然你一定会返工。

    2. 设计重于编码,接口重于实现

    制定接口的过程,本身就是设计过程,接口一定要反复推敲,尽量做减法而不是加法,在能满足需求的情况下越简单越好。

    另外,不要一个人冥思苦想,先简单做一个雏形出来,然后拿去找使用方沟通,直到对方满意为止。
    不要完全根据使用需求去设计接口,参考 MVVM,ViewModel 就是根据 View 的需要而对 Model 进行的再封装,不能将这些接口直接设计到 Model 中。

    3. 不盲从设计模式

    设计模式只是一种解决问题的套路方法,你也可以有自己的方法,当然设计模式如果用好了,会让你的设计显得专业与优雅,毕竟前辈们的心血结晶。但是滥用的话,也会导致更严重的问题,甚至可能成为灾难。个人觉得面向对象设计原则更加重要,有些原则是必须遵守的(如单向依赖、SRP 等),而设计模式本身都是遵守这些原则的,有些模式就是为了遵循某原则而设计出来的。

    抽象不是万能的,在适当的地方使用,需要仔细推敲。当有更好的方案不用抽象就能解决问题时,尽量避免抽象,笔者见过太多的抽象过火过度设计的案例了,增加了太多维护成本,还不如按照最自然的方式去写。

    4. 空杯心态,向身边的同学学习,站在巨人的肩上,站在别人的肩上

    有人提意见,先收下它(无论接受与否)。

    很多程序猿,也都有一个毛病,就是觉得自己技术牛的不行,不愿意接受别人的意见,尤其是否定意见(文人相轻)。

    而无论是理论的学习,还是编码实践,向身边的同学学习将是对自己影响最大的(三人行,必有我师),比刻意参加相关培训要有用的多。

    我自己就经常在跟团队同学的讨论中获益,当百思不得解的时候,把问题抛出来讨论一下,通常都能得到一个最佳方案。

    另外,跟团队其他人讨论还有一个好处,就是当你的设计有妥协,有些不专业的时候,别人看到代码也不会产生质疑,因为他参与了讨论的,你不用花那么多时间去做解释。

    设计期间就一定要找他人讨论,我一直比较反对一个人把设计做完了,把文档写完了,然后才找大家开个评审会那种模式,虽然也有效果,但是效果真的达不到极致,大家没有参与到设计中来,通过一场会议的时间理解不一定有那么深,最关键的是,如果设计有些问题的时候,但也不是致命问题,难道还让打回重新设计么?

    等前期讨论足够后,大家都知道你的思路与方案,而且最后也有设计文档,当其他人来阅读你的代码的时候,根本无需你再指引,今后的工作交接都不是很需要了,何乐而不为呢?

    最后,我想在此呼吁一下,当你去修改维护别人的代码时,最好找模块负责人做深入的讨论沟通,让他明白你的需求以及你的方案,请他帮忙评估方案是否可行,是否会踩坑、埋坑等。这样我们的项目才不会出现坏味道蔓延,而如果你恰好是某模块负责人,请行使你的权力,拒绝有问题的不符合要求的代码提交入库。

    大家共勉。

    展开全文
  • 枸杞的由来和技术栈

    2021-01-02 15:11:32
    而这些功能如果不熟悉原生开发完全没办法解决的。 对于 React Native 视图层的社区也并没有好到哪里去。目前带有测试并且仍然在良好维护的库屈指可数。你甚至仍然能找到一个 1k star 但是把临时变量也放在 <code>...

空空如也

空空如也

1 2 3
收藏数 52
精华内容 20
关键字:

云原生学出来是做什么的