“一问一答”第3期 | 18个软件开发常见问题解决策略
宝玉
你好，我是宝玉。我们专栏已经完成了架构设计和开发这两个模块的学习。这两个模块都是和技术有很大关系，也是很多人关心的内容。
希望你通过对架构设计内容的学习，能控制好软件项目中技术复杂的问题。遇到技术选型，能心中有数，通过一个科学的过程去完成选型；对于项目中的技术债务，能及早识别，及早应对。
通过对开发模块的学习，可以帮助你在项目中搭建持续集成环境，推行自动化测试，改进基于源代码管理工具的开发流程。借助工具和流程，让你项目的开发质量更上一个台阶。
本篇继续分享同学们的精彩留言，这些问答和同学们的分享都是对专栏内容的最好补充，希望可以帮助你更好地学习和理解软件工程知识。
一问一答
No.1
一路向北：每次看这些架构的思想方法的时候，总是和实际的应用没能很好的结合起来，原因是不是架构设计的实践不够？或者是对各种实现的分析和思考太少？
宝玉：我觉得不仅要有架构实践，还要有不同场景的实践。
举个例子来说，你平时做企业应用架构，没什么流量，没多少数据，复杂的地方都在业务逻辑，这时候你去看那些讲大数据、讲高并发的文章，很难带入到场景去。
还有就是一些架构，不自己搭一遍是很难了解其中的优缺点的，这也是另一个原因。
可以考虑有机会自己尝试，把看到的一些好的架构用一个原型程序搭一遍，造一点数据出来，用工具压测一下，这样会更有感觉。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《软件工程之美》，新⼈⾸单¥59
《软件工程之美》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(6)
- 最新
- 精选
mgxian重构最重要的原则是小步快跑 甚至小到你觉得这一步没有必要 这样做的意义是可以随时停下来 不影响用来的功能正常运行 如果出错 由于步子小 你很容易能找到哪里修改出现了错误 重构之前一定要写测试 如果没有测试你将不知道自己的重构有没有破坏原来的功能。 测试可以使用BDD的测试形式 测试不是说为每一个函数 每一个类写一个单元测试 应该为那些 public api 写测试，为使用场景写测试。想把测试写好 可以看看 那本测试驱动开发 tdd by example 重构强烈建议看看 重构第二版 注意看每一个重构小步骤 每一个小步骤都是为了可以让重构随时停下来 而不影响原来的功能作者回复: 👍👍非常有价值的分享！
5
Sudouble以前天天追着某种开发语言的语法，最近渐渐地意识到，学好语法其实也仅仅起了个头，如同刚学会写字的小学生，要写出优美的散文，又是另外一回事了。 还有是测试驱动开发的强大之处。自己写了一个小软件，最近要加新功能和补bug，庆幸那时候忍着补齐了测试代码，不然在改动里真是寸步难行。作者回复: 👍是呀，语言学会不难，要用好才行！ 测试覆盖很重要，重构的时候就省心了！
3
易林林特别感谢宝玉老师准备如此精彩的专栏，使我们无论在技术、架构、产品、管理方面都得以全面成长。看到IT同行如此多独特的见解，受益匪浅，同时发现自己还有很多需要思考和践行的地方。作者回复: 也谢谢你还有其他很多的精彩留言，补充了很多有用的分享👍
3
纯洁的憎恶学习到的知识一定要多用，而且要变着花样的用。作者回复: 👍知识应用了才能变成自己的
2
無名老师好，我们在敏捷流程中遇到一个问题 现状：现在有多个敏捷组并行运行，一般都是各组承接自己组的模块功能开发，这是比较理想的情况，但是我们遇到好多个大需求，贯穿了好几个敏捷组负责的模块，在排期的时候又因为其他组没有人力的原因无无法排入只能硬头皮去改另一个组的功能。并且同期另一个组也还继续开发自己的需求。 问题 1.有没有什么策论能够解决这个穿插各组需求问题，虽然我觉得不能因为人力原因就把活等给不熟悉的一个组，但是现实就是为了某个目标硬排入归属地：北京
ifelse
学习了
收起评论
