对于“个人”项目而言你想的太多了，只要抓住两点就可以
1、这个项目必须能解决一个你遇到的实际问题，这个问题不能是杜撰的。
2、你必须用这个项目来解决的你遇到的这个问题，不能用其它方案。

一言以蔽之就是自己给自己挠痒痒。

既然是个人项目，我想这个解决方案就带有很强的个人色彩了，跟一个人的思维习惯有很大的关系。我把个人项目分成两个过程：思考+实干，我把设计也算在思考过程里了，因为设计实际上就是总结你的思考结果

做事前先全面思考是一个好习惯

我在做一个项目之初会处于一种个人的头脑风暴状态，因为我希望每做完一个项目都是有所突破的，所以不论在结构上还是思想上，我会经历一个长时间的构思过程。

在这个阶段中，我会个人尝试完成一些小的demo，然后做无数次推演，并且权衡一些新的技术是否用得上。这个过程我个人认为是个人项目的最大魅力所在，整个决策过程没有干扰，你可以选择就一个点做很深的思考，也可以一次做很多方案权衡。但是我建议初学者在这个过程中给自己设置一个节点，因为自控力差，初学者可能会陷入无休止的推倒和重建过程中，进入自我的死循环，处女座尤其需要注意:)

至于跟其他人的交流，你可以自我控制，谁叫这是个人项目呢。我记得大学的时候看过一本讲费马定理证明过程的书，当数学家安德鲁·怀尔斯感觉没有思路的时候，他会到一些数学会议上与其它人交流一些具体问题的碎片。这种方式避免了每次交流你都需要把你做的事情全部交代一遍的痛苦，可以快速切入问题，而且可以让你做的事情保持私密性，不会被其他人的想法打断。

思考很重要，但思考不能解决所有问题

一个高手写代码，一边写一边就可以把各种情况考虑到，这是因为他遇到的多了。初学者就算想一个月，可能写出来的东西还是有bug，因为一些情况你从来没有遇到过，也就不会考虑进去。

所以你要知道，想很重要，但也没有上升到最高的地步，只做不想那是蛮干，只想不做那就是空想，工程师不是幻想家。好的开发者，哪一个不是腥风血雨的bug堆出来的。

所以不要怕你想不到，等你做出来，再看看结果，你就想到了。

我来分享一下我的方法。

总的来说我会把一个项目的设计分成以下几步，其中思维导图这一步并非必须，项目不大的时候在头脑中进行就行。

1. 写交互设计文档
2. 制作思维导图
3. 设计核心框架
4. 开始迭代开发、实现

项目刚开始设计时，我会用一种类似于交互式设计的思路来开始，第一件要做的事情不是代码设计本身，而是写这个项目的使用方法。

比如要写一个框架或工具，我会从怎么使用这个项目开始，用某个 markdown 编辑器以面向最终用户的语言描述项目的基本概念和用法。就好像到处能看到的项目 tutorial 页面一样，我会写出一个完整的 tutorial，并反复阅读它，用一个用户的角度来审视这个项目，看看这个 tutorial 是否能够让我自己明白该如何使用它，以及它是不是足够 sexy 让我有冲动去使用它。如果我自己觉得这个 tutorial 足够好了，我就可以真正开始设计细节了。

比如 这个项目 就是我正在设计中的东西，写的这个 tutorial 就是我最开始的设计文档，其实代码（因为种种原因）还没开始写。

在核心交互式设计完成之后，我就会开始用思维导图进行发散。关于如何发散这个可能没什么好说，各人有各人的方法，我主要说一下我如何修正发散的结果。

我自己比较喜欢迭代的发散，每次集中一段时间去充分发散，把所有东西都写下来，过几个小时后或几天后再来审视以前的设计，对思维导图进行“重构”。因为这只是设计，重构的代价极度小，所以我会不断尝试用更好的思路来替代以前的思路。重构的重要准则就是那些经典的设计原则（比如 SOLID ），同时我会不断调研其他类似项目，看看别人是怎么设计和实现的。

等到我觉得思维导图已经足够详细，我就会继续到下一个环节，从思维导图中标记出最最核心的部分开始准备实现。

我比较崇尚敏捷开发的一些理念，喜欢迭代式开发，喜欢重构，不过不喜欢写太多的测试用例。在标记最核心内容的时候我不会考虑测试的事情，只会考虑如何能在短时间内把所有核心全部实现。这个“短时间”有多短就看我有多少空闲时间：如果是一个公司支持的大项目，我可以在工作时间慢慢做，这个短时间可能是一两周；如果只是个人兴趣，可能我只会花半天来写它。因为时间紧迫，我会比较小心的标记核心内容，避免逾期太久让我失去继续做的兴致。

实现核心内容的过程就是第一次真正检测设计可行性的过程，等这个开发完成之后多少都能发现一些设计缺憾，于是我就会开始进入重构过程。我不喜欢写测试用例，但我还是会写最核心的测试用例，比如至少把 tutorial 提到的内容都变成 case，测试有多复杂就完全取决于最终的 tutorial 有多长。同时，我会不断 review 自己写过的代码，一方面是找 bug，另一方面是找 bad smell，我会尽量在早期通过重构来消除一切不和谐的代码。

由于我十分注重自我 review，而且会用相当多的静态/动态错误检查来及早发现问题，比如 C++ static_assert 、编译期检查、各种 assert 等，所以程序和设计上的 bug 出现概率会非常低，这让我有理由在测试用例很少的情况下也能做大刀阔斧的重构。不过这只是个人习惯，并不见得好，所以好孩子不要学习……

以上就是我的一些方法，不知不觉就絮絮叨叨的说了不少，希望对大家有一些帮助。
(￣▽￣)o∠※PAN!=.: :'☆.: :'★':*