暂无个人介绍
2024年05月
2024年04月
2024年03月
2024年01月
2023年12月
2023年11月
2023年08月
2023年07月
2023年02月
2023年01月
2022年11月
2022年10月
最好是能有详细的教程,什么关键词能出现什么样的图片,想要什么样的效果需要什么样的积累。这样能不断的吸引人来参与,人多了,社区就活跃了,社区活跃一些好的想法,好的思路自然就会出现了。
我不畏惧修改需求,我也拥抱修改。但是,需求要修改,上线时间却不修改,这就太可怕了。
数据结构和算法还有设计模式。没有接触这些之前一直是增删改查,感觉就是业务代码的堆积。接触了这些,才意识到代码并只是增删改查的堆积。
这个升级很有意义,有一些专业论文写的晦涩难懂。可以让ai帮助理解,并且快速的对核心内容进行提炼,节省好多时间。如果模型训练的好,在某一领域有可能将获得一个不错的专家。
1.在日常工作中,你会用到代码生成工具吗?最喜欢哪一种呢?
在日常工作中确实需要代码生成工具,没有什么最喜欢的,我都是选用各个开源平台自带的生成工具来生成javabean,dao,mapper文件这些通用的java类。
2.你一般使用代码生成工具来做什么?
用来生成一些通用的java类。像各种javabean,vo,do,mapper,简单的service等。
3.面对尚处于“成长期”的代码生成工具,你有哪些期待和诉求呢?
希望它能更智能一些,能生成一些业务上的逻辑。
1、我会成为一个独立的开发者。不过我是被动的,随着年龄的增长,又不喜欢管理岗位和销售岗位,本身性格也做不了。留给我的只能是独立开发者了。毕竟已经没有公司喜欢大龄的开发者了。
2、尽量丰富自己的技术栈,侧重于中小项目的技术栈。那种大数据量,高并发的项目可能要与我无缘了。
我印象最深的sql性能异常是,在mysql慢查询日志中有一个慢查询,用EXPLAIN查看了执行计划。做了详细的优化,但是效果并不理想,怎么看怎么觉得别扭。了解了业务需求之后,发现是需求有变更,影响到了基本的表结构,开发团队为了赶工期没有对表结构进行调整,只增加一些额外的表来辅助解决问题。拿出时间来做了表结构的调整,修改了响应的代码,效果立竿见影。有的时候做优化,也需要了解一下项目的背景,业务方便的,开发层面的,有的时候有奇效。
正常的项目都有BA参与,开发人员拿到需求开发即可,需求的变更和确认都有规范的流程。就怕那些非正常的项目,时间特别紧张,需求流转到开发人员这边往往就是邮件或者简单的文档。正常的工具,审批流程都没有走,没有留痕。如果需求方,ba,开发管理人员,开发人员的理解是一致的,那么开发顺利能如期上线。如果理解不一致,就会进入互相扯皮的阶段。
1、bug和实现bug出入比较大的情况,通常都是修改别人的bug。对他们的代码逻辑和业务逻辑并不是十分的了解,只是一个页面的小bug临时指派到我了。顺着页面,找到它调用的出错的方法就修改了,页面显示正常,以为小case,顺利搞定。但是。。。。有一些隐藏的角落就会因为这个修改显示新的bug。
2、怎么解决。把原来的方法老老实实的恢复成原来的样子。自己重新写一个方法,供那个出错的方法调用。
2023年的关键词就是坚持。
2023年经历了公司的减猿增效,很多对新技术方向探索的项目都砍掉了,又回归了传统的业务交付部门,工作量什么的都增加了,就是薪资没有增加。总之坚持吧,只有坚持了才能慢慢变好。
对未来有想法的人都会有焦虑的时候。自己没有达到自己的要求或者目标时,就会焦虑无论是生活还是工作。
对抗焦虑的办法就是,忽略一切聚焦自己。要从不同的角度和自己和解,无论做什么只要自己每天有一点小小的进步就不会焦虑了。比如读了一段好文章,对某些事情或者生活有所感悟。比如你学了什么新技术。即时做了什么错事,只要自己有了认识,能反思,以后不再犯,这也是一种进步。总之,和自己和解,小步慢走不要停,我们的sheg生活会越来越好。
1、我认为年度最受欢迎的语言是python,它简单的语法,强大的功能,更加完善的社区环境,肯定还会霸榜几年。
2、我认为还是python,虽然C#的排名上升很快。现在火热的领域是人工智能,大数据模型等,在这些方面C#明细没有什么明显的优势。
3、一个全新的时代来临了,肯定得需要学习新的开发语言,程序员毕竟就是得终身学习的。
程序员面对着不断更新的技术,必须得终身学习。不管是愿意还是不愿意,只要是想继续干下去就得学习。如果还有人给激励,那当然是太好了,学到就是赚到了。
微服务还是单体架构哪种架构更好,其实是要看应用的场景。
1、单体应用所需要的开发、部署、维护成本较低,如果实际业务对高可用,高并发没有特殊的要求,应该选用这种架构。这样能大大降低项目的成本。小公司内部管理系统的首选架构。
2、微服务对高并发、高可用有了很完善的解决方案。但是,为了实现这些功能付出的成本还是有的。高可用,就意味着你的节点是多个,多个的话占用的服务器资源就会变多。开发人员和运维人员需要拥有的技术栈就要增多。
实际工作选用哪种架构,不能只单纯的看这个架构是不是先进,是不是主流的技术框架,还是看应用的场景。之前做的类似于电商的平台使用的是微服务的架构。现在在做内部管理软件,采用的是单体架构。
在云上肯定是微服务有更好的发展前景,毕竟云的特性和微服务的特效更契合。
通勤时间40分钟,需要全神贯注开车。只能听听音乐放松一下紧张的精神。
双十一为女儿买的家庭用大路灯用于学习,女儿最近鼻炎有严重的趋势买了除螨仪,清理一下螨虫,让她的鼻子舒服一点。看着不怎么鼓的钱包,自己用的东西就忽略了,等下一个双十一吧。
1、作为开发者,你参加开源项目建设的核心动力是?
A. 技术人为爱发电的初心
B. 绩效晋升躲不开的现实需要
选A
2.、你在考虑使用数据库服务时,会如何选择?
A. 直接购买“商用数据库 ”
B. “开源数据库”
选B
我的代码逻辑肯定没有问题,是不是网络延迟造成的?
开发者究竟是做技术还是做管理,还是要看自己擅长什么。 其实无论做技术还是管理,如果你足够优秀都会混的不错。 如果你并不擅长做管理,在管理领域投入了80%的时间精力,仅仅取得20%的收益。怎么和那些擅长做管理的人员去竞争。你在努力的时候别人也在努力,长久下去差距就拉开了。毕业3-5年大家的差距看上去还是可以追赶的,但是5-10之后,有的人就让人望尘莫及。 所以说我个人感觉还是先认清自己,再决定怎么投资自己。
前端,后端,运维,测试。这些岗位作为程序员多少都应该知道点。是深度发展还是广度发展这个需要看看你想要在哪个类型的公司发展。 1、如果你在大厂,那当然是往深度发展,因为大厂的人很多,大家都专精一块。比如你是后端工程师,就没有必要把前端的活也分给你。因为交由前端工程师完成的话,完成比你快还好,这样公司更能节省成本。 2、如果你在小公司,小公司不可能配置很多人手,成本太高,那么就需要你身兼多职。由于小公司的项目技术复杂度都不是很大,基本上一个人前端、后端、运维都能应付得来。 不过,无论你在哪里发展,都需要有自己擅长的领域。要不你的可替代性就太高了。