This topic created in 5016 days ago, the information mentioned may be changed or developed.
 |
avelineFeb 17, 2013
1
复杂度高的时候会，简单的就直接上手了。
|
 |
reorxFeb 17, 2013
2
一开始可能不需要，凭着一点灵思就做起来了，但往往在进行了一个阶段后发现效率降低，这时候就需要先写一些文档，整理下思路，再列好任务清单，一项一项来，免得不知不觉犯了并行多个任务的弊病。
|
 |
subpoFeb 17, 2013
3
至少用个todo，不然做不起来
|
 |
kedronFeb 17, 2013
4
用MindNode画脑图。
|
 |
KaiFeb 17, 2013
5
我会先列出自己拿不准的点，然后逐个考察。这样整理一遍，基本上心里就有数了，然后开始。
|
 |
CofycFeb 17, 2013
6
写之前整理好思路大多时候有点困难，一般是边写边整理。
|
 |
zhy0216Feb 17, 2013
7
我一般先画个ER图...
|
 |
vicalloyFeb 17, 2013
8
只会做个大致规划和方案，评估一下可行性。
把主要问题点的大致方案做出来，保证不会中途卡壳。 接下来基本上边做边整理。 |
 |
chloereiFeb 17, 2013
9
用纸画很多草稿。
|
 |
kaiixFeb 17, 2013
10
1.找难点 2.阅读资料和开源代码 3.写demo 4.列任务 5.具体实现
根据目标难度可从1开始 或者从4,5开始 P.S. @Livid 这里的文档具体指什么 是技术资料? 定义的阶段性目标? 还是其他? |
 |
ytzongFeb 17, 2013
11
不会，一切凭感觉
|
 |
SuperOSFeb 17, 2013
12
规划还是要先写的，详细文档跟代码同步完善，最后再整理
|
 |
sivacohanFeb 17, 2013
13
如果是自己的项目，会在纸上写写画画。目的有两个：
1、明确自己要做什么。 2、冻结需求，保证自己不会因为对某个地方的忘我重构导致流产。（我很多东西都是这么流产的） 如果是需要几个人合作的项目，我必然会好好写这个。目的： 1、明确需求，解决的问题。这样才能给别人讲的时候条理清晰。 2、易于分工。 3、易于交流，当所有人对项目的认知统一的时候，交流的成本是最低的。 4、保证项目不会没事乱改。 |
|
sivacohanFeb 17, 2013
14
哦，自己的项目如果中间有灵感了。会记在todo list上。以后再说。我不是靠谱的人，大多数灵感都不靠谱。
|
 |
yaotianFeb 17, 2013
15
我的经验是先写comments, 这些comment实际上就是思路。
然后再代码实现。 我会用这样的格式。 //== xxxxxx //== xxxxxx 要看完整文档，就用grep == * 当然这是说代码中的格式。 其它的格式要符合各个项目的代码规范。 |
 |
hzlzhFeb 17, 2013
16
我会把整个流程想清楚，然后把细节注意的地方记载下来备用(Clear App)，也提前想好完成之后运维的条理东西，放到 Evernote 里，然后再开始搞。
|
 |
dreampufFeb 18, 2013
17
尽可能的找相关资料，丢到一个地方。
比较甄选方案 自行开发 记录troubleshooting 导出文档，作为日后维护以及追溯 |
 |
dqariaFeb 18, 2013
18
先确定一下具体功能和实现难点，开发时用Cucumber与Rspec进行BDD开发~Cucumber本身就可以作为文档使用~
|
 |
alexrezitFeb 18, 2013 via iPhone
19
不会, 会用图. MindNode, 但更喜欢用纸.
|
 |
ShadowStarFeb 18, 2013
20
从来不写文档~~
在脑子里设计好了就动手 |
 |
Narcissu5Feb 18, 2013
21
TDD测试驱动，先写测试代码是理清思路的最好方法，也能有效的提高代码质量，就是比较费时间。
|
 |
masterFeb 18, 2013
22
一般会随手抓写纸画一些图，做一些备忘吧
|
 |
hpyhackingFeb 18, 2013
23
A4白纸少许 铅笔一只
|
 |
soolbyFeb 18, 2013
24
文档不是PM都准备了吗~
|
Select Language