暂无个人介绍
暂时未有相关通用技术能力~
阿里云技能认证
详细说明
2024年01月
2023年12月
2023年11月
1.作为开发者,你有“IPv4地址紧缺”的担忧吗?如果遇到这种情况,你打算在日常工作中主动支持IPv6吗?
没有担忧,应该是理论上的分配完吧,应该还有一些较小的地址块中可能还有剩余的地址可以分配。还有就是,10.0.0.0/8,172.16.0.0/12,和192.168.0.0/16这三个私有地址块是留作实验和网络内部使用的,通常不被用于互联网上的设备地址。
日常工作中并没有主动支持IPv6,首先是工作环境不需要,其次就是不方便与其他同事沟通。
2.在IPv6“一粒沙一个IP”的广阔前景与当前迁移挑战并存的局面下,你觉得 IPv4 地址的收费策略能否有效推动 IPv6 的普及?为什么?
能有效推动 IPv6 的普及吧!
IPv4地址收费可能会增加企业和个人用户的成本,尤其是那些拥有大量IPv4地址需求的企业。如果IPv6能够提供成本效益更高的解决方案,那么用户可能会更愿意迁移。经过一段时间,用户对IPv6的技术特性有足够的了解和接受度,他们可能会由于成本原因选择IPv6,即便存在迁移成本。
3.对于目前IPv6迁移准备不足的说法,你有哪些担忧或建议呢?
IPv4 地址的收费策略可以说是IPv6的机遇,但是还是存在IPv6迁移准备不足的问题,以下是一些建议:
只能说,这只是部分有效措施,还有很多需要并发进行,才会有助于IPv6 的普及。
2、中国在数据库领域正在赶超世界先进水平,您觉得数据库产业的突破到底意味着什么?
中国在数据库领域正在取得突破,这代表了我国信息技术产业自主创新能力的重要进步,同时也对全球数据库市场格局产生重要影响。以下是几个方面的重要意义:
总之,中国在数据库领域的突破意味着我国信息产业在技术自主、国际竞争力、数字经济、数据治理、产学研合作、人才吸纳及国家安全等方面的综合进步。这一突破将进一步增强我国信息产业的竞争力,并可能在全球范围内产生深远影响。
我是不太建议企业要求能用AI写的代码,不容许程序员手写。程序员的手写代码和决策在某些情况下仍是必要的,企业应当尊重这一点,并提供适当的指导和支持。
我的态度是企业在推行此类政策时,应确保程序员有足够的自由来处理AI目前尚无法胜任的复杂任务。当然,要求程序员提供AI无法编写那段代码的注释说明,可以帮助企业更好地理解AI工具的限制,并在适当的情况下分配人力来完成这些任务。这种做法有利于企业做出明智的资源分配决策,并推动技术团队持续进步。
1、你会选择成为一名独立开发者吗?
条件允许的话,肯定是会的。大学毕业的时时候就有一些调研,认为智慧医疗很有前景,当时有想法但是没能力,现在过了几年了,有点基础了。当时看好的项目确实也火起来了,再加上疫情,我感觉自己错过了成为大佬的机会。
2、要成为一名独立开发者,需要做哪些准备?
单单是有理想的话就不行了,而且靠自己不行,所以首先就是人脉,这样才有能力保证自己的想法有实现的可能。
其次就是,技术能力,这是好的产品的基础。
至于管理、财务、营销的方面,了解就好,可以慢慢学,也可以找人做,自己要有大局观,要能够有市场眼光。
最后,要有热情,不然最终很难坚持下去。
1.如何让系统长期维持理想的“三高”标准?
作为前端,我也不好拿出好的建议。就我了解的情况来说,产品经理、技术经理、研发人员,在产品会的时候定下一个大的基调,有架构或领导思考,业务的范围,从而做到“三高”各自占比,这就是最好的,不一定要做到均衡。
2.在实际业务场景中,“三高”是真实存在的吗?
存在的,但是应该很难做到都兼容的状态吧。但是,有倾向的可以做到,并且大多数项目来说做到某一方面就可以了,毕竟场景各有不同。
3.如果你是技术负责人,你会选择用“三高”来评价系统开发工作吗?
技术负责人通常会选择“三高”等指标来评价一个系统开发工作的质量和效果,但是不是唯一标准。项目定位、业务需求,都是影响因素,往往也影响了“三高”的某一项的比重。
1、你都遇到过哪些以为的Bug和实际的Bug有非常大的出入?
一般情况都是小问题,因为是前端,有一次系统登录不行了,直接报问题给后端。排查发现后端也没问题。
反正最终是因为前端改了一个cookie参数名导致的,当时就为了优化,没想到会启用这个参数。
2、最后都是如何解决的?
一般的步骤都是前端排查、后端排查。都做在一起,大家一块看吧。通过浏览器与后端的交互,每一步去排查每个参数,只能一步步来。
1.在实际业务中,你遇到过优化代码却导致过度设计的状况吗?
肯定遇到过,而且很容易陷入死循环。
2.你有哪些方法可以避免代码过度设计呢?
优化风格也是因人而异,所以过度设计难以避免。
所以制定统一的规范必不可少,公司内部采用公示,收集大家意见,整合后形成最合理的优化方案。
1、后端架构经验而谈的,但是个人经验不同,所在环境需要不同。
2、当然倾向于微服务,主要是因为,给我的感觉是更加健壮,日常使用的时候,尤其业务变更比较频繁的时候还是反映挺迅速的。
3、我认为微服务架构更符合未来云的发展趋势吧,最为前端,了解不够深刻,但是接触的项目中还是微服务很多。
微服务架构的路还很长,也会更加健壮。未来的一定趋势应该会是它,毕竟实践项目已经不少了,经验很丰富,社区比较活跃,思路清晰。