纯干货丨19个软件开发常见问题及解决议略，你有遇到吗？【云开体育app官网入口下载】

本文摘要：No.1每次看这些架构的思想方法的时候，总是和实际的应用没能很好的联合起来，原因是不是架构设计的实践不够？或者是对种种实现的分析和思考太少？我以为不仅要有架构实践，还要有差别场景的实践。举个例子来说，你平时做企业应用架构，没什么流量，没几多数据，庞大的地方都在业务逻辑，这时候你去看那些讲大数据、讲高并发的文章，很难带入加入景去。另有就是一些架构，不自己搭一遍是很难相识其中的优缺点的，这也是另一个原因。

No.1每次看这些架构的思想方法的时候，总是和实际的应用没能很好的联合起来，原因是不是架构设计的实践不够？或者是对种种实现的分析和思考太少？我以为不仅要有架构实践，还要有差别场景的实践。举个例子来说，你平时做企业应用架构，没什么流量，没几多数据，庞大的地方都在业务逻辑，这时候你去看那些讲大数据、讲高并发的文章，很难带入加入景去。另有就是一些架构，不自己搭一遍是很难相识其中的优缺点的，这也是另一个原因。

可以思量有时机自己实验，把看到的一些好的架构用一个原型法式搭一遍，造一点数据出来，用工具压测一下，这样会更有感受。和实际应用想联合的问题，一方面说明你现有的架构可能并没有什么大问题，没有那么迫切的需求要革新；另一方面可能还是因为缺少实践履历，心里没底，不知道真用上了有没有用。

No.2比力规范的文档有哪些，它们功效划分是什么？对于瀑布模型，每个阶段竣事后，都有相应的验收文档，而敏捷开发则没有那么多硬性的要求，而是凭据项目需要，写须要的文档。有些团队对于测试阶段，会有测试用例文档、测试验收陈诉，公布前还会有部署文档、维护手册，但现在这类文档基本上被测试工具、部署剧本替代了，也没有什么存在须要。

我以为项目中须要的文档，主要包罗这几类：设计类文档：这类文档主要用来说明、讨论需求设计、架构设计，可以用来相识、讨论和评审，以及记载后续效果。说明类文档：这类文档用来对规范、API、设置、操作等做说明，便于规范和统一。陈诉类文档：对事情效果的陈诉和说明，好比说验收陈诉、故障陈诉、调研等。

而这些文档的价值，在于资助成员相识设计、到场讨论，记载项目结果，淘汰相同成本。重要的不是文档多富厚，而是这些文档有没有价值，你能不能实时通过这些文档获得想要的谜底。

所以你也可以对照一下你的项目中，现在的文档有哪些地方是可以简化的，哪些地方是要增强的。好比说，提要设计 / 接口设计 / 详细设计是不是可以适当合并，减轻文档事情？PRD 是不是够详细？会不会引起歧义不容易明白，要不要增加原型设计文档辅助？No.3项目团队的开发人员，基本都是从外包公司暂时找的，水平乱七八糟，稳定性差，因此技术选型更多思量技术的普及度的和是否容易学习掌握，从这方面看基本不太可能选择比力小众、但在特定领域很高效的技术。

加上是企业内部治理的系统，数据量和用户数量可控，因此存在技术瓶颈的可能性很小，综合下来看，最好的选择就是最成熟和通用的技术，好比说选择 java 技术栈，web 开发的ssm 框架等，但这样久远看团队和小我私家的技术能力很难提升，请问老师在这方面有什么建议？我以为团队的技术提升和项目的技术选型要离开，不要总想着两个都兼顾，优先保证好项目稳定、低成本运行。技术提升这种事，需要让一部门人先发展起来，然后动员其他人。

我自己事情之外会做一些业余项目，然后在这些项目中体验新的技术，体会其中优缺点，然后再逐步应用到事情的项目中，教授给同事们。我也勉励其他同事这么做，去做一点自己的项目。但事情中的项目，我是很守旧的。No.4对于开源技术方面，有没有什么履历来指导选型？开源技术选型，我的履历一般是这样的。

