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

guyeuro · 2017-06-29T16:16:25Z

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

清楚

细节

不周

牛人

31 replies • 2017-07-01 01:02:19 +08:00

geelaw

Jun 30, 2017

2

1

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

imn1

Jun 30, 2017

2

不能，又不是穆罕默德

cranelee13

Jun 30, 2017 via iPhone

3

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

guyeuro

OP

Jun 30, 2017

4

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

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

binux

Jun 30, 2017

5

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

WhoMercy

Jun 30, 2017 via Android

6

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

cloverii

Jun 30, 2017 via Android

7

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

JonyOang

Jun 30, 2017

8

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

Tunar

Jun 30, 2017 via Android

9

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

FinnBai

Jun 30, 2017

10

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

GaoYL

Jun 30, 2017

11

尽量想呗.

buckyRRRR

Jun 30, 2017

12

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

Jameson1559

Jun 30, 2017

13

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

TaoSama

Jun 30, 2017 via Android

14

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

lsido

Jun 30, 2017

15

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

msg7086

Jun 30, 2017

16

整数数字转读音

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

chnhyg

Jun 30, 2017

17

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

guyeuro

OP

Jun 30, 2017

18

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

guyeuro

OP

Jun 30, 2017

19

@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

Jun 30, 2017 via Android

20

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

JacksonBond

Jun 30, 2017

21

shit happens

ksaa0096329

Jun 30, 2017

22

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

msg7086

Jun 30, 2017

2

23

@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

Jun 30, 2017

24

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

QQ2171775959

Jun 30, 2017

25

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

katsusan

Jun 30, 2017 via iPhone

26

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

uxstone

Jun 30, 2017

27

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

Ouyangan

Jun 30, 2017

28

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

Messidaredream

Jun 30, 2017

29

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

msg7086

Jul 1, 2017

30

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

zhx1991

Jul 1, 2017

31

当然不能

复杂系统逻辑多交互多

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