本文探讨了软件开发中常见的问题，如架构实践与实际应用的结合、文档价值、团队技术选型、开源技术选型策略、技术选型原则等。强调了实践和文档的价值，建议团队成员通过业余项目提升技术，以及在技术选型时考虑成熟度和团队熟悉度。同时，提出了重构的原则，代码管理和自动化测试的重要性，以及在微服务架构中如何处理服务间的依赖。
本文转载自：纯干货丨18个软件开发常见问题及解决策略，你有遇到吗？
No.1
每次看这些架构的思想方法的时候，总是和实际的应用没能很好的结合起来，原因是不是架构设计的实践不够？或者是对各种实现的分析和思考太少？
我觉得不仅要有架构实践，还要有不同场景的实践。
举个例子来说，你平时做企业应用架构，没什么流量，没多少数据，复杂的地方都在业务逻辑，这时候你去看那些讲大数据、讲高并发的文章，很难带入到场景去。
还有就是一些架构，不自己搭一遍是很难了解其中的优缺点的，这也是另一个原因。
可以考虑有机会自己尝试，把看到的一些好的架构用一个原型程序搭一遍，造一点数据出来，用工具压测一下，这样会更有感觉。
和实际应用想结合的问题，一方面说明你现有的架构可能并没有什么大问题，没有那么迫切的需求要改造；另一方面可能还是因为缺少实践经验，心里没底，不知道真用上了有没有用。
No.2
比较规范的文档有哪些，他们功能分别是什么？
对于瀑布模型，每个阶段结束后，都有相应的验收文档，而敏捷开发则没有那么多硬性的要求，而是根据项目需要，写必要的文档。
有些团队对于测试阶段，会有测试用例文档、测试验收报告，发布前还会有部署文档、维护手册，但现在这类文档基本上被测试工具、部署脚本替代了，也没有什么存在必要。
我觉得项目中必要的文档，主要包括这几类：
- 设计类文档：这类文档主要用来说明、讨论需求设计、架构设计，可以用来了解、讨论和评审，以及记录后续结果。
- 说明类文档：这类文档用来对规范、API、配置、操作等做说明，便于规范和统一。
- 报告类文档：对事情结果的报告和说明，比如说验收报告、故障报告、调研等。
而这些文档的价值，在于帮助成员了解设计、参与讨论，记录项目成果，减少沟通成本。重要的不是文档多丰富，而是这些文档有没有价值，你能不能及时通过这些文档得到想要的答案。
所以你也可以对照一下你的项目中，现在的文档有哪些地方是可以简化的，哪些地方是要增强的。
比如说，概要设计 / 接口设计 / 详细设计是不是可以适当合并，减轻文档工作？PRD 是不是够详细？会不会引起歧义不容易理解，要不要增加原型设计文档辅助？
No.3
项目团队的开发人员
最低0.47元/天 解锁文章
扫一扫
366
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
