保存成功
订阅成功
保存失败,请重试
提交成功
IT老兵哥

IT老兵哥

架构专家/培训讲师
程序老兵 | 架构专家 | 培训讲师,个人站点:www.laobingge.com...更多
创作文章20

程序员“求包养”攻略揭秘

程序员,不仅要干得好,还要嫁得好!哪怎样才能嫁入豪门,找到如意好工作呢? 方向比速度更重要:2003 年前后,BAT 还都是名不见经传的创业公司,虽然国外有 Google、eBay、ICQ 等探路先锋,但彼时这些公司的商业模式尚未成型,业态超前却不被看好。因此,在老兵哥研究生毕业时,我们大多数同学都加盟了传统 IT 领域的头部企业,只有少数同学选择了 BAT。但短短十来年,IT 行业发生了翻天覆地的变化,当初的抉择对人生产生了极大的影响,那些在 BAT 坚持下来的同学获得了超预期的物质回报,在公司飞速发展的过程中还获得了更多的成长机会和空间,得以站上更高的舞台,看见更大的世界。 选择比努力更重要:错过了 BAT,是否就错过了全世界呢?实则不然,BAT 的发展势头依然很猛,我身边就有朋友死磕 BAT,兜兜转转在 A、T 之间跳了好多次,不折不挠,终于拿到了梦寐以求的期权。除了 BAT,这些年还出现了京东、头条、美团和滴滴等独角兽企业,甚至在普遍认为没有机会的领域又杀出了小米、拼多多等巨无霸。另外,随着云计算、大数据、人工智能、区块链、金融科技、5G 和物联网等风口的涌现,各个领域都诞生了许多优质企业。因此,我们程序员最不缺少机会,缺的是甄别机会并抓住它的能力。 顺势者昌,在滚滚向前、不可抵挡的趋势面前,个体力量很渺小。当然,个人奋斗也很重要,否则连选择的机会都没有。但你我都很容易掉进“用战术上的勤奋掩盖战略上的懒惰”这个陷阱,只知埋头赶路,很少抬头看天,从不曾学习如何做选择。其实,任何选择都存在风险,都有选错的可能,你我能做的就是从一次次选择中积累经验方法,不断降低选错的概率。活少、钱多、离家近,这或许是我们大多数人对好工作的定义,但单凭这些真能筛选出好工作吗?投递简历时,你是漫无目的地被选择,还是锁定目标主动出击?有多份 Offer 可选时,你是完全听从家人朋友的意见,还是有办法选出最适合的?工作遇到了瓶颈挑战,或面对外部诱惑,或遭遇公司动荡期,你到底要不要跳槽? 结合个人和朋友真实经历,以及多位读者小伙伴的咨询案例,老兵哥我从行业领域、资方类型、股权结构、公司规模、业务类型、长短收益等维度梳理出了工作筛选标准。如果你对此话题感兴趣,或正困惑于下列问题,那赶快来听一听老兵哥给你的独家建议吧! * 扎根某个行业,还是跳槽到热门的行业? * 跨行业跳槽时,怎样包装自己的优势呢? * 国企\民营\外资,哪种风格更加适合我? * 加盟创业公司,为什么要留意股权结构? * 大、小公司,你能告诉我该怎么选择吗? * 2C\2B,商业模式跟找工作有什么关系? * 股票期权跟落袋为安的工资,哪个更香? * ......
个人提升
94 订阅

性能调优,你转型架构师途中的拦路虎

