极客时间已完结课程限时免费阅读

结束语 | 万事皆项目,软件工程无处不在

结束语 | 万事皆项目,软件工程无处不在-极客时间

结束语 | 万事皆项目,软件工程无处不在

讲述:宝玉

时长08:12大小6.58M

你好,我是宝玉。不知不觉,我们专栏就接近尾声,也该告一段落啦。
在专栏更新之初我就提到,把每件事都当作一个项目来推进,现在我也用“万事皆项目”来作为我们专栏的结束。
我学习软件工程最大的收获,就是在看问题的时候,不再局限于从技术层面或者是一个局部去思考问题,而是站在整体,用软件工程的方法去指导自己的思考和决策。
所以在整个专栏的讲述中,我也希望能给你带来这样的转变:在做一件事情之前你可以先考虑一下,这是不是可以当作一个项目来推进,站在整体思考,有目的、有计划、有步骤地解决问题。

万事皆项目

实际上,日常工作生活中,不仅是软件项目可以应用软件工程的知识,很多事情都可以应用软件工程的知识。就拿我们《软件工程之美》的专栏来说,这也是一个项目,从专栏诞生到完成,你从中也可以感受到对软件工程知识的应用。
项目都是从一个想法开始的
在写这个专栏之前,我曾在微博上多次建议从事软件开发的开发人员学习一下软件工程,这是一门非常有价值的学科,所以后来极客时间邀请我开专栏,我首先想到的就是写一个软件工程相关的专栏,而极客时间还没有这样的专栏,所以我们初步达成了做软件工程专栏的意向。
项目开始之前不要忘记可行性研究
在有想法后,并不是直接就立项开始做,在软件工程中会有可行性研究。在专栏开始之初,也是有一个磨合的过程,我会试写几篇稿子与极客时间内容团队一起打磨,双方都需要通过磨合来确认是不是可能继续合作,当磨合好后,双方觉得没问题了才会最终立项。
如果没有经过可行性研究就贸然立项,到项目开始才发现不适合,那对双方都是不负责任的。所以项目开始之前,先进行可行性研究,是避免损失的有效方式。
项目未动,计划先行
一个项目开始之前,制定计划是保障项目正常推进的关键。一个专栏 40 多篇文章,每周更新 3 篇,如果没有一个科学的计划,没有 Dead Line,那是很难保证项目进度的。所以要做到项目未动,计划先行。
在制定计划时,也不能盲目乐观,还要考虑到项目风险。比如说作者临时有事可能就会有断更的风险,这时就需要对风险进行控制。
在具体实现一个项目之前,先进行分析和设计
在做一个软件项目的时候,首先要做的就是分析需求,然后根据需求分析的结果设计架构。对于一个专栏来说也是这样的,首先要考虑清楚专栏的主题是什么?专栏的受众是谁?他们想要什么样的内容,然后再去设计专栏的目录。
可以说专栏的目录对于一个专栏的成功至关重要,如果没有目录直接天马行空去写,可能会导致写出来的内容偏离主题,用户也不容易理解。当然目录也不是一成不变的,在写作的过程中,根据大家的反馈,我也会做一些微小调整。
从瀑布模型到敏捷开发,从集中交付到持续交付
传统书籍的出版,类似于瀑布模型,作者统一完成书稿,然后交给编辑修订,最后出版。而现在的专栏写作,更像敏捷开发,作者每完成一篇内容,就交给编辑审阅,反复修订后才可以上线发布。《软件工程之美》专栏采用的是持续交付模式,甚至于提纲写好了就先交付,编辑给出反馈意见后,进一步补充完善细节,最终完成上线。
测试和线上维护也很重要
我平时在网上也会写一些文章,通常写完就发出去了,甚至都没有仔细检查,结果经常是有读者留言才发现很多错误。但专栏文章的发布,每一篇除了自己检查,编辑还会对内容进行校对,避免出现错别字或者语法错误,从而保证大家阅读专栏时的体验。
软件发布后还会对线上的版本维护,保障稳定运行。专栏每一篇文章上线后,都会有同学留言,对同学的留言进行回复也是很重要的工作,可以帮助同学解答一些文章中的疑惑,也可以从同学们的留言中收获很多有价值的反馈。
项目完成后,不忘总结复盘
如果说软件工程之美专栏是一个项目,现在也到了总结复盘的时候了。
首先从做的不太完善的地方开始,总结经验教训。我平时在对于知识的理解和学习,更多是停留在思考上,日常并没有养成习惯去把这些思考写成文字。写作专栏的过程,是把这些知识系统思考梳理的过程,如果日常只是零散的思考,写作的时候就需要对很多细节进行学习和补充。
这其实也是我在《学习攻略 | 怎样学好软件工程?》中给你的建议:在学习软件工程时,尝试把学到的知识写下来,去教给其他人,这样你的收获也会是最大的。
接下来,我们复盘下哪些地方做的比较好。
软件工程的知识虽然不像一些编程语言或者框架更新的那样快,但也一直在演进。就像十多年前还是瀑布模型为主流,现在越来越多的是敏捷开发和快速迭代的开发模式;十多年前每日构建还是当时最好的实践之一,而现在持续集成已经取代了每日构建成为新的最佳实践。
我觉得我还算比较幸运,有很多不同的项目和团队的经历,有小创业团队也有大厂。因为大学转专业学习了软件工程的原因,也一直在留心观察工作中的软件工程实践,所以有机会去学习和实践很多软件工程知识,并在这个专栏中,将这些知识输出交付给你。
在专栏更新的过程中,确实引起了不少同学的思考,提出了很多有价值的问题。通过留言,让我有机会去解答一些文章中没有涵盖的内容,通过留言也诞生了很多对专栏精彩的补充分享。通过这些留言,我也切实地感受到很多同学从专栏学习中有收获、有进步,这也是我认为在专栏项目中做的还不错的地方。

