这是一个创建于 2779 天前的主题，其中的信息可能已经有所发展或是发生改变。
在实现一个方法的时候，经过思考，思路基本明确，但是在写的时候，在处理各种边界条件时就会把原来的思路打乱，导致要重新捋一捋思路，感觉很浪费精力，间接导致编程效率降低。 请问各位怎么解决这个问题？有什么好的工具的话麻烦推荐一下！谢谢。
第 1 条附言 · 2018-03-22 09:24:09 +08:00
看了各位的回答，目前最好的解决方案如下：
- 通过图形化工具定好流程逻辑，处理好边界。
- 通过注释理好思路
目前的想发是先实践2，带着用一下图形工具试试效果怎样。
谢谢各位!
第 2 条附言 · 2018-03-22 09:54:25 +08:00
经各位的指点，现在发觉更多的是自己的编码方法上出现问题。 回去看看代码，处理边界、异常的代码远远多于正常的逻辑代码。 看了大部分V友的实践，大部分是先不管，先写正常逻辑代码，先跑通， 然后在完善各种边界、异常处理。
感觉这种方式更自然，效率更高，打算实践这一方法。
 |
1
pkookp8 2018-03-22 08:56:28 +08:00 via Android  1
先写框架流程。。。其实我也不懂，乱讲的
|
 |
2
binjoo 2018-03-22 08:57:46 +08:00 1
思维导图记录下来吧，看着图更加清晰。
|
 |
