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

[sundev]

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

[sundev]

@Leigg 可实践性很高，打算试试，谢谢！

[starmoon1994]

你们都不写 todo 的吗。。。

[sundev]

@starmoon1994 我以前 TODO 更多的是用在某个模块或方法上，方法内部没用过。

[janus77]

先把最理想的情况 整个流程跑通，写完以后再从头开始处理分支情况。这时候可以一点一点啃，完全不慌

[sundev]

@janus77 嗯，赞同，感觉自己原来的那一套方法编码效率太低了。

打算实践这种方式！

[wqzjk393]

@sundev 流程图逻辑图推荐 visio，其实觉得拿笔画个简图更方便。

[ThirdFlame]

边界条件处理时 ，我是画个脑图，一个一个分支都确定出来。然后开始干。

[sundev]

@wqzjk393 @ThirdFlame 看来还是得借助图像化工具，谢谢了，打算试试脑图工具，不太复杂的手话貌似更方便。

[ThirdFlame]

@sundev #28 当然 16 楼的大神思路是非常值得学习的，先把功能实现了。 然后再处理边界和异常

[luoluoluo]

少摸鱼，专注点

[tmac33]

我开始之前一般都会写个单元测试

[weer0026]

个人经验是：复杂功能有思路就狂写，先实现流程再 debug，简单但是凌乱的功能要列个 todo list 一个一个慢慢清。

[whypool]

每个 task 先写流程，先写业务，遇到卡的地方打个 todo，即使弄个假数据也要把流程写通
然后把单元测试写了，再去搞卡壳的地方，假数据一换，测试一跑通就可以关 task

[metorm]

先搭框架，再处理琐碎的东西。如果你发现为了处理边角需要修改框架，那么说明你技术不过关或者框架设计错了。

[luanjia]

学习了

[nullen]

先写文档，思维导图，然后再开始编码。

[ibolee]

补充一点:戴个隔音耳塞而不是耳机。

[MinonHeart]

@vegito2002 哈哈，说的话。架构师做的事可能真好想法

[qymhy]

先理清产品 /功能逻辑，再将其落实为文档，最后基于文档开发。

[AckywOw]

边界问题有大有小，大的一开始就要想到设计好，小的最后修补一下就 OK