楼主:
yamakazi (大安吴彦祖)
2020-07-12 12:17:55如果你没写错的话
一年多看几万行code真的不多
我也是转职仔,原本在ic house写C做韧体,一个人负责一个.c/.h档。一年才进三行code。
转职后写C++整个team大约十多人,负责的那一层有两千万行code。然后第一年就进快一万行code。
我原本不会C++的,所以什么framework,modern C++,design pattern,multithreaded 之类的都没学过要重学。
我不知道你的工作类似哪种,如果是类似我第一种其实很简单,IDE 上function name点进去看函数定义就好了没那么难。
第二种的话有文件可看那当然最好,但没文件也是很正常。正常人不可能每新增一个class就写一份文件,那样开发速度太慢。而且像MVC或design pattern这种很generic的架构也没人在写文件的。再加上写class diagram或sequence diagram其实很花时间。我刚转职的时候也会写但做上手了以后根本懒得写。
建议你多准备一个萤幕,用双萤幕看会比较快,如果是笔电的话还可以三萤幕。
然后选择适合的editor,我个人是用visual studio code,ctrl加鼠标左键点到function上就可以看到函数定义,用launch.json就可以用debug mode,设断点看call stack然后单步执行。
注解的话我们公司不太写在程式码里面的,都是用issue tracker和git去追踪。比如说你想看这段code是谁写的基于什么理由然后又经过了怎样的演进。你就用git查blame,就会看到这段code是哪几张ticket改的,你再去ticket看上面应该都有商业逻辑和注解可看。有code review的公司在bitbucket上应该也有大家的讨论和注解可以看。
大概是这样,其他想到再补充
作者: dwudwu (NCTUPGOne) 2020-07-12 12:39:00
怎么会离开猪屎屋去系统厂呢?
楼主:
yamakazi (大安吴彦祖)
2020-07-12 12:44:00系统场没有不好呀,而且我公司比较像是外商软件公司
作者:
rainkaras (rainkaras)
2020-07-12 13:01:00推比较现代的作法,很多地方开发时程都压超紧,连测试时间都不给了还写文件
老实说习惯古早时代写小工具都会留readme跟更新纪录了现在都习惯写满满的注解 issue tracker简单标原因就好
作者:
sarau (我是男的)
2020-07-12 13:46:00注解应该是很重要的 毕竟是很直觉的 用git找太费时间了
作者:
Phater (肥特)
2020-07-12 13:54:00楼上倒过来了吧,成千上万行的程式分布不同目录档案,你要找注解还不确定是谁或何时写的,注解是不是还有效. 看git log直接知道作者时间,加上git diff可以知道变化的内容. 跟JIRA Redmine合起来用一目了然
作者: nec1002 (训练自己 加强能力) 2020-07-12 17:40:00
简单来讲就是要用时间补能力 不然就不要干 离职
作者:
cphe (魔鬼藏在垃圾筒里)
2020-07-12 19:05:00注解对于了解细节还是很重要,某些功能的patch修修补补都不知道演进多少次,git log比较适合用来看演进过程,不是trace
最好是有人在看演进过程,git垃圾工具无误,一堆错误观念
楼主:
yamakazi (大安吴彦祖)
2020-07-12 20:24:00其实我比较喜欢perforce
作者:
oneheat (等待)
2020-07-12 21:53:00八成是android+高通...
作者:
sqt (深海)
2020-07-13 06:45:00谢谢分享
作者:
holmes006 (zerglooky)
2020-07-13 12:16:00推git
作者:
cphe (魔鬼藏在垃圾筒里)
2020-07-13 12:57:00某人对git 很悲愤XDD