大家平时怎么码代码的？

看文档质量

太复杂的就 MindNode 画个图. 不过一般我都是直接选 2, 先从独立性较强的模块出发, 然后再组织到一起, 先做一个最小可用原型.

看情况，一般的是2

觉得第一个很有必要.
最近遇到了很多推到从来的情况.

我感觉我现在越来越多的时候开始用第一种了

一般都是第一种
所以我很喜欢身边放着纸和笔

从没用过第二种，确定第二种码出来的代码能执行？

第一种，基本不debug，打log就行吧。

我一般是先写dummy function，返回定值，
确保这个文件能跑起来
然后在一个一个实现。

我是业余程式员
第二种

补充下，自己码自己想实现的代码时用的方式（产品设计，定好接口什么的不算进去）

@binux 可以的，神奇吧。还有最初我发现面试用白板的时候，一度怀疑自己无法写出代码呢

@arbipher 嗯，我说的“一点”大致也是一个函数，一小段流程。并不是一个变量，一行就算“一点”了

@onemoo 最初我都无法想象这种编码方式呢

@ios 这个好像只是喜好不同，不是用业余专业区分的

随心，第一种第二种都会用。

@artwalk 那和我的也不一样啊。我每次run的时候，程序和功能看上去是“全”的
# step one - dummy #
def init():
pass


def handle():
pass


def clean_up():
pass


def main():
init();
handle();
clean_up();


# step two - implement init #
def parseConfigFile(file):
return STATIC_CONFIG


def is_config_valid(config)
return True


def init():
cOnfig= load_config(CONFIG_FILE_NAME)
if (!is_config_valid(config)): raise IOError

先写注释, 再写代码.

https://gist.github.com/arbipher/9308302
我要是再在回复框里写代码我就吃键盘。。。

我是先1然后放弃转2……每每如此

遇到比较乱的或者逻辑性比较强的都1

新手时期用1，后来工作压力大了开始变成2

@digfire 还可以这样？

@RIcter 想不清楚的时候有时确实需要稿纸

@artwalk
因为要快速出原型，要快到连思考的时间都没有。
想想真是不合理

码得久了，就是边想边码基本没debug就出来了……

没写过大项目，一般都是脑袋里想了一下怎么把架子搭起来，然后就开始动手写， 边写边整理思路。。写到一个函数的具体实现的时候，就是完全的DEBUG了

先构思，然后分出大概的模块，然后再码模块接口、写过程代码，最后拼装<->重构

一般都是混用的吧。

@arbipher 求视频验证。。。 吃hhkb吧

想一下，然后一次性把骨架都写好，然后不断debug，让程序跑起来，跑起来之后再填充东西，感觉流程是有点混乱..

先是第二种，如果发觉有一些问题再循环到第一种

第2种，我是业余选手

@cyberscorpio 就是说更偏向哪一种；比如上来IDE就打开，码崩溃了实在不行了再草稿，还是草稿好了，脑子里运行通过了再码

@tywtyw2002 Σ( ￣д￣；) 你！！ 太残忍了。同求视频

@digfire 大环境所迫啊

没有先写 user case 的吗

写一段运行一次,有问题就debug,正常运行的话写下一段,直到完成整个流程.这样可以保证写过的代码是没有问题的

一般整体是1，局部是2

先把最核心的功能用bpython调试实现了，再把这几十行代码变成几百行代码的类或者函数，加上变量预处理，防错之类的东西，当然这个时候大框架已经出来了。

我以前也是二。现在有点变化。都是先写函数名，或者接口名，把整个程序的流程给固定下来。然后再单个函数单个函数的写。

我一般是这样的 比如我要写一个js的插件
1》大致的框架功能定义（实现这个插件大概要什么功能 尽量解耦）
2》具体实现（如果之前的定义有弊端，回头修改（1））

一般到一定地步的。基本上都是第二种了……

第二种比较有乐趣。

看功能的复杂性，一般代码都是第二种，搭框架都是第一种

2

身边留纸笔，必须走清流程，不然很容易返工

不管业务简单复杂，脑子里过一下，然后根据复杂程度画个流程图，一般用yed ，xmind

个人喜欢用螺旋式，先大概纸上画个框架后，写出最简单的功能，然后不断往上添加功能，再不断修改设计。开发过程中想到什么新东西就记下来，再下个修改中加上去。

所以现在在公司写代码很不习惯，不喜欢一开始订好详细的计划，要做成什么样，花多少时间。

独立工作时，绝大部分时候是在基于现成的代码结构做调整，不存在从零开始。

纸笔大部分是由于非独立工作需要和别人去沟通需求，返工往往是理解错误造成。

容易搞定的2，困难复杂的1

1+2 吧，动手写代码的前几天，可能是编译都编不过去的。

纸笔很必要。

这个主要就是设计文档，参照设计文档；
1、使用axure设计出界面原型；
2、考虑好交互流程和相关的处理逻辑；
3、设计好数据库结构
4、开始码

@MikeAfc 返工，这么惨的？

我一般首先是用手码，偶尔才用脚。。。

其实，也看是什么代码，如果不能引起思考的，那就直接写写试试。如果有点儿兴趣，有点儿挑战的就苦苦思索一下。

好像都差不多，大问题先分解成小问题，小问题不用怎么考虑挨着就往下写

先写测试再写代码吧

流程比较复杂的1，其他的2

看复杂程度，如果你要写个hello world还用1吗？

分解问题到自己觉得一天能搞定的单元，然后每个单元用2。