美文网首页
纯干货丨18个软件开发常见问题及解决策略,你有遇到吗?

纯干货丨18个软件开发常见问题及解决策略,你有遇到吗?

作者: 来壹杯卡布奇诺 | 来源:发表于2020-06-17 16:31 被阅读0次

    说明:
    作者:苏先生
    原文链接:纯干货丨18个软件开发常见问题及解决策略,你有遇到吗?

    No.1

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

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

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

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

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

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

    No.2

    比较规范的文档有哪些,他们功能分别是什么?

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

    有些团队对于测试阶段,会有测试用例文档、测试验收报告,发布前还会有部署文档、维护手册,但现在这类文档基本上被测试工具、部署脚本替代了,也没有什么存在必要。

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

    1. 设计类文档:这类文档主要用来说明、讨论需求设计、架构设计,可以用来了解、讨论和评审,以及记录后续结果。
    2. 说明类文档:这类文档用来对规范、API、配置、操作等做说明,便于规范和统一。
    3. 报告类文档:对事情结果的报告和说明,比如说验收报告、故障报告、调研等。

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

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

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

    No.3

    项目团队的开发人员,基本都是从外包公司临时找的,水平参差不齐,稳定性差,因此技术选型更多考虑技术的普及度的和是否容易学习掌握,从这方面看基本不太可能选择比较小众、但在特定领域很高效的技术。

    加上是企业内部管理的系统,数据量和用户数量可控,因此存在技术瓶颈的可能性很小,综合下来看,最好的选择就是最成熟和通用的技术,比如说选择 java 技术栈,web 开发的ssm 框架等,但这样长远看团队和个人的技术能力很难提升,请问老师在这方面有什么建议?

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

    技术提升这种事,需要让一部分人先成长起来,然后带动其他人。我自己工作之外会做一些业余项目,然后在这些项目中体验新的技术,体会其中优缺点,然后再逐步应用到工作的项目中,传授给同事们。

    我也鼓励其他同事这么做,去做一点自己的项目。但工作中的项目,我是很保守的。

    No.4

    对于开源技术方面,有没有什么经验来指导选型?

    答:开源技术选型,我的经验一般是这样的。

    1. 先找朋友推荐,少走一点弯路。
    2. 没有推荐的话,就去网上搜索,找几个满足需求的备选。
    3. 对比以下几个指标:
    • 代码质量、有无测试;
    • 文档健全度;
    • 看 Issue 处理情况、最后更新时间(无人维护的项目后续恐怕有问题都没法解决);
    • 看 Star 数量,通过 Google 和 StackOverflow 看使用情况。
    1. 自己按照说明试试看。

    No.5

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

    我认为在满足设计目标的前提下,大的原则还是在于项目约束,尤其是成本和时间,然后就是看技术可行性和风险是不是可控,其他看团队风格,有的偏保守有的追新。

    比如说我自己的原则:

    1. 成熟的好过新酷的;
    2. 流行的好过小众的;
    3. 团队熟悉的好过陌生的;
    4. 简单的好过复杂的;
    5. 开源的好过商业的(有时候也视情况而定)。

    No.6

    有着正常职位或头衔的架构师,对一个全新的项目理解产品需求后进行架构设计,一般会产出哪些“东西”,来满足后续的架构讲解和项目开发过程中的沟通?

    互联网产品特点是用户多,企业产品特点是业务复杂,所以架构的侧重点不一样。

    架构师在架构设计后,产出首先是架构设计文档,让大家理解架构。然后还要写架构开发的文档,比如如何基于这个架构开发功能模块,有哪些公共 API 可以调用,怎么样是最佳实践,要遵守哪些规范等。

    再要帮助搭脚手架和基础模块或示例项目,也就是要搭建一个最基础的可运行项目,通过这个项目,大家可以直观地理解你的架构是怎么落地的,通过基础模块或者示例项目,可以知道如何基于框架开发,后面就也可以照葫芦画瓢照着实现。

    还有就是在开发过程中,要答疑、解决架构中存在的问题,对架构做优化,还要做代码审查,对于不符合架构规范的地方要指出和修正。

    No.7

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

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

    No.8

    老师能不能具体讲讲重构有哪些原则和要注意的地方,感觉一直得不到要领。

    重构的要领我觉得两点。

    第一:你要先写一部分自动化测试代码,保证重构后这些测试代码能帮助你检测出来问题;

    第二:在重构模块的时候,老的代码先保留,写新的代码,然后指向新代码,或者用特定开关控制新旧代码的指向(这样上线后可以自己先测试,有问题也可以及时关闭),然后让自动化测试通过,再部署测试,新代码没问题了,删除旧代码。

    No.9

    有没有事情管理的工具?因为如果不记录下来,一会儿就忘记了。

    我个人的话,一般就用系统自带的记事本记一下,或者贴一个便签纸在显示器。如果时间跨度长,我就记到 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+ 培训。

    No.14

    各种类型的测试覆盖率你们一般采用什么指标?个人感觉在理想的情况下最好是做到百分百覆盖率。

    100% 覆盖,这个我觉得可以作为一种理想追求,但是没必要追求极致,还是要在进度和质量之间有个平衡比较好,毕竟进度也很重要。

    另外对于前端业务,我更重视集成测试的覆盖,对于主要业务场景集成测试覆盖到位后,单元测试也就有比较多的覆盖,相对性价比更高,然后再逐步补充单元测试的覆盖率。

    No.15

    持续集成怎么理解呢?我看知乎上说,有的团队成员在一天内多次进行编译,发布或自动化测试。

    狭义的持续集成不包括发布,主要指集成,持续的(每次提交代码变更都触发,频繁地提交)对代码进行集成(合并到主干),但集成前要确保自动化测试通过。广义的持续集成还包括部署,也就是集成后自动部署测试环境 (持续交付) 或者生产环境(持续部署)。

    No.16

    请问下有没有介绍开发如何写好测试不错的书?

    推荐:《how we test software at microsoft》中文版《微软的软件测试之道》。不过没有书其实你也可以找到很多资料的。比如我平时写前端程序,那么我会去 GitHub或者 Google,通过关键字、语言找跟我项目类似的开源项目,然后看其中有没有自动化测试写得好的。

    找到了 (例如:reactstrap、electron-react-boilerplate、kitematic) 就照葫芦画瓢好了,因为都是真实项目,所以特别简单有效,建议你也可以试试。

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

    No.17

    代码审核是纯手工做的吗?没有好的工具?

    代码审查可以参考 GitHub 上一些开源项目的 PR Review,通常网页上可以清楚地标记出代码修改,针对代码行可以写 Review 的评论,这就已经很方便了。

    其他工具主要是 Lint 检查代码规范、语法错误等,这个一般在 CI 里面就集成了。

    No.18

    相关文章

      网友评论

          本文标题:纯干货丨18个软件开发常见问题及解决策略,你有遇到吗?

          本文链接:https://www.haomeiwen.com/subject/bnpsxktx.html