这是一个创建于 3429 天前的主题，其中的信息可能已经有所发展或是发生改变。
不知道大家有没有这样的经历，你当前所做的项目的代码很乱，无架构可言，每天又会有源源不断的新需求过来，参与开发的人并不全是比较牛的人，所以还会补充进去一些烂代码。这样的代码最后如何能变好，或者怎么做才能让这样的代码变得更好。人很少，需求很多，代码比较烂。
 |
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？要不是，那貌似就比较纠结了~
|
Select Language