我是个习惯于凡事有规矩的人，所以这也影响我的开发思路和代码风格。

面对一个新项目，我不会选择仅仅为了快速而放弃项目结构、性能效率、格式规范和可重用性的。打个比方吧，未合理分包分层及文档注释的项目结构、代码里出现使用“+”连接多个不同字符串变量、使用magic number而不定义常量或枚举的等等，这些问题可能别人不以为然，可在我看来是不能接受的。

说者无心，听者有意。到底这么“细扣”真的是无所谓的吗？我觉得不尽然，很简单一个例子，好的编码习惯可以极大地提高我们犯错和排错的机率。在编码中，良好的软件结构和完善的日志记录是有利于我们迅速理解开发思路，发现和修补bug，特别是当若干天后添加功能或者代码重构时，好的编码习惯更是能起到事半功倍的效果，试想一下，如果重构时满篇都是诸如此类：

int magicNo = 3721; // what the fuck 3721 mean? so it's a magic number

我真的很难想象你当时的心情应该用多少个感叹号和问号才能化解，也不知道当你耗尽洪荒之力理解了这一段段“奇思妙想”的代码后，还有多少余力进行添加功能和重构。

适当的忽略部分功能实现，简化项目结构会是有效推进项目进度的方式之一，但不规范使用API、不遵循基本的编码规范，这也是提高项目开发进度吗？我觉得不尽然，就以刚才的魔数例子为例，它往往会带来很多不易察觉的bug以及大量重复性的易出错的替换操作，这会极大影响开发者的效率和注意力，降低对项目问题本身的逻辑思考能力，并不会显著提高开发进度，相反，还会降低开发进度。所以，我的观点是：在规范用词和格式的前提下，为了推进项目进度，是应该适当地简化功能和结构，但如果仅仅为了提高进度，不遵守编码规范，这就是另外的问题了。

在我看来，每次项目开发的过程其实就是“解题 + 排错”的过程。解题的思路可以千差万别，可以有好有坏，有巧有拙，但遇到bug都是需要在最靠近bug发生的地方找到它，并确认它的来源。否则，等项目基本成型的时候，面对大体量的代码，找出应用中一个个高层的或藏匿的bug只能更加耽误项目进度，白白耗费精力和时间，也起不到提高自身编码能力和项目代码质量的作用。

俗话说，“基础不牢，地动山摇”，就像我们在写东西的时候，文章的思想很重要，它反映了作者的思想深度和认识水平，但同样重要的是，文字的用词规范和版式要求也是评价作者对待作品的专业素养和严谨态度的衡量标准。“万丈高楼平地起”，只要我们保持对优秀代码的不懈追求和“不断思考，勇于实践”的态度，相信未来总有一座高楼因你而起。

have fun！

END