个人项目在规划初期如何尽量想到各种功能和逻辑

Question

在做自己新的个人项目的时候，如果在规划的时候就尽量想到应该实现的功能，以及每个功能的逻辑部分。尽可能减少后来重新设计功能和逻辑部分，以及不断地修逻辑bug。我想到的有：用思维导图，覆盖绝大多数功能利用现有成熟框架，利用他们的思想解决逻辑上可能出现的bug。我的问题：个人项目时会不会写单元测试，个人项目的单元测试是否会必要和浪费时间。如何在一开始就想到绝大多数可能的逻辑，尽可能减少bug希望大家能把自己的经验分享给大家

Answer 1

我来分享一下我的方法。
总的来说我会把一个项目的设计分成以下几步，其中思维导图这一步并非必须，项目不大的时候在头脑中进行就行。
写交互设计文档
制作思维导图
设计核心框架
开始迭代开发、实现
项目刚开始设计时，我会用一种类似于交互式设计的思路来开始，第一件要做的事情不是代码设计本身，而是写这个项目的使用方法。
比如要写一个框架或工具，我会从怎么使用这个项目开始，用某个markdown编辑器以面向最终用户的语言描述项目的基本概念和用法。就好像到处能看到的项目tutorial页面一样，我会写出一个完整的tutorial，并反复阅读它，用一个用户的角度来审视这个项目，看看这个tutorial是否能够让我自己明白该如何使用它，以及它是不是足够sexy让我有冲动去使用它。如果我自己觉得这个tutorial足够好了，我就可以真正开始设计细节了。
比如这个项目就是我正在设计中的东西，写的这个tutorial就是我最开始的设计文档，其实代码（因为种种原因）还没开始写。
在核心交互式设计完成之后，我就会开始用思维导图进行发散。关于如何发散这个可能没什么好说，各人有各人的方法，我主要说一下我如何修正发散的结果。
我自己比较喜欢迭代的发散，每次集中一段时间去充分发散，把所有东西都写下来，过几个小时后或几天后再来审视以前的设计，对思维导图进行“重构”。因为这只是设计，重构的代价极度小，所以我会不断尝试用更好的思路来替代以前的思路。重构的重要准则就是那些经典的设计原则（比如SOLID），同时我会不断调研其他类似项目，看看别人是怎么设计和实现的。
等到我觉得思维导图已经足够详细，我就会继续到下一个环节，从思维导图中标记出最最核心的部分开始准备实现。
我比较崇尚敏捷开发的一些理念，喜欢迭代式开发，喜欢重构，不过不喜欢写太多的测试用例。在标记最核心内容的时候我不会考虑测试的事情，只会考虑如何能在短时间内把所有核心全部实现。这个“短时间”有多短就看我有多少空闲时间：如果是一个公司支持的大项目，我可以在工作时间慢慢做，这个短时间可能是一两周；如果只是个人兴趣，可能我只会花半天来写它。因为时间紧迫，我会比较小心的标记核心内容，避免逾期太久让我失去继续做的兴致。
实现核心内容的过程就是第一次真正检测设计可行性的过程，等这个开发完成之后多少都能发现一些设计缺憾，于是我就会开始进入重构过程。我不喜欢写测试用例，但我还是会写最核心的测试用例，比如至少把tutorial提到的内容都变成case，测试有多复杂就完全取决于最终的tutorial有多长。同时，我会不断review自己写过的代码，一方面是找bug，另一方面是找badsmell，我会尽量在早期通过重构来消除一切不和谐的代码。
由于我十分注重自我review，而且会用相当多的静态/动态错误检查来及早发现问题，比如C++static_assert、编译期检查、各种assert等，所以程序和设计上的bug出现概率会非常低，这让我有理由在测试用例很少的情况下也能做大刀阔斧的重构。不过这只是个人习惯，并不见得好，所以好孩子不要学习……
以上就是我的一些方法，不知不觉就絮絮叨叨的说了不少，希望对大家有一些帮助。
(￣▽￣)o∠※PAN!=.::'☆.::'★':*