如何做好一个项目

我是一个有轻微洁癖的人，做任何事，都希望将它尽量做好，不愿意得过且过。

有时候我就在想，一个软件项目最重要的究竟是什么，是那些代码吗？也许在许多人看来答案是肯定的，但是我是不认同这个观点的，我觉得一个项目它的所需的那些背景资料还有项目本身的逻辑框架才是最重要的。毕竟，再怎么看代码只是一个工具，代码只是人的思维逻辑的一种表达形式，归根到底还是人脑的逻辑在左右着一个项目，这才是评价一个项目好坏所需要关注的地方。我们在讨论一个项目的时候，更多的时间精力不是在讨论代码怎么写，这个写代码是个体力活，真正值得我们耗费精力的是项目的逻辑框架，以及如何实现具体功能的逻辑思维。

我并不是说写代码不重要，相反它确实很重要，但是它是一个合格的程序员最基本的技能。就目前来看，大多数所谓的程序员写代码这一关就没能过去，但他们却一直在勤奋的产出代码，产出那些垃圾代码，也许在他们看来，他们的程序能执行啊，跑得很好啊，也能得到想要的结果啊。但我不得不说，他们写的还是一堆垃圾代码，因为这种代码不能锻炼一个人的思维，这样的代码在其他人看来晦涩难懂，用一句话概括：这段代码写出来，除了作者本人，没人愿意多看它一眼。如果作者自己都不愿意再看了，就该重新写啊。

综上，一个合格的项目，应该是生成的逻辑框架合理、代码规范，然后配有完整详细的文档。如果项目的整体框架合理，代码实现规范的话，那么文档的编写也将会十分的顺利。如果写文档的时候发现难以找到简洁明了的组织方式，那很有可能不是写文档这个事难办，或者写文档的人水平不够，很有可能是项目实现的不合理。所以我觉得，实现一个项目，前期的需求分析和项目逻辑框架的规划应该给与充足的时间，只要这里把功夫做足了，代码实现将会是一个一气呵成，简单愉快的过程，而且伴随而来的是项目文档的编写将会呼之欲出。在这里提出一个观点：后期项目变动越大，越说明前期规划的不充分；后期文档越难写，说明项目做得越不合理；项目测试的时候bug越多，越说明项目规划不到位，代码不够规范。编写文档不应该由其他人完成，应该由项目的参与者完成，每个人对自己负责的部分进行详细描述，这既有助于大家互相沟通了解，对日后项目的优化也是很有利的，同时也是对自己代码逻辑的一个检验，也是提高自身水平的捷径。

曾经读过一篇文章《关于烂代码的那些事 － 为什么每个团队存在大量烂代码》，深有感触，大家可以在网上搜搜看，也看一下下面的链接http://chuansong.me/n/2159610

这里我要另提一个概念，就是科学和技术是两回事。科学是可公理化可预测结果的可解释问题的，技术则是强调实现不追求解释。多数人是技术型而不是科学型的。技术型的人面对一个问题会倾向于不断做技巧性的尝试而忽视思考理论的正确性，他们解决问题往往依赖经验而不是科学理论。这种人的高度是有限的，但他们有他们的存在价值。如果一个产品团队是重视科学理论正确性的，他们的项目研发速度可能会慢一点，但产品出去会更稳定；如果是倾向技术型的，项目研发速度可能会快一点，但他们的产品会经常出问题，经常折腾。
我倾向于优先从理论上验证项目的可行性，按照科学合理的安排一步一步实现项目，这样可能会做出一些别人看来没必要的事情，但是一旦完成之后，项目的成果是可以预期的，项目的内部功能是可以保证的，这就会使我们对整个项目非常有信心，同时从理论上就杜绝了许多bug的出现，从而是产品更稳定，后期投入的人力物力越少，甚至可以做到长期持续运转不出问题，而这种产品质量是那些技术型的人做不到的。