软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

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

宝玉 2019-04-25
你好,我是宝玉,今天我想与你讨论一个每个开发人员和项目管理者都关心的话题:如何提高开发效率。
我其实也一直很关注这个话题,收集了很多方法让自己工作变得卓有成效。通过对这些方法的应用,我也可以算得上是一个高效的程序员:曾一个人在很短时间完成了飞信 Web 版客户端;在 DePaul 上学之余,帮学校完成了在线教学播放器系统的改造;三个月时间帮公司完成了主站从 jQuery 到 React 的迁移。
如果让我对学过的这些方法做个整理和总结,再进一步精选提炼,我觉得对我影响最大的是“积极主动”、“以终为始”和“要事第一”这几条看似简单的工作原则。

积极主动,行动起来改变自己

相信你也跟我有过相同的经历。成为一个高效程序员,最大的阻力不是来自于不知道方法,而是自己的消极心态。遇到进度延迟、效率低下之类的问题,你就会下意识觉得:
时间进度太紧了;
我已经尽力了;
最近加班太多了没精神;
产品经理太不靠谱了,需求没想清楚,害的我瞎忙活。
是的,你也知道这些答案都很消极负面,可是怎么控制自己不这么想呢?首先你要知道,无论这些事情的本质责任在于环境还是个人,抱怨排斥的心态对于实际工作的改进是没有任何帮助的。
当然,很多人也知道抱怨没用,但具体怎样才能做到不抱怨,并且积极主动呢?史蒂芬・柯维写在他的《高效能人士的七个习惯》书中,对这个问题提到了两个行之有效的建议,我们可以结合着软件开发来分析一下。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(15)

  • Joey
    再次请教宝玉老师:对于一个研发部门,一次性入职300+的新员工(原来老员工近700人),可以通过哪些环节的哪些手段,来加强对新员工的研发质量管理,以免出现新员工频频挖坑的情况?

    作者回复: 对于大量新员工加入的情况,我建议可以从多个方面入手:

    首先是人员的培训方面,有相关的入职培训,新人入职后能快速了解整体的开发流程、规范,新人入职后有指定的Mentor(师傅),在遇到问题时知道该找谁。

    然后是项目的开发流程方面,多花时间在流程建设上。具体体现在:
    - 整体的项目流程是基于软件工程的标准开发流程的,并且适合你业务特点的,比如说敏捷、迭代或瀑布
    - 对于关键环节要有审查,比如设计方案的评审,比如代码合并前的Review
    - 要有规范的代码开发流程,比如我多次提到的Github Flow,基于分支开发,代码审查通过并且自动化测试通过才能合并主干
    - 要应用好工具,有一定量的自动化脚本和工具辅助,比如说Git,CI/CD的应用,日志数据的收集和监控等。如果这些工具的应用还不够到位,作为一个近1000人的团队,应该成立专门的小组去实施,去做针对公司业务的定制化,去帮助其他团队实施和推广。

    再有就是团队组成上,要形成梯队,一个健康的团队,应该有资深的工程师、架构师,有中间的丰富开发经验的工程师,有新手程序员。对于资深的工程师,应该鼓励他们把一部分精力用在评审和帮助新人上,多参与设计的Review和Code Review,帮助团队一起成长,从而实现个人的成长和整个团队的成长。

    最后就是对于整个组织架构和技术架构要有针对性设计,一个公司的研发团队目标是满足公司业务需求,这些业务需求又是有各个大大小小的项目组成的,这些项目之间有共同点,有不同点,需要有团队有人能站在整体去思考去设计整体的业务架构,提取公共的架构和服务,将复杂的业务能化整为零,拆分成和组织架构匹配的技术架构,或者按照技术架构去调整组织架构。简单来说就是你的技术架构和组织架构要是匹配的。

    比如说你可以把整体的技术架构设计成为微服务的架构,整体组织架构也可以拆分成一个个小的业务小组,一个小组专注于一两个微服务,各自独立维护和发布。这样新人加入,不需要了解整体繁复的架构,只要先了解所属小组的服务架构,就能快速的熟悉业务,快速上手,就算挖坑了,也不会影响太大。

    2019-09-10
    4
  • 胡鹏
    请问宝玉老师:
    我现在遇到一些情况,需求出来了,估时的时候,通常有两种心理
    第一种: 尽量压缩自己的时间,当然领导也会压缩时间, 这时心里想的是要好好表现,把时间压短一点
    第二种: 尽量多一点充裕时间,当出现问题能有足够的时间来解决,不至于延期

    第一种优点是,估时的自己心里畅快一点
    缺点是: 经常因为特殊原因延期,,印象分就越来越不好

    第二种优点是基本上不会延期,有时候还能空一点时间来做项目优化,,但是这个时候要抗住领导压时间

    现实场景肯定会更加复杂,有时候紧急需求都是高一两个层级的管理直接下发紧急需求,越快越好,,这个时候时间估短了容易做不完,,长了会被质疑能力问题。(个人感觉了)

    我目前主要采用第一种,但是我发现自己做的事很容易延期,为了做好,我就有了更多的加班

    和我行程鲜明对比的一个同事,他估时就是第二种,尽量多一点时间,估时的时候长,,,但是整体有保证,,然后领导对他的信任程度比我高一些(我拿了年度最佳担当奖),

    对于这种估时,取一还是取二还是如果在一和二之间平衡,
    不知宝玉老师有什么好的建议和观点呢

    作者回复: 太紧和太松的时间估算都不可取,应该是尽可能准确的接近实际情况的时间,并且留有一点富裕应对意外情况。

    时间太紧了要加班加点还要被质疑能力;时间太松了会影响以后估算时间的真实性。你同事的估算时间应该不是偏松,而是接近实际情况的时间,你可以向他请教经验。

    准确的估算时间是程序员能力的一种,做好不容易,一些建议供参考:
    1. 充分理解清楚需求,知道要做什么,这是基本前提,不然做着做着发现需求没搞清楚,那一定是要多出很多额外时间
    2. 非功能性的需求,比如说写自动化测试、搭环境、重构代码这些任务也应该作为计划的一部分,要把时间算进去
    3. 拿到任务后,将任务要分解到尽可能细,越小的任务力度估算越准确,而且在跟领导说时间进度的时候也有理有据,底气足扛得住
    4. 综合考虑任务并行的情况,给线上版本修bug、开会这些时间也要算进去,想想每天真正有效的工作时间是多少?
    5. 计划保持及时更新,当出现延迟或者有延迟风险的时候,或者进度提前,需要及时和项目负责人沟通,作出调整,避免影响整体项目进度
    6. 留一点余量,应对突发情况

    反过来,如果你是领导,在下属估算时间的时候,也要参考上面的一些建议,让计划尽可能的接近真实情况,而不是下属给一个很紧的时间就按照这个时间执行,最后得加班加点,加班是为了应对突发情况的,而不是正常情况。

    2019-05-17
    4
  • Joey
    请教宝玉老师:软件工程领域,如果要“树精品意识,扬工匠精神”,有什么思路可以建议,感谢老师解答!(我们现在采用瀑布研发模式,部分条线实现了CI)

    作者回复: 精品,其实核心是要小要精,所以你要考虑让产品需求需求小而精,让团队小而精。

    工匠精神这已经超出软件工程范畴了:)

    2019-04-29
    3
  • kirogiyi
    非常感谢宝玉老师的每一篇文章,逐渐完善了我在软件工程方面的知识和应用。

    我觉得高效,意味着自律,自律的好坏是可以通过你散发出来的气息让周围的人感受到的,比如:说话有没有条理,做事拖不拖延等等。生活自律,你会发现每一分每一秒都充满了希望和力量,用积极乐观的心态去完成每一件事,知道自己上一步做好什么,下一步才能做好什么。工作也是一样,要想高效的完成任务,需要利用前辈们总结的思想和方法,去长期实际应用,在使用的过程中就会体现出你的高效,不能说我知道单元测试,我知道CI...,很少有人讲我一直在用。

    如果我们注意观察,会看到身边的同事,有的很少加班(活蹦乱跳),有的经常加班(蔫头耷脑),做了一样的事情用了不一样的时间,此时就能真正的体会到高效做事的魅力了。我不提倡加班的原因就在于此,但那是针对高效人士的,低效人士不加班,老板是不会答应的。而一般对自己的时间把握比较好的人,在估算工作时间或工作量的时候,都比较果断,不会支支吾吾,还会主动给出具体时间点和阶段性成果,让人觉得这才是真正做事的人应该有的态度。

    我的看法是,积极、主动、自律是高效人士的必备素质。

    作者回复: 感谢分享!

    👍自律的收益之一就是让你可以专注,比如不会经常刷个微博摸个鱼啥的:)还可以保证自己有更多时间去练习技能。

    高效是个正循环,一旦开始高效起来,就不愿意低效率的做事情。

    2019-04-25
    3
  • 小老鼠
    要事第一,我也尝试过,往往我忙时别人闲,我闲时别人忙。另外作计划,往计划敢不上变化,中间总有意想不到的事情发生,如何处理?

    作者回复: 可以参考文中“要事第一,把时间用在刀刃上”:
    按照“紧急重要四象限”对事情进行分级,然后优先处理紧急重要的事,然后处理不紧急重要的事。紧急不重要的事情可集中处理。

    2019-09-21
    1
  • alan
    谢谢老师分享宝贵经验!积极主动、以终为始,要事第一。和吴军老师说的“不做伪工作者”很像!

    作者回复: 👍吴军老师很多道理讲的特别好,比如把事情做好的三条边

    2019-04-30
    1
  • alva_xu
    我记得有本极其经典的书叫《人件》,对如何提高效率,讲了很多方法。比如,办公室的布置。我自己的办公室就是按照《人件》的建议,在办公桌和门之间,放了一个隔断,这就可以让我在工作的时候,不会受外部的干扰。

    作者回复: 没错,人件是很经典的软件工程书

    2019-04-26
    1
  • bearlu
    老师,有没有事情管理的工具?因为如果不记录下来,一会儿就忘记了。

    作者回复: 楼下的McCree同学推荐了滴答清单。

    我个人的话,一般就用系统自带的记事本记一下,或者贴一个便签纸在显示器。如果时间跨度长,我就记到Calendars上,加上提醒。

    工作中的任务,我则会创建成Ticket。

    2019-04-25
    1
  • 青石
    设置番茄钟,单次20分钟每天3-4个,关注微信、邮件通知、免打扰。
    利用状态最好的时间解决重要紧急问题。
    重要不紧急问题优先制定解决方案,定番茄钟解决。
    紧急不重要的问题,看优先级集中解决。
    不紧急不重要的问题,零散时间解决。

    作者回复: 👍谢谢补充

    2019-04-25
    1
  • Tomcat
    积极主动、 以终为始和要事第一重新确立了我的工作原则,我也从中收益较多。
    作为程序员,的确会经常被日常的杂事所打断,没有整片时间来专注于写代码,我们能够奢求的,就是要做最重要的事情,其他的事情不要去做!

    作者回复: 是的,仔细想想,一天的上班时间,其实做不了多少事情,能把最重要的事情做好就不错了

    2019-04-25
    1
  • 梁中华
    后面互赖圈的三点也很重要,比如双赢思维特别适合,努力工作,提升自我,与公与私都是双赢

    作者回复: 《高效能人士的七个习惯》是一本非常好的书,值得学习。

    2019-04-25
    1
  • miketan
    每次开发前先想清楚如何实现;核心接口做单元测试全覆盖;

    作者回复: 👍是的,想清楚做什么特别重要。
    除了单元测试,建议还可以配合一些集成测试来测试接口的调用。

    2019-04-25
    1
  • AI午间狂睡Steve
    谢谢老师,时间四象限实在太棒了👏🌟

    作者回复: 🤝

    2019-10-01
  • Sudouble
    最近一直在用番茄时钟,中间还可以稍微休息一下。把现在的刻意练习逐渐变成习惯。

    作者回复: 👍养成习惯了就容易多了。

    2019-05-07
  • McCree
    楼上的,滴答清单

    作者回复: 🙏感谢推荐

    2019-04-25
收起评论
15
返回
顶部