作为一个按位操作的业余爱好者，这几天来我总结了一下自己知道的小技巧，希望能和大家分享。由于水平实在有限，这方面的知识储备不多了，需要重新充电。今天这个主题就将先告一段落，将来有新的总结体会了再写下来。我想趁这个机会，说说自己对按位操作的一些想法。
我猜按位操作受到的最大的质疑是现在计算机能力这么强大了，我们还需要拼了命的削尖了脑袋，想这种边边角角的好处么?很多时候拼命想出来的东西，实际运行起来对结果几乎没有任何影响。
我的回答是，看情况。
计算能力够不够用，这不能单凭计算机运算速度来评价，要结合具体任务对计算能力的需求。如果需求大于计算能力，即使计算机速度已经很高了，但我们仍然认为计算能力不够用。反之，如果只是求一些基本的加减乘除，那么哪怕是用古董一样的八位机，计算能力仍然够用。平时我们觉得计算机（主要是个人计算机）能力很强，主要是因为它足够处理日常生活中的问题。可是要知道世界问题千千万，有各种各样不同的需求。在有些情况下，计算机处理能力可能很低，比如嵌入式计算机，只是一个小小的芯片。受尺寸限制，有些单片机内存只有几兆，存不下太多数据。而在另一些情况下问题数据量又很大，需要极为复杂的运算，比如天气预报，以及各种各样别的大数据问题，TB级数据量是很常见的，一次任务动不动就要算好几天。在这些情况下，我们就继续绞尽脑汁想想怎么提高机器利用效率了。
关于按位操作的另一个矛盾是，方便机器，还是方便人？按位操作的作用无疑是方便机器，它帮助机器跑的更快，存更多的内容，可是它的问题是让人不容易理解。越是精妙的代码，越需要花更长的时间来理解。这些技巧在写“代码”的时候可以，但在开发“软件”的时候，除非是个别特殊情况，否则应该严禁出现这种晦涩的按位操作。软件最重要的是易于程序猿理解，易于维护和更新。面对少则几万几十万行，多则成百上千万行的代码任务，程序猿恨不得用最简单易懂的方式写出来。开发软件的时候，人们更关心的是如何组织这些代码（软件工程这门学科就做这个的），让程序猿看着更容易些，不会轻易为了一些性能上的提高而牺牲稳定性的。有一句话是这么说的：一个好的程序猿一定不是一个好的架构师，原因就在于，程序猿瞄准局部代码的优化，而架构师思考的是整体结构怎么设计，怎么把众多的程序猿和代码组织起来。很难想象一个整天用汇编语言的程序猿能够灵活运用各种设计模式，同样，也很难想象一个经常用Java的程序猿，会依据面相过程的原理来架构软件。
