1
YouXia 2015-07-04 11:08:00 +08:00 via Android
重构
|
2
hh3755 OP @YouXia 人少,需求多。是要抽出一个人来做专门重构吗。如何解决项目进度和重构本身挤占时间的冲突呢。重构如何做呢。专门设计还是调整当前的东西以满足需求,有何准则,或书推荐。
|
3
loading 2015-07-04 11:13:47 +08:00 via Android
跑起来再说,等你们人走差不多了,项目不能看,自然就“重构”了…
|
4
kn007 2015-07-04 11:16:34 +08:00
没有规划是很sb的,以后很难改,牵一发而动全身。。。
没有规划就如 @loading 所说的,等你们走光了, 这个项目就可以重构了。。。 |
5
gongweixin 2015-07-04 11:18:43 +08:00
逐步优化,每个新需求多估点时间,每次把周边的优化下,全部重构在公司里不现实
|
7
hh3755 OP @gongweixin 我也觉得可以这样。但是每次新需求,并不是所有人(有新手)都愿意去动哪些容易产生问题的东西,比如重构,一般是怎么处理这种情况的呢。另外遵循怎么样的准则,重构能做得比较好呢。
|
9
hh3755 OP @loading 设计架构弄不好就弄巧成拙,大家都是如何提高自己的架构设计水平的呢。目前我只知道*重构*那本书。想顺便把大家的重构水平也提高一下。
|
10
kn007 2015-07-04 11:25:20 +08:00 1
@hh3755 如果你确实有时间,而且这个项目老板也不想投入金钱去重构新的。。。
看下你这个项目,尽量先把这个项目按功能模块化(简单说就是函数汇集),然后看下模块里函数是不是有重复的东西,去掉,有些东西只能顺藤摸瓜,才能搞好。全部弄好后,集成起来就是烂尾的代码了。 最好一个方向,就是选好个项目的核心,围绕那个核心来模块化。 就像核心交换机、路由器、无线控制器、防火墙、一堆二层交换机、一堆AP。肯定要以核心交换机为主,其他为辅,来配置规则。 |
11
ZackYang 2015-07-04 11:29:17 +08:00
<<代码大全2>>, <<重构>>, <<PoEAA>>, <<设计模式>>
|
12
hh3755 OP @kn007 谢谢中肯的建议。我也渐渐发现某些东西在原来尚能满足需求,但是源源不断的新的需求进来之后,让原来的架构渐渐的运行起来有些吃力,进而慢慢变成一个大问题。但是需求进来的时候时间往往是不可控的。大家都不能等你把架构改了再做需求。如果是盲目的直接调整架构是有益的。比如觉得哪点就好,需要调整就直接调整。问题就是说 架构哪些,怎么判断哪些需要被架构。
|
14
initialdp 2015-07-04 11:43:56 +08:00
从来没有见过这种情况下代码最后会变好。
|
15
hahasong 2015-07-04 11:49:44 +08:00
并不能变好,有一天你受不了走人的时候,这事就算完了
|
16
datou552211 2015-07-04 13:36:28 +08:00 via iPhone
赶紧重构,要不然恶性循环,甚至影响产品质量
|
17
Felldeadbird 2015-07-04 15:11:36 +08:00 1
我给楼主一些建议:
1.先明确目前项目是否公司核心。核心项目不是你说重构就重构的, 2.核心项目如何重构?最好就是在开发某些大功能时,偷偷加入自己的设想架构。但是未必凑效。我就试过这样做,而且很快就失败了。因为该改动的需求流产了,我做的重构也没了。 3.是否有相同的新项目开发。老板可能会让你使用现有的程序直接修改过去。把握这个时机,强烈向老板推荐重构或者自己有权利进行重构。 我现在就是走这样的路线。在新项目用新架构,待新项目成熟了,就淘汰掉旧项目的旧架构,使用新架构。 4.旧项目如何处理?有一个过渡期,楼主可能需要投入第一时间进行维护的。所以做好觉悟吧。 这玩意其实吃力不讨好,因为整个团队里面,不是每个人都有重构的思想。 |
18
kn007 2015-07-04 15:17:25 +08:00
@Felldeadbird 这种处理方式好,哈哈,也挺无奈的
|
19
vietor 2015-07-04 15:25:00 +08:00 via Android
逐步分拆独立模块
|
20
hohoho 2015-07-04 15:28:37 +08:00 via iPhone
也遇到了楼主的问题。公司的 iOS app 找的外包,我接手时看了代码都快哭了。新需求很多,没人没时间重构,领导关心的是功能,跟老大提出来老大也很无奈,完全推倒重写是不可能的。
能做的就是边加新功能边力所能及地修改重构原来的,这个过程好蛋疼。到现在也重写了近三分之一啦,希望最近的需求忙完能稍微空闲些,至少把tm的那一坨storyboard都删了! |
22
Clarencep 2015-07-04 17:58:21 +08:00
难道不是代码越来越烂,快要无法维护的时候,干脆起个2.0版本,重写一遍...
2.0也越来越烂,要无法维护了,老板终于下定决心搞代码质量,起个NG(next generation)版本,要狠抓代码质量... NG版本依旧越来越烂, 干脆起个3.0版本继续重写吧... |
23
hh3755 OP @Felldeadbird 对于第2点。关键是我们在不断的在原来的功能上加需求。越加越乱,不重构似乎已不可能。时间上的确很紧张。很多时候花了很多时间,结果新重构的功能比原来的功能不稳定还引来怀疑改动的价值。 对于第3,4点,公司只想把代码跑下去。重写一个新版本根本不是产品能提得出来的需求。也不会有那么多时间。也同意不是每个人愿意重构。
|
24
hh3755 OP @datou552211 是否有重构的经历可供参考。其实现在比较迷茫。
|
25
mouhong 2015-07-04 21:39:24 +08:00
重构,小步慢进。一般情况下不要想着重写,在很多时候,重写要么是写不完,要么是写完不见得比原来的好
|
26
mouhong 2015-07-04 21:44:48 +08:00
不过,你是项目负责人的角色么?要是,那或许可以先争取让上层认同重构的重要性,再通过一些制定一些规范让其它开发人员来遵循,定期做些 Code Review?要不是,那貌似就比较纠结了~
|