首先我自己也是培训班出来的,工作了三年,很有资格说下我的感受。刚出来时,确实有楼主说的情况,看不懂相关公司的代码,培训班培训的跟实际可能存在着差异。代码本身并不难,大部分有javase知识都能看不懂。难的是公司代码逻辑的机构和层次。可能他自己封装了底层,可能他们自己做了框架。可能他们自己重写了jdk的方法。这很可能是导致新来员工看不懂的原因,其次就是代码讲究独立性,解偶性,可重复性。可能一个功能的实现,要有大量的架包和方法支持,你从controll看一个方法,他调用了service层,service层做逻辑判断,可能调用其他包的方法…其他包的方法可能又调用了其他包的方法,如此循环下去,导致看不懂。最后就是新技术的引用,现在主流技术是spring微服务,zk,redis,kafka等,可能楼主对这些远程调用,负载均衡不太熟悉导致看不懂。 对于这三个问题,首先第一个问题。楼主可以多问问老员工,不要害怕他们冷嘲热讽,只要能赚到钱,这点委屈不算什么,毕竟公司封装的自己的东西,真的和所学有所差别。第二个问题,楼主要夯实自己的基础,知道自己去看代码,代码不是一行一行看的,看三层,主要侧重看返回值,第三个问题,楼主要树立终身学习的观念,程序员不学习,两三年就会被淘汰,现在技术水平更新那么快,所以只要有心,这些都不算什么! 稳住,不要慌。 刚参加工作的Java程序员,看不懂公司的代码是很正常的一件事儿,不过题主已经入职一个月了,如果依然是懵懵懂懂的状态,那么一定要紧张起来了。 为什么看不懂公司的代码 题主说自己是培训机构出身,通常来说,培训机构为了把一个学员短期内培训出来,通常培训的内容都是停留在"会用"这个程度。大部分时候会告诉学员,这样做可以,那样写可以;但是如果稍加变化的话,有时候学员就变得无从下手的; 培训机构的项目,通常业务比较简单,甚至没有什么业务,只是几个框架做了集成,实现对数据的增删查改,而公司的项目一定是需要了解业务流程的; 题主说自己了解Control,Service,Dao这些代码分层,因为这是培训机构教科书似的项目,而且确实应该这样遵守;不过现实中,特别是老项目,有些公司是不注意这些代码规范和分层的,或者虽然有分层,但是程序员没有严格要求,比如Service层直接访问了数据库,Dao中包含了复杂的业务逻辑;所以你会觉得"杂七杂八的一大堆"。 那么需要如何解决呢?给题主几条建议: 首先,最容易改变的就是工作态度,既然工作比较吃力,那么多投入一些时间,没事儿多加加班,至少让领导觉得你是一个肯吃苦的新人; 不懂就多问:通常新人进公司,都会安排一个老人带的,如果没有特殊指定的话,你可以选择问直属的领导,或者项目组中看起来比较和蔼的前辈,都可以直接问; 询问之前,你至少看过代码,带着问题去问,千万别上来就说:"代码我看不懂,你给我讲讲"; 自己看代码的时候,首先要在自己电脑上,把项目跑起来,知道功能入口是什么;比如有些系统有前端页面,那么功能入口就是前台页面的某个操作;有些系统没有页面,那么入口可能是接口或定时服务;一定要了解如何操作,然后给代码加上断点,一步一步地跟踪下来,了解一个功能是如何触发、处理、返回; 每次问问题之后,如果当时不能理解,一定要先记录下来,然后再反复地看代码;简单的问题,千万不要重复问; 利用一切可以利用的文档和注释;包括需求文档、设计文档、操作手册、数据库设计文档等。 刚工作的这段阶段是很痛苦的,一定要多投入些时间,早日突破这个瓶颈期。 我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。 哈哈哈哈,让我先笑一会。ヾ(^Д^*)/ ,好言归正传。 新员工完全看不懂代码,我推测你可能是刚刚学习编程不久。或者是刚刚从培训班出来参加工作。 对于你这种情况我非常感同身受。那么作为一名经历过你一样的痛苦的工程师,我会给你一些下面的建议,帮助你从各个方面得到公司同事的认可。 一、端正态度 没办法了,我摊牌了! 神人也不可能让你立刻看懂公司项目的代码,熟悉完整流程。那就先从态度上入手。 1、每天一定要早点到公司,身边准备一个notbook,写一写,画一画。 2、每天晚上要晚点走,把今天遇到的问题列个清单,做个总结。 3、千万不要相信"有什么问题尽管问!"这句鬼话!任何问题,都要先自己去查阅资料,通过自己的努力要解决至少80%的问题。 4、面对上级或者长辈的批评,一定不要掉小脸子!要记住他们,回家再写在小本本上! 5、做事要积极主动,比如主动请求领导分配给自己一些小的功能做,不要怕做错,可以在请求任务的时候顺便表示一下"有不会的地方一定要多多指点"。 6、适当的夸夸同事的编码能力,因为这样可以拉近你和同事之间的距离。二、从if-else入手 说实话,我就是先从最简单的if-else开始的,把这个记牢。 大部分编程工作就是在不断的if-else、if-else、if-else.......那句话怎么说来着?没错,人类的本质就是复读机! 如果你细心一点,你可以发现项目中大多数if-else还是可以看懂的。三、看代码的时候假装自己是一名特工 这个不可外传,不过我还是希望能帮助到你。 这个方法就是我在看别人代码的时候养成的一种小习惯。假设自己是一名正在执行机密任务的中央特工,需要在短时间内破解敌人的内部代码,维护世界和平! 有了这种心理暗示,你将会不自觉的进入一种战斗状态!肾上腺素暴增!注意力高度集中,效率翻倍! 那么你的焦虑也会随之减少,因为没有时间紧张、恐惧,世界正在等着我去维护正义!四、重视积累 这一点要从编程经验来谈。 对于软件行业来说,编程经验都是需要不断积累的,而且每个人都是这样走过来的,不用害怕。 你不必一天吃成一个胖子,只需要每天提高自己,将昨天的学习不断总结,你就会看到惊人的变化。 正所谓"不积跬步无以至千里",其实你的领导和同事也没有要求你是个天才,你只需要像一个正常人一样,犯过的错误,不要重复犯错,掌握的知识能够乐于分享就可以了。他们一定会看到你的成长,并给予你鼓励,这个世界还是挺宽容的。 综上,就是我提供的帮助,希望点赞、关注哦! 你把培训的三层架构照搬到实际项目中?你看得懂那就有鬼了,人家架构师是吃素的?每个人都以为是MVC那一套,还要架构师干嘛。 不要觉得项目杂七杂八的,每一段代码都是人家呕心沥血想出来的,你写的还不如人家的。麻烦用点心吧,看代码是看不出来什么来的 你要做到以下几点才入门 第一、一切的代码都是围绕业务开展的,你连你做的项目干嘛用的都不知道,就去看代码,这不是南辕北辙嘛,多跟老人,测试,需求了解业务 第二、你培训的三层五花肉架构,就别拿出来秀了,不然会显得你的无知,虚心询问同事,组长,他们都是你最快上手项目的人。 但是不要一上来就问,你要自己先理解一遍,哪里不懂的再去问,不然谁有空给你解释那么多,都很忙的。 第三、下班以后,可以学习一下项目所用的技术,这样会让你上手更快,度过试用期就轻松了 第四、处理好和同事之间的关系,比如中午一起吃饭,可以聊一聊项目的进度,技术,业务,增进同事之间的感情 第五、遇到什么困难要第一时间汇报,不然导致项目的进度拖延了,会死得很惨,一堆人跟着遭殃,多跟领导汇报问题,显得你善于沟通,性格开朗。 做到以上几点,基本就能玩转整个项目了,不管是新手还是老手,接触到新项目起点都是一样的,加油! 谢谢邀请! 不少新入职的程序员往往都会遇到类似的问题,但是有过实习经历的程序员遇到类似的问题会从容很多,毕竟了解了软件开发的流程和环节会对阅读代码有较大的帮助。 通常情况下,要想能够快速了解代码并融入到开发团队中,应该做好以下几件事: 第一:从功能入手。 不少公司的代码都是经过多个程序员的编写,难免在书写的过程中存在一些不规范的情况,要想了解这些代码最直接的方式就是从功能入手,根据功能的执行过程来梳理代码结构。不少程序员在半路接手别人代码的时候,通常都是采用类似的方案,这样也不会影响新功能的开发。 第二:做好标注。 有的程序员在看代码的过程中会对代码进行一定的标注,标注的过程一方面可以梳理代码的功能,另一方面也方便回头再看。不少初级程序员采用标注代码的方式是比较适合的,因为标注代码的过程也是学习的过程。 第三:注重交流。 不同团队往往都有较为统一的编码规则,所以对于初入团队的新人来说,应该多找机会与团队中的主力程序员进行交流,在交流的过程中往往就能了解到一些编码的结构和规则,这对于阅读代码是有较大帮助的。另外,遇到比较棘手的问题时,也不要一味的自己思考,完全可以通过交流得到答案。作为新人来说,一定不要不好意思,因为这也是为了工作能够顺利开展。目前不少科技公司也会为新人配备一名主力程序员,这样会提升新人的成长速度。 对于初入职场的程序员来说,一方面要多读代码,另一方面也要多动手敲代码,随着自身编程能力的提升,阅读代码的能力也会随之提高。 我从事互联网行业多年,目前也在带计算机专业的研究生,主要的研究方向集中在大数据和人工智能领域,我会陆续写一些关于互联网技术方面的文章,感兴趣的朋友可以关注我,相信一定会有所收获。 如果有互联网方面的问题,也可以咨询我,谢谢! 谢邀! 作为一个长期奋斗在程序开发一线的老程序员,也带过很多新人,对这种接手代码后长期没有读懂代码或者能看懂却不会独立维护的情况,遇到过很多。不用着急,可能是你的方法不对,下面说一下我的经验: 研读文档 可行性研究报告、需求规格说明书、项目计划、概要设计说明书、详细设计说明书这些都是最基本的开发文档,好的文档基本可以将项目的应用背景、实现方式、发展方向都会描述清楚。看这些文档会对将要着手的工作有一个更高层次的认识,而不是仅仅纠结于代码本身, 另外,看设计本档会对代码实现的功能上有一个整体的认识,对弄懂代码有高屋建瓴的作用。当然很多小公司对文档没有严格要求,或仅仅走个过场,很多开发人员也很烦写文档,整个项目里只有一个代码在裸奔,文字说明都在代码注释里,这对后期项目维护造成很大困难。 代码模块化拆分 在深入了解功能之后,不要着急一行行的去读代码,将代码按照功能模块区分出来,知道哪些源码文件是用于实现某个模块功能的,模块与模块之间数据传递是怎么实现的,要传递哪些数据,然后一步步将大模块按照功能拆分成小模块,并继续将代码按小模块分类。 依据功能读懂代码 如果能够将代码按照功能模块拆分清楚后,可以试试带着问题去研究代码了,比如为了实现登录功能,画出流程图,从页面的录入到后台的判断再到数据库的读写是怎么传递数据的。 如果只是维护一个项目代码功能,哪里有问题改哪里,做到这里基本就够了,但如果是要对项目进行优化升级, 那就必须弄懂原先代码为什么要这样写,不要盲目按照自己的理解去修改别人的代码 ,经过实践的代码总有对的理由,牵一发而动全身,不经过测试使用,不能保证一定没有bug。 谢邀。 我从三个层面来说: 阅读业务代码的方法 脸皮要厚,不会就问 可以考虑换公司阅读业务代码的方法 之前我回答了一篇关于《如何快速阅读源码》的问题,那个主要是针对阅读开源框架的,针对公司的业务代码,其实流程差不多,我简单说下不同点。具体流程题主可以去找一下,我就不贴在这里了。 主要流程分四步:先「跑起来」:在这里就是先要去了解项目的业务流程,能够先搞懂业务是什么样的自顶向下拆解:从业务流程对应到代码里面去,先找模块、再到包、然后是类、最后是方法。注意这里不要在意细节,能够把类,方法按照业务流程给串起来就行。深入细节:然后再到方法里面去看具体的细节延伸改进:这是在你梳理完了代码之后,再考虑的事情。可以想想为什么代码这么写,有没有什么更好的方法。脸皮要厚,不会就问 公司肯定有老员工,逮到了就问,别怕人烦,现在你不搞清楚了,后面正式开始写代码的时候,写出来一堆问题,同事和领导的意见会更大。 我就遇到过几个人,真的是郁闷。不问他,一句话都不说,一问全是问题。一些小问题卡了好几个小时,也不说,就闷在那里不知道在干嘛。 按照上面的流程,先找人把业务给理清楚了,然后再去理代码。注意代码问题也主要关注业务流程层面,而不是语法层面,语法层面的自己去搜搜就可以了。 问的标准是自己十到二十分钟搞不定的问题,就立刻去问!!!可以考虑换公司 工作本来就是双向选择。如果代码逻辑很乱,又没人能把业务和代码给你讲清楚,或者没人愿意给你讲。那说明这家公司的管理很乱,你可能接的是个锅,你在这家公司不一定能学到东西,要不要继续待在这里是很值得考虑的。 用Eclipse插件生成的UML类的关系图。 在关系图上,就可以非常清晰看到代码之间的关系。 按MVC模式,先搞明白一个功能模块,再去看其他的功能。 看代码时,会有代码注释的。Eclipse里有导出注释文档的功能。 熟悉相关功能之后,你可以修改一些Bug。 随着对项目的逐步深入,你就会慢慢地熟悉整个工程代码的了。 不用那么着急。任何公司都会给刚入职的同事,一段时间熟悉代码的。 我@老陈说编程,搞了10多年代码,当技术总监都将近10年。我对新来同事的工作安排:学会生成类的关系图,搞明白一个功能模块,接着再熟悉其他的,最后修改Bug或开发新功能。 你问了,我就分享给你了。有问题可以关注@老陈说编程。 谢谢邀请。 这个问题的本质具有跨行业的普遍性,所以我就采取分拆,多角度更详细地回答一下,希望可以帮到题主和其他有类似问题的职场新人朋友们。 角度1: 因为IT行业程序员的薪资普遍较高,所以很多人想转行学编程,拿到这个看上去高薪体面的工作。 这里面有2个误区,招聘启事中的高薪是给有丰富项目经验的成手程序员们的,而不包括新手,尤其是只参加完短期培训就入职的程序员朋友。 由于项目开发具有工作连续性和团队协作性等特点,所以加班是这个工作岗位的常态,而不仅仅是因为公司或老板的额外要求。 在培训班里,我们参与项目学习的时候,面对的是一个相对简单,目的明确、需求详细的作业性质的项目,所以目录清晰,文档说明和注释完备。但是实际工作中,由于甲方或者老板的需求变动比较频繁,很多时候来不及修改文档或者增加更详细的代码注释,一旦换人,读不懂代码或者感觉项目需求文档不匹配就很正常了,这个不是新人本身的问题,而是企业管理不规范导致的。 角度2: 不论是不是参加短训的程序员新手朋友们第一次选择工作,最好还是要去一些相对正规的大型公司,参与一些相对重要的项目,哪怕入职以后,你仅仅负责一些不太重要的部分,都没有关系,最起码你可以学习更多培训班或者书本上学不到的项目实操经验。 同时可以规范自己的代码书写习惯,加强项目需求分析能力,夯实基础,真正达到学以致用,这样你才能够在这个行业中站稳脚跟,你才能真正端好程序员这碗饭。 角度3: 入职以后,不要心急,不要觉得自己没有参与到重要的项目就是对自己的轻视。其实新人需要一个过渡期,你要做好自己的本职工作,抓住机会展示你的能力,哪怕是扎实的基本功这种最普通的能力都可以,为今后逐渐被同事、主管们重视和重用做好准备。 抓住机会研读你所在项目的所有文档,然后尝试着用项目管理者的角度去分析需求和划分开发进度,最后用项目中已经做好的工作进度安排去与自己的想法对照,看看差别在哪里?为什么会有这样的差别? 抽出大段时间进行项目原有代码的阅读,对照项目相关文档和已有成品的相对应功能,对于实在不懂的部分,标记出来询问老同事。 【题外话】 本人混迹互联网行业18年,参与过8次创业,组建过至少10次技术团队,管理过很多从0到1的研发项目,所以职场新人们遇见的问题,我都有过无数次帮忙分析和建议,希望多交流、多沟通,能够帮到大家。 程序员都是从新人过来的,不要着急,我认为可以从三个方面来解决: 1 有师兄 大公司一般都有师兄制。所谓师兄制就是项目组会为新同事分配一个固定的师兄,带着熟悉业务和相关技术框架。师弟对代码掌握情况和能否快速融入团队是师兄考核指标。我认为这是非常好的传帮带模式。 如果没有师兄制,建议你主动为找一个师兄,虚心向他请教和学习,师兄可以帮你少走技术弯路。 2 有态度 师兄平常也有自己繁忙的工作,所以关键还是要靠自己。师兄可以帮你少走弯路,但是大量的学习工作还是要靠自己,所以刚进项目组要比别人多花时间钻研,看代码,看文档,看架构图。 3 有方法 首先从项目全貌来观察项目,最好有业务架构图和技术架构图。业务架构图帮你梳理整个业务解决了什么问题,进入了什么阶段。技术架构图拆解了每个技术模块,要熟悉每个技术模块作用,以及自己要做的模块处在整个技术架构的什么位置。 其次要读代码。从功能最核心的入口开始,把项目跑起来,断点把代码跟进下去,我认为这是比较有效的方法。 最后要动手练。光看是不够的,要从一个简单的功能开始做起来,边做边熟悉,并且要跟进整个项目周期(需求、设计、开发、测试、打包、上线、监控)为后续复杂功能做准备。敬请关注 请点击关注按钮【IT徐胖子】会持续为大家奉献互联网和技术干货内容,感谢支持