【软件工程之美 - 专栏笔记】“一问一答”第3期 | 18个软件开发常见问题解决策略

---

专栏信息

1. 专栏作者：宝玉

2. 专栏发布平台：极客时间

---

主要内容

---

一、一问一答

1. 问：每次看这些架构的思想方法的时候，总是和实际的应用没能很好的结合起来，原因是不是架构设计的实践不够？或者是对各种实现的分析和思考太少？

   答：我觉得不仅要有架构实践，还要有不同场景的实践。

   举个例子来说，你平时做企业应用架构，没什么流量，没多少数据，复杂的地方都在业务逻辑，这时候你去看那些讲大数据、讲高并发的文章，很难带入到场景去。

   还有就是一些架构，不自己搭一遍是很难了解其中的优缺点的，这也是另一个原因。

   可以考虑有机会自己尝试，把看到的一些好的架构用一个原型程序搭一遍，造一点数据出来，用工具压测一下，这样会更有感觉。

   和实际应用相结合的问题，一方面说明你现有的架构可能并没有什么大问题，没有那么迫切的需求要改造；另一方面可能还是因为缺少实践经验，心里没底，不知道真用上了有没有用。

2. 问：比较规范的文档有哪些，他们功能分别是什么？

   答：对于瀑布模型，每个阶段结束后，都有相应的验收文档，而敏捷开发则没有那么多硬性的要求，而是根据项目需要，写必要的文档。

   我觉得项目中必要的文档，主要包括这几类：

   1. 设计类文档

      这类文档主要用来说明、讨论需求设计、架构设计，可以用来了解、讨论和评审，以及记录后续结果。

   2. 说明类文档

      这类文档用来对规范、API、配置、操作等做说明，便于规范和统一。

   3. 报告类文档

      对事情结果的报告和说明，比如说验收报告、故障报告、调研等。

   而这些文档的价值，在于帮助成员了解设计、参与讨论，记录项目成果，减少沟通成本。重要的不是文档多丰富，而是这些文档有没有价值，你能不能及时通过这些文档得到想要的答案。

   所以你也可以对照一下你的项目中，现在的文档有哪些地方是可以简化的，哪些地方是要增强的。

   比如说，概要设计 / 接口设计 / 详细设计是不是可以适当合并，减轻文档工作量？PRD 是不是够详细？会不会引起歧义不容易理解，要不要增加原型设计文档辅助？

3. 问：互联网架构，要考虑互联网很快的迭代速度，所以对于扩展等特别注意。企业架构，内部 IT 系统相对稳定，对比互联网架构，更简单？

   答：挺好的分析。帮你补充几点：互联网架构不仅迭代会快一些，用户规模通常更大，但业务也会单一些；企业应用通常业务比较复杂，尤其是和行业会有一些结合，但是用户规模要小很多。这些特点，都会影响架构设计的选择。

4. 问：有没有事情管理的工具？因为如果不记录下来，一会儿就忘记了。

   答：留言区 McCree 同学推荐了滴答清单。我个人的话，一般就用系统自带的记事本记一下，或者贴一个便签纸在显示器。如果时间跨度长，我就记到 Calendars 上，加上提醒。工作中的任务，我则会创建成 Ticket。

5. 问：老师所讲排查生产问题的案例，首先回滚版本，再看日志。这会引发更多的系统功能不可用吧，两个版本之间的功能差异尚不清楚就直接回滚，系统风险是否被进一步扩大？

   答：这个确实要具体情况具体看，因为我日常的系统上线，都会有回滚方案，回滚也是自动化的很方便。有些跟数据库相关的，如果数据库结构发生变化又产生了新数据，确实没法直接回滚。

---

二、精选留言

1. 在没有特殊要求的情况下，项目中更加倾向选择更为熟悉的技术，因为我们需要对项目的质量与交付时间负责，可以做到可控的。而新技术有着新的设计思想与强大的功能，同时也伴随着无法预知的“坑”。在后续产品迭代的时间里，有针对性的升级或者选择更换同类技术里更优的。

2. 技术债务不全坏，与金融债务一样，需要具体问题具体分析。轻率 & 有意的债务要避免。谨慎 & 有意的债务有收益。轻率 & 无意的债务要警惕。谨慎 & 无意的债务要改变。识别债务防患于未然。根据成本收益分析，决定重写（一次性还款）、维持（只还利息）还是重构（分期付款）。相关阅读：24 | 技术债务：是继续修修补补凑合着用，还是推翻重来？

---

总结

问答和留言很长，这里只节选了一部分。