3
quickma 2018-03-22 08:58:05 +08:00 1
一边写一边往腿上的伤口撒辣椒水(雾
好吧，先写一个整体思路的 todo，再实现，再处理琐碎的东西。其实不这样做也是可以保持思路清晰的，如果你需要重新捋思路，说明逻辑能力和记忆力不够强，需要加强锻炼。 |
 |
4
460881773 2018-03-22 08:58:40 +08:00 1
写着写着就清晰了
|
 |
5
micean 2018-03-22 09:00:48 +08:00 1
先把思路先写在注释里不就解决了，还要上工具？
|
 |
6
l57t7q 2018-03-22 09:01:20 +08:00 1
我一般把关键字手写到本子上，还有你这种还算好的。我经常想问题的时候，好多烦人的家伙过来给我讲需求，问问题，而且一般都是按照 5 分钟以上。
|
 |
7
justinwu 2018-03-22 09:01:44 +08:00 via iPhone 2
画图（流程图、活动图、序列图、状态机等），或者写伪代码（注释也行）把主要流程写出来。
多画图，多用自然语言描述问题，编程思路就越来越清晰了。 |
 |
8
z0z 2018-03-22 09:02:25 +08:00 1
不用特意保持清晰。
你上来就开始写，想到哪就写哪，写着写着就会发现有很多地方需要改，然后就去改。 等到要做下一个实现时，重复上面的操作。 每次觉得写完时把整个流程捋一遍。 等你写了十几个，几十个的时候，你的大脑自动就会告诉你了。 |
 |
9
qping 2018-03-22 09:06:51 +08:00 3
先搭好架子，不管细节，预留一个空方法，等到所有流程都梳理完再回头实现细节。
这样效率特别高。 |
 |
10
dandycheung 2018-03-22 09:08:34 +08:00 via Android 1
专心写。
|
 |
11
sundev OP @x7395759 自认为逻辑性还行，记忆力跟不上的确是这样。一开始想逻辑的时候是基于广度优先，但是写代码的时候又变成深度优先（处理各种边界条件），渐渐的原来想好的逻辑有忘了。
看了楼上各位的实践，觉得最好的还是画流程图或者思维导图，但是觉得先写注释貌似更方便一点。 |
|
14
sundev OP @qping 同感，想的太多反而降低了效率。
以前学校的时候，老是一再强调容错能力，感觉这个观念一直根植于脑海中（主要是这个观点也符合本人的观点），然后在写代码时候，不自觉的就处理各种边界，各种异常，如果不处理总感觉自己的代码没写好，不完美。 |
|
15
qping 2018-03-22 09:19:08 +08:00
@sundev #14 容错的观念是对的，写出的代码也健壮。这些可以放在后面优化，效率优先，最快的实现一个 demo 是最重要的
|
 |
16
vegito2002 2018-03-22 09:19:37 +08:00 via iPad 1
一般来说刚开始写的时候不要想太多， 脑子里想一个最典型的 case， 根据这个来写就行了； 什么特殊的 case 后面再考虑； 大不了改代码， 有个第一版的代码再改比一开始就想写一个面面俱到的版本要容易很多；
我最懒的时候，recursion 一律先不写 base case，while 循环的 header 一律先写 true ； 后面再改。 包括如果是大的结构设计也是一样， 一开始就 C 风格的先开始写， 写着写着感觉有些代码应该放在一起有些代码可以复用， 再提取出去到单独的类或者函数里面。 套用一个大神教给我的话： 硬着头皮先开始写。 写代码不要掺杂太多数学性的习惯（哎呀没有完备的理论基础写出来的代码怎么能行啊） |
 |
17
Leigg 2018-03-22 09:25:01 +08:00 via iPhone 1
现在习惯先把要做的事情分解成几个步骤，别分太细，写在真·笔记本上。就酱，用本子的感觉和写在记事本或者其他工具上是不一样的
|
 |
19
southsala 2018-03-22 09:28:57 +08:00 1
复杂的画图 不复杂的拿起键盘直接写不过会很累脑子
|
|
20
sundev OP @vegito2002 谢谢你详尽的回答，你的这些方法对我的启发非常大。尤其是关于递归，我写递归经常被绕进去！
|
 |
22
starmoon1994 2018-03-22 09:35:12 +08:00 1
你们都不写 todo 的吗。。。
|
|
23
sundev OP @starmoon1994 我以前 TODO 更多的是用在某个模块或方法上，方法内部没用过。
|
 |
24
rb6221 2018-03-22 09:44:24 +08:00 via Android 1
先把最理想的情况 整个流程跑通，写完以后再从头开始处理分支情况。这时候可以一点一点啃，完全不慌
|
 |
27
ThirdFlame 2018-03-22 10:04:14 +08:00 1
边界条件处理时 ，我是画个脑图，一个一个分支都确定出来。然后开始干。
|
|
28
sundev OP @wqzjk393 @ThirdFlame 看来还是得借助图像化工具，谢谢了，打算试试脑图工具，不太复杂的手话貌似更方便。
|
|
29
ThirdFlame 2018-03-22 10:12:02 +08:00
@sundev #28 当然 16 楼的大神思路是非常值得学习的，先把功能实现了。 然后再处理边界和异常
|
 |
30
luoluoluo 2018-03-22 10:20:57 +08:00 1
少摸鱼，专注点
|
 |
31
tmac33 2018-03-22 10:31:57 +08:00 via Android 1
我开始之前一般都会写个单元测试
|
 |
32
weer0026 2018-03-22 10:34:32 +08:00 1
个人经验是：复杂功能有思路就狂写，先实现流程再 debug，简单但是凌乱的功能要列个 todo list 一个一个慢慢清。
|
 |
33
whypool 2018-03-22 10:44:46 +08:00 1
每个 task 先写流程，先写业务，遇到卡的地方打个 todo，即使弄个假数据也要把流程写通
然后把单元测试写了，再去搞卡壳的地方，假数据一换，测试一跑通就可以关 task |
 |
34
metorm 2018-03-22 10:46:58 +08:00 via Android 1
先搭框架，再处理琐碎的东西。如果你发现为了处理边角需要修改框架，那么说明你技术不过关或者框架设计错了。
|
 |
35
luanjia 2018-03-22 10:50:12 +08:00 via Android 1
学习了
|
 |
36
nullen 2018-03-22 11:27:34 +08:00 1
先写文档，思维导图，然后再开始编码。
|
 |
37
ibolee 2018-03-22 11:42:17 +08:00 1
补充一点:戴个隔音耳塞而不是耳机。
|
 |
38
MinonHeart 2018-03-22 13:56:05 +08:00 via iPhone 1
@vegito2002 哈哈，说的话。架构师做的事可能真好想法
|
 |
39
qymhy 2018-03-22 14:27:51 +08:00 1
先理清产品 /功能逻辑，再将其落实为文档，最后基于文档开发。
|
 |
40
AckywOw 2018-03-22 14:30:38 +08:00 1
边界问题有大有小，大的一开始就要想到设计好，小的最后修补一下就 OK
|
 |
41
ytlm 2018-03-23 07:53:46 +08:00 via Android 1
有大致思路的话就先写吧，总有想不完的情况。
|
Select Language