软件开发项目建议书-平遥古城旅游现状及开发建议

一号

每次看这些架构的思路，总是没能很好的和实际应用结合起来。 是架构设计实践不够的原因吗？ 还是对各种实现的分析和思考太少？

我觉得不仅要进行架构实践，还要在不同的场景下进行实践。

比如你平时做企业应用架构，流量不多，数据也不多，复杂的部分都在业务逻辑上。 这时候你再看大数据和高并发的文章，很难把它们带入场景去。

还有一些架构。 如果不自己构建它们，很难理解某些架构的优点和缺点。 这是另一个原因。

可以考虑有机会自己尝试一下，用原型程序搭建一些你见过的好的架构，创建一些数据，用工具测试一下，这样会让你感觉更好。

结合实际应用的问题，一方面说明你现有的架构可能没有什么大的问题，没有那么迫切需要改造； 另一方面，可能还是因为缺乏实践经验，信心不足，不知道如何使用。 有用吗。

2号

比较规范的文件有哪些，它们的作用是什么？

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

测试阶段，有的团队在发布前有测试用例文档、测试验收报告，还有部署文档和维护手册，但现在这些文档基本都被测试工具和部署脚本代替了，不需要了。

我觉得项目中必备的文件主要有这几类：

设计文档：这类文档主要用于说明和讨论需求设计和架构设计，可用于理解、讨论和审查、记录后续结果。 解释性文档：这类文档用于解释规范、API、配置、操作等，便于标准化和统一。 报告文件：对事物结果的报告和说明，如验收报告、故障报告、调研等。

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

所以你也可以对比一下你的项目，当前文档哪些部分可以简化，哪些部分需要加强。

例如，能否将总体设计/界面设计/详细设计适当结合起来，减少文档工作？ PRD 够详细吗？ 会不会造成歧义，难以理解？ 你想增加原型文件的帮助吗？

3号

项目组的开发人员基本都是从外包公司临时找来的，层次参差不齐，稳定性差。 因此，技术选型更看重技术的普及程度，是否容易学习和掌握。 从这点来看，基本是不可能的。 选择相对小众但在特定领域有效的技术。

再加上它是企业内部管理的系统，数据量和用户数量都是可控的，所以出现技术瓶颈的可能性很小。 整体来说，最好的选择是最成熟最通用的技术，比如选择java技术栈，web开发的ssm框架等，但长期内很难提升团队和个人的技术能力跑步。 老师在这方面有什么建议吗？

我觉得团队的技术提升和项目的技术选型应该分开。 不要总想着两者兼顾，优先保证项目的稳定和低成本运行。

像技术进步这样的事情，需要先让一些人成长起来，然后再去带动其他人。 我会在工作之余做一些业余项目，然后在这些项目中体验新技术，了解它们的优缺点，然后逐步将其应用到工作项目中，并传递给同事。

我也鼓励其他同事也这样做，做一些他们自己的项目。 但是对于工作中的项目，我是非常保守的。

4号

对于开源技术，有没有什么经验可以指导选型？

开源技术选型，我的经历大体是这样的。

先找朋友推荐，少走弯路。 如果没有推荐，请在 Internet 上搜索一些满足您需要的替代方案。 比较以下指标： 按照说明自行尝试。 5号

有没有什么大原则可以指导技术选型？ 比如技术成熟度等？

我觉得在满足设计目标的前提下，大的原则在于项目的约束，尤其是成本和时间，然后还要看技术可行性和风险是否可控。 有的看队风，有的保守，有的求新。

比如我自己的原则：

成熟胜于新，酷； 流行胜于小众； 对团队熟悉总比不熟悉好； 简单胜于复杂； 开源优于商业（有时视情况而定）。 6号

一个正常职位或职称的架构师，了解一个全新项目的产品需求并进行架构设计，在项目开发过程中一般会产生什么“东西”来满足后续的架构讲解和沟通？

互联网产品的特点是用户量大，而企业产品的特点是服务复杂，所以架构侧重点不同。

架构师设计好架构后，首先输出的是架构设计文档，让大家了解架构。 然后我们需要编写架构开发的文档，比如如何基于这个架构开发功能模块，可以调用哪些公共API，什么是最佳实践，应该遵循什么规范。

那么我们需要帮助搭建脚手架和基础模块或者示例项目，也就是搭建一个最基本的可运行项目。 通过这个项目，大家可以直观的了解你的架构是如何实现的。 通过基础模块或者示例工程，可以知道如何基于框架进行开发，也可以在后面实现。

另外，在开发过程中，需要答疑解惑，解决架构中存在的问题，优化架构，进行代码审查，对不符合架构规范的地方进行指出和改正。

7号

互联网架构必须考虑互联网的快速迭代速度，所以要特别注意扩展。 企业架构，内部IT系统相对稳定，与互联网架构相比，是不是更简单？

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

8号

老师能不能详细讲一下重构的原理和注意点，感觉没能领会要领。

我认为重构的要领有两点。

第一：你需要先写一些自动化测试代码，保证这些测试代码可以帮助你重构后发现问题；

第二：重构模块时，先保留旧代码，写新代码，再指向新代码，或者用特定的开关控制新旧代码的指向（方便去后自己测试在线，有问题可以及时关闭）），然后让自动化测试通过，再部署测试，新代码没问题，删掉旧代码。

9号

有活动管理工具吗？ 因为不记下来，过一段时间就会忘记。

我个人一般是用系统自带的记事本记下来，或者在显示器上贴个便利贴。 如果时间跨度长，我会记录在日历上，并添加提醒。 对于工作中的任务，我将创建工单。

10号

