《软件工程之美》打卡第五周

348 阅读9分钟

上周因为临时公司有紧急需求,大部分时间都投入到工作上,所以就暂缓打卡的计划,这周正式进入远程办公的第一周,继续把专栏的学习计划滚动起来,这周会分享宝玉老的极客时间专栏——**《软件工程之美》**中的开发编码篇。

25 | 有哪些方法可以提高开发效率?

这个估计是每个开发人员和项目管理者关心的话题,宝玉老师分享了对他影响比较大的几个工作原则:

  • 积极主动
  • 以终为始
  • 要事第一

积极主动

  • 避免消极负面的情绪,做到不抱怨,以积极的心态对待实际工作的改进
  • 面对不熟悉或者未知的事情,不立马打退堂鼓,而是提醒自己再想想,多尝试
  • 减少关注圈,扩大影响圈,不要总盯着自己无法改变的部分,多花时间去扩大自己能影响的范围

关于这一点,我平时也会有负面的情绪,面对不合理的需求也会抱怨,但慢慢的我也发现抱怨无用,只有自己采取积极的心态去看待,扩展自己的能力,让自己能成为影响别人的人,而不是被动去接受一些东西,越积极自然也就越高效。

以终为始

接到需求里面就写代码的必然是最低效的,相比以前现在的我接到需求会先把需求hold住,我会仔细分析一下这个需求最终想要达到什么效果,然后再去跟产品经理讨论,根据目前的现状去定可行性方案,评估工作量,然后再开始按节奏去开发。

这里提到的以终为始需要注意三点:目标、原则和计划

我们做每件事都有它原始的目标,如果现在做的事情不是围绕这个目前做的,那么你的方向就错了,需要停下来想想。

做事情需要给自己定一些原则,避免产生技术债务,比如:

  • 先运行再优化
  • 不复制粘贴代码
  • 每个PR要尽可能小
  • ....

有原则还不够,需要有计划去执行,设定deadline,让每件事都能够在限定的时间内完成。

要事第一

这里其实说的就是把事情按重要紧急程度排个优先级,也就是我们常看到的时间四象限

  • 重要紧急的事情马上处理
  • 重要不紧急的事情,要多花时间
  • 紧急不重要的事情延后集中做
  • 不重要不紧急的事情尽可能少做或者不做

26 | 持续交付:如何做到随时发布新版本到生产环境?

我们经常听到DevOps中的CI/CD,就是持续集成持续交付,这节课还提到了持续部署,是一种更自动化的程度。我们该怎么理解它们之间的区别,首先它们前面都有共同之处——持续,就是把软件工程中让人痛苦的事情更加频繁的做,更低成本的做,从手动变成自动的过程就是持续

持续拆分出来就是集成交付部署,它们的概念如下:

  • 集成:开发人员将代码从分支合并到主干,必须测试才能合入
  • 交付:基于集成,测试完成之后构建生成发布包,部署到测试环境和生产环境
  • 部署:特指环境部署,测试和生产环境

我们软件工程的发展就是从持续集成持续交付再到持续部署,后者都是在前者的基础上,更高级别的实现自动化,对开发人员和工具都要求更高。

持续交付和用什么开发模型没有关系,它的好处有以下几点:

  • 尽快暴露问题
  • 极大提升效率
  • 提升质量
  • 降低项目成本

还有关于如何搭建持续交付系统,主要还是基于源代码工具和持续集成工具,然后配合自身业务去落地实施,大家可以去学习乔梁老师的持续交付:发布可靠软件的系统方法

27 | 软件工程师的核心竞争力是什么?(上)

关于软件工程师的核心竞争力话题,估计大家都很感兴趣,我也一样,也一直思考自己所掌握的能力是否能成为自己的核心竞争力。这节课主要是讲了哪些方面的能力构成了软件工程师的核心竞争力。

学习能力

不只掌握一种语言和能够熟练使用工具、框架,能够快速掌握编程语言、框架、工具的学习能力。关于学习能力这一点,我的看法是业务不可能一直不变,技术不可能不会更新迭代,能让我们更快适应变化的就是学习能力。就好像现在做终端,你只会Android,不懂点iOS,面对跨端的问题你就不知道怎么解决,换做另一个两端都精通的同学,别人的竞争力就比你要强了。

解决问题的能力

关于这个点,我之前还专门写过一篇文章:

www.jianshu.com/p/bdd7e4927…

我们日常工作体现解决问题的能力核心在于:

  • 发现问题(方案存在的问题,异常情况)
  • 分析问题(分析故障的深层次原因,避免下次再发生,提出机制)
  • 解决问题(学会提问,学会搜索)

