※ 引述《sbbty018 (charlie)》之铭言： : 各位大神好 : 我是最近刚从资策会(java)毕业找到目前这间台中的类博弈公司(40k) : 面试的时候没问目前团队的状态 : 上班第一天才发现原来我是第一个RD。MIS则是大概有六位 : 公司目前的code都是之前中国外包厂商写的 : 然後一两个月前公司决定要自己组台湾的RD团队就跟中国厂商停止合作 : 所以我这个菜鸟一进来就得自己慢慢看code然後debug : 另外他们还有用到redis跟rabbitMQ也是我在资策会没学到的让我感到有些负荷不来 : 请问这种情况在业界很常见吗? (超菜junior接手别人的code然後没有人能够请教) 我的第一份跟第二份工作都是这个样子，一开始你会像麻痹的人，给你几个建议 1. 掌握启动前的入口 - 大部分程式语言都会有一个从作业系统下命令开始执行 的进入点，可能会载入 config、环境变数、命令参数这些东西，你要先清楚 这些东西的配置意义是什麽。 2. 掌握启动後的入口 - 如果是 server 或常驻程式，在执行阶段就会有监听行为。 可能来自於 http API、socket、message hook、Redis subscribe .... 你就要找到这些呼叫点的 function，尝试插 log 或 print，追踪一些上下游关系 然後学习用工具打约定好的通讯格式测试，像 postman 或去 redis 丢 pub 3. 尝试动动手脚 - 掌握入口後你就知道哪边会像大脑发出命令，而你要让程式神经 将命令传达到该去的地方。所以你要先假定一个起点跟终点，比如 rabbitMQ 收到 讯息经过逻辑运算会将结果存进 redis 某个 key 值，那你就去追 function 的 资料流向以及中途被包装成什麽样的资料结构最後又转成什麽样的字串存 redis 4. 起身连续动作 - 独立的资料处理都掌握的差不多後就要看系统 state machine 跟 life cycle 结构的运作模型，自己去新增一些状态、设计一些复杂的脚本看看 程式运作的结果跟你想要的是否相同。配合前面三点，自己去修改 config 丢不同 参数、自己开发一个测试的入口，然後呼叫已知的 function 却在逻辑中判断命令 夹带自定义的 config 参数并达成某些状态条件时要引导至自己另外写的 function 印 log，这样你就有办法介入原有程式并增加新功能 5. 外部工具先学有用到的部分 - 例如 redis 写资料有很多命令，set, hset, rpush .. 每个的用法和适合的场景不同，照理说科班教育会让你全部学懂避免误用才去实作 但你接手别人程式面对陌生工具时你其实是要反过来根据程式的资料结构去搞清楚 这个指令的用法就好。先别浪费时间知道他们存在 redis 内有何差别，你要看的 只是在程式内从介面定义读回来的资料长什麽样子。除非你很有兴趣，否则训练自己 在 code 内看到对 redis 呼叫的指令能快速从文件中找到用法说明更重要 6. 一知半解下的行车纪录 - 到这阶段差不多你就可以开发新需求，但会有很长一段时间 你觉得自己是在一知半解下做出新功能的。很多时候你是从 try error 发现一条可以 正确执行完的路就走了，然後不知道状态或资料变了会产生 side effect。别慌，在 你不懂的地方加注解，给个编号，然後在自己的文件中写上编号并纪录起来。当 side effect 发生时，你有机会从文件中判断可能与哪几条有关，去 code 搜寻注解所在 档案有助缩小判断的范围。 7. 不要改坏胜过不要怕改坏 - 有些人会说你就是要放胆去改不要怕坏，从零开发是如此 因为那是你自己写的，掌握度高，又没有曾经稳定运作的印象，坏就坏了再修就好。 但今天你是在很多东西没摸熟不懂的情况下接一个已架构好的系统， 维持运作稳定才不会给自己找加班的麻烦，老板对你的新人印象才会好。 一堆需求进来先挑自己有把握的并告诉 PM 她想先上但你会花超过预期时间的东西 大多专案管理者会同意完成一个不起眼的功能胜过引人注目却花超久时间还搞不定 在稳定中累积经验也累积自信，再慢慢往可能改坏的功能开发 8. 换轮胎 - 过一阵子你可能突然发现好多新功能你其实重复造了轮子，只是当初看不 出来某个 function 跟你写的目的相同。研究对方写法，你会柳暗花明又一村；这 时候你的思考逻辑会渐渐与原作者同化，突然开窍了，看懂很多东西了，这才是你 可以开始不要怕改坏准备对模组重构或大展身手的阶段。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.169.59.75 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1657754514.A.AE1.html