1
davepkxxx 2014-03-02 21:20:28 +08:00
看文档质量
|
2
alexrezit 2014-03-02 21:20:40 +08:00 1
太复杂的就 MindNode 画个图. 不过一般我都是直接选 2, 先从独立性较强的模块出发, 然后再组织到一起, 先做一个最小可用原型.
|
3
pirex 2014-03-02 21:37:33 +08:00
看情况,一般的是2
|
4
emric 2014-03-02 21:50:47 +08:00
觉得第一个很有必要.
最近遇到了很多推到从来的情况. |
5
ffts 2014-03-02 22:07:09 +08:00
我感觉我现在越来越多的时候开始用第一种了
|
6
onemoo 2014-03-02 22:12:58 +08:00
一般都是第一种
所以我很喜欢身边放着纸和笔 |
7
binux 2014-03-02 22:15:43 +08:00
从没用过第二种,确定第二种码出来的代码能执行?
|
8
wuyadong 2014-03-02 22:27:31 +08:00
第一种,基本不debug,打log就行吧。
|
9
arbipher 2014-03-02 22:31:40 +08:00
我一般是先写dummy function,返回定值,
确保这个文件能跑起来 然后在一个一个实现。 |
10
ios 2014-03-02 22:33:46 +08:00
我是业余程式员
第二种 |
11
artwalk OP 补充下,自己码自己想实现的代码时用的方式(产品设计,定好接口什么的不算进去)
|
16
hustlzp 2014-03-02 23:01:30 +08:00
随心,第一种第二种都会用。
|
17
arbipher 2014-03-02 23:34:29 +08:00
@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 |
18
leofml 2014-03-02 23:34:59 +08:00
先写注释, 再写代码.
|
19
arbipher 2014-03-02 23:36:15 +08:00
https://gist.github.com/arbipher/9308302
我要是再在回复框里写代码我就吃键盘。。。 |
20
zorceta 2014-03-02 23:38:14 +08:00
我是先1然后放弃转2……每每如此
|
21
RIcter 2014-03-02 23:52:48 +08:00 1
遇到比较乱的或者逻辑性比较强的都1
|
22
digfire 2014-03-02 23:56:06 +08:00
新手时期用1,后来工作压力大了开始变成2
|
26
otakustay 2014-03-03 00:42:33 +08:00
码得久了,就是边想边码基本没debug就出来了……
|
27
iEverX 2014-03-03 00:52:46 +08:00
没写过大项目,一般都是脑袋里想了一下怎么把架子搭起来,然后就开始动手写, 边写边整理思路。。写到一个函数的具体实现的时候,就是完全的DEBUG了
|
28
GeekGao 2014-03-03 01:00:20 +08:00
先构思,然后分出大概的模块,然后再码模块接口、写过程代码,最后拼装<->重构
|
29
cyberscorpio 2014-03-03 02:28:03 +08:00
一般都是混用的吧。
|
30
tywtyw2002 2014-03-03 03:59:57 +08:00 via iPhone
@arbipher 求视频验证。。。 吃hhkb吧
|
31
powerfj 2014-03-03 07:24:50 +08:00
想一下,然后一次性把骨架都写好,然后不断debug,让程序跑起来,跑起来之后再填充东西,感觉流程是有点混乱..
|
32
anjunecha 2014-03-03 08:10:40 +08:00
先是第二种,如果发觉有一些问题再循环到第一种
|
33
Matrix24 2014-03-03 08:27:14 +08:00
第2种,我是业余选手
|
34
artwalk OP @cyberscorpio 就是说更偏向哪一种;比如上来IDE就打开,码崩溃了实在不行了再草稿,还是草稿好了,脑子里运行通过了再码
|
35
artwalk OP @tywtyw2002 Σ(  ̄д ̄;) 你!! 太残忍了。同求视频
|
37
Mutoo 2014-03-03 08:59:50 +08:00 1
没有先写 user case 的吗
|
38
viator42 2014-03-03 09:08:20 +08:00
写一段运行一次,有问题就debug,正常运行的话写下一段,直到完成整个流程.这样可以保证写过的代码是没有问题的
|
39
lixm 2014-03-03 09:21:56 +08:00
一般整体是1,局部是2
|
40
ayang23 2014-03-03 09:22:12 +08:00
先把最核心的功能用bpython调试实现了,再把这几十行代码变成几百行代码的类或者函数,加上变量预处理,防错之类的东西,当然这个时候大框架已经出来了。
|
41
jianghu52 2014-03-03 09:27:22 +08:00
我以前也是二。现在有点变化。都是先写函数名,或者接口名,把整个程序的流程给固定下来。然后再单个函数单个函数的写。
|
42
yahon 2014-03-03 09:30:55 +08:00
我一般是这样的 比如我要写一个js的插件
1》大致的框架功能定义(实现这个插件大概要什么功能 尽量解耦) 2》具体实现(如果之前的定义有弊端,回头修改(1)) |
43
vob636 2014-03-03 09:35:24 +08:00
一般到一定地步的。基本上都是第二种了……
|
44
chisj 2014-03-03 09:35:58 +08:00
第二种比较有乐趣。
|
45
str0ng 2014-03-03 10:04:49 +08:00
看功能的复杂性,一般代码都是第二种,搭框架都是第一种
|
46
railgun 2014-03-03 11:02:40 +08:00
2
|
47
MikeAfc 2014-03-03 11:45:10 +08:00
身边留纸笔,必须走清流程,不然很容易返工
|
48
lsbwahaha 2014-03-03 11:50:24 +08:00
不管业务简单复杂,脑子里过一下,然后根据复杂程度画个流程图,一般用yed ,xmind
|
49
Crossin 2014-03-03 11:52:30 +08:00
个人喜欢用螺旋式,先大概纸上画个框架后,写出最简单的功能,然后不断往上添加功能,再不断修改设计。开发过程中想到什么新东西就记下来,再下个修改中加上去。
所以现在在公司写代码很不习惯,不喜欢一开始订好详细的计划,要做成什么样,花多少时间。 |
50
j 2014-03-03 12:03:13 +08:00
独立工作时,绝大部分时候是在基于现成的代码结构做调整,不存在从零开始。
纸笔大部分是由于非独立工作需要和别人去沟通需求,返工往往是理解错误造成。 |
51
Taivas 2014-03-03 12:16:16 +08:00
容易搞定的2,困难复杂的1
|
52
ahtsiu 2014-03-03 12:29:29 +08:00
1+2 吧,动手写代码的前几天,可能是编译都编不过去的。
纸笔很必要。 |
53
hu437 2014-03-03 13:39:21 +08:00
这个主要就是设计文档,参照设计文档;
1、使用axure设计出界面原型; 2、考虑好交互流程和相关的处理逻辑; 3、设计好数据库结构 4、开始码 |
55
Ricepig 2014-03-03 14:16:32 +08:00
我一般首先是用手码,偶尔才用脚。。。
其实,也看是什么代码,如果不能引起思考的,那就直接写写试试。如果有点儿兴趣,有点儿挑战的就苦苦思索一下。 |
56
mfaner 2014-03-03 14:36:44 +08:00
好像都差不多,大问题先分解成小问题,小问题不用怎么考虑挨着就往下写
|
57
akinoniku 2014-03-03 21:55:21 +08:00
先写测试再写代码吧
|
58
missdeer 2014-03-04 09:07:41 +08:00
流程比较复杂的1,其他的2
|
59
tonitech 2014-03-04 09:18:41 +08:00
看复杂程度,如果你要写个hello world还用1吗?
|
60
icylogic 2014-03-04 09:26:35 +08:00 via Android
分解问题到自己觉得一天能搞定的单元,然后每个单元用2。
|