我有时写一些有点算法或者复杂点的程序, 都是只能想个大概 感觉不动手写,就不能把细节完全想清楚 而是边写边改 写出来才发现有些地方考虑不周(调试前) 然后改一下
牛人估计是写之前就每个细节都想清楚了吧
1
geelaw 2017-06-30 01:02:00 +08:00 2
正确的模块化+自顶向下的顺序书写可以让你不用立刻想好细节。
|
2
imn1 2017-06-30 01:07:44 +08:00 2
不能,又不是穆罕默德
|
3
cranelee13 2017-06-30 02:49:22 +08:00 via iPhone
我认为那怕是 Linus 也不会想好整个细节才干活吧。
|
4
guyeuro OP |
5
binux 2017-06-30 03:20:11 +08:00
可以啊
不过你这个「十几二十行的程序」根本就没必要想清楚 「整数数字转读音」这又是另一个问题,根本不是是否想清楚程序的问题,而是是否想清楚规则的问题。 |
6
WhoMercy 2017-06-30 07:54:00 +08:00 via Android
小的程序有大概思路就可以写了,边写边思考。
大的程序动手前一般都要构思好对当前项目的影响、对以后开发的帮助,基本上要把细节都拿捏好(看经验)。 |
7
cloverii 2017-06-30 08:15:17 +08:00 via Android
以下特指 lc 这种不超过 50 行的代码 我也有类似情况,以为自己想清楚了但是写起来还是会有问题,跟我汉子讨论过这个问题,得出的结论是我人脑编译能力不太够 - - 不过我们可能还是不太一样?毕竟我开写的时候是确确实实以为自己想清楚了…
|
8
JonyOang 2017-06-30 08:16:52 +08:00
都想清楚了,估计就没点儿开始写了
|
9
Tunar 2017-06-30 08:37:41 +08:00 via Android
大致框架想清楚了,然后再一点一点往里填
|
10
baiyi 2017-06-30 09:54:06 +08:00
每个细节都能想清楚 是不是就没有 重构 的事了
|
11
GaoYL 2017-06-30 09:55:17 +08:00
尽量想呗.
|
12
buckyRRRR 2017-06-30 10:07:31 +08:00
如果能想清楚的话,请问 bug 是怎么出现的,不是程序员,纯好奇
|
13
Jameson1559 2017-06-30 10:20:07 +08:00
@buckyRRRR 如果能想清楚……那可能导致 BUG 的只有手癌了吧……哈哈哈哈哈……
|
14
TaoSama 2017-06-30 10:36:17 +08:00 via Android
说明思考的太少了 = = 一开始能 control 50 行就很不错 多刷刷题就能 control 100~200 行 最后 300~500 行都是可以的
再往上就没啥意义了 毕竟 50 行的水平感觉就能 hold 住一般工程了 (我 xbb 每个人的感觉毕竟不一样 |
15
lsido 2017-06-30 11:48:23 +08:00
我一般都是做个需求分析就开始做了,遇到问题再解决,一个项目里会出现千奇百怪的问题,怎么可能把每个细节都想到呢?神人也!
|
16
msg7086 2017-06-30 12:35:07 +08:00
整数数字转读音
这个能十几二十行? 光写个单元测试都不够十几二十行吧。 |
17
chnhyg 2017-06-30 13:11:28 +08:00
每个细节都想清楚是不可能的,但想清楚七八成的细节还是没问题的,80% 的时间思考,20% 的时间编码。
|
19
guyeuro OP @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 里的细节等等 然后写了之后,再慢慢花几分钟调整,就能把细节全想清楚 |
20
TaoSama 2017-06-30 15:22:41 +08:00 via Android
@guyeuro 这还是思考的太少啊 你可以强迫自己去完全想清楚所有的细节 (我的意思是指编译器编译的结果跟人脑编译的结果完全一致) 注意强迫二字 反正非一日之功 不想清楚就不写 这样才会有提高
|
21
JacksonBond 2017-06-30 16:13:01 +08:00
shit happens
|
22
ksaa0096329 2017-06-30 16:13:33 +08:00
想的太多,做的太少...结果就是浪费时间
|
23
msg7086 2017-06-30 16:22:23 +08:00 2
@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 的实现,就可以提前做测试了,只要让函数返回一个固定值,就可以测试万位、亿位的正确性了。 |
24
msg7086 2017-06-30 16:23:48 +08:00
好像漏打了点逻辑,随便看看就好,手打的没进编辑器。
|
25
QQ2171775959 2017-06-30 16:27:05 +08:00
手码这么多代码,不错。。不过还是得细心点吧,老兄加油。
|
26
katsusan 2017-06-30 19:45:23 +08:00 via iPhone
我也和 lz 差不多,感觉自己蠢蠢的,都是拿纸算
|
27
uxstone 2017-06-30 21:18:29 +08:00
先想好要挖几个坑,
再在每个坑里深挖 |
28
Ouyangan 2017-06-30 21:57:13 +08:00
我会将整个流程和关键细节想清楚再动手 , 并且用为知笔记写下整个思考过程 . 总体时间差不多 ,但是真正写代码的效率和 bug
|
29
Messidaredream 2017-06-30 23:06:26 +08:00
自上而下,边做边改,列大纲。
|
30
msg7086 2017-07-01 00:13:50 +08:00
@QQ2171775959 这种逻辑一般都会当场写测试代码,调一下就行了。
|
31
zhx1991 2017-07-01 01:02:19 +08:00
当然不能
复杂系统逻辑多交互多 事先能想个主流程的大概, 有些边边角角的东西写到了才能发现有坑 |