条件编译 #IFDEF ... 的使用有什么需要注意的地方？ 有何利弊？ 该怎样恰当使用？ 如果软件每新做一个功能或者完成一个新需求就增加一个编译开关是否是一种好的做法？
问的不好。提问点太泛太宽太多，对解答者是很大的负担甚至是不尊重。我绝对不相信“没有不好的问题，只有不好的答案”。
泛泛的提问，就泛泛解答。条件编译主要需要注意解耦和避免命名冲突。解耦的意思是说一个条件编译块的存在与否，一定要尽最大努力，保证最好不要影响到其他模块的编译。避免命名冲突就是要小心起名，保证控制条件编译的常量，不会在别处被意外定义。
具体的提问，就具体解答。每做一个新功能就加一个条件编译开关，绝对是一个不好的实践。
首先虽然“高内聚低耦合”是个原则，但如果软件的规模上去了，打死我也不相信软件里的每个功能，你都能把所有的耦合解开，让每个单一的功能都能从软件中去掉。其次，软件的功能必须保持一定的一致性。同一个软件，功能不应该有太多的增减和区别。如果编译参数的改变就能把软件“改头换面”，这绝对只会造成迷惑，而不会提供任何的方便！另外，每改变一次功能都要重新编译整个程序，这在性能和观感上看，也经常是不可行的。
条件编译的目的，是实现对编译过程本身的控制。（虽然这个任务现在也更多的由Makefile来共同承担）这也就是说：如果编译的条件有不可预先假定的变化，才需要条件编译。
这一点如果做过单片机开发就很容易理解。在这些应用场合中，对目标系统的控制是不可或缺的，例如MCU型号的些微变化，就能引起编译过程的本质改变。所以单片机开发的头文件中（例如AVR libc的io-avr.h）往往会有大量和硬件相关的条件编译。
所以条件编译的恰当使用，也就容易解答了：该用则用，不该用别用。条件编译只控制编译过程，而不能影响软件成品（实在有影响也要控制到最低程度）。
我猜你需要的可能是以下二者其一：
如果你要管理开发过程，希望能够记录、跟踪一个新需求的开发，并且希望新开发的同时稳定版本保持不变——你需要一个版本管理系统，例如Git或Subversion。
如果你要允许用户控制软件功能的多少——你需要引入主程序-外挂组件的设计方法，将软件本身分解为多个部分，允许用户在安装的同时进行控制。（你可以参考很多Windows软件的安装程序，中间的“自定义安装组件”一步）