With any project you need a clear goal, a point where you can say "I'm finished". A clear outcome will give you direction. Once you have that, you can start planning how to get there. The size and complexity of the project will determine how much detail your plan needs, but in general you'll want to feel your making progress against your plan quite regularly.
My next step is to sketch out a design of the modules that will be needed and the APIs between each module. If the APIs are clean then the modules are probably right. Then I start implementing the modules, testing as I go.
I spend a lot of time thinking about the various aspects of the project before I even touch a keyboard.
I go through what I've learnt from previous projects and write it down in various categories ('technical', 'promotion', etc)
Personal project or not, I always set up source code control. Git, Mercurial of Bazaar are examples of source code control tools that are not intrusive because you do not need to set up a master server. Just type a simple command to create the project, check your files in, commit. In the future, when you mess up one of your files, you will be able to 'undo'
I also set up a lightweight ticket system to keep track of 1.issues and 2.ideas By "lightweight" I mean that if maintaining two text documents with these lists works for you, that's good enough.
Planning a minimal implementation that does something useful as a first complete release.
Have concrete goals about what you want to achieve to have something to compare your progress with.
I would also recommend beginning with a lightweight design of you overall architecture so you can have a roadmap of how to build your product.
I find it difficult to start building something when I don't have a clear idea about how it should look at least at a first level of decomposition. Think about what do you need besides functionality: high performance?, extensibility scenarios?, which ones?, usability goals?, high scalability?, ease of deployment and installability?, etc. Ask yourself: What components I will have to build in order to achieve those architectural qualities?.
And don't get me wrong, I'm a strong proponent of agile software development. You don't need to spend a lot of times designing your architecture (because it surely will have to evolve as you build and get feedback about what works and what doesn't), but having a blueprint of how to build your product based on its architecture should be useful in for planning your progress and setting realistic goals.
Define the goal for the project. Sounds like you are looking almost exclusively at the solution rather than the problem.
A program isn't useful to you or anyone else unless it addresses some problem. Writing code to get moving is great, but you appear to lose interest and focus after you start -- because you're looking at the code, not the problem.
Spend some time considering what led you to write this code. Ponder how other people might discover the same need, what path might take them to the same frustration you worked to solve.
Then, find some of those people and offer your (partial) solution, and you'll generate interest and suggestions among them all.
THAT will keep you going on your project. The fellow interest, the sharing, even the disagreements -- it's people who need software! Don't create solutions (software) looking for a problem (people). You started with YOU, with your need or desire, but focused on the code, and lost the impetus for the project.
Programming's a lot more fun when you're problem-solving. But you need to keep the problem in front of you. Sharing the problem builds community. That's what this is really all about, isn't it?
For my own personal projects I just dive right in. Of course, none of these have yet been sufficiently large as to require any sort of pre-planning. If this is going to be a serious project or a relatively large scale, it is always a good idea to flush out at least what each part of the program needs to do and a high level view of how they will do it.
Like the others, my personal projects always have:
A Final Goal
A Task List
Small usable units
Source control
As an additional motivator, I try to use a technology that I have never used before. Learning something new generally becomes the largest motivator for me.
Easy - don't start at all projects you're likely to lose interest in. Spend more time to make sure you want to commit yourself to an idea before beginning any work.
If I'm writing the next Notepad clone I might just dive in, if I wanted to roll my own operating system it'd take a lot more non-coding work.
I like to do a lot of diagrams, the tool I use for most development is clean A4 paper and a pencil. Draw out the UI, workflow, basic classes, and how you're going to store any data - then the coding is just a computer readable way of writing what you drew already.
Source control le.g. SVN is a couple of keystrokes/clicks, so the overhead is low and the benefit is high, its handy to try stuff and just revert to an earlier state if they don't work.
Then just make the most basic protoype that will work - once something is actually going it is much easier to get enthused and add more. If it is overwhelming I'll find I think the problem is solved in my head, and thats enough.
First plan out the basic outline of the final application. Most important features, basic GUI, program flow, etc. Then refine that so that you don't take on too much at first, remove unnecessary features, and add what else you want in the first version. Then use that outline to start a task list to create the smallest possible working version of your application. Then it's much easier to add extra features and make it fully functioning.
I like Maximillian's answer.. to expand a little, my person projects are developed to solve something I'm working on already. So when I get tired of repeat work I'll prototype a solution. and then use it. If Its similar enough to one of my earlier projects I'll borrow as much code as I can and try to improve the level of my work, make it more professional.
Fusion's use of Source Control is important too. Takes 2 minutes to install SVN.
If you want to turn it into a public open source project, Producing Open Source Software is supposed to be a good read (available both online and in print).
If your personal project is similar to an existing open source project, you should consider contributing to that project instead. A couple of small contributions (bug fixes etc.) are more valuable than a half finished project.
发布评论
评论（14）
唯一对我有用的事情：创建尽可能最小的可用的实现，然后使用它。
The only thing that works for me: Create the smallest possible implementation of it that's somehow usable and then use it.
来自高效人士的 7 个习惯，习惯 2：以终为始。
对于任何项目，你都需要一个明确的目标，一个你可以说“我完成了”的目标。 明确的结果将为您指明方向。 一旦你有了这些，你就可以开始计划如何到达那里。 项目的规模和复杂性将决定您的计划需要多少细节，但总的来说，您会希望定期感受到您的计划取得的进展。
我的下一步是勾勒出所需模块的设计以及每个模块之间的 API。 如果 API 是干净的，那么模块可能是正确的。 然后我开始实施模块，并进行测试。
From 7 Habits of Highly Effective People, Habit 2: Begin with the End In Mind.
With any project you need a clear goal, a point where you can say "I'm finished". A clear outcome will give you direction. Once you have that, you can start planning how to get there. The size and complexity of the project will determine how much detail your plan needs, but in general you'll want to feel your making progress against your plan quite regularly.
My next step is to sketch out a design of the modules that will be needed and the APIs between each module. If the APIs are clean then the modules are probably right. Then I start implementing the modules, testing as I go.
在我接触键盘之前，我花了很多时间思考项目的各个方面。
我浏览从以前的项目中学到的东西，并将其写在不同的类别（“技术”、“促销”等）中。
无论是否是个人项目，我总是设置源代码控制。 Git、Bazaar 的 Mercurial 都是非侵入性的源代码控制工具，因为您不需要设置主服务器。 只需键入一个简单的命令即可创建项目，签入文件，然后提交。 将来，当你弄乱一个文件时，你将能够“撤消”
我还设置了一个轻量级票证系统来跟踪 1.issues 和 2.ideas
我所说的“轻量级”的意思是，如果使用这些列表维护两个文本文档对您有用，那就足够了。
希望这可以帮助。
I spend a lot of time thinking about the various aspects of the project before I even touch a keyboard.
I go through what I've learnt from previous projects and write it down in various categories ('technical', 'promotion', etc)
Personal project or not, I always set up source code control. Git, Mercurial of Bazaar are examples of source code control tools that are not intrusive because you do not need to set up a master server. Just type a simple command to create the project, check your files in, commit. In the future, when you mess up one of your files, you will be able to 'undo'
I also set up a lightweight ticket system to keep track of 1.issues and 2.ideas
By "lightweight" I mean that if maintaining two text documents with these lists works for you, that's good enough.
Hope this helps.
我同意已经给出的建议：
我还建议您从整体架构的轻量级设计开始，这样您就可以制定如何构建产品的路线图。
当我不清楚它至少在第一级分解时应该是什么样子时，我发现很难开始构建一些东西。 想想除了功能之外您还需要什么：高性能？、可扩展性场景？、哪些？、可用性目标？、高可扩展性？、易于部署和安装？等等。问问自己：我必须按顺序构建哪些组件实现那些建筑品质？
不要误会我的意思，我是敏捷软件开发的坚定支持者。 您不需要花费大量时间来设计您的架构（因为它肯定会随着您的构建而不断发展，并获得有关哪些有效、哪些无效的反馈），但是拥有一个如何构建您的架构的蓝图基于其架构的产品应该有助于规划您的进度和设定现实的目标。
I agree with the already given advice of:
I would also recommend beginning with a lightweight design of you overall architecture so you can have a roadmap of how to build your product.
I find it difficult to start building something when I don't have a clear idea about how it should look at least at a first level of decomposition. Think about what do you need besides functionality: high performance?, extensibility scenarios?, which ones?, usability goals?, high scalability?, ease of deployment and installability?, etc. Ask yourself: What components I will have to build in order to achieve those architectural qualities?.
And don't get me wrong, I'm a strong proponent of agile software development. You don't need to spend a lot of times designing your architecture (because it surely will have to evolve as you build and get feedback about what works and what doesn't), but having a blueprint of how to build your product based on its architecture should be useful in for planning your progress and setting realistic goals.
定义项目的目标。 听起来您几乎只关注解决方案而不是问题。
除非解决某个问题，否则程序对您或其他任何人都没有用。 编写代码来开始行动固然很棒，但是在开始之后您似乎会失去兴趣和注意力——因为您正在查看代码，而不是问题。
花一些时间考虑一下是什么促使您编写这段代码。 思考其他人如何发现同样的需求，什么途径可能会让他们遇到你努力解决的同样的挫败感。
然后，找到其中一些人并提供您的（部分）解决方案，您将在他们中产生兴趣和建议。
这会让你继续你的项目。 同伴的兴趣、分享、甚至分歧——正是人们需要软件！ 不要为了寻找问题（人）而创建解决方案（软件）。 你从你自己开始，带着你的需要或愿望，但专注于代码，失去了项目的动力。
当你解决问题时，编程会变得更有趣。 但你需要把问题摆在你面前。 分享问题可以建立社区。 这才是真正的意义所在，不是吗？
Define the goal for the project. Sounds like you are looking almost exclusively at the solution rather than the problem.
A program isn't useful to you or anyone else unless it addresses some problem. Writing code to get moving is great, but you appear to lose interest and focus after you start -- because you're looking at the code, not the problem.
Spend some time considering what led you to write this code. Ponder how other people might discover the same need, what path might take them to the same frustration you worked to solve.
Then, find some of those people and offer your (partial) solution, and you'll generate interest and suggestions among them all.
THAT will keep you going on your project. The fellow interest, the sharing, even the disagreements -- it's people who need software! Don't create solutions (software) looking for a problem (people). You started with YOU, with your need or desire, but focused on the code, and lost the impetus for the project.
Programming's a lot more fun when you're problem-solving. But you need to keep the problem in front of you. Sharing the problem builds community. That's what this is really all about, isn't it?
对于我自己的个人项目，我只是直接投入。当然，这些项目都还没有大到需要任何形式的预先规划。 如果这将是一个严肃的项目或规模相对较大，那么至少弄清楚该计划的每个部分需要做什么以及他们将如何做的高层次视图总是一个好主意。
For my own personal projects I just dive right in. Of course, none of these have yet been sufficiently large as to require any sort of pre-planning. If this is going to be a serious project or a relatively large scale, it is always a good idea to flush out at least what each part of the program needs to do and a high level view of how they will do it.
和其他人一样，我的个人项目总是有：
作为额外的动力，我尝试使用以前从未使用过的技术。 学习新东西通常成为我最大的动力。
Like the others, my personal projects always have:
As an additional motivator, I try to use a technology that I have never used before. Learning something new generally becomes the largest motivator for me.
很简单——不要开始所有你可能会失去兴趣的项目。在开始任何工作之前，花更多的时间来确保你想要致力于某个想法。
Easy - don't start at all projects you're likely to lose interest in. Spend more time to make sure you want to commit yourself to an idea before beginning any work.
这取决于项目——有多大？
如果我正在编写下一个记事本克隆，我可能会直接投入其中，如果我想推出自己的操作系统，则需要更多的非编码工作。
我喜欢做很多图表，我用于大多数开发的工具是干净的 A4 纸和铅笔。 绘制出 UI、工作流程、基本类以及如何存储任何数据 - 然后编码只是一种计算机可读的方式来编写您已经绘制的内容。
源代码控制分支 SVN 只需几次击键/点击，因此开销很低，效益很高，可以方便地尝试一些东西，如果不起作用，就恢复到之前的状态。
然后，只需制作最基本的可用原型即可 - 一旦某件事真正发生，就更容易感到兴奋并添加更多内容。 如果它是压倒性的，我会发现我认为问题已经在我的脑海中解决了，这就足够了。
It depends on the project - how big is it?
If I'm writing the next Notepad clone I might just dive in, if I wanted to roll my own operating system it'd take a lot more non-coding work.
I like to do a lot of diagrams, the tool I use for most development is clean A4 paper and a pencil. Draw out the UI, workflow, basic classes, and how you're going to store any data - then the coding is just a computer readable way of writing what you drew already.
Source control le.g. SVN is a couple of keystrokes/clicks, so the overhead is low and the benefit is high, its handy to try stuff and just revert to an earlier state if they don't work.
Then just make the most basic protoype that will work - once something is actually going it is much easier to get enthused and add more. If it is overwhelming I'll find I think the problem is solved in my head, and thats enough.
首先规划出最终应用的基本轮廓。 最重要的功能、基本 GUI、程序流程等。然后对其进行改进，以便您一开始就不会承担太多内容，删除不必要的功能，并在第一个版本中添加您想要的其他功能。 然后使用该大纲启动任务列表，以创建应用程序的最小可能工作版本。 然后添加额外的功能并使其充分发挥作用就容易多了。
First plan out the basic outline of the final application. Most important features, basic GUI, program flow, etc. Then refine that so that you don't take on too much at first, remove unnecessary features, and add what else you want in the first version. Then use that outline to start a task list to create the smallest possible working version of your application. Then it's much easier to add extra features and make it fully functioning.
我喜欢马克西米利安的回答……稍微扩展一下，我的个人项目是为了解决我已经在做的事情而开发的。 因此，当我厌倦了重复工作时，我会制作一个解决方案的原型。 然后使用它。 如果它与我早期的项目之一足够相似，我会尽可能多地借用代码，并尝试提高我的工作水平，使其更加专业。
Fusion 对源代码控制的使用也很重要。 安装 SVN 需要 2 分钟。
I like Maximillian's answer.. to expand a little, my person projects are developed to solve something I'm working on already. So when I get tired of repeat work I'll prototype a solution. and then use it. If Its similar enough to one of my earlier projects I'll borrow as much code as I can and try to improve the level of my work, make it more professional.
Fusion's use of Source Control is important too. Takes 2 minutes to install SVN.
如果你想把它变成一个公共开源项目，生产开源软件应该是一本不错的读物（在线和印刷版均可提供）。
If you want to turn it into a public open source project, Producing Open Source Software is supposed to be a good read (available both online and in print).
如果您的个人项目与现有的开源项目类似，您应该考虑为该项目做出贡献。 一些小的贡献（错误修复等）是
比完成一半的项目更有价值。
If your personal project is similar to an existing open source project, you should consider contributing to that project instead. A couple of small contributions (bug fixes etc.) are
more valuable than a half finished project.
上述所有内容，但开始巩固计划......
去寻找一些工具
SmartSheet - 即使您自己工作，您也应该列出一些阶段和日期
yEd - 和来自 www.yworks.com 的 Graphity
All of the above, but start to cement the plan in place.....
Go for some tools
SmartSheet - even if you are working on your own you should set out some stages and dates
yEd - and Graphity from www.yworks.com