你会在 coding 之前先用足够多的文档理清思路么？

[Livid]

[aveline]

复杂度高的时候会，简单的就直接上手了。

[reorx]

一开始可能不需要，凭着一点灵思就做起来了，但往往在进行了一个阶段后发现效率降低，这时候就需要先写一些文档，整理下思路，再列好任务清单，一项一项来，免得不知不觉犯了并行多个任务的弊病。

[subpo]

至少用个todo，不然做不起来

[kedron]

用MindNode画脑图。

[Kai]

我会先列出自己拿不准的点，然后逐个考察。这样整理一遍，基本上心里就有数了，然后开始。

[Cofyc]

写之前整理好思路大多时候有点困难，一般是边写边整理。

[zhy0216]

我一般先画个ER图...

[vicalloy]

只会做个大致规划和方案，评估一下可行性。
把主要问题点的大致方案做出来，保证不会中途卡壳。
接下来基本上边做边整理。

[chloerei]

用纸画很多草稿。

[kaiix]

1.找难点 2.阅读资料和开源代码 3.写demo 4.列任务 5.具体实现
根据目标难度可从1开始 或者从4,5开始

P.S. @Livid 这里的文档具体指什么 是技术资料? 定义的阶段性目标? 还是其他?

[ytzong]

不会，一切凭感觉

[SuperOS]

规划还是要先写的，详细文档跟代码同步完善，最后再整理

[sivacohan]

如果是自己的项目，会在纸上写写画画。目的有两个：
1、明确自己要做什么。
2、冻结需求，保证自己不会因为对某个地方的忘我重构导致流产。（我很多东西都是这么流产的）

如果是需要几个人合作的项目，我必然会好好写这个。目的：
1、明确需求，解决的问题。这样才能给别人讲的时候条理清晰。
2、易于分工。
3、易于交流，当所有人对项目的认知统一的时候，交流的成本是最低的。
4、保证项目不会没事乱改。

[sivacohan]

哦，自己的项目如果中间有灵感了。会记在todo list上。以后再说。我不是靠谱的人，大多数灵感都不靠谱。

[yaotian]

我的经验是先写comments, 这些comment实际上就是思路。
然后再代码实现。

我会用这样的格式。
//== xxxxxx

//== xxxxxx

要看完整文档，就用grep == *

当然这是说代码中的格式。

其它的格式要符合各个项目的代码规范。

[hzlzh]

我会把整个流程想清楚，然后把细节注意的地方记载下来备用(Clear App)，也提前想好完成之后运维的条理东西，放到 Evernote 里，然后再开始搞。

[dreampuf]

尽可能的找相关资料，丢到一个地方。
比较甄选方案
自行开发
记录troubleshooting

导出文档，作为日后维护以及追溯

[dqaria]

先确定一下具体功能和实现难点，开发时用Cucumber与Rspec进行BDD开发~Cucumber本身就可以作为文档使用~

[alexrezit]

不会, 会用图. MindNode, 但更喜欢用纸.

[ShadowStar]

从来不写文档~~
在脑子里设计好了就动手