1
sangbill 2016-10-15 20:16:37 +08:00 via iPhone
同入职不久,加油!
|
2
chaleaoch 2016-10-15 20:20:52 +08:00
没有文档同时也没有人讲解业务流程吗?
|
3
ainimuyan 2016-10-15 20:42:31 +08:00
同样刚入坑,问题相当多,提了很多重构建议被质疑。。看来他们是要深入践行破窗效应。。
|
4
lynnworld 2016-10-15 20:46:06 +08:00
慢慢来,先从自己的新代码入手
|
5
wbing 2016-10-15 21:11:07 +08:00 via Android
感觉熟悉代码最好的方式是直接找几个现有的 bug 去修复,边调试边熟悉代码比较快,至少我是这么干的
|
6
ruandao 2016-10-15 21:15:25 +08:00
直接做功能,然后根据功能去找代码
|
7
youfang 2016-10-15 21:25:07 +08:00 via Android
刚入新项目 要学习公司内部前端框架 坑爹
|
8
huhuhushan 2016-10-15 21:44:28 +08:00
@ruandao 赞同,这应该是最方便高效的方法。
|
9
zonghua 2016-10-15 22:03:48 +08:00
哈哈哈。看文档看了一个星期
|
10
veelog 2016-10-15 22:27:36 +08:00
当年刚入职 啃 webkit 源码, 这一啃就是好几年啊。。
|
11
ivvei 2016-10-15 22:30:32 +08:00
同样在啃代码,没文档。代码特么还没注释…… 这代码还是现任 CTO 写的,喷都不好喷……
|
12
woojuno 2016-10-15 22:36:00 +08:00
我这接手个项目,不光没文档,代码还没注释。拿到开发任务,提出疑问,回复我让我自己判断,其实就是“猜”的意思。我也是醉
|
13
xsstomy 2016-10-15 22:53:47 +08:00
看到一种说法是,如果对自己的调试能力自信,直接源代码跑起来,开启调试模式,一步一步的调试。
|
14
palytoxin 2016-10-15 23:37:23 +08:00 via Android
@ainimuyan 别提重构建议了,你又不会真的去重构,能让代码跑起来这么基础的问题你都不一定做得到,重构的工作量放到谁头上,你给他发工资么?
|
15
loveyu 2016-10-15 23:51:44 +08:00
修 BUG 应该是最好的途径了,想重构这事至少得把整个业务逻辑整得熟练再说,最烦公司来个人就说要重构的了
|
16
fish267 2016-10-15 23:54:59 +08:00 via iPhone
Debug
|
17
billyu 2016-10-16 08:06:44 +08:00 via Android
一样一样,我 java,公司自己弄了一些库
|
18
leefly 2016-10-16 09:47:12 +08:00 via iPhone
花了两个多月 大部分业务都重构了一遍🌚
|
19
ainimuyan 2016-10-16 12:02:56 +08:00
为何大家对重构如此反感呢,或者大家认为重构就是全盘推翻重来?
现在每天做的就是为了更好的添加新功能而对原有代码做一些调整,这算是一种重构,或者有的代码写的不堪入目。 后面业务越来越多,而且业务方向有些调整,现在的整体设计完全是为了满足原有的业务范围,而且都是自下而上设计,层层抽象后发现现在的整体方式并不适用于去扩展新的业务分支,这时候不改怎么办呢,继续往上堆? |
20
palytoxin 2016-10-17 00:38:53 +08:00 via iPhone
@ainimuyan 公司新来个人,代码看不到两行,天天嚷嚷没文档看不懂,多看几行就说 代码傻要重构。给你你能忍?
|
21
tilv37 2016-10-17 11:07:27 +08:00
接手新公司的代码,前人 1 年前早已离职,无文档,公司里唯一“懂”该程序的人,只能告诉我程序的使用方法。其他的全都不知道。我都不知道我那一阵是怎么度过的。
|
22
RiceNoodle 2016-10-17 13:04:15 +08:00
@ainimuyan 刚入坑就重构,会不会太自信了点?
我觉得重构起码要基于对于业务有足够的了解。而且重构要确信带来优势,无论是阅读上的优势还是维护上的优势,这个优势不能只你一个人说了算,起码得到大多数项目组的认可才行吧。 再一点,你重构了代码,也要和测试同事沟通清楚。不测试上线的话,是对项目的不负责,测试的话,就涉及到测试同事的工作安排了。 我以为,想清楚了重构的目的,有了足够的资源(时间,同事对重构基本方案的认可,测试同事的时间),再去重构会更合理一点。 不赞成动不动就重构的做法,我那样更大概率只会留下更多的坑而不是减少坑。。 |
23
ainimuyan 2016-10-17 22:30:08 +08:00
@RiceNoodle 你说的很多点都是对的,各种因素自然会考虑的,并且业务也不是很复杂,不然我傻啊给自己挖坑。。😁
|
24
ainimuyan 2016-10-17 22:39:27 +08:00
@palytoxin 当然不能忍,我是接手了一段时间了,项目不大也增加了不少功能了,业务的各个方面感觉理解的还算透彻并且也提了不少建议被接受了,基于这些前提以及后续业务方向的调整,同时原有的代码是一个刚学几个月 java 的同事为了赶进度写的。。。自然会有一些问题的,因此。。感觉要是你的脾气,你会比我还想改一改。另外自信谈不上,我更愿意向大家学习,各种前辈的代码也是看了又看,或者有问题的话尽早提出来一起讨论避免埋下什么隐患。。。大家何必这么激动呢。。😁
|