各位大神，写代码时的思路是如何保持清晰的？

[sundev]

在实现一个方法的时候，经过思考，思路基本明确，但是在写的时候，在处理各种边界条件时就会把原来的思路打乱，导致要重新捋一捋思路，感觉很浪费精力，间接导致编程效率降低。 请问各位怎么解决这个问题？有什么好的工具的话麻烦推荐一下！谢谢。

[pkookp8]

先写框架流程。。。其实我也不懂，乱讲的

[binjoo]

思维导图记录下来吧，看着图更加清晰。

[x7395759]

一边写一边往腿上的伤口撒辣椒水(雾

好吧，先写一个整体思路的 todo，再实现，再处理琐碎的东西。其实不这样做也是可以保持思路清晰的，如果你需要重新捋思路，说明逻辑能力和记忆力不够强，需要加强锻炼。

[460881773]

写着写着就清晰了

[micean]

先把思路先写在注释里不就解决了，还要上工具？

[l57t7q]

我一般把关键字手写到本子上，还有你这种还算好的。我经常想问题的时候，好多烦人的家伙过来给我讲需求，问问题，而且一般都是按照 5 分钟以上。

[justinwu]

画图（流程图、活动图、序列图、状态机等），或者写伪代码（注释也行）把主要流程写出来。

多画图，多用自然语言描述问题，编程思路就越来越清晰了。

[z0z]

不用特意保持清晰。
你上来就开始写，想到哪就写哪，写着写着就会发现有很多地方需要改，然后就去改。
等到要做下一个实现时，重复上面的操作。
每次觉得写完时把整个流程捋一遍。
等你写了十几个，几十个的时候，你的大脑自动就会告诉你了。

[qping]

先搭好架子，不管细节，预留一个空方法，等到所有流程都梳理完再回头实现细节。
这样效率特别高。

[dandycheung]

专心写。

[sundev]

@x7395759 自认为逻辑性还行，记忆力跟不上的确是这样。一开始想逻辑的时候是基于广度优先，但是写代码的时候又变成深度优先（处理各种边界条件），渐渐的原来想好的逻辑有忘了。


看了楼上各位的实践，觉得最好的还是画流程图或者思维导图，但是觉得先写注释貌似更方便一点。

[qping]

@qping #9 个人经验是不要画图。。。。想得太多效率也低。。。。

[sundev]

@justinwu 请问你话流程图用的什么工具？

[sundev]

@qping 同感，想的太多反而降低了效率。

以前学校的时候，老是一再强调容错能力，感觉这个观念一直根植于脑海中（主要是这个观点也符合本人的观点），然后在写代码时候，不自觉的就处理各种边界，各种异常，如果不处理总感觉自己的代码没写好，不完美。

[qping]

@sundev #14 容错的观念是对的，写出的代码也健壮。这些可以放在后面优化，效率优先，最快的实现一个 demo 是最重要的

[vegito2002]

一般来说刚开始写的时候不要想太多， 脑子里想一个最典型的 case， 根据这个来写就行了； 什么特殊的 case 后面再考虑； 大不了改代码， 有个第一版的代码再改比一开始就想写一个面面俱到的版本要容易很多；

我最懒的时候，recursion 一律先不写 base case，while 循环的 header 一律先写 true ； 后面再改。

包括如果是大的结构设计也是一样， 一开始就 C 风格的先开始写， 写着写着感觉有些代码应该放在一起有些代码可以复用， 再提取出去到单独的类或者函数里面。

套用一个大神教给我的话： 硬着头皮先开始写。

写代码不要掺杂太多数学性的习惯（哎呀没有完备的理论基础写出来的代码怎么能行啊）

[Leigg]

现在习惯先把要做的事情分解成几个步骤，别分太细，写在真·笔记本上。就酱，用本子的感觉和写在记事本或者其他工具上是不一样的

[justinwu]

@sundev visio 或是 starUML，有时也在纸上画。

[southsala]

复杂的画图 不复杂的拿起键盘直接写不过会很累脑子

[sundev]

@vegito2002 谢谢你详尽的回答，你的这些方法对我的启发非常大。尤其是关于递归，我写递归经常被绕进去！