先找朋侪推荐，少走一点弯路。没有推荐的话，就去网上搜索，找几个满足需求的备选。对比以下几个指标：代码质量、有无测试；文档健全度；看 Issue 处置惩罚情况、最后更新时间（无人维护的项目后续恐怕有问题都没法解决）；看 Star 数量，通过 Google 和 StackOverflow 看使用情况。

自己根据说明试试看。No.5有没有什么大的原则可以指导技术选型？好比技术成熟度等？我认为在满足设计目的的前提下，大的原则还是在于项目约束，尤其是成本和时间，然后就是看技术可行性和风险是不是可控，其他看团队气势派头，有的偏守旧有的追新。

好比说我自己的原则：成熟的好过新酷的；盛行的好过小众的；团队熟悉的好过生疏的；简朴的好过庞大的；开源的好过商业的（有时候也视情况而定）。No.6有着正常职位或头衔的架构师，对一个全新的项目明白产物需求后举行架构设计，一般会产出哪些“工具”，来满足后续的架构解说和项目开发历程中的相同？互联网产物特点是用户多，企业产物特点是业务庞大，所以架构的偏重点纷歧样。架构师在架构设计后，产出首先是架构设计文档，让大家明白架构。

然后还要写架构开发的文档，好比如何基于这个架构开发功效模块，有哪些公共 API 可以挪用，怎么样是最佳实践，要遵守哪些规范等。再要资助搭脚手架和基础模块或示例项目，也就是要搭建一个最基础的可运行项目，通过这个项目，大家可以直观地明白你的架构是怎么落地的，通过基础模块或者示例项目，可以知道如何基于框架开发，后面就也可以照葫芦画瓢照着实现。另有就是在开发历程中，要答疑、解决架构中存在的问题，对架构做优化，还要做代码审查，对于不切合架构规范的地方要指出和修正。No.7互联网架构，要思量互联网很快的迭代速度，所以对于扩展等特别注意。

企业架构，内部 IT 系统相对稳定，对比互联网架构，更简朴？答：挺好的分析。帮你增补几点：互联网架构不仅迭代会快一些，用户规模通常更大，但业务也会单一些；企业应用通常业务比力庞大，尤其是和行业会有一些联合，可是用户规模要小许多。

这些特点，都市影响架构设计的选择。No.8老师能不能详细讲讲重构有哪些原则和要注意的地方，感受一直得不到要领。

重构的要领我以为两点。第一：你要先写一部门自动化测试代码，保证重构后这些测试代码能资助你检测出来问题；第二：在重构模块的时候，老的代码先保留，写新的代码，然后指向新代码，或者用特定开关控制新旧代码的指向（这样上线后可以自己先测试，有问题也可以实时关闭），然后让自动化测试通过，再部署测试，新代码没问题了，删除旧代码。No.9有没有事情治理的工具？因为如果不记载下来，一会儿就忘记了。

我小我私家的话，一般就用系统自带的记事本记一下，或者贴一个便签纸在显示器。如果时间跨度长，我就记到 Calendars 上，加上提醒。

事情中的任务，我则会建立成 Ticket。No.10现在另有一种说法：提倡基于主分支开发，效率更高；而不是您提到的每人基于自己的分支开发完再合并回主分支。您怎么看待这个问题？我认为对于软件工程来说，许多问题，并不是只有唯一解，纵然是最佳实践，也得看适用的场景和团队。

无论是基于主干还是分支开发，有两点需要注意的：就是一定要有一个稳定的分支，可以随时公布的那种，至于是叫 master 还是叫 release并不重要。合并之前要有代码审查和自动化测试（配合 CI）。上面两点才是焦点。No.11如果一个项目有 5 个开发做，连续集成怎么保证不乱？好比开发 A 刚刚修复的bug1，开发 B 把自己修复的 bug2 上传，之前的代码 bug1 没修复，怎么办？如果接纳分支怎么合并？如果是直接更新 master 分支，那 A 不是白做了？要注意是“合并”而不是“笼罩”。

好比说 bug1 涉及 file1 和 file3 的修改，那么开发 A 合并的时候只合并 file1 和 file3。等到开发 B 修复了 bug2，修改了 file1 和 file2，file2 直接合并，file1 需要手动去修复合并冲突才气合并。

