2024年软件项目常见问题 篇1
软件产品的架构，通常都是随着业务的发展而不断演变的；我从事软件开发行业也有十余年了，遇到过的软件（企业级应用，我是从事Java开发）架构主要有这么几种：单体架构架构
总的概括来说，单体架构就是应用所有的功能，只有一个代码包，开发和部署都在一起，这是一种比较传统的架构风格；当然，单体架构也有着诸多的缺点：
代码越来越多，增加了代码的复杂性；作为开发人员一定深有感触，每当修改一个老方法的时候，一定会格外的小心翼翼，生怕影响了其他的功能；
单体应用需要统一技术栈，团队中的开发人员，都需要掌握相同的开发语言和框架；
随着开发人员的流动，老员工离开项目组，复杂且庞大的项目代码又让新成员难以阅读和理解，技术债务越积越多；
代码都在一个代码包中，就算是修改一个小小的功能，都要把整个项目打包上线；
所有的模块都运行在同一个JVM中，非关键性业务可能占用大量的资源，导致关键性业务发生问题；不能单独对某一个模块进行扩展。
SOA架构
因为单体应用架构的种种缺点，已经不能再满足业务需求的时候，于是就出现了SOA架构。
SOA架构的主要思想是把应用程序的模块化组件，通过接口联系起来（接口可以独立于语言、框架、硬件、操作系统）；在SOA架构中，有两个主流实现方式：
Web Service：使用WSDL定义接口，SOAP协议通信，传输XML数据；缺点是SOAP、XML较重；服务管理不完善；
ESB：企业服务总线，每个服务提供者通过总线模式插入系统，总线完成服务的编排和转发；但ESB本身就比较中，而且它本身算是一个单点，在软件架构中，单点意味着风险；
微服务架构
微服务的产生，也是由于SOA架构的一些缺点，这里再次印证了这句话，【应用架构的演进的过程通常是被业务逼出来的】。
在微服务的架构中，服务拆分粒度更细，提高了复用性；各个微服务可以独立开发，独立部署；
微服务之间通常使用Restful风格的API通信，传输格式也通常选择JSON；
微服务是SOA架构的延续，它们和单体应用相比，大大提高了系统的负载能力，解决了应用高并发的需求；
服务和服务之间的耦合度也被降低，并且项目团队可以被拆分成多个小团队，每个微服务都可以进行敏捷开发部署；
每个团队的技术栈也可以不相同，只要遵守接口协议即可。
当然SOA、微服务的出现，在解决一些问题的时候，也带来了另外一部分的问题，比如增加了网络开销、服务依赖性、增加了测试运维难度、数据一致性问题等等。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
2024年软件项目常见问题 篇2
针对这个问题我提几种方案，因为不同的项目的背景不同，也别上来就上统一配置中心，还是针对实际情况，选择不同的方案。
不同代码基线，使用不同配置文件
正常情况，我们的代码基线会有多条，比如最简单的开发基线和生产基线，开发人员在开发基线上进行代码开发，配置文件中的内容对应的是开发环境；同理，生产基线中的配置文件对应的是生产环境；
可以看出来，不同基线，代码是一致的（或者说会最终一致），但是配置文件是不同的；如果配置文件需要修改的话，就不能通过merge的方式进行代码合并了。
Spring Boot中配置不同环境的配置文件
我们现在的项目都是基于Spring Boot，不同的配置文件，比如数据源的配置、远程接口地址、日志打印等，Spring Boot是支持通过不同的profile来配置不同环境的配置。大概的配置就是：
根据不同的环境，设置不同的yml文件，命名：application-xxx.yml
设置spring.profiles.active的值，可以在打包的时候指定。
多个基线的代码可以是完全一样。
Spring Boot项目在启动时指定配置
这个拿一个实际项目举例，是我们项目的做法，实现思路可能会有些怪异。我简单说一下：
程序有两个定时任务，分别是：job1和job2；
job1中的代码：if(job1run==true){逻辑处理}，job2类似；job1run和job2run默认false；
项目正常打包，不需要做额外处理，得到：project.jar
机器1运行：java -jar project.jar --job1run=true
机器2运行：java -jar project.jar --job2run=true
过程有些怪异，可以实现同一个代码包，再运行的时候指定它做什么工作。
写在数据库中
其实我是不排斥这种做法的，但是要注意：
有可能会发生变化的配置，放在数据库中；
懒加载的方式读取到内存中，不要每次使用的时候读一次数据库；
根据实际场景，决定加载到内存中的配置是否需要定时失效/重载。
统一配置中心
随着项目功能的增多：配置会越来越多，修改配置后实时生效的要求也会越来越高，所以很多公司会采用搭建【统一配置中心】的方式来解决这个问题。
配置中心的核心功能就是【配置】，但肯定不局限于此，另外还需要有：审批、灰度发布、回滚等功能；
常用的开源配置中心有：spring-cloud-config、Apollo、Nacos;
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
2024年软件项目常见问题 篇3
1“简单”的自我介绍一下！
不夸张的说，有99%的面试是在这一句开场白中开始的。简单的自我介绍一下，但是，“简单”二字真的是单纯的简单吗？
一些同学误把HR所谓的“简单”二字书面化理解，只是介绍了自己的姓名、年龄、毕业学校、爱好、工作经验等。
其实，这样介绍是远远不够的。这些信息在个人简历中，完全可以一眼看到，HR又何必浪费时间再问一遍？
所以，除了以上基本资料之外，HR更希望听到的是你的优点，你擅长的技能，做过的项目，成绩等，能够为公司带来的收益和价值。
注意自我介绍时间不要太长，3-5分钟最好，突出重点，让HR一针见血最好不过。
2为什么从上家公司离职？
这个问题，非常难回答。稍有不慎，就是减分项。
那么，怎样回答既不会觉得自己随便跳槽，并且还能给自己加分呢？
首先，一定不要当着HR的面说上家公司的各种不好。可以很委婉的从自己的职业规划、技术路线、发展等方面回答。
比如说：“上家公司不是不好，是我自己的原因，为了自己的职业规划和发展，为了自己的技术得到更好的提升，所以选择离职。”
这样的回答，HR不但不会觉得你很随便跳槽，还觉得你是一个爱学习，有规划的人，将一个难题变成了自己的加分项。
3你对我们公司了解多少？
如果面试前没有了解公司，可能会觉得无从回答。
但是，就算自己真的不知道，也不能直接说“不知道”，这样的话，会让HR觉得你来面试没有做功课，没有诚意。
可以这样说：“我对贵公司也没了解很多，简单来说，是做互联网的，之前有在百度搜索过公司的一些简介和相关业务的介绍，所以也是简单的了解了一下”。
这样一来，既解决了直接回答“不知道”这三个字的尴尬，还可以告诉HR自己面试前有上网查询过公司的情况。
4你对加班有什么看法？
不能说不接受接班，也不能说已经习惯了加班。
说自己不加班的，会让HR觉得你不是一个真正做技术的人，不是一个好程序员。说自己天天加班的，这样会觉得可能你能力不足，需要加班来做，或者会觉得你加班是理所当然。
可以说：“对于加班，我有自己的看法，首先，加班可以按照调休或者加班工资来计算，如果项目比较赶，短期的加班我是理解并支持的，如果项目长期加班的话，这个我是认为有点不太好，对程序员的身体和脑力休息不好，也会降低开发效率。”
这样的回答，既表达了你不是不加班的人，也不会觉得你加班也是理所当然的事情。
5你对自己薪资有什么要求？
这个问题，如果立刻说多少K，或者说多少钱，会让HR觉得你在漫天要价。
可以说：“我是通过某某平台投递的简历，我看了这个岗位的薪资区间，我肯定也是符合贵公司的薪资要求才过来面试的，我在简历上面有写到。”
这样一来，没有把这个薪资说死，也没有觉得自己把薪资开低了，或者开太高了。
要的低了，显得自己没有能力，缺乏自信；要的太高，显得自己漫天要价，公司受用不起。
希望以上问题和回答能对大家有所帮助，祝大家都能找到理想的高薪工作，一面成功！