大家平时怎么码代码的？

[artwalk]

大致说来，有两种方式

1. 脑子里演算，甚至纸上草稿，整个流程搞定了，再码
2. 想一点码一点，不断DEBUG，直到搞定

我自己是第二种模式

[davepkxxx]

看文档质量

[alexrezit]

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

[pirex]

看情况，一般的是2

[emric]

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

[ffts]

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

[onemoo]

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

[binux]

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

[wuyadong]

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

[arbipher]

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

[ios]

我是业余程式员
第二种

[artwalk]

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

[artwalk]

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

[artwalk]

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

[artwalk]

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

[artwalk]

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

[hustlzp]

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

[arbipher]

@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

[leofml]

先写注释, 再写代码.

[arbipher]

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

[zorceta]

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

[RIcter]

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

[digfire]

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

[artwalk]

@digfire 还可以这样？

[artwalk]

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

[digfire]

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

[otakustay]

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

[iEverX]

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

[GeekGao]

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

[cyberscorpio]

一般都是混用的吧。

[tywtyw2002]

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

[powerfj]

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

[anjunecha]

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

[Matrix24]

第2种，我是业余选手

[artwalk]

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

[artwalk]

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

[artwalk]

@digfire 大环境所迫啊

[Mutoo]

没有先写 user case 的吗

[viator42]

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

[lixm]

一般整体是1，局部是2

[ayang23]

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

[jianghu52]

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

[yahon]

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

[vob636]

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

[chisj]

第二种比较有乐趣。

[str0ng]

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

[railgun]

2

[MikeAfc]

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

[lsbwahaha]

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

[Crossin]

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

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

[j]

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

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

[Taivas]

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

[ahtsiu]

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

纸笔很必要。

[hu437]

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

[artwalk]

@MikeAfc 返工，这么惨的？

[Ricepig]

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

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

[mfaner]

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

[akinoniku]

先写测试再写代码吧

[missdeer]

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

[tonitech]

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

[icylogic]

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