大家能在写程序之前把每个细节都能想清楚吗？

[guyeuro]

我有时写一些有点算法或者复杂点的程序， 都是只能想个大概 感觉不动手写，就不能把细节完全想清楚 而是边写边改 写出来才发现有些地方考虑不周（调试前） 然后改一下

牛人估计是写之前就每个细节都想清楚了吧

[geelaw]

正确的模块化+自顶向下的顺序书写可以让你不用立刻想好细节。

[imn1]

不能，又不是穆罕默德

[cranelee13]

我认为那怕是 Linus 也不会想好整个细节才干活吧。

[guyeuro]

@cranelee13 我意思是十几二十行的程序，譬如写下面这个方法：

整数数字转读音]
string num2Voice(int num) { … }
例：输入：12345 输出：一万二千三百四十五

[binux]

可以啊
不过你这个「十几二十行的程序」根本就没必要想清楚
「整数数字转读音」这又是另一个问题，根本不是是否想清楚程序的问题，而是是否想清楚规则的问题。

[WhoMercy]

小的程序有大概思路就可以写了，边写边思考。
大的程序动手前一般都要构思好对当前项目的影响、对以后开发的帮助，基本上要把细节都拿捏好(看经验)。

[cloverii]

以下特指 lc 这种不超过 50 行的代码 我也有类似情况，以为自己想清楚了但是写起来还是会有问题，跟我汉子讨论过这个问题，得出的结论是我人脑编译能力不太够 - - 不过我们可能还是不太一样？毕竟我开写的时候是确确实实以为自己想清楚了…

[JonyOang]

都想清楚了，估计就没点儿开始写了

[Tunar]

大致框架想清楚了，然后再一点一点往里填

[FinnBai]

每个细节都能想清楚 是不是就没有 重构 的事了

[GaoYL]

尽量想呗.

[buckyRRRR]

如果能想清楚的话，请问 bug 是怎么出现的，不是程序员，纯好奇

[Jameson1559]

@buckyRRRR 如果能想清楚……那可能导致 BUG 的只有手癌了吧……哈哈哈哈哈……

[TaoSama]

说明思考的太少了 = = 一开始能 control 50 行就很不错 多刷刷题就能 control 100~200 行 最后 300~500 行都是可以的
再往上就没啥意义了 毕竟 50 行的水平感觉就能 hold 住一般工程了
(我 xbb 每个人的感觉毕竟不一样

[lsido]

我一般都是做个需求分析就开始做了，遇到问题再解决，一个项目里会出现千奇百怪的问题，怎么可能把每个细节都想到呢？神人也！

[msg7086]

整数数字转读音

这个能十几二十行？
光写个单元测试都不够十几二十行吧。

[chnhyg]

每个细节都想清楚是不可能的，但想清楚七八成的细节还是没问题的，80% 的时间思考，20% 的时间编码。

[guyeuro]

@msg7086 我看了下我写的这个方法，二十多行，不包括单元测试

[guyeuro]

@TaoSama

比如我写这个方法的这一段


voice[maxlen-1] = numberChars[number % 10];
int i = 2, j = 0;
number /= 10;
while(number != 0){
int x = number % 10;
if(x == 0){
voice[maxlen-i] = numberChars[0];
}else {
voice[maxlen-i] = units[j];
i++;
voice[maxlen-i] = numberChars[x];
}
i++; j++;
number /= 10;
}

动手写之前只能想个大概，不动手写，去想细节，就想不清楚[]里是-i 还是-i-1, i 和 j 的初始值设为多少合适，if else 里的细节等等
然后写了之后，再慢慢花几分钟调整，就能把细节全想清楚

[TaoSama]

@guyeuro 这还是思考的太少啊 你可以强迫自己去完全想清楚所有的细节 (我的意思是指编译器编译的结果跟人脑编译的结果完全一致) 注意强迫二字 反正非一日之功 不想清楚就不写 这样才会有提高

[JacksonBond]

shit happens

[ksaa0096329]

想的太多,做的太少...结果就是浪费时间

[msg7086]

@guyeuro 比如让我写这个代码的话，我会先写结构。
注释也好伪代码也好，得先打框架起来，然后再去慢慢想细节。
比如这个 num2voice，那么首先把功能细分开。
1. 正负号
2. 整数部分
3. 小数点和小数部分（如果有的话）

那么这个函数实现就是：
def num2voice(num)
# const
suffix10k = ['', '万', '亿', ...]

# sign
puts '负' if num < 0
num = num.abs

# partition to 10k segments and convert to voice
segments = []
seg = 0
while num > 0 do
segments << suffix10k[seg]
segments << num10k2voice(num % 10_000)
seg += 1
end
puts segments.reverse.join

# TODO: fraction part
end

到这里主体功能就写完了，接下来只要把 1 万以内的 num10k2voice 实现就好。

我记得上一次写这个类似的程序还是初二的时候，那时候也不知道怎么做软件架构设计，就是从头到尾硬生生开着循环写代码，最后写得老长还难读。现在写得多了以后，养成了逐步细分的习惯，把功能细分到不同的方法里，然后再串起来调用，就很容易想也很容易写了。
而且你看，这些搞完以后，我都不需要写 num10k2voice 的实现，就可以提前做测试了，只要让函数返回一个固定值，就可以测试万位、亿位的正确性了。

[msg7086]

好像漏打了点逻辑，随便看看就好，手打的没进编辑器。

[QQ2171775959]

手码这么多代码，不错。。不过还是得细心点吧，老兄加油。

[katsusan]

我也和 lz 差不多，感觉自己蠢蠢的，都是拿纸算

[uxstone]

先想好要挖几个坑，
再在每个坑里深挖

[Ouyangan]

我会将整个流程和关键细节想清楚再动手 , 并且用为知笔记写下整个思考过程 . 总体时间差不多 ,但是真正写代码的效率和 bug

[Messidaredream]

自上而下，边做边改，列大纲。

[msg7086]

@QQ2171775959 这种逻辑一般都会当场写测试代码，调一下就行了。

[zhx1991]

当然不能

复杂系统逻辑多交互多

事先能想个主流程的大概, 有些边边角角的东西写到了才能发现有坑