启动项目的最佳方法
当我们开始一个个人编程项目时,第一步是什么?我正在尝试启动一个项目,目前仅是一个主意。我得到了很多,而我直接进入了代码,过了一会儿就完全失去了兴趣,或者只是忘记了这个项目。
当我们开始时,第一步是什么?你计划这个项目吗?做一个图?在纸上写一些代码?我们如何以成功的方式开始项目?
解决方案
回答
对于我自己的个人项目,我只是直接参与其中。当然,这些项目都还不够庞大,不需要任何形式的预先计划。如果这将是一个严肃的项目或者相对较大的规模,那么至少清除该程序每个部分需要执行的操作以及对其执行方式的高级了解始终是一个好主意。
回答
在触摸键盘之前,我花了很多时间思考项目的各个方面。
我回顾了我从以前的项目中学到的知识,并将其写下来,分为不同的类别("技术","促销"等)
不论是否个人项目,我总是设置源代码控制。 Git,Bazaar的Mercurial是源代码控制工具的示例,这些工具不是侵入性的,因为我们不需要设置主服务器。只需键入一个简单的命令即可创建项目,检入文件,然后提交。将来,当我们弄乱其中一个文件时,便可以"撤消"
我还建立了一个轻量级的票务系统来跟踪1.issues和2.ideas
"轻量级"是指,如果使用这些列表维护两个文本文档对我们有用,那就足够了。
希望这可以帮助。
回答
唯一对我有用的方法:创建以某种方式可用的最小可能实现,然后使用它。
回答
首先计划最终应用程序的基本轮廓。最重要的功能,即基本的GUI,程序流程等。然后对其进行优化,以使我们起初不会承担太多的工作,删除不必要的功能,并在第一个版本中添加我们想要的其他功能。然后使用该大纲启动任务列表,以创建应用程序的最小可行版本。然后,添加额外的功能并使之充分发挥作用要容易得多。
回答
从7个高效人员的习惯中,习惯2:从头脑中的结尾开始。
对于任何项目,我们都需要一个明确的目标,在这一点上我们可以说"我完成了"。明确的结果将为我们指明方向。一旦有了这些,就可以开始计划如何到达那里。项目的规模和复杂程度将决定计划需要多少细节,但总的来说,我们将希望定期感觉自己在计划方面取得的进展。
我的下一步是设计所需模块的设计以及每个模块之间的API。如果API干净,则模块可能正确。然后,我开始实施模块,并进行测试。
回答
取决于项目的大小是多少?
如果要编写下一个记事本克隆,我可能会涉足其中,如果要推出自己的操作系统,它将需要进行更多非编码工作。
我喜欢做很多图,我用于大多数开发的工具是干净的A4纸和一支铅笔。绘制出UI,工作流,基本类以及如何存储任何数据,然后编码只是一种计算机可读的方式来编写已经绘制的内容。
源代码控制,例如SVN是几次击键/单击,因此开销很低,收益很高,它很容易尝试,如果不起作用,只需恢复到较早的状态即可。
然后,只要制作出最基本的原型即可,一旦实际可行,该原型便会奏效,更容易引起人们的热情并添加更多。如果压倒性的话,我会发现我认为这个问题已经解决了,那就足够了。
回答
我喜欢马克西米利安(Maximillian)的答案..扩大一点,我的人项目开发出来是为了解决我已经在做的事情。因此,当我厌倦了重复工作时,我将为解决方案提供原型。然后使用它。如果它与我以前的项目之一足够相似,那么我将尽可能借用代码并尝试提高工作水平,使其更加专业。
Fusion对Source Control的使用也很重要。安装SVN需要2分钟。
回答
与其他项目一样,我的个人项目始终具有:
- 最终目标
- 任务清单
- 可用小单位
- 源代码控制
作为另一个激励因素,我尝试使用以前从未使用过的技术。学习新事物通常成为我最大的动力。
回答
如果我们想将其变成一个公共的开源项目,则应该最好阅读《生产开源软件》(在线和印刷版均可)。
回答
不要轻易从我们可能会失去兴趣的所有项目开始。花更多的时间来确保我们想在开始任何工作之前致力于一个想法。
回答
我同意以下意见:
- 规划一个最小的实现,该实现在首次发布时会做一些有用的事情。
- 为要达到的目标设定具体目标,以便与进度进行比较。
我还建议我们从总体架构的轻量级设计开始,这样我们就可以获得如何构建产品的路线图。
当我对至少在分解的第一阶段应该如何看不清楚时,我很难开始构建某些东西。考虑一下除功能之外我们还需要什么:高性能?,可扩展性方案?,哪些?可用性目标?,高可扩展性?,易于部署和可安装性?等。问问自己:我将必须构建哪些组件达到那些建筑品质?
别误会,我是敏捷软件开发的坚定支持者。我们不需要花费很多时间来设计体系结构(因为它肯定会在构建时不断发展,并获得有关哪些有效和哪些无效的反馈),但是具有如何根据以下内容构建产品的蓝图它的体系结构对于计划进度和设定切合实际的目标应该很有用。
回答
如果个人项目与现有的开源项目相似,则应考虑为该项目做出贡献。一些小贡献(错误修复等)是
比完成一半的项目更有价值。
回答
定义项目目标。听起来我们几乎只在关注解决方案,而不是问题。
程序不能解决问题,对我们或者其他任何人都没有用。编写代码以使自己动起来很棒,但是开始后我们似乎失去了兴趣和注意力-因为我们正在查看代码,而不是问题。
花一些时间考虑导致我们编写此代码的原因。思考其他人如何发现相同的需求,什么途径可能使他们陷入与我们同样的沮丧中。
然后,找到其中的一些人并提供(部分)解决方案,我们将在所有这些人中产生兴趣和建议。
那将使我们继续进行项目。同伴的兴趣,共享甚至分歧-是需要软件的人!不要创建寻找问题(人员)的解决方案(软件)。我们从自己的需要或者愿望开始,但专注于代码,却失去了该项目的动力。
解决问题时,编程会变得更加有趣。但是我们需要将问题摆在面前。共享问题可以建立社区。这才是真正的全部,不是吗?