每小我私家开发之前，都市从 master 获取最新版本，合并的时候，如果泛起冲突，要先解决冲突才气合并进去。这些其实应该自己去动手试试，会体会更深刻。No.12在微服务架构中，一个服务在测试情况的交付验证，往往还依赖于其他相关服务的新版本，导致新的 feature 很难独立的交付。

对于这种情况，有什么好的方法吗？我以为对于大部门时候，微服务之间应该是独立的，而不是依赖过于精密，如果每一个新功效都市这样，那架构设计一定是有问题的，需要重新思考服务划分的合理性。但你需要有更多上线或者场景我才气针对性提出一些意见。对于有一些确实需要跨服务互助的大 Feature，这样也是正常的，就是需要一起协作，实现商量好通信协议，分头开发，再联调。

No.13老师所讲排查生产问题的案例，首先回滚版本，再看日志。这会引发更多的系统功效不行用吧，两个版本之间的功效差异尚不清楚就直接回滚，系统风险是否被进一步扩大？这个确实要详细情况详细看，因为我日常的系统上线，都市有回滚方案，回滚也是自动化的很利便。

有些跟数据库相关的，如果数据库结构发生变化又发生了新数据，确实没法直接回滚。No.14团队成员的能力和素质乱七八糟，如何有效的去组织和治理项目的自动化测试，自动化集成？首先，你要先搭建好自动化测试情况，让自动化测试代码能跑起来，最好要和CI（连续集成工具）整合在一起，每次提交接码 CI 都市跑自动测试，然后能看到运行效果。

然后，把自动化测试作为开发流程的一部门，好比说要代码审查和自动化测试通事后才气合并代码。这部门事情如果和 CI 集成会容易许多。再有就是要培训，好比遇到不会写的，开始先带着他写几个，确保他学会了自己能写，然后下次代码审查的时候，看到缺了就要求补上，还不会就继续教，来不及写的就建立个Ticket 跟踪起来。

简朴来说，就是代码审查 +CI+ 培训。No.15种种类型的测试笼罩率你们一般接纳什么指标？小我私家感受在理想的情况下最好是做到百分百笼罩率。

100% 笼罩，这个我以为可以作为一种理想追求，可是没须要追求极致，还是要在进度和质量之间有个平衡比力好，究竟进度也很重要。另外对于前端业务，我更重视集成测试的笼罩，对于主要业务场景集成测试笼罩到位后，单元测试也就有比力多的笼罩，相对性价比更高，然后再逐步增补单元测试的笼罩率。No.16连续集成怎么明白呢？我看知乎上说，有的团队成员在一天内多次举行编译，公布或自动化测试。狭义的连续集成不包罗公布，主要指集成，连续的（每次提交接码变换都触发，频繁地提交）对代码举行集成（合并到主干），但集成前要确保自动化测试通过。

广义的连续集成还包罗部署，也就是集成后自动部署测试情况 (连续交付) 或者生产情况（连续部署）。No.17请问下有没有先容开发如何写好测试不错的书？推荐：《how we test software at microsoft》中文版《微软的软件测试之道》。不外没有书其实你也可以找到许多资料的。

好比我平时写前端法式，那么我会去 GitHub或者 Google，通过关键字、语言找跟我项目类似的开源项目，然后看其中有没有自动化测试写得好的。找到了 (例如：reactstrap、electron-react-boilerplate、kitematic) 就照葫芦画瓢好了，因为都是真实项目，所以特别简朴有效，建议你也可以试试。另外耐心一点，你也可以看到许多关于测试知识分享的技术文章，多看一看也有收获。

No.18代码审核是纯手工做的吗？没有好的工具？代码审查可以参考 GitHub 上一些开源项目的 PR Review，通常网页上可以清楚地标志出代码修改，针对代码行可以写 Review 的评论，这就已经很利便了。其他工具主要是 Lint 检查代码规范、语法错误等，这个一般在 CI 内里就集成了。

No.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】即可获取免费的下载方式，接待白嫖如果本文对你有资助，记得帮助转发一下哦。

本文关键词：云开体育app官网入口下载,纯,干货,丨,19个,软件开发,常见问题,及,解,No.1

本文来源：云开体育app官网入口下载-www.keyijin.com