埋下一颗种子

日常生活中很多事情,就像去写一个专栏,并不是一个软件项目,但是你应用软件工程的知识去指导去推进,一样可以帮助你有计划、有步骤地完成它,一样可以让你有很多机会去实践软件工程的知识。
你对软件工程知识实践的越多,你对它的理解也会越深刻,这样当你在做软件项目时,你就能更好地应用这些知识,帮助你高质量地完成项目。
通过对大家留言的观察,我也发现那些已经有丰富的项目经验的同学收获是最大的,因为他们很容易将丰富的项目经验和软件工程的知识串起来,把零散的知识点借助专栏的学习一点点构建成了完整的软件工程知识体系。
如果你现在觉得对这些软件工程知识的吸收有限也没关系,当你从第一天开始学习软件工程,就相当于埋下了一颗种子,当今后再遇到项目中的问题,相信你可以跳出细节之外,站在项目的整体去思考,去软件工程的知识中寻找答案,一点一滴的积累,这颗种子不久后就会变成参天大树。
专栏从上线至今,已经 4 个月有余,如果你能坚持学习并真的学以致用、学有所有,这将是最美好的事。虽然现在专栏更新结束,但我们还可以通过留言区再见!谢谢你一路的支持,祝工作顺利!
分享给需要的人,Ta购买本课程,你将得18
生成海报并分享

赞 6

提建议

上一篇
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
下一篇
结课测试 | 这些软件工程知识,你都掌握了吗?
 写留言

