代码越写越多，有一种失控的感觉？

flyue

原来家里没电脑，所以想做什么都得去网吧。
但是网吧环境不好，不利于思考，所以就养成了这习惯。
先在家里设计，写在纸上，然后统一去网吧输入。

tonykee

楼上是牛人,p服p服 [em16]

HackerStar

LS的LS好勤奋哦！！！
去网吧写代码的我还真没见过...

clayman

重构

qrli

没有一种结构能永远适用，随着开发的深入，总会出现现有结构不再适用的情况，所以重构是半年到一两年就要做一次的，所以一开始设计时就要考虑到日后需要重构的问题，所以designed to be refactored。

所以代码可以分成3类：
1. 十几年内都不会有多大变化的基础代码，如数学库、字符串函数、平台抽象等。这些都很独立，没有什么复杂性。
2. 应用核心模块、框架代码。这部分一定要费心设计好，重构时这部分是比较难于重构的，因为影响比较大。
3. 具体的业务逻辑代码、胶合层代码。只需要局部的考虑，容易写。代码质量要求不高，日后改写、重写的概率很大。这部分有相当的代码可以称作抛弃型代码或一次性代码，不需要重用。

由上，也就可以对应出架构上的分层。当然不是说严格对应，但至少是指导性的对应。

sjinny

恩……说道重构，我想起了那个笑话，但是不记得原版文字了，汗……
假如：
1.做设计时需求已经定义清楚，也就是说要解决的问题本身被定义清楚了
2.需求定义是正确的、完整的，也就是说没有把精力用于解决错误的问题
3.设计时不做需求定义中不存在的任何假设，接口定义清晰、正交
那么应该的结果是：
只要需要解决的问题不变，那么就不需要对设计进行重构

所以我觉得，重构应该是在要解决的问题发生了转变时才进行，所以：
1.一开始做设计时，首先要定义清楚问题，如果有太多的“可能需要”、“如果以后需要”，那么应该使用最保守的问题定义，也就是把所有的“可能”、“如果”去掉，仅仅针对必须解决的问题进行定义，接下来也只解决那些必须解决的问题
2.当以后真正发生了第一条中的变化时，应该可以仅仅通过添加代码来解决问题，而对原有代码的修改应该尽量少，甚至没有修改
3.由于大家是人而不是神，所以前两条的处理中可能会出现失误或瑕疵，而重构是解决这些失误或瑕疵的

clayman

sjinny: Re:代码越写越多，有一种失控的感觉？
只要需要解决的问题不变，那么就不需要对设计进行重构

需求改变只是一方面
有人说过在软件完成之前，你都不可能真正知道自己要写的是什么
难很保证前期需求分析时没有遗漏，做出的设计完美无缺
很多问题只有在开发过程中才会暴露出来
这时候就必须通过重构来修正前期的设计缺陷和不足

sjinny

恩……我猜需求模糊很多时候是因为觉得这个可能需要实现、那个可能需要实现，结果需求边界就模糊了……所以需求定义不仅需要定义需要做什么，还需要定义不需要或暂时不需要做什么，后面一点可能还缺少重视。我觉得把后面这点做好了，以后发生变动时应该可以以增加代码为主，修改代码为辅。更理想的就是多进程的设计，新增需求时就新增程序……

qrli

sjinny: Re:代码越写越多，有一种失控的感觉？

恩……我猜需求模糊很多时候是因为觉得这个可能需要实现、那个可能需要实现，结果需求边界就模糊了……所以...

理想情况就是现实中几乎不可能存在的情况：现实中没有啥项目的需求是明确的，很多项目的需求都是从领导一句话开始的；现实中也几乎没有需求不会变的，计划赶不上变化。所以，我们的设计需要适应现实情况，而不是苛求理想情况。 [em16]

sjinny

呃……我是想逼近理想情况；）