2008-12-02 34 views
1

当你开始思考一个编程项目时,你首先要做什么?你拿出一张纸并开始勾画出建筑物吗?你有想法的笔记本吗?你开始编码吗?或者你是在一个奇特的软件包中建模软件。来,澄清你的想法...当你开始思考一个编程项目时,你首先会做什么?

+0

看到这个问题:http://stackoverflow.com/questions/284578/design-or-prototype-first。 – 2008-12-02 23:30:49

回答

7

为了开始思考架构或设计,我倾向于写假设的代码片段,我想“只是工作”,以解决核心问题的应用。

例如,我的设计数据库时,我通常会尽量想一些例子查询我想到写,而不是抽象地考虑数据实体和关系。

这种方法可以帮助我(个人)避免第一遍抽象化太多。你可以称之为“美丽的代码优先”方法。它与TDD有着相似之处,除了您首先针对表达性,简洁的代码,然后构建体系结构和抽象以支持它。

这是我个人认为的表现,清晰的代码是从长远来看比笨重的,彻底的测试代码更可取。当然,这些并不是相互排斥的。只是不要让美丽的“架构”的愿望导致您的业务逻辑笨拙的客户端代码。

+0

+1:数据优先(通过查询) – 2008-12-03 00:10:40

+1

有人给出了这个名字......“Readme driven development”http://tom.preston-werner。com/2010/08/23/readme-driven-development.html – Larsenal 2012-01-27 21:33:00

5

我几乎总是从绘制一个粗略的对象模型开始,给我一个关于系统结构的视觉概念。然后从那里建立。

2

我坐下来开始编码......然后我删除了所有项目文件并转到白板,并开始映射对象和关系。

+0

这肯定是值得怀疑的方法,但我也这样做。弄清楚为什么会很有趣。 =))) – Din 2008-12-03 20:59:45

+0

哦...我永远不会推荐这种方法。 – EBGreen 2008-12-03 21:10:10

1

我写下的功能列表,然后进入它详细一点的,然后我开始我的对象的一些涂鸦,他们会如何相互交流,那种半arsed DFD ..我所有的图纸是一团糟!

6

我会谷歌它首先看到的东西存在以相同的方式/甚至更接近和了解更多关于它。利用当今可用的语言和框架的强大功能,任何普通程序员都可以编写代码,但质量将取决于您用来实现该解决方案的多少'最佳实践'。你实现结果的速度也很重要。

所以我觉得谷歌搜索将是在SDLC过程:)

1

一个重要周期我抢本子和笔,并开始素描笔记和流程图,没有什么特别的,只是可视化概念模型从那以后,我尝试在更简单和更简单的任务中打破每个部分。

一旦我无法进一步简化了任务,我开始写输伪代码和粗糙了数据库方案。只有这样我才能开始编码样本/测试代码。

2

我把我写的一切我都在想法的笔记本电脑。我一般写一两页关于项目/产品/等密集的笔记,然后息事宁人,因为我没有时间做任何事情。在实际设计事物的时候,我会重读我的笔记并尝试在UML中创建类图。通常这会失败,这会导致更多页面的笔记改进想法,解决奇怪的边缘案例和未定义的事情等。冲洗并重复。一旦我有一个可以记录所有主要参与者的类图,我就开始编写代码。

6

我想想用户和他们想要什么,他们会得到

他们不关心后端或花哨的语言,直到你已经计算出到底是什么程序会做,为什么会有人想使用它,没有别的真正重要的。

4

通过编程项目,我要承担起“为客户”,而不是一个嗜好/个人项目。

我通过让客户介绍给我,他们想要什么高级语言的第一次启动。我寻找诸如“我想要一个有多个部门并允许通过电子邮件进行回复/更新的票务系统”的东西。东西快速简单。

从那里开始规范文档的初稿。我开始询问客户的问题,以帮助完善原始草案并降低到更细化的水平,直到系统最终完全被指定出来。完全地,我的意思是客户无法给我更多关于他们想要的信息。

对于个人或爱好类的项目,我通常会花几天围绕滚动的东西在我的头,设计在纸上或在我的模拟程序的一些基本的数据库模式。我喜欢在几个晚上睡觉,看看它是否会继续有兴趣发展,而不是在它完成之前放弃。一旦我确定它是我会看到的,我会继续起草自己的规范并从那里开始。

1

尝试分析buisiness域。即应用程序试图解决的业务问题的结构。它需要操纵/管理哪些实体,它们是可变的/不可变的吗?应用程序需要实现哪些流程(从业务角度来看)?每个进程需要哪些实体,以及每个进程对该实体做了什么?等等。

2
  1. 收集requrements
  2. 定义优先级
  3. 估算努力
  4. 开始工作
  5. 跟踪和评估进展
0

我开始记录一个视觉,一描述项目的简短文档,围绕它的业务以及它的成功标准。

这有助于优先功能,并给出了同一个方向大家对项目的工作。

0

我总是解释什么,我认为它是我试图与该项目给别人,最好另一位开发人员来解决。除非我能够清楚地解释我想要做什么,否则我不会希望地狱有机会创造能够解决问题的东西。不得不将其描述给另一个人的行为经常会引发我对问题领域知识的空白,并暴露出我有未经证实的假设。 如果我有一个方便,这通常涉及到我如何在白板上看到问题。

相关问题