精选留言(47)

  • MJ
    2019-06-20
    谢谢老师 👩‍🏫

    作者回复: 🤝谢谢支持

    共 2 条评论
    10
  • Joey
    2019-06-28
    请教宝玉老师:研发质量,可以使用哪些维度去量化? 目前使用千行代码缺陷流出率量化,感觉有一定弊端,一是代码行无法精确统计,二是有时候给研发人员错觉:一种干的多,错的多。 最后感谢宝玉老师这个专栏,也感谢老师对每个问题详细、耐心的解答,受益匪浅!
    展开

    作者回复: 我是不建议对研发进行量化考核的,尤其是Bug率这种,弊远大于利,因为通常写的少的人错的才少! 研发这种事情,最好的模式还是要激励开发人员自驱动去做事,这也就是为什么现在软件公司都流行敏捷开发和OKR(目标与关键结果工作法)。 敏捷开发本质上是让组织小型化、扁平化,减少管理,让项目成员按照流程规范自驱动的做事。 OKR也是让项目成员参与目标的制定,自发制定目标,激发成员自驱动的做事。 如果你要度量代码质量,我建议通过人去度量,也就是负责技术的人应该有能力去度量代码质量的好坏。 要提升代码的质量,我觉得可以通过三个纬度: 1. 架构设计:好的架构设计,降低实现的复杂度; 2. 自动化测试:通过自动化测试和持续集成,将Bug发现在摇篮中; 3. 代码审查:通过代码审查,让水平高的带动水平低的,水平低的学习水平高的,从而提升团队整体的代码质量。

    5
  • OnRoad
    2019-06-22
    感谢老师精彩分享,我是一名汽车软件开发工程师,工作6年,里面很多内容我都遇到了,感触很深,事事皆项目。事事皆工程。

    作者回复: 谢谢你的支持,希望这些知识对你工作能有所帮助,祝工作顺利!

    5
  • javaadu
    2019-11-09
    每次阅读宝玉老师的文章,都能有所收获,自己现在所做的工作是风控系统的后端工程师,对于Java后端这个领域,我已经掌握了大部分常用的技术栈,并在JVM这块具备了一点深度,不过,目前发现该岗位对自己有一些新的需求:具备基本的前端开发技能;具备一定的数据算法能力;具备优秀的项目管理能力等等。 如何在后面的工作中实现破局?我就准备使用在这门课中学习到的思维——万事皆项目,将想法一点点落地,有计划有步骤得去提升自己的能力,加油💪
    展开

    作者回复: 建议除了计划和步骤外,职业规划上多思考多找资深同事请教,想清楚三年五年甚至十年后的职业目标是什么,再去制定计划就更能有的放矢,少走弯路。 前端如果要用懂一点恐怕是不够的,建议多花一点时间精力,前后端都能做并且都比较深入的话,在技术上是很有竞争力的

    4
  • 文若
    2019-08-14
    全部学完了,感觉很有收获,老师能否推荐一些关于敏捷开发的书。

    作者回复: 《敏捷实践指南》、《敏捷武士》、《高效程序员的45个习惯》、《敏捷革命》都可以参阅

    4
  • 2019-07-14
    请问老师关于代码review有什么好的做法可以推荐呢

    作者回复: 抱歉回复晚了一点,因为我专门去写了一片长文: https://www.weibo.com/ttarticle/p/show?id=2309404394657529331917

    共 4 条评论
    4
  • 江湖刺客
    2019-06-27
    非常感谢老师的课程,部分课程读了很多遍。项目经理程序员都做了几年,老师的课程对我的知识梳理总结帮助很大,通过课程及网友评论也开阔了视野

    作者回复: 🙏谢谢支持,能有帮助是最好不过的了!

    4
  • 冰糕不冰
    2019-06-21
    感谢老师!真的学到很多,不过我还要反复阅读,应用到工作中

    作者回复: 也谢谢你的支持🤝 后续有学习上的问题,也欢迎留言提问。

    4
  • 一步
    2019-06-20
    万事皆项目,在日常中应用软件工程的思想

    作者回复: 👍

    4
  • yu
    2019-06-20
    軟件工程之美,提供了更宏寬的視角,去檢視工程項目中的每一個流程與規範,並且描述了軟件工程中最佳實踐法則與各家大廠經驗守則。並且很好的融入實踐與理論,為每個開發者在浩瀚與混沌並存的軟件開發工程中提供一盞明燈。提起燈,找到路,開始走,是這個專欄最佳的實踐方法。感謝老師的經驗分享。

    作者回复: 👍你这个总结比我自己写得好,按编辑的话说:感性多了!😃 🙏感谢你的支持!

    5
  • 宝宝太喜欢极客时间了
    2019-06-20
    万事皆项目,每周二、四、六早上到单位第一件事就是看老师专栏,突然结束了感觉空落落的,哈哈,感谢老师

    作者回复: 谢谢一路的支持🙏

    共 2 条评论
    4
  • 不靠谱的琴谱
    2019-08-31
    感谢宝玉老师让我大开眼界,一个值得熬夜看的专栏。

    作者回复: 🤝也谢谢你的支持

    3
  • 大王叫我来巡山
    2019-08-20
    学完了,并且做了花了7个小时做了复盘,感谢老师。复盘的思维导图:https://github.com/Abner1990/notes 给大家复习提供个思路

    作者回复: 👍谢谢分享! 如果能导出成html或者pdf格式将会更利于大家查阅参考:)

    共 2 条评论
    3
  • gfkdcadet
    2019-06-23
    软件工程的专栏确实是很稀有的内容。 大家习惯从局部技术出发讲述,视角比较窄,而讲好软件工程则需要宽广的视野。而且要讲出软件工程之美更是需要丰富的体验和思考。 宝玉老师讲软件工程,重传道。从软件开发之道出发,引出自己的思考,映射自己的工作经验,非常解渴。 我还发现,宝玉老师讲软件工程知识,重覆盖面。全流程的开发过程,让我对软件开发工作有了全面的认知,很快的跟上了研发工作的思路,对于我的工作有很大的助益。 最后,感谢宝玉老师如此热心的讲述。祝好!
    展开

    作者回复: 也谢谢你的支持🙏 祝好!

    3
  • Miletos
    2019-06-23
    种子已种下,开始发芽。

    作者回复: 祝早日长成参天大树!

    3
  • hhk
    2020-08-09
    其实我是跳着看的. 买这门课是因为我觉得自己, 在工作上, 需要做一些“心理建设”. 比如说, 项目排期不合理, 我该怎么样去给产品经理项目经理去解释确实需要怎么多时间; 欠下的技术债务该怎么去看待、处理; 项目内不同角色对需求理解不同的时候, 大家怎么去沟通以达到一种都可以接受的平衡等等. 那么我现在的感受就是做事情要有大局观, 整体意识. 同时也更能体会到一套合理的方法论和完整的工作流程, 对于完成一个项目(做一件事情)的益处. 特别喜欢老师说的“万事皆项目”, 我觉得做技术人员给我带来的一个很大的改变就是, 我慢慢会开始把从技术上和项目上学的的一些东西用到生活中. 谢谢老师, 感谢您的分享交流.
    展开
    2
  • Sylh
    2019-08-26
    老师,整体学完了,但在实际应用过程中存在很多问题,比如一个完整的项目开发流程是什么?各个阶段中每个人负责的主要工作是什么?需求分析阶段,架构设计阶段,评审阶段,原型设计阶段等; web类型项目是先做界面原型还是先做架构设计? 前后端分离方式的开发,接口设计是在界面原型之后吗? 现在感觉把软件工程应用在一个完整的项目还是比较困难。 希望有张大图,能完整覆盖软件工程各个阶段每个项目参与者的工作和输出。 谢谢
    展开

    作者回复: 一个完整的开发流程根据开发模型的不同会有所不同,但总体上来说,会有需求分析、系统设计、开发和测试这几个主要阶段,对于迭代模型或者敏捷开发,这几个阶段是周期性的迭代进行。 各个阶段负责的主要工作可以参考《03 | 瀑布模型:像工厂流水线一样把软件开发分层化》、《06/07 | 大厂都在用哪些敏捷方法?》和《43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?》中的案例。 界面原型是帮助确定需求,确定界面交互,架构设计是对已经确定的需求进行技术架构上的设计,所以通常界面原型在前,但如果需求已经明确也可以并行。 接口设计是架构设计的一部分。 不用着急完整应用,可以先观察,然后思考后部分应用,再总结反思改进。

    2
  • 纯洁的憎恶
    2019-06-23
    感谢宝玉老师的4个月的陪伴与耐心讲解,尤其感谢老师对每个留言的认真回复和靠谱建议。 虽说我是科班出身,但工作与软件开发关系不大,然而有幸以业务负责人的身份,深度参与了几个软件项目建设。可惜我对软件工程的认识大多还停留在野路子的层面。宝玉老师让我开阔了眼界、增长了见识,使我能够有针对性的思考软件项目管理中遇到的问题,我也确实找到了不少答案。万事皆项目的思维方式,也会让我在其他工作中获得灵感。更令人高兴的是,我还借此影响了一批没接触过软件工程的领导和同事,让他们更支持我的工作。除此之外,我还了解到一个优秀的工程师乃至职场人应该具备的素质,以及如何有效学习使自身价值不断提升。但我也发现自己和公司对软件工程的实践仍然很肤浅,尚未涉猎像敏捷开发、持续集成、自动化测试、自动化工具等等业界比较先进的手段。不止软件工程方面,在信息技术应用这个大方向上还有很长的路要走。 虽然工作与所学专业无关,但我依旧在极客时间订阅了不少课程,也许是出于对求学时光的依恋与不舍吧,实在不忍心把它丢弃了。其中,数据结构与算法之美学得最用心,软件工程之美收获最大,也有一些课因为离行太久,啃起来十分吃力渐渐放弃了。这也不难理解,毕竟对于我来说算法最基础,软件工程与工作最近,其他课程多介于两者之间吧。这也算是找到了一个有效使用极客时间的方法吧。从兴趣和工作出发,通过实践促进学习,再学以致用不断循环强化。在这个智能时代里,谁能说自己与计算机无关呢?谁又愿意被时代抛弃呢?
    展开

    作者回复: 你的留言也让我印象深刻,明显有很多结合项目的感悟在其中。 相信这些软件工程知识能帮助你的工作带来一些积极的变化。 祝工作顺利!

    2
  • hua168
    2019-06-22
    宝哥,有微博之类吗?这么快就结束了,以后想你了怎么找你😂

    作者回复: 我微博账号是 @宝玉xp

    2
  • Sam_Deep_Thinking
    2019-06-21
    我们这边不同,所做的软件应用极度不健康,bug多,因此当前最重要的是,先保证软件稳定,bug少,这个是第一重要的事情,且不能随便往上面叠加大需求了,尽量让产品方和业务方多提优化需求。因此在当前业务和技术实际情况下,我是不喜欢有dead line思想的,如果业务方或者产品方定死了时间的,我这边大部分情况下是通通不接受的,必须等我们研发这边做了 【可行性分析】【需求分析】【技术分析】【估故事点:估的最重要目的是知道细节,研发知道要具体做什么,跟工作量没啥关系】后,才给出提测的时间点。
    展开

    作者回复: 👍保障质量和搞清楚需求都是至关重要的事情。 我现在项目组也是没有强Dead Line,但是每个Sprint还是会承诺一些,并交付一些内容,一方面可以让开发有进度的压力,一方面让业务也有收获,每个Sprint都有新的进展。

    2