2019-06-20谢谢老师 👩🏫作者回复: 🤝谢谢支持
1 7
2019-06-22感谢老师精彩分享，我是一名汽车软件开发工程师，工作6年，里面很多内容我都遇到了，感触很深，事事皆项目。事事皆工程。作者回复: 谢谢你的支持，希望这些知识对你工作能有所帮助，祝工作顺利！
4
2019-06-20万事皆项目，在日常中应用软件工程的思想作者回复: 👍
4- 2019-06-20万事皆项目，每周二、四、六早上到单位第一件事就是看老师专栏，突然结束了感觉空落落的，哈哈，感谢老师
作者回复: 谢谢一路的支持🙏
4 
2019-08-31感谢宝玉老师让我大开眼界，一个值得熬夜看的专栏。作者回复: 🤝也谢谢你的支持
3
2019-11-09每次阅读宝玉老师的文章，都能有所收获，自己现在所做的工作是风控系统的后端工程师，对于Java后端这个领域，我已经掌握了大部分常用的技术栈，并在JVM这块具备了一点深度，不过，目前发现该岗位对自己有一些新的需求：具备基本的前端开发技能；具备一定的数据算法能力；具备优秀的项目管理能力等等。
如何在后面的工作中实现破局？我就准备使用在这门课中学习到的思维——万事皆项目，将想法一点点落地，有计划有步骤得去提升自己的能力，加油💪作者回复: 建议除了计划和步骤外，职业规划上多思考多找资深同事请教，想清楚三年五年甚至十年后的职业目标是什么，再去制定计划就更能有的放矢，少走弯路。
前端如果要用懂一点恐怕是不够的，建议多花一点时间精力，前后端都能做并且都比较深入的话，在技术上是很有竞争力的 2- 2019-08-26老师，整体学完了，但在实际应用过程中存在很多问题，比如一个完整的项目开发流程是什么？各个阶段中每个人负责的主要工作是什么？需求分析阶段，架构设计阶段，评审阶段，原型设计阶段等；
web类型项目是先做界面原型还是先做架构设计？
前后端分离方式的开发，接口设计是在界面原型之后吗？
现在感觉把软件工程应用在一个完整的项目还是比较困难。
希望有张大图，能完整覆盖软件工程各个阶段每个项目参与者的工作和输出。
谢谢展开作者回复: 一个完整的开发流程根据开发模型的不同会有所不同，但总体上来说，会有需求分析、系统设计、开发和测试这几个主要阶段，对于迭代模型或者敏捷开发，这几个阶段是周期性的迭代进行。
各个阶段负责的主要工作可以参考《03 | 瀑布模型：像工厂流水线一样把软件开发分层化》、《06/07 | 大厂都在用哪些敏捷方法？》和《43 | 以VS Code为例，看大型开源项目是如何应用软件工程的？》中的案例。
界面原型是帮助确定需求，确定界面交互，架构设计是对已经确定的需求进行技术架构上的设计，所以通常界面原型在前，但如果需求已经明确也可以并行。
接口设计是架构设计的一部分。
不用着急完整应用，可以先观察，然后思考后部分应用，再总结反思改进。 2 
2019-08-20学完了，并且做了花了7个小时做了复盘，感谢老师。复盘的思维导图：https://github.com/Abner1990/notes
给大家复习提供个思路作者回复: 👍谢谢分享！
如果能导出成html或者pdf格式将会更利于大家查阅参考：） 1 2
2019-07-14请问老师关于代码review有什么好的做法可以推荐呢作者回复: 抱歉回复晚了一点，因为我专门去写了一片长文：
https://www.weibo.com/ttarticle/p/show?id=2309404394657529331917 2
2019-06-28请教宝玉老师：研发质量，可以使用哪些维度去量化？
目前使用千行代码缺陷流出率量化，感觉有一定弊端，一是代码行无法精确统计，二是有时候给研发人员错觉：一种干的多，错的多。
最后感谢宝玉老师这个专栏，也感谢老师对每个问题详细、耐心的解答，受益匪浅！作者回复: 我是不建议对研发进行量化考核的，尤其是Bug率这种，弊远大于利，因为通常写的少的人错的才少！
研发这种事情，最好的模式还是要激励开发人员自驱动去做事，这也就是为什么现在软件公司都流行敏捷开发和OKR（目标与关键结果工作法）。
敏捷开发本质上是让组织小型化、扁平化，减少管理，让项目成员按照流程规范自驱动的做事。
OKR也是让项目成员参与目标的制定，自发制定目标，激发成员自驱动的做事。
如果你要度量代码质量，我建议通过人去度量，也就是负责技术的人应该有能力去度量代码质量的好坏。
要提升代码的质量，我觉得可以通过三个纬度：
1. 架构设计：好的架构设计，降低实现的复杂度；
2. 自动化测试：通过自动化测试和持续集成，将Bug发现在摇篮中；
3. 代码审查：通过代码审查，让水平高的带动水平低的，水平低的学习水平高的，从而提升团队整体的代码质量。 2
2019-06-27非常感谢老师的课程，部分课程读了很多遍。项目经理程序员都做了几年，老师的课程对我的知识梳理总结帮助很大，通过课程及网友评论也开阔了视野作者回复: 🙏谢谢支持，能有帮助是最好不过的了！
2
2019-06-23感谢宝玉老师的4个月的陪伴与耐心讲解，尤其感谢老师对每个留言的认真回复和靠谱建议。
虽说我是科班出身，但工作与软件开发关系不大，然而有幸以业务负责人的身份，深度参与了几个软件项目建设。可惜我对软件工程的认识大多还停留在野路子的层面。宝玉老师让我开阔了眼界、增长了见识，使我能够有针对性的思考软件项目管理中遇到的问题，我也确实找到了不少答案。万事皆项目的思维方式，也会让我在其他工作中获得灵感。更令人高兴的是，我还借此影响了一批没接触过软件工程的领导和同事，让他们更支持我的工作。除此之外，我还了解到一个优秀的工程师乃至职场人应该具备的素质，以及如何有效学习使自身价值不断提升。但我也发现自己和公司对软件工程的实践仍然很肤浅，尚未涉猎像敏捷开发、持续集成、自动化测试、自动化工具等等业界比较先进的手段。不止软件工程方面，在信息技术应用这个大方向上还有很长的路要走。
虽然工作与所学专业无关，但我依旧在极客时间订阅了不少课程，也许是出于对求学时光的依恋与不舍吧，实在不忍心把它丢弃了。其中，数据结构与算法之美学得最用心，软件工程之美收获最大，也有一些课因为离行太久，啃起来十分吃力渐渐放弃了。这也不难理解，毕竟对于我来说算法最基础，软件工程与工作最近，其他课程多介于两者之间吧。这也算是找到了一个有效使用极客时间的方法吧。从兴趣和工作出发，通过实践促进学习，再学以致用不断循环强化。在这个智能时代里，谁能说自己与计算机无关呢？谁又愿意被时代抛弃呢？展开作者回复: 你的留言也让我印象深刻，明显有很多结合项目的感悟在其中。
相信这些软件工程知识能帮助你的工作带来一些积极的变化。
祝工作顺利！ 2
2019-06-21我们这边不同，所做的软件应用极度不健康，bug多，因此当前最重要的是，先保证软件稳定，bug少，这个是第一重要的事情，且不能随便往上面叠加大需求了，尽量让产品方和业务方多提优化需求。因此在当前业务和技术实际情况下，我是不喜欢有dead line思想的，如果业务方或者产品方定死了时间的，我这边大部分情况下是通通不接受的，必须等我们研发这边做了 【可行性分析】【需求分析】【技术分析】【估故事点：估的最重要目的是知道细节，研发知道要具体做什么，跟工作量没啥关系】后，才给出提测的时间点。作者回复: 👍保障质量和搞清楚需求都是至关重要的事情。
我现在项目组也是没有强Dead Line，但是每个Sprint还是会承诺一些，并交付一些内容，一方面可以让开发有进度的压力，一方面让业务也有收获，每个Sprint都有新的进展。 2
2019-06-21感谢老师！真的学到很多，不过我还要反复阅读，应用到工作中作者回复: 也谢谢你的支持🤝
后续有学习上的问题，也欢迎留言提问。 2- 2019-06-20宝玉老师，收集的用户需求有专门的工具吗，目前我用过Tfs,云效，都不好对需求进行闭环，有更合适的吗
作者回复: 如果你结合在线文档工具来收集需求应该会更好一点，比如说Google Docs或者石墨文档。
也就是说对于需求的收集、描述、讨论都放到在线文档工具中进行，定稿后，提交Ticket，Ticket中链接需求文档，这样可以基于Ticket跟踪整个需求的开发和上线过程。对于没有定稿的需求，继续放在在线文档中讨论即可。
在线文档也可以按照目录去归类需求文档。 2 
2019-06-20軟件工程之美，提供了更宏寬的視角，去檢視工程項目中的每一個流程與規範，並且描述了軟件工程中最佳實踐法則與各家大廠經驗守則。並且很好的融入實踐與理論，為每個開發者在浩瀚與混沌並存的軟件開發工程中提供一盞明燈。提起燈，找到路，開始走，是這個專欄最佳的實踐方法。感謝老師的經驗分享。作者回复: 👍你这个总结比我自己写得好，按编辑的话说：感性多了！😃
🙏感谢你的支持！ 2
2019-08-14全部学完了，感觉很有收获，老师能否推荐一些关于敏捷开发的书。作者回复: 《敏捷实践指南》、《敏捷武士》、《高效程序员的45个习惯》、《敏捷革命》都可以参阅
1
2019-06-27感谢老师作者回复: 🤝也谢谢你的支持
1
2019-06-25很感谢老师授课，受益匪浅作者回复: 🤝谢谢你的支持
1
2019-06-23软件工程的专栏确实是很稀有的内容。
大家习惯从局部技术出发讲述，视角比较窄，而讲好软件工程则需要宽广的视野。而且要讲出软件工程之美更是需要丰富的体验和思考。
宝玉老师讲软件工程，重传道。从软件开发之道出发，引出自己的思考，映射自己的工作经验，非常解渴。
我还发现，宝玉老师讲软件工程知识，重覆盖面。全流程的开发过程，让我对软件开发工作有了全面的认知，很快的跟上了研发工作的思路，对于我的工作有很大的助益。
最后，感谢宝玉老师如此热心的讲述。祝好！作者回复: 也谢谢你的支持🙏
祝好！ 1