结束语 | 万事皆项目,软件工程无处不在
结束语 | 万事皆项目,软件工程无处不在
讲述:宝玉
时长08:12大小6.58M
万事皆项目
埋下一颗种子
赞 6
提建议
精选留言(47)
- MJ2019-06-20谢谢老师 👩🏫
作者回复: 🤝谢谢支持
共 2 条评论10 - Joey2019-06-28请教宝玉老师:研发质量,可以使用哪些维度去量化? 目前使用千行代码缺陷流出率量化,感觉有一定弊端,一是代码行无法精确统计,二是有时候给研发人员错觉:一种干的多,错的多。 最后感谢宝玉老师这个专栏,也感谢老师对每个问题详细、耐心的解答,受益匪浅!展开
作者回复: 我是不建议对研发进行量化考核的,尤其是Bug率这种,弊远大于利,因为通常写的少的人错的才少! 研发这种事情,最好的模式还是要激励开发人员自驱动去做事,这也就是为什么现在软件公司都流行敏捷开发和OKR(目标与关键结果工作法)。 敏捷开发本质上是让组织小型化、扁平化,减少管理,让项目成员按照流程规范自驱动的做事。 OKR也是让项目成员参与目标的制定,自发制定目标,激发成员自驱动的做事。 如果你要度量代码质量,我建议通过人去度量,也就是负责技术的人应该有能力去度量代码质量的好坏。 要提升代码的质量,我觉得可以通过三个纬度: 1. 架构设计:好的架构设计,降低实现的复杂度; 2. 自动化测试:通过自动化测试和持续集成,将Bug发现在摇篮中; 3. 代码审查:通过代码审查,让水平高的带动水平低的,水平低的学习水平高的,从而提升团队整体的代码质量。
5 - OnRoad2019-06-22感谢老师精彩分享,我是一名汽车软件开发工程师,工作6年,里面很多内容我都遇到了,感触很深,事事皆项目。事事皆工程。
作者回复: 谢谢你的支持,希望这些知识对你工作能有所帮助,祝工作顺利!
5 - javaadu2019-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 - yu2019-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 - gfkdcadet2019-06-23软件工程的专栏确实是很稀有的内容。 大家习惯从局部技术出发讲述,视角比较窄,而讲好软件工程则需要宽广的视野。而且要讲出软件工程之美更是需要丰富的体验和思考。 宝玉老师讲软件工程,重传道。从软件开发之道出发,引出自己的思考,映射自己的工作经验,非常解渴。 我还发现,宝玉老师讲软件工程知识,重覆盖面。全流程的开发过程,让我对软件开发工作有了全面的认知,很快的跟上了研发工作的思路,对于我的工作有很大的助益。 最后,感谢宝玉老师如此热心的讲述。祝好!展开
作者回复: 也谢谢你的支持🙏 祝好!
3 - Miletos2019-06-23种子已种下,开始发芽。
作者回复: 祝早日长成参天大树!
3 - hhk2020-08-09其实我是跳着看的. 买这门课是因为我觉得自己, 在工作上, 需要做一些“心理建设”. 比如说, 项目排期不合理, 我该怎么样去给产品经理项目经理去解释确实需要怎么多时间; 欠下的技术债务该怎么去看待、处理; 项目内不同角色对需求理解不同的时候, 大家怎么去沟通以达到一种都可以接受的平衡等等. 那么我现在的感受就是做事情要有大局观, 整体意识. 同时也更能体会到一套合理的方法论和完整的工作流程, 对于完成一个项目(做一件事情)的益处. 特别喜欢老师说的“万事皆项目”, 我觉得做技术人员给我带来的一个很大的改变就是, 我慢慢会开始把从技术上和项目上学的的一些东西用到生活中. 谢谢老师, 感谢您的分享交流.展开2
- Sylh2019-08-26老师,整体学完了,但在实际应用过程中存在很多问题,比如一个完整的项目开发流程是什么?各个阶段中每个人负责的主要工作是什么?需求分析阶段,架构设计阶段,评审阶段,原型设计阶段等; web类型项目是先做界面原型还是先做架构设计? 前后端分离方式的开发,接口设计是在界面原型之后吗? 现在感觉把软件工程应用在一个完整的项目还是比较困难。 希望有张大图,能完整覆盖软件工程各个阶段每个项目参与者的工作和输出。 谢谢展开
作者回复: 一个完整的开发流程根据开发模型的不同会有所不同,但总体上来说,会有需求分析、系统设计、开发和测试这几个主要阶段,对于迭代模型或者敏捷开发,这几个阶段是周期性的迭代进行。 各个阶段负责的主要工作可以参考《03 | 瀑布模型:像工厂流水线一样把软件开发分层化》、《06/07 | 大厂都在用哪些敏捷方法?》和《43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?》中的案例。 界面原型是帮助确定需求,确定界面交互,架构设计是对已经确定的需求进行技术架构上的设计,所以通常界面原型在前,但如果需求已经明确也可以并行。 接口设计是架构设计的一部分。 不用着急完整应用,可以先观察,然后思考后部分应用,再总结反思改进。
2 - 纯洁的憎恶2019-06-23感谢宝玉老师的4个月的陪伴与耐心讲解,尤其感谢老师对每个留言的认真回复和靠谱建议。 虽说我是科班出身,但工作与软件开发关系不大,然而有幸以业务负责人的身份,深度参与了几个软件项目建设。可惜我对软件工程的认识大多还停留在野路子的层面。宝玉老师让我开阔了眼界、增长了见识,使我能够有针对性的思考软件项目管理中遇到的问题,我也确实找到了不少答案。万事皆项目的思维方式,也会让我在其他工作中获得灵感。更令人高兴的是,我还借此影响了一批没接触过软件工程的领导和同事,让他们更支持我的工作。除此之外,我还了解到一个优秀的工程师乃至职场人应该具备的素质,以及如何有效学习使自身价值不断提升。但我也发现自己和公司对软件工程的实践仍然很肤浅,尚未涉猎像敏捷开发、持续集成、自动化测试、自动化工具等等业界比较先进的手段。不止软件工程方面,在信息技术应用这个大方向上还有很长的路要走。 虽然工作与所学专业无关,但我依旧在极客时间订阅了不少课程,也许是出于对求学时光的依恋与不舍吧,实在不忍心把它丢弃了。其中,数据结构与算法之美学得最用心,软件工程之美收获最大,也有一些课因为离行太久,啃起来十分吃力渐渐放弃了。这也不难理解,毕竟对于我来说算法最基础,软件工程与工作最近,其他课程多介于两者之间吧。这也算是找到了一个有效使用极客时间的方法吧。从兴趣和工作出发,通过实践促进学习,再学以致用不断循环强化。在这个智能时代里,谁能说自己与计算机无关呢?谁又愿意被时代抛弃呢?展开
作者回复: 你的留言也让我印象深刻,明显有很多结合项目的感悟在其中。 相信这些软件工程知识能帮助你的工作带来一些积极的变化。 祝工作顺利!
2 - hua1682019-06-22宝哥,有微博之类吗?这么快就结束了,以后想你了怎么找你😂
作者回复: 我微博账号是 @宝玉xp
2 - Sam_Deep_Thinking2019-06-21我们这边不同,所做的软件应用极度不健康,bug多,因此当前最重要的是,先保证软件稳定,bug少,这个是第一重要的事情,且不能随便往上面叠加大需求了,尽量让产品方和业务方多提优化需求。因此在当前业务和技术实际情况下,我是不喜欢有dead line思想的,如果业务方或者产品方定死了时间的,我这边大部分情况下是通通不接受的,必须等我们研发这边做了 【可行性分析】【需求分析】【技术分析】【估故事点:估的最重要目的是知道细节,研发知道要具体做什么,跟工作量没啥关系】后,才给出提测的时间点。展开
作者回复: 👍保障质量和搞清楚需求都是至关重要的事情。 我现在项目组也是没有强Dead Line,但是每个Sprint还是会承诺一些,并交付一些内容,一方面可以让开发有进度的压力,一方面让业务也有收获,每个Sprint都有新的进展。
2