影响力

  • 经验总结分享,技术博客、论坛、技术社区
  • 独特的项目、公司或者行业经历
  • 技术大会、公开演讲等

以上就是我关于软件工程师核心竞争力的总结,个人感觉还是蛮有收获的。

28 | 软件工程师的核心竞争力是什么?(下)

上节课讲的什么是软件工程师核心竞争力,这节课讲的是怎么去做。宝玉老师分享了以下内容,我做了下提炼:

如何提升学习能力

  • 深耕某技术领域,吃透领域知识,构建知识领域森林
  • 横向扩展相近领域,利用已有知识,加速学习速度

如何提高解决问题的能力?

一套可行的方法论:

  • 第一步:明确问题(分析问题本质,是否还有其他问题)
  • 第二步:拆分和定位问题(复杂问题拆分成简单问题,逐个定位)
  • 第三步:提出解决方案并总结
    • 更好的解决
    • 预防同样问题的方案

如何提升影响力?

  • 在某个领域做出足够牛的成绩
  • 做事情超出预期,期望值管理
  • 帮助他人就是帮助自己
  • 分析就是学习和打造影响力

宝玉老师提的这三点也是我一直在践行的,纵向深耕,横向扩展技术领域,日常思考更好的解决工作中的问题,总结经验沉淀方法论,这让我在技术这条路走得更加自信。

29 | 自动化测试:如何把Bug杀死在摇篮里?

这一讲主要就是讲通过自动化测试来提升代码质量,以下是我的总结:

自动化测试其实就是用程序来代替人来做测试,我们测试一般包含以下几个要素:

  • 测试用例
  • 输入和操作
  • 真实情况和预期情况

一些简单重复的逻辑写成单元测试,每次编译之前都自动跑一边,百分百通过再继续代码合流,保证了代码稳定,预防产生新的bug。

自动化测试分类

Google将自动化测试分为三大类:

  • 小型测试(我们常说的单元测试,针对一个函数或者一个类的测试)
  • 中型测试(验证两个或者多个模块之间的交互,也叫集成测试,模拟或者使用真实的服务来完成测试)
  • 大型测试(不模拟,使用真实的服务进行测试,也叫系统测试或者端到端测试)

一图胜千言:

测试类型

测试金字塔,从上往下速度更快,从下往上实现成本更高:

测试金字塔

自动化代码怎么写?包含四个部分:

  • 准备(创建实例、创建模拟对象)
  • 执行(执行测试的方法,传入参数)
  • 断言(校验结果,预期成功or失败)
  • 清理(清理数据,避免影响下一次测试)

完整的自动化测试包含三个部分:

  • 验证功能是不是正确
  • 覆盖边界条件
  • 异常和错误处理

为项目实施自动化测试

一图胜千言:

为项目实施自动化测试

核心在于能够在持续集成环境中自动跑写好的测试代码。

这节课很好的讲了自动化测试的本质,也是我们项目目前欠缺的模块,后面会尝试推广到项目组。

30 | 用好源代码管理工具,让你的协作更高效

这节课讲了代码版本管理从集成式到分布式的发展历史:

SCCS(Source Code Control System)-> RCS(Revision Control System) -> CVS(Concurrent Versions System) -> SVN(Subversion)-> DVC(Distributed Version Control)

目前主流的版本管理工具就是SVN和Git,分别是集中式和分布式版本管理的代表。Git基本已经替代SVN成为最主流的源代码管理工具,我们团队目前也是采用Git作为我们的代码版本管理。

自己搭建源代码管理系统

  • Git
  • Gitlab
  • Gerrit

网上代码托管平台

  • Github
  • Gitlab
  • Coding
  • 其他...

用好源代码工具的可行原则

  • 原则一:要频繁的提交(粒度小,便于Code Review,出现问题方便回滚,尽可能保证完整性)
  • 原则二:每次提交要跑自动化测试(将bug消灭在摇篮里)
  • 原则三:提交的代码要有人审查

选择合适的开发流程

这三个最佳实践自行查看,选择一个合适自己团队来实践就好。

最后

这篇文章晚了两天,因为实在是太忙,连续一周连轴转,开发需求过程中遇到一些问题,通宵达旦去解决,最后才如期完成开发。关于这一周学习《软件工程之美》专栏中的开发编码篇,我觉得都值得每位开发者去学习的,这里面不管提到的理念和实践都很有参考价值,会让你更加深刻理解自身的痛点,重新审视作为一名软件工程师核心能力是什么,自己还欠缺什么。

好了,这一周的学习总结就到这,下周继续学习软件测试篇的内容,敬请期待。

欢迎关注我的公众号:巫山老妖

巫山老妖