纯⼲货⼁18个软件开发常见问题及解决策略，你有遇到吗？
本⽂转载⾃：
手机练习sql的软件No.1
每次看这些架构的思想⽅法的时候，总是和实际的应⽤没能很好的结合起来，原因是不是架构设计的实践不够？或者是对各种实现的分析和思考太少？
我觉得不仅要有架构实践，还要有不同场景的实践。
举个例⼦来说，你平时做企业应⽤架构，没什么流量，没多少数据，复杂的地⽅都在业务逻辑，这时候你去看那些讲⼤数据、讲⾼并发的⽂章，很难带⼊到场景去。
hbuilder空格怎么打还有就是⼀些架构，不⾃⼰搭⼀遍是很难了解其中的优缺点的，这也是另⼀个原因。
可以考虑有机会⾃⼰尝试，把看到的⼀些好的架构⽤⼀个原型程序搭⼀遍，造⼀点数据出来，⽤⼯具压测⼀下，这样会更有感觉。
和实际应⽤想结合的问题，⼀⽅⾯说明你现有的架构可能并没有什么⼤问题，没有那么迫切的需求要改造；另⼀⽅⾯可能还是因为缺少实践经验，⼼⾥没底，不知道真⽤上了有没有⽤。
No.2
⽐较规范的⽂档有哪些，他们功能分别是什么？
对于瀑布模型，每个阶段结束后，都有相应的验收⽂档，⽽敏捷开发则没有那么多硬性的要求，⽽是根据项⽬需要，写必要的⽂档。
有些团队对于测试阶段，会有测试⽤例⽂档、测试验收报告，发布前还会有部署⽂档、维护⼿册，但现在这类⽂档基本上被测试⼯具、部署脚本替代了，也没有什么存在必要。
我觉得项⽬中必要的⽂档，主要包括这⼏类：
1. 设计类⽂档：这类⽂档主要⽤来说明、讨论需求设计、架构设计，可以⽤来了解、讨论和评审，以及记录后续结果。
2. 说明类⽂档：这类⽂档⽤来对规范、API、配置、操作等做说明，便于规范和统⼀。
3. 报告类⽂档：对事情结果的报告和说明，⽐如说验收报告、故障报告、调研等。
⽽这些⽂档的价值，在于帮助成员了解设计、参与讨论，记录项⽬成果，减少沟通成本。重要的不是⽂档多丰富，⽽是这些⽂档有没有价值，你能不能及时通过这些⽂档得到想要的答案。
所以你也可以对照⼀下你的项⽬中，现在的⽂档有哪些地⽅是可以简化的，哪些地⽅是要增强的。
⽐如说，概要设计 / 接⼝设计 / 详细设计是不是可以适当合并，减轻⽂档⼯作？PRD 是不是够详细？会不会引起歧义不容易理解，要不要增加原型设计⽂档辅助？
No.3
项⽬团队的开发⼈员，基本都是从外包公司临时的，⽔平参差不齐，稳定性差，因此技术选型更多考虑技术的普及度的和是否容易学习掌握，从这⽅⾯看基本不太可能选择⽐较⼩众、但在特定领域很⾼效的技术。
加上是企业内部管理的系统，数据量和⽤户数量可控，因此存在技术瓶颈的可能性很⼩，综合下来看，最好的选择就是最成熟和通⽤的技术，⽐如说选择 java 技术栈，web 开发的ssm 框架等，但这样长远看团队和个⼈的技术能⼒很难提升，请问⽼师在这⽅⾯有什么建议？
我觉得团队的技术提升和项⽬的技术选型要分开，不要总想着两个都兼顾，优先保证好项⽬稳定、低成本运⾏。
技术提升这种事，需要让⼀部分⼈先成长起来，然后带动其他⼈。我⾃⼰⼯作之外会做⼀些业余项⽬，然后在这些项⽬中体验新的技术，体会其中优缺点，然后再逐步应⽤到⼯作的项⽬中，传授给同
事们。
我也⿎励其他同事这么做，去做⼀点⾃⼰的项⽬。但⼯作中的项⽬，我是很保守的。
No.4
对于开源技术⽅⾯，有没有什么经验来指导选型？
答：开源技术选型，我的经验⼀般是这样的。
1. 先朋友推荐，少⾛⼀点弯路。
2. 没有推荐的话，就去⽹上搜索，⼏个满⾜需求的备选。
3. 对⽐以下⼏个指标：
代码质量、有⽆测试；
⽂档健全度；
看 Issue 处理情况、最后更新时间（⽆⼈维护的项⽬后续恐怕有问题都没法解决）；
看 Star 数量，通过 Google 和 StackOverflow 看使⽤情况。
4. ⾃⼰按照说明试试看。
No.5
有没有什么⼤的原则可以指导技术选型？⽐如技术成熟度等？
我认为在满⾜设计⽬标的前提下，⼤的原则还是在于项⽬约束，尤其是成本和时间，然后就是看技术可⾏性和风险是不是可控，其他看团队风格，有的偏保守有的追新。
⽐如说我⾃⼰的原则：
1. 成熟的好过新酷的；
2. 流⾏的好过⼩众的；
3. 团队熟悉的好过陌⽣的；
4. 简单的好过复杂的；
5. 开源的好过商业的（有时候也视情况⽽定）。
No.6
有着正常职位或头衔的架构师，对⼀个全新的项⽬理解产品需求后进⾏架构设计，⼀般会产出哪些“东西”，来满⾜后续的架构讲解和项⽬开发过程中的沟通？
互联⽹产品特点是⽤户多，企业产品特点是业务复杂，所以架构的侧重点不⼀样。数据库中count函数怎么用
架构师在架构设计后，产出⾸先是架构设计⽂档，让⼤家理解架构。然后还要写架构开发的⽂档，⽐如如何基于这个架构开发功能模块，有哪些公共 API 可以调⽤，怎么样是最佳实践，要遵守哪些规范等。
再要帮助搭脚⼿架和基础模块或⽰例项⽬，也就是要搭建⼀个最基础的可运⾏项⽬，通过这个项⽬，⼤家可以直观地理解你的架构是怎么落地的，通过基础模块或者⽰例项⽬，可以知道如何基于框架开发，后⾯就也可以照葫芦画瓢照着实现。
还有就是在开发过程中，要答疑、解决架构中存在的问题，对架构做优化，还要做代码审查，对于不符合架构规范的地⽅要指出和修正。No.7
互联⽹架构，要考虑互联⽹很快的迭代速度，所以对于扩展等特别注意。企业架构，内部 IT 系统相对稳定，对⽐互联⽹架构，更简单？
挺好的分析。帮你补充⼏点：互联⽹架构不仅迭代会快⼀些，⽤户规模通常更⼤，但业务也会单⼀些；企业应⽤通常业务⽐较复杂，尤其是和⾏业会有⼀些结合，但是⽤户规模要⼩很多。这些特点，都会影响架构设计的选择。
No.8
⽼师能不能具体讲讲重构有哪些原则和要注意的地⽅，感觉⼀直得不到要领。
重构的要领我觉得两点。
第⼀：你要先写⼀部分⾃动化测试代码，保证重构后这些测试代码能帮助你检测出来问题；
第⼆：在重构模块的时候，⽼的代码先保留，写新的代码，然后指向新代码，或者⽤特定开关控制新旧代码的指向（这样上线后可以⾃⼰先测试，有问题也可以及时关闭），然后让⾃动化测试通过，再部署测试，新代码没问题了，删除旧代码。
No.9
tdsql有没有事情管理的⼯具？因为如果不记录下来，⼀会⼉就忘记了。
我个⼈的话，⼀般就⽤系统⾃带的记事本记⼀下，或者贴⼀个便签纸在显⽰器。如果时间跨度长，我就记到 Calendars 上，加上提醒。⼯作中的任务，我则会创建成 Ticket。
No.10
现在还有⼀种说法：提倡基于主分⽀开发，效率更⾼；⽽不是您提到的每⼈基于⾃⼰的分⽀开发完再合并回主分⽀。您怎么看待这个问题？我认为对于软件⼯程来说，很多问题，并不是只有唯⼀解，即使是最佳实践，也得看适⽤的场景和团队。
⽆论是基于主⼲还是分⽀开发，有两点需要注意的：
1. 就是⼀定要有⼀个稳定的分⽀，可以随时发布的那种，⾄于是叫 master 还是叫 release并不重要。
2. 合并之前要有代码审查和⾃动化测试（配合 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
团队成员的能⼒和素质参差不齐，如何有效的去组织和管理项⽬的⾃动化测试，⾃动化集成？
⾸先，你要先搭建好⾃动化测试环境，让⾃动化测试代码能跑起来，最好要和CI（持续集成⼯具）整合在⼀起，每次提交代码 CI 都会跑⾃动测试，然后能看到运⾏结果。
然后，把⾃动化测试作为开发流程的⼀部分，⽐如说要代码审查和⾃动化测试通过后才能合并代码。这部分⼯作如果和 CI 集成会容易很多。
再有就是要培训，⽐如遇到不会写的，开始先带着他写⼏个，确保他学会了⾃⼰能写，然后下次代码审查的时候，看到缺了就要求补上，还不会就继续教，来不及写的就创建个Ticket 跟踪起来。
简单来说，就是代码审查 +CI+ 培训。
mysql面试题 知乎No.14
各种类型的测试覆盖率你们⼀般采⽤什么指标？个⼈感觉在理想的情况下最好是做到百分百覆盖率。
100% 覆盖，这个我觉得可以作为⼀种理想追求，但是没必要追求极致，还是要在进度和质量之间有个平衡⽐较好，毕竟进度也很重要。
另外对于前端业务，我更重视集成测试的覆盖，对于主要业务场景集成测试覆盖到位后，单元测试也就有⽐较多的覆盖，相对性价⽐更⾼，然后再逐步补充单元测试的覆盖率。
No.15
持续集成怎么理解呢？我看知乎上说，有的团队成员在⼀天内多次进⾏编译，发布或⾃动化测试。
狭义的持续集成不包括发布，主要指集成，持续的（每次提交代码变更都触发，频繁地提交）对代码进⾏集成（合并到主⼲），但集成前要确保⾃动化测试通过。⼴义的持续集成还包括部署，也就是集成后⾃动部署测试环境 (持续交付) 或者⽣产环境（持续部署）。
No.16
请问下有没有介绍开发如何写好测试不错的书？
推荐：《how we test software at microsoft》中⽂版《微软的软件测试之道》。不过没有书其实你也可以到很多资料的。⽐如我平时写前端程序，那么我会去 GitHub或者 Google，通过关键字、语⾔跟我项⽬类似的开源项⽬，然后看其中有没有⾃动化测试写得好的。
canvas菜鸟教程
到了 (例如：reactstrap、electron-react-boilerplate、kitematic) 就照葫芦画瓢好了，因为都是真实项⽬，所以特别简单有效，建议你也可以试试。
另外耐⼼⼀点，你也可以看到很多关于测试知识分享的技术⽂章，多看⼀看也有收获。
No.17
代码审核是纯⼿⼯做的吗？没有好的⼯具？
代码审查可以参考 GitHub 上⼀些开源项⽬的 PR Review，通常⽹页上可以清楚地标记出代码修改，针对代码⾏可以写 Review 的评论，这就已经很⽅便了。
其他⼯具主要是 Lint 检查代码规范、语法错误等，这个⼀般在 CI ⾥⾯就集成了。
No.18
有没有⽐较齐全的后端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⾯试题⼤全》

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。