刚入职,要熟悉现有代码(没有文档)好头痛...

[mortonnex]

代码量非常大,没有文档

只有劝自己死磕了...

[sangbill]

同入职不久，加油！

[chaleaoch]

没有文档同时也没有人讲解业务流程吗？

[ainimuyan]

同样刚入坑，问题相当多，提了很多重构建议被质疑。。看来他们是要深入践行破窗效应。。

[lynnworld]

慢慢来，先从自己的新代码入手

[wbing]

感觉熟悉代码最好的方式是直接找几个现有的 bug 去修复，边调试边熟悉代码比较快，至少我是这么干的

[ruandao]

直接做功能,然后根据功能去找代码

[youfang]

刚入新项目 要学习公司内部前端框架 坑爹

[huhuhushan]

@ruandao 赞同，这应该是最方便高效的方法。

[zonghua]

哈哈哈。看文档看了一个星期

[veelog]

当年刚入职 啃 webkit 源码， 这一啃就是好几年啊。。

[ivvei]

同样在啃代码，没文档。代码特么还没注释…… 这代码还是现任 CTO 写的，喷都不好喷……

[woojuno]

我这接手个项目，不光没文档，代码还没注释。拿到开发任务，提出疑问，回复我让我自己判断，其实就是“猜”的意思。我也是醉

[xsstomy]

看到一种说法是，如果对自己的调试能力自信，直接源代码跑起来，开启调试模式，一步一步的调试。

[palytoxin]

@ainimuyan 别提重构建议了，你又不会真的去重构，能让代码跑起来这么基础的问题你都不一定做得到，重构的工作量放到谁头上，你给他发工资么？

[loveyu]

修 BUG 应该是最好的途径了，想重构这事至少得把整个业务逻辑整得熟练再说，最烦公司来个人就说要重构的了

[fish267]

Debug

[billyu]

一样一样,我 java,公司自己弄了一些库

[leefly]

花了两个多月 大部分业务都重构了一遍🌚

[ainimuyan]

为何大家对重构如此反感呢，或者大家认为重构就是全盘推翻重来？
现在每天做的就是为了更好的添加新功能而对原有代码做一些调整，这算是一种重构，或者有的代码写的不堪入目。
后面业务越来越多，而且业务方向有些调整，现在的整体设计完全是为了满足原有的业务范围，而且都是自下而上设计，层层抽象后发现现在的整体方式并不适用于去扩展新的业务分支，这时候不改怎么办呢，继续往上堆？

[palytoxin]

@ainimuyan 公司新来个人，代码看不到两行，天天嚷嚷没文档看不懂，多看几行就说 代码傻要重构。给你你能忍？

[tilv37]

接手新公司的代码，前人 1 年前早已离职，无文档，公司里唯一“懂”该程序的人，只能告诉我程序的使用方法。其他的全都不知道。我都不知道我那一阵是怎么度过的。

[RiceNoodle]

@ainimuyan 刚入坑就重构，会不会太自信了点？
我觉得重构起码要基于对于业务有足够的了解。而且重构要确信带来优势，无论是阅读上的优势还是维护上的优势，这个优势不能只你一个人说了算，起码得到大多数项目组的认可才行吧。
再一点，你重构了代码，也要和测试同事沟通清楚。不测试上线的话，是对项目的不负责，测试的话，就涉及到测试同事的工作安排了。
我以为，想清楚了重构的目的，有了足够的资源（时间，同事对重构基本方案的认可，测试同事的时间），再去重构会更合理一点。
不赞成动不动就重构的做法，我那样更大概率只会留下更多的坑而不是减少坑。。

[ainimuyan]

@RiceNoodle 你说的很多点都是对的，各种因素自然会考虑的，并且业务也不是很复杂，不然我傻啊给自己挖坑。。😁

[ainimuyan]

@palytoxin 当然不能忍，我是接手了一段时间了，项目不大也增加了不少功能了，业务的各个方面感觉理解的还算透彻并且也提了不少建议被接受了，基于这些前提以及后续业务方向的调整，同时原有的代码是一个刚学几个月 java 的同事为了赶进度写的。。。自然会有一些问题的，因此。。感觉要是你的脾气，你会比我还想改一改。另外自信谈不上，我更愿意向大家学习，各种前辈的代码也是看了又看，或者有问题的话尽早提出来一起讨论避免埋下什么隐患。。。大家何必这么激动呢。。😁

[ainimuyan]

@palytoxin 我也应该反思反思，或许我一些地方做的比较激进，应该慢慢来，考虑大家的感受，每个人的感受，循序渐进，比如等到问题出现了大家会更容易接受一点。。。

[palytoxin]

@ainimuyan 别小瞧任何业务逻辑，很可能有你根本想不到的坑。测试不是百分百覆盖的情况下，除了性能特别不能忍，尽量别动生产代码。