2003 ~ 2008 年,这五年老兵哥我在通信行业做实习生和开发岗,主要用 C / C++ / MFC 开发嵌入式 / 服务器 / 桌面等应用程序,期间做过大量代码重构优化,但很少涉及性能调优,要么我负责的局部无需考虑并发访问和海量数据,要么网管平台仅供客户内部人员使用,不存在并发访问和海量数据。2008 年底,老兵哥我跳槽到了移动互联网做技术经理,随后五年主要用 Java / C++ 开发 Web / 服务器等互联网应用。 当时,架构师这个岗位在业界还是很罕见的,不懂预估并发用户、业务数据等规模,自然就预见不到后续并发访问和海量数据会带来巨大的性能挑战。我们赶着工期把功能需求实现、业务流程跑通,然后就上线了,但移动互联网爆发的那些年业务增长非常快,系统上线不久就遇到性能问题了,其现象就是原来耗时很短的操作现在动不动就超时,或者界面刷不出来数据等等,巨大的压力跟着客户投诉一起摆到了我面前。 性能调优任务不像普通开发任务,它需要背负业务、时间和难度等多种压力。罗马不是一天建成的,导致性能问题的原因错综复杂,当时老兵哥我也不知道从何处下手,找不到解决问题的切入点。好性能不是调优出来的,更多是设计出来的。只有经历过性能调优,才能体会这句话的真谛。性能调优,其实就是对承载业务的现网系统做重构优化,就像是边开车边换轮胎,它所需要的技能跟代码重构完全不在一个层级上。 现在老兵哥我知道,性能是系统性问题,性能调优离不开架构视角。不识庐山真面目,只缘身在此山中。当你陷在具体的、局部的问题当中,你是无法找到解决问题的思路的。你必须从实现细节跳脱出来,从更加宏观全局的视角来梳理业务流程,就像另一篇 Chat[《图解 Spring Cloud:HTTP 请求的处理流程与机制》](https://gitbook.cn/m/mazi/activity/5d82f91c92b6fc25da79965a)的剖析过程类似,然后以业务流程为线索分析每个环节存在的性能瓶颈原因,这样你就不再困惑了。 当每个环节潜在问题梳理出来之后,根据资源、时间等外部限制,按照帕累托二八原则,你可以决定优先解决哪些问题,从而有条不紊地化解性能压力了。随着在性能调优上的经验不断丰富,你就越来越有信心掌控更大规模的系统了。更值得高兴的是,当你费老牛劲把这些自己挖的巨坑填上后,你就记得下次不要再给自己挖坑了,也就懂得怎样设计一个高性能的互联网系统了,这不就是从开发跃迁至架构的契机吗? 性能调优,是从开发岗跃迁至架构岗的拦路虎。升级思维的过程是痛苦的,尤其是在背负压力下的被动升级,跳出原先的舒适区,进入更大的舒适区,这样才能站上新平面。记得当时老兵哥我还有不少负面情绪,回顾过往才懂得要感谢当时的领导给我这份压力,逼迫我高强度学习并突破了旧的思维,机会和挑战是并存的。现在老兵哥我把这些调优经验和架构视角梳理出来供转型升级的你参考,希望帮你少走些弯路: * 性能优化的 X Y Z 三维度视角 * 从 X 维度优化业务的交互设计,包括业务规则、交互设计等 * 从 Y 维度优化系统的处理流程,包括 Web 容器、Spring、ORM、数据库等 * 从 Z 维度优化系统的技术堆栈,包括操作系统 OS、Java 虚拟机 JVM 等 * 数据访问层性能调优案例详解,包括 SQL、 Hibernate、JProfiler 等 * 性能优化当中蕴藏的架构思维 适合读者:计划转型升级的开发、测试、运维等
性能优化
127 订阅

程序员必须懂的架构入门课

程序员,真有必要了解架构吗?在解答这个疑惑之前,我们先来看一则故事: 旅行者路过某个工地,建筑工人们都在忙碌。出于好奇,旅行者问第一个人在干什么,那人头也没抬地回答道:我在搬砖。旅行者问第二个人在干什么,这个匆匆抬起头认真地说:我在砌墙。旅行者问第三个人在干什么,那个人脸上充满了光彩,很自豪地说:我在建造圣索菲亚大教堂,将福音传播给更多人! 有的人只关注眼下的“点”,有的人看到了延伸的“线”,还有人畅想出未来的“面”。就像在丛林中穿越,当你迷路找不到方向时,最好的办法就是登上山顶或者爬上树冠,让自己有更宽广的视野,从而找到通往目的地的最佳路径。既要脚踏实地、低头赶路,也要抬头望天、畅想未来,正确的方向比速度更重要! 接下来,我们再来看看架构跟你的“点、线、面”关系: 点:跟垒土坯房不同,建造摩天大楼离不开各式各样的设计图纸,我们构建复杂的应用系统也离不开架构设计。相信你所在的团队也配了架构角色,或由资深开发兼任,或由专职架构负责。不管你从事哪方面工作,包括产品、开发、测试、运维或项目等,你都要跟架构师打交道,例如:产品可研、概要设计、技术选型、详细设计、测试规划、部署规划、问题解决、招聘面试等等。如果对架构缺乏了解,那你就不清楚你跟架构师之间的协作界面,不知道架构师能给你提供哪些支持或帮助,不知道如何跟架构师高效地协作。如果只关心自己眼前的一亩三分地,那你很容易就滞留在“搬砖”层级。 线:中年危机,35 岁定律,这些命题对于你来说都是客观存在的。随着 IT 技术的不断更新换代,普通程序员在市场上竞争力跟年龄成反比,除非你能提前构建出转型升级所需的新技能树。如果沿着技术通道发展,可选的晋升方向有两个:技术专家,扎根于某个垂直的技术领域,往纵深发展;架构专家,构建出更加全面的技术体系,往广博发展。虽然进化方向不同,但殊途同归,最终你战胜危机、突破自我,晋升到更高的职位,获得了更好的薪酬。如果你的性格特质更适合往架构方向发展,那你有必要提前了解架构师的主要职责和必备技能。十年磨一剑,五年小成,十年大成,转型升级所需的专业技能不是一朝一夕就能练就的。如果你现在就主动筹备 35 岁这场战役,那你很容易从“搬砖”跃迁至“砌墙”。 面:学而优则仕,即使修炼成了技术大神,但个人能量总归是有限的,管理岗是所有通道的终极进化方向,只有带领更多人,你才能做更大的事。在互联网行业,“科技是第一生产力”体现的最为淋漓尽致,不管往产品还是管理发展,拥有深厚技术背景都是你的优势。架构师,从某种角度看,就是全面了解各种技术或中间件的优劣,然后让它们在你所设计的方案中扬长避短、优势互补,发挥出最佳的合作效用。这跟产品维度的业务架构、管理维度的组织架构有异曲同工之妙,等你从技术架构中学习到知人善任、调兵遣将、排兵布阵等道理,那你就可以站上更高的平“面”了,从“砌墙”跃迁至建造宫殿。 25 岁入行搬砖,30 岁前担任技术经理,兼职架构,35 岁前转型架构专家,一路走来,老兵哥我积累了大量开发转型架构、架构\培训\咨询等实战经验。近些年我开始整理输出,曾面向初中级程序员开设过多门面授架构课程,累计参训学员超千人,颇受好评。现在借助网络分享平台,老兵哥我把初中级程序员关注度最高的这些问题梳理出来,结合个人实战经历分享给需要的你,欢迎订阅: * 架构到底是什么?它都有什么作用? * 架构的演进过程,不同架构的特点? * 架构风格、模式、框架的相互关系? * 架构设计的输入、输出和工作流程? * 不同岗位应该关注架构的哪些方面? * 是否有标准来评价架构设计的优劣? * 架构师核心职责和必备能力有哪些? * 哪些特质适合往架构专家方向发展? * 架构专家需要搭建怎样的知识体系? * 如何从资深开发成功转型架构专家? * 架构师之后有哪些可选的发展方向? 适合读者:初中级开发、测试、运维或产品等
架构演进
417 订阅

图解 Spring Cloud:HTTP 请求的处理流程与机制

2003 年,老兵哥初到中兴开始研究生实习,Spring 就是那年诞生的,2004 年 3 月发布了 1.0 版本,到现在已经超过 15 年了。从单体式分层架构到云原生微服务架构,它稳坐在 JAVA 应用框架的头把交椅上从未被撼动,它给我们带来了巨大的价值,不仅可以降低开发难度,同时还可以提升开发效率。但时间这把杀猪刀不仅改变了老兵哥,也同样没放过 Spring,我们都变得越来越强大了。 在 Spring Boot / Spring Cloud 面世之前,它已经演进了 5 个大版本和无数小版本,功能和生态都变得越来越丰富。但对初涉 Spring 的小伙伴们来说,这就不太公平了,不像老兵哥可以伴着它慢慢成长,现在这套技术栈已经很庞大了,短时间内吃透这个巨无霸,有没有捷径可走呢?有,就像当年 DOS 操作系统一张软盘就装下了,总共才几 MB,现在动不动就几十上百 GB,但操作系统内核是很小的,其原理机制就是教科书上那些,一生二、二生三、三生万物,唯有掌握这些稳定不变的“一”,即核心原理机制(例如:IOC \ AOP \ ORM 等),那我们的学习就可以达到事半功倍了。 就像我们购买了毛坯房,入住前必须装修一番,其中水、电、气、网等管路的布线必须先行,不同管路有不同的走法,有的走地板,有的走墙面,等管路都铺设妥当了才能铺地砖、吊天花、刷墙贴纸等。作为业主,如果你不知道这些管路的走线,当出现停电、断网或漏水等问题时,你压根不知道怎么分析、定位和修复。在公司内老兵哥经常接到的问题求助,由于小伙伴不知道这些原理机制,蛮简单的问题分析定位了好些天还没头绪。如果循着原理机制,那我们就可以做到游刃有余了。 其实,这些底层原理机制并不算复杂,仅仅是我们不知道,或者缺乏好资料,老兵哥准备通过图解的方式把这些原理机制剖析给大家伙听。本 Chat 将聚焦 Spring 处理 HTTP 请求的全流程,帮助大家了解掌握 Spring 这座摩天大楼里面的管路布线,让学习变得事半功倍,让使用变得游刃有余,具体将包含下述几个方面内容,欢迎大家尽快订阅,以便早日发布上线,谢谢! 1. HTTP 请求处理全流程,包括浏览器、Web 服务器、应用 Spring 等; 2. Web 服务器与应用 Spring 之间的交互界面、协作机制和配置规则等; 3. Spring 处理 HTTP 请求的机制,包括 Dispatcher、Controller、View、Model、Service、DAO 等; 4. 不同应用架构场景下 HTTP 请求处理的子流程,包括 JSP、前后端分离等; 5. HTTP 请求处理相关配置文件说明,包括 Web、Bootstrap、Spring MVC、Application Context 等; 6. HTTP 请求处理常见问题说明等。 适合读者:开发、测试、架构等
Spring Cloud
124 订阅

Spring Cloud 与微服务化改造的常见问题

老兵哥从 2015 年开始从事云计算、微服务相关的平台建设和技术推广,短短几年微服务技术栈也经历了几轮更新换代,从 Dubbo 到 Spring Cloud,再到潜力巨大的 Service Mesh 等,哪种框架更适合我们呢?目前国内各大厂都推出了以上述开源产品为基础的微服务套件,各有特色,但扩展定制的思路都非常相似,我们从中可以借鉴些什么经验呢? 从小范围试点开始,现在微服务改造进入到攻坚战阶段了,我们必须向规模巨大的存量单体式老系统发起进攻了,如何赢得这场战役呢?相信我们对这些问题都比较感兴趣,接下来老兵哥将会把这些年积累的血汗经验梳理分享给大家,欢迎订阅支持! 1. 微服务架构落地实施时主要有哪些挑战? 2. 为什么选择 Spring Cloud 这套微服务框架 3. Spring Cloud 需扩展哪些特性才满足生产可用 4. 如何基于 Spring Cloud 做二次扩展定制 5. 单体式老系统的微服务化改造有哪些关键障碍 6. 如何提升单体式老系统的微服务化改造成功率 7. 从微服务架构到云原生应用还要做些什么 8. DevOps、容器云、微服务三者之间的关系 适读人群:开发、测试、架构、产品等
138 订阅

如何筹办一场千人技术峰会?

我们大多数人都参加过技术峰会,通过嘉宾的分享拓宽视野,在交流互动中结识朋友。但除了观众视角外,技术峰会还有哪些其他视角?不同视角之下,各有什么价值?技术峰会的各种构成元素中哪些是最核心、最重要的?哪些是附着在这些要素上的?如果现在让你策划筹办一场技术峰会,如何从零开始招募到大量优质嘉宾和观众呢?如何让嘉宾产出高质量的分享材料呢? 或许你会觉得谁没事筹办会议啊?隔行如隔山,懂不懂这些对职业发展没任何影响,这也是老兵哥我首次筹办会议时的想法,当时压根不知道如何完成这项新任务。但现在我会把技术峰会看作一款产品,筹办过程就是产品设计和运营的过程,担当产品经理所需的技能在这里都找得到用武之地。作为技术人,我们越往上发展就越需要产品和管理等综合技能,从技术峰会筹办中体会产品思维,可以帮我们达到触类旁通。 好吧!现在让我们以一场近六十位演讲嘉宾、八百多位观众的真实技术峰会为例,换上产品思维来重新剖析技术峰会的筹办过程: 1. 技术峰会到底是一款什么产品 2. 技术峰会都有哪些类型的用户 3. 不同类型的用户各有什么诉求 4. 如何找到技术峰会的独特定位 5. 峰会运营策略中的空手套白狼 6. 招募嘉宾或观众时的增长黑客 7. 如何拉到足够多的大会赞助商 适读人群:技术、产品、培训等。
峰会
80 订阅

Spring 核心技术与产品理念剖析

IT 技术发展太快了,就像浪潮一样一波接着一波,朝你迎面扑来,稍不留神就会被巨浪卷至海底而不得翻身。我们必须要学会抓住那些不变的本质或规律,只有这样才能屹立潮头而不倒,乘风破浪,做这个巨变时代的弄潮儿! 2003年,Rod Johnson 创建了 Spring,我在那一年开始了研究生实习。2005年参加工作,通信行业,主力开发语言是 C/C++。在校勤工俭学时捣鼓过 JSP,2005年前后我开始自学 Spring 搭建个人网站,那时 Java 领域最火的开发框架组合就是:Struts + Spring + Hibernate,SSH。2009年,我跳槽到了移动互联网行业,主力开发语言逐渐转为 Java。2014年,我再次跳槽进了互联网金融行业,基于 Spring 扩展定制内部开发框架,从 Spring 用户变成了扩展开发者。2016年因参与内部云平台建设,我跟 Spring 的东家 Pivotal 公司还有过一次合作。随着微服务等技术的兴起,近些年我做了许多 Spring Boot\Spring Cloud 扩展定制和培训推广。 一晃眼十五年过去了,从取代 EJB 的轻量级开发框架开始,到无比强大的生态圈,再到 Spring Boot\Spring Cloud 重新塑身成为云原生应用开发领域的首选框架。Spring 早已不是最初的模样了,在它身上发生过无数变化,但唯一不变的是它仍旧稳坐 Java 开发框架领域的头把交椅。或许大部分读者都熟悉 Spring 的使用,但你知道它背后的核心技术有哪些吗?这些年它都发生过哪些重大的变化?它演进至 Spring Boot/Spring Cloud 的原因是什么?它的成功源于哪些关键的产品设计理念?...... 熟悉 Spring 的使用仅仅是"知其然",唯有"知其所以然",我们才能真正融会贯通用好它。 快来吧,千万不要错过!老兵用血汗经验为你剖析那些风云变幻中的不变量: 1. Spring 背后的核心技术 2. Spring 演进发展的历程 3. Spring Boot/Spring Cloud 之蝶变重生 4. Spring 的产品设计理念 5. Spring 的产品推广策略 6. ...... 适读人群:开发、测试、架构、产品等
Spring
189 订阅

如何快速修炼成为技术面霸?

不管我们承不承认,人生的许多转折点都是由一场场面试答辩构成的,毕业答辩决定了我们能否拿到学位,面试应聘决定了我们能否获得工作,晋升答辩决定了我们能否升职。如何更加顺利地通过技术生涯当中的各种答辩呢?最关键就是提高自身的技术能力,除此之外还有一项关键能力,那就是展示能力。 前者是日常积累,后者是临场发挥,虽然能力的提升都没有捷径,都要经年累月学习和实践,但我们技术人通常很少关注展示能力,就像未曾开采过的露天矿,只要稍稍努力就能获得差异化优势,拉开跟其他技术能力相近的竞争者的差距。 在展示能力上缺乏关注的我们,就像一个细颈瓶,虽然肚子里装满了学问却倒不出来,无法充分地展示自己的技术能力,这对于我们来说是非常吃亏的,尤其身处这个酒香也怕巷子深的时代,许多怀才不遇不是因为伯乐难寻,而是当着伯乐的面却秀不出来。 结合笔者做候选人和面试官(不少于百次)的经验,本文将介绍一些快速提升展示能力的实战经验: 1. 如何更全面地展示个人技术能力; 2. 如何阐述不同类型系统研发经历; 3. 如何呈现个人成功案例效果更佳; 4. 哪些思维方式有助于体现方法论; 5. 如何兼顾技术能力的宽度和鲜度; 6. 如何跟面试官互动把控问答节奏; 7. 如何编制出一份合格的答辩材料; 8. 哪些综合能力可以获得额外加分; 9. 如何消除临场紧张彰显技术热情。
面试
162 订阅

微服务架构演进策略与实施指南

互联网的发展日新月异,最让我们焦虑的就是:新技术的层出不穷。任何技能的精进都离不开长期投入,但我们天天被热点撵着跑,难得喘息之机,更无从仔细思考该将个人有限的时间精力投入的哪个领域。微服务,跟容器、DevOps 等技术构成了云原生应用的默认技术栈,目前已经趋近成熟。但从笔者推广微服务的情况看,依然有许多团队和个人站在微服务技术的门口犹豫不决。 微服务,优点不少,但也不乏副作用。就像在穿越森林的过程中,你面前突然出现了好几条岔道,机会和风险并存,如果不清楚每条道会把我们带向何处之前,任何选择都是赌博。此时,我们需要登上高地,或山顶或树冠,打探出每条道的走向,这样才能选择出正确的道路,然后全力以赴。从纯技术的角度看,微服务并不难,关键是缺乏一个打动我们的理由,以及对演进趋势的洞察。 本文将理论结合实践,帮您答疑解惑,找到学习新技术的内驱力和方法论,从而更快更深地掌握这门技术: 1. 拨云见日,微服务到底是什么 2. 我们为什么要引进微服务架构 3. 微服务为何从前后端分离开始 4. 如何逐步演进至全微服务架构 5. 微服务实施包括哪些关键步骤 6. 哪些系统适合改造成微服务呢 适读人群:开发、架构、测试等。
微服务
172 订阅

微服务架构的演进、融合与选型

云计算像水、电、气一样提供计算、存储和网络等基础资源,而引领云市场的企业自然会成为水厂、电网和气站一样的基础设施,这意味着什么呢?意味着除了现在必缴的水费、电费、气费、话费和网费之外,我们每个月又多了一项必须缴纳的云费,这真是一个风云变幻的大时代! 往日的巨头们希望再续辉煌,新进的创业者渴望乘势逆袭,大家凭借资本或知本纵横天下,作为云原生应用架构的微服务领域也是战火纷飞、硝烟弥漫。由 RPC 框架演进而来的 Dubbo,由开发框架演进而来的 Spring Cloud,以及扛着新一代微服务架构 Service Mesh 旗帜闪耀登场的 Istio 等等,微服务相关的技术产品层出不穷,面对如此多的选择你是否感到手足无措? “所谓的大时代,不过就是一个选择,或去或留,我选择了留在属于我自己的年月,那是我最开心的日子”,生活在记忆里不是我的选择,面对云计算这个IT人的大时代,我选择重新出发。让我们一起拨开云雾进一步认识微服务,不止于仅做这个大时代的见证者,还要做一个优秀的参与者和建设者: 1. 微服务架构都有哪些组件构成? 2. 微服务框架与 PaaS 平台的关系? 3. 微服务框架彼此有什么异同点? 4. 微服务框架对比各有什么优势? 5. 微服务框架的演进和融合方案? 6. 如何选择最适合的微服务框架? 学习是反人性的,改变认知也是一个既痛苦又漫长的过程,但我更憧憬未知的快乐……你呢?
严选微服务
425 订阅

老系统微服务改造经验谈

微服务是当下最流行的应用架构了,它跟容器云、DevOps 合称新时代三剑客,帮我们化解业务发展过快导致的产品迭代压力,让我们有自由选择最适合自己团队的技术栈,让系统能够承载互联网海量用户的访问。近些年在厂商、社区和用户等各方努力推动下,微服务相关的理论和产品都日趋成熟,从零开始搭建微服务变得非常简单快捷,那我们是否就此全面进入微服务时代呢? 微服务的演进成熟需要时间,我们熟悉掌握这套新技术也需要时间,除此之外机房里面还跑着大量的单体式应用,它们需要继续维护和升级,任何时候我们都不可能抛开历史轻松上阵。这些单体式应用还担负着公司的核心业务,全部推倒重来、休克式重构是不可取的,投入大周期长,风险完全不可控。 我们必须学会边行车边换胎的技能,在不影响现网业务的前提下推动微服务改造,让老系统焕发新的生命力,继续支持业务下一个十年的发展。本场 Chat 将跟你一起探讨微服务改造相关的经验方法,让你更加从容地拥抱微服务: 1. 边行车边换胎三步走演进策略。 2. 隔离网关接管新旧系统间交互。 3. 单体式应用拆解微服务的方法。 4. 旧模块微服务改造优先级原则。 5. 微服务改造是否结束判断标准。 6. 微服务架构新挑战与解决方案。
微服务
366 订阅

如何写出好的产品帮助文档?

程序员不喜欢写文档,有写文档的时间,还不如把代码再重构一遍。前些年我也这么认为,究其原因,一则自己不喜欢也不擅长写文档,代码是给机器读的,只要语法和逻辑没问题,计算机就能听令运行,而文档是给人看的,除了语法和逻辑,好文档还要照顾读者的心理情绪;二则传统软件的客户对文档无感,它仅仅作为合同约定的交付物而存在,客户压根就不会读这些文档,他们更依赖我们提供的现场培训和技术支持,让客户自己看文档学习太不符合甲方的身份了。 但现如今大部分软件产品都通过互联网向用户提供服务了,在线文档才是最高效的客户服务手段,我们熟知的那些开源软件都配有高质量的帮助文档。好文档已经成为优秀产品的标配,它不仅可以帮你带来更多的用户,而且还可以帮你服务更多的用户。作为互联网程序员的你,要是还不懂写文档,都不好意思跟人打招呼,也别想转型做产品,那如何才能写好产品文档呢? 1. 好文档的评判标准是什么 2. 文档目录设计与用户思维 3. 故事思维让文档不再枯燥 4. 故事线模拟用户学习过程 5. 进阶式设计跨越学习曲线 6. 双视图服务不同类型用户 7. 常用开源或免费文档工具 想提升技术写作的能力吗?赶紧订阅吧,本文将带给你技术写作的新思维和新方法!
产品文档
162 订阅

如何正确使用 Spring Cloud?

如何更快地交付软件,每周、每天甚至每个小时向用户发布新特性?如何让新员工在入职后就能部署代码?在如此快的节奏下如何保证质量?快,我们应用开发面临的主要挑战,交付越快就越能紧密地收集到用户反馈,从而更有效地满足用户需求。 微服务、DevOps、云计算,业界应对“快”挑战的三大兵器,但其中任何一件都不是能轻松玩转的。微服务,在带来好处的同时,也引入了大量复杂度;DevOps,不仅要求团队文化、组织架构和研发流程做出调整,还对应用开发提出了新的要求;虚拟机、容器、镜像等新技术亟待学习,我们能快速跨越云计算这套技术栈吗? Spring Cloud,它将帮我们填平横跨在应用开发与微服务、DevOps、云计算之间的沟壑,让我们轻松拥抱云上微服务,但你知道它是如何做到的吗?你对它有全面的了解吗?你知道如何正确使用它吗?新概念新技术层出不穷,让人云里雾里,你是否想拨开云雾对它们有更清晰的认知? 磨刀不误砍柴工,赶快来听一听吧!通过本 Chat 你将学到如下内容: 1. 微服务、DevOps、云计算的关系 2. Spring Boot 的设计原理 3. Spring Boot 集成了哪些常用套件 4. Spring Cloud 微服务全家桶有哪些 5. Spring Cloud 如何支持 DevOps 6. Spring Cloud 如何适配云基础设施 7. Spring Cloud 填空式应用开发模式 8. 总结
JavaSpring Cloud
885 订阅

如何玩转短视频提升影响力?

短视频越来越火,不管是娱乐还是学习,许多内容都通过短视频传播了。你是否想过成为视频中的主角,在镜头前侃侃而谈?近两年公司转型做平台、打造生态圈,同时我也在往培训、咨询等方向转型,这都需要我提升影响力,而短视频是非常有效的载体。 对于缺乏录播经验的人来说,这个挑战还是蛮大的,有的同事觉得压力太大就放弃了。这是一个非常专业的领域,培训授课的经验有助于视频录播,但还有许多新知识需要学习:它跟现场培训、在线直播有什么异同?视频录播包含哪些流程?演讲内容如何设置?演讲词如何编写?录制对着装和身体语言有什么要求?...... 压力既是动力,也是阻力,关键看如何管控它,管控能力就是专业能力。学习、实践、总结,这是能力提升的闭环,如果你也想玩转短视频,借助它来传播技术,那就跟我一起来探索其中的奥秘吧!
免费短视频
122 订阅

如何做好个人职业转型?

从小就清楚自己喜欢什么,知道自己适合从事什么类型的工作,而且足够努力和幸运,如愿以偿地考进了理想的大学和专业,毕业后进了最好的公司,从事着最擅长的工作,一路顺风顺水。但现实并不是这样的,我们的择业会受个人能力、就业环境、薪酬待遇、发展空间、中年危机、兴趣爱好等因素的影响,趋近理想的过程必定是曲折的。 本科学的机电工程,读研时我转到了计算机,第一份工作做开发,第二份工作涉足项目管理,现在主要做架构和产品相关的工作,同时还在做培训和咨询,逐渐找到了自己喜欢又适合自己的职业类型。这个过程我走了不少弯路错路,也迷茫彷徨过,站在当前回望过去,彼时的困惑都能释然。借此对这些经验做一次梳理,供需要的朋友参考: * 可选的发展方向有哪些? * 你我适合从事什么工作? * 职业转型需要做些什么? * 如何渡过职业的倦怠期? * … 如果你正在经历职业倦怠、正在纠结要不要转型、或正在焦虑中年危机,欢迎找我一起交流讨论,谢谢!
职业规划
128 订阅

如何跨界做一个培训师?

做培训有什么好处?除了有机会走遍全国各地、品尝特色美食、认识不同朋友、拓宽眼界认知、提升综合能力等等,我看重它可以带来复利,俗称“睡后收入”。通常我们工薪族都是干活才有收入,休息时就没有了,而开发培训课程跟写文章、写书类似,将个人的专业知识和经验以课程的形式固化存储下来,每次授课都可以复用它。 待课程相对成熟之后,我们还可以录制线上的音视频课程,或集结成书,像产品一样可以销售给更多的人,孵化出真正的“睡后收入”。等到“睡后收入”足以支撑生活之后,那我们就能腾出更多时间做喜欢的事情。接着前几篇 Chat 继续分享我跨界做培训的心得体会: * 做培训师有没有门槛? * 上讲台需要注意什么? * 现场出现失误怎么办? * 互动冷场该如何应对? * 拍照合影要注意什么? * 在线直播有哪些异同? 如果你也考虑跨界做培训,那赶紧订阅吧!
个人提升
99 订阅

如何设计优美的 WEB API?

构建前后端分离的 WEB 应用或跨终端的移动应用、集成内外部系统、对外开放服务、开发可嵌入其他网页微件等,这些场景都离不开 WEB API。虽然我们经常使用他人提供的 WEB API,但如何评判它们的优劣呢?我们也经常设计开发 WEB API,但如何让它们更易于使用、方便更改和牢固健壮呢? 在设计 WEB API 的过程中,我们需要确定它的调用地址、请求方式(HTTP 方法)、请求参数(Headers/Query/Body)、数据格式、错误码、认证方式等内容,这当中存在不少标准规范,你都熟悉吗?你是否遇到过这些问题: - 如何让 URI 易懂易记、便于修改? - 如何最大程度地利用 HTTP 协议? - 如何通过查询参数实现搜索分页? - 如何选择数据格式和数据结构? - 如何通过状态码表示出错信息? - 如何规划 API 的版本和更新策略? - 如何让对外开放的 API 安全可靠? - …… 作者在建设 API 网关和市场过程中积累不少实战经验,有兴趣来听一听吗?
APIWeb
332 订阅

轻轻松松做演讲的小窍门

在[《如何突破公众演讲》](http://gitbook.cn/m/mazi/activity/5abc3d0dfcdc1a23681388f5)中,我结合个人经历分享了一个观点:学会演讲对技术人的发展非常重要,尤其是身处互联网时代,提升专业影响力,打造个人品牌等等,各种工作场景都离不开公众演讲。 将好东西分享给他人的初心,点燃了我走上讲台的热情。重新认知演讲之后获得的胆识,让我敢于面对无数观众。但每次演讲我还会有压力,临场会紧张,发挥不稳定。再身经百战的演讲家临场也会紧张,但专业和业余的差别就在管控压力的功夫上,管控得当就是动力,否则是阻力。一次次实践让我对压力源有了更多认知,它们就是潜藏的担忧: - 哪有这么多内容好讲? - 怎样才能不忘记台词? - 如何让身体放松下来? - 如何面对陌生的观众? - 如何营造轻松的氛围? - 遇上尴尬情况怎么办? - …… 消除了它们才能轻松做演讲,在实战中我摸索出了不少实用的小窍门,你不想听一听吗?
演讲
102 订阅

如何通过晋升答辩?既升职又加薪!

晋升不单是成就感,还有更好的薪酬待遇和发展平台。我的进步不算快,但从开发工程师到资深架构师,这些年也经历了七八次晋升,从焦虑于被人评品到积极准备、从容应对,除了硬性的工作绩效,还要掌握一些非常有用的软技能。 不擅长展示自己,晋升上很吃亏。近几年我有幸参与公司的人才发展工作,以评委身份参加了几百人次的晋升评审,发现许多同事跟我先前一样不擅长答辩,无法让评委感受到自己的热情、专业和价值,肚子有货倒不出,影响了发展。 结合我做候选人和评委这两种角色时的真实案例,谈一谈晋升答辩所需的软技能: 1. 心理调适:但行好事,莫问前程,不以成败论英雄。 2. 向上沟通:换位思考,深入浅出,站在评委的视角。 3. 素材准备:价值导向,生动形象,简单明了有重点。 4. 现场展示:从容自信,谦虚热情,结构化思维逻辑。
晋升答辩
178 订阅

如何突破公众演讲?助力个人发展!

应聘面试、工作汇报、团队管理、宣讲推广、培训授课、晋升答辩、岗位竞聘等场景,都离不开公众演讲,但我们缺失这方面能力的培养,严重阻碍个人发展。除了循序渐进地学习和训练,演讲能力的提升还需要突破许多思维观念: 1. 从技术宅到分享达人:公众演讲助我顺利转型,未来之路越走越宽。 2. 热衷分享事业的初心:传播技术,交流成长,将分享变成一种习惯! 3. 别骗自己,你真的不会说话:能力提升离不开学习,演讲也不例外。 4. 如何迈上演讲的舞台:一胆二力三功夫,从胆识、专业和方法突破。 5. 如何战胜演讲的恐惧:胆识源自正确的认知,哪些错误观点困住你? 6. 十年磨一剑,你能够做到吗?段带式进阶让这个过程更加轻松快乐! 以上都是我的亲身经历和心得体会,欢迎订阅!
演讲
125 订阅
微信扫描登录