现在还有一种说法：提倡基于主分支开发效率更高； 而不是你提到的每个人都基于他们自己的分支开发然后合并回主分支。 你怎么看待这个问题？

我认为对于软件工程来说，很多问题不是只有一种解决方案。 即使是最佳实践也取决于适用的场景和团队。

无论是基于trunk还是branch开发，有两点需要注意：

即必须有一个稳定的分支，可以随时发布。 叫master还是release都无所谓。 合并前需要进行代码审查和自动化测试（使用 CI）。

以上两点是核心。

11号

如果有 5 个开发人员在做一个项目，持续集成如何确保不混乱？ 比如开发者A刚刚修复了bug1，开发者B上传了他修复的bug2，但是之前的代码bug1并没有修复，怎么办？ 如果分支被采用，如何合并？ 如果直接更新master分支，A不就白做了吗？

请注意软件开发项目建议书，它是“合并”而不是“覆盖”。 比如bug1涉及到file1和file3的修改，那么合并开发A时只会合并file1和file3。

开发B修复bug2时，修改file1和file2，直接合并file2，file1需要手动修复合并冲突后才能合并。

大家开发之前，都会从master那里拿到最新的版本。 合并的时候，如果有冲突，必须先解决冲突再合并。 其实你自己去试试吧，你会体会的更深。

12号

在微服务架构中，一个服务在测试环境下的交付验证往往依赖于其他相关服务的新版本，难以独立交付新特性。 这种情况有什么好的办法吗？

我认为大多数时候，微服务应该是独立的，而不是过于紧密地依赖。 如果每一个新功能都是这样，那么架构设计一定有问题，服务划分的合理性需要重新思考。

但是你需要更多的在线或场景，我才能做出一些有针对性的评论。 对于一些确实需要跨服务协作的大特性，这也是正常的，也就是需要共同协作，实现良好的通信协议，分别开发，然后联调。

13号

遇到老师提到的排查生产问题，先回滚版本，再看日志。 这将导致更多的系统功能不可用。 如果两个版本之间的功能差异不清楚，就回滚。 系统风险是否会进一步扩大？

这个真的要看具体情况，因为我日常系统上线软件开发项目建议书，都会有回滚计划，而且回滚也是自动化的，很方便。 有些与数据库有关。 如果数据库结构发生变化，产生了新的数据，直接回滚确实不行。

14号

团队成员的能力和素质参差不齐。 如何有效组织和管理项目的自动化测试和自动化集成？

首先，你需要搭建一个自动化测试环境，让自动化测试代码能够运行起来。 最好将其与CI（持续集成工具）集成。 每次提交代码，CI都会运行自动化测试，然后你就可以看到运行结果。

然后，使用自动化测试作为开发过程的一部分。 例如，在代码审查和自动化测试通过之前，不能合并代码。 这部分工作如果与CI集成的话会容易很多。

然后是培训的需要。 比如遇到不会写字的人，就开始跟他写几句，保证他已经自学写字了。 然后，在下一次 code review 中，如果他发现有遗漏的地方，他会要求补上。 我会继续教，如果没时间写，我会创建一个Ticket来跟踪它。

简单的说就是code review + CI + training。

15号

您通常使用哪些指标来衡量各种类型的测试覆盖率？ 个人觉得在理想情况下，最好能达到100%的覆盖率。

100%的覆盖率，我觉得这也算是一种理想的追求，但是没必要追求极致，最好在进步和质量之间有个平衡，毕竟进步也很重要。

另外，对于前端业务，我更注重集成测试的覆盖率。 主要业务场景的集成测试覆盖到位后，单元测试的覆盖会更多一些，相对来说更划算，然后逐步补充单元测试的覆盖。

16号

如何理解持续集成？ 我在知乎上看到一些团队成员每天多次编译、发布或自动化测试。

狭义的持续集成不包括发布，主要是指集成，持续（每次代码变更提交时触发，频繁提交）代码集成（合并到主干），但在集成之前，需要保证自动化测试通过。 广义的持续集成还包括部署，即集成后自动部署测试环境（持续交付）或生产环境（持续部署）。

17号

有没有关于如何编写好的开发测试的好书？

推荐：《How we test software at microsoft》中文版《微软的软件测试之道》。 但是没有书，其实也能找到很多资料。 比如我平时写前端程序，然后我会去GitHub或者Google，通过关键字和语言找到和我的项目类似的开源项目，然后看看有没有写的好的自动化测试。

如果找到了（例如：reactstrap、electron-react-boilerplate、kitematic），照葫芦画瓢就好了。 因为都是真实的项目，所以非常简单有效。 我建议你也试试看。

另外，耐心点，也可以看到很多关于测试知识分享的技术文章，多读会有收获。

18号

代码审查是纯手动的吗？ 没有好的工具？

代码审查可以参考GitHub上一些开源项目的PR Review。 通常，代码的修改可以在网页上明确标注，代码行可以写Review注释，非常方便。

其他工具主要是检查代码规范、语法错误等的Lint，一般都集成在CI中。

19号

有没有更完整的后端Java开发面试题？最近想换工作，想复习一下

是的，针对Java后端程序员，小编准备了Java基础、Dubbo、异常、JVM、容器、Linux、Mybatis、MySQL、Netty、Redis、Spring、Spring Boot、Spring Cloud、Spring MVC、Tomcat、Zookeeper、并发编程，消息中间件面试题目PDF文档，还有一本《技术面试所需基础知识汇编》，足以应对80%以上的Java技术面试。

有技术面试题，HR面试题也少不了。 小编收集了《70道Hr面试题》

私信小编【666】附上以上资料获取免费下载方法，欢迎嫖

如果这篇文章对你有帮助，记得帮忙转发