【IT168 技术】根据“帕累托原则”的界定，特定事件中80%的最终结果往往实际源自20%的可能性因素。这种划分方式被称为二八开原则，而且几乎影响到了人类活动所触及的每一个领域。

　　在软件开发领域，该原则也可以被解释为，大部分问题实际都是由一小部分不良编码实践所引发。只要消除这部分因素，我们的工作将会变得更轻松也更加富有成效。

　　下面我们就一起来看这十种给工作带来无穷困扰的糟糕编码实践。

　　1. 代码当中的拼写错误

　　这类问题的出现频繁可能超出大家的想象，它们之所以如何普遍与猖獗、是因为这一切与我们的编程技能水平并没有必然联系。再出色的开发人员也有可能在代码中写出错误的变量名或者函数名，而这最终将成为一股肆虐无忌的狂暴力量。更重要的是，揪出它们实在是件困难的差事。

　　那我们该如何解决这一难题呢?使用一款良好的集成开发环境(简称IDE)甚至是选择一种专门面向程序员的文本编辑器，这些都能大大降低拼写错误出现的机率。除此之外，我们还有另一条道路可以选择：刻意选择较容量拼写的变量与函数名称，这样一来发现错误的过程就会变得相对轻松。最好不要使用receive这类词汇，因为不管检查多少次、我们都不太可能发现它被错写成了recieve。

　　2.没有对代码进行缩进或者格式调整

　　一定记得为代码行设定缩进或者作出格式调整，否则大家一定会发现自己的代码内容既难于理解又不容易从中找出错误。此外，简洁明确的格式设置还能带来一致化的显示效果，进而降低他人对代码的维护难度。

　　如果大家使用的IDE不具备代码格式自动调整功能，则不妨考虑使用Uncrustify等代码美化工具，这类方案能够根据我们事先设定好的配置机制完成格式转换。

　　3. 未能实现代码模块化

　　在编写函数时保证其能且只能实现一种效果绝对算是非常重要的良好编码实践。这种处理方式能够让代码保持精悍，并因此更易于理解与维护。过长的函数可能拥有多种可能的接入路径，从而导致其更难于进行测试。

　　这里教大家个好办法：一个函数最多不要超过单一屏幕的显示极限。另外，如果代码当中包含十个甚至更多“if”语句或者循环，那就说明其关系太过复杂、应该重新进行编写。

　　4.不要被IDE功能所带来的虚假安全感所蒙蔽

　　IDE以及其它能够自动实例代码的工具能够奇迹般地提升生产效率。它们会根据大家已经输入的内容给出建议变量以及其它相关提示内容。不过这类工具在实际使用时也有可能带来潜在问题——由于能够毫不费力地从看似正确的选项中挑出自己需要的内容，大家往往会因此而放下戒心。不要这样，请务必确保我们选择的与自己需要的确切吻合。从本质上讲，这类功能相当于将思考工作转移到了工具身上，在这种情况下确保其思路正确自然是第一要务。

　　这相当于给我们提供了一条新的思考准线。代码完成工具可以消除当中的拼写等错误并提高生产力，但它们同时也可能在我们放松警惕时悄悄把错误埋入其中。

　　5. 硬编码密码

　　以硬编码方式创建秘密账户与密码可谓极具吸引力，大家可以借此在随后的使用过程中直接进入系统。我相信大家都知道这种作法不好、不对——没错，这种方式确实非常方便，但同时也等于是给任何有意访问源代码的人士提供了便利之门。

　　真正的问题在于，硬编码密码最终总会扩散到我们意料之外的人群当中。这就使其成为一种巨大的安全威胁，而且很难得到彻底修复。

　　6.没有利用良好的加密机制进行数据保护

　　敏感数据需要在网络传输的过程中受到加密，这是因为在传送期间它被可能遭遇恶意人士的拦截。这并不仅仅是什么好主意或者推荐方案，这是一种监管要求——甚至可以上升到法律的高度。

　　也就是说，直接发送数据内容的作法必须得到“明令禁止”。此外，大家也绝对不要使用自己的加密或者模糊处理方案。编写自己的安全加密系统难度很高——大家看看WEP的遭遇就能明白——因此请务必选择符合相关行业标准的加密库并加以正确使用。

　　7. 过早对代码进行优化

　　传奇程序员Donald Knuth曾经说过，“程序员们把大量时间浪费在了考虑或者担忧程序当中非关键性部件的执行速度上，这些尝试往往会给代码的调试与维护工作带来严重的负面影响。”

　　在我们的代码上多花心思可能确实会让它的执行速度不断提升，但同时也会给调试与维护带来更高难度。最好的处理办法是：以清晰的方式编写代码，然后在真正有必要的时候再通过优化提升其性能表现。

　　8. 不具备超前思维能力

　　我们的项目是用来做什么的、预计将会扩展到怎样的程度、有多少用户会对其进行操作、又将以怎样的速度付诸运行?这些问题的答案在开发过程中也许并不明确——但如果大家不能提前作好规划，那又该如何准确选择合适的框架来开发出能够满足这些需求的应用程序呢?

　　Twitter技术团队遇到的实际情况就是个很好的例子：如果对未来的实际使用情况估计不足，后续处理将变得极度困难。Twitter不得不放弃了Ruby on Rails并利用Scale及其它技术方案对代码进行重新编写，这是因为Ruby代码在最初设计上根本没有考虑到Twitter会拥有增长速度如此迅猛的用户群体规模。

　　9.添加人手来加快开发进度

　　几乎每一个软件项目都无法真正实现预定时间进度。添加人手来加快进度并使其符合原本计划听起来像是个好主意，但这仅仅是种理论而非现实，而且通常甚至属于严重失误。在现实世界中，向项目中添加新人几乎总会导致整体生产效率产生下滑。

　　10.坚持根本无法实现的时间规划

　　与此同时，我们还应该保持清醒的头脑、意识到在团队规模不变的情况下根本不可能重新赶上预定进度，这样的理性思维非常重要。如果大家没能遵循原有时间表，那很可能是因为这份进度规划在制定时就存在失误。也就是说，大家需要创建一份新的项目时间规划，而不是盲目坚持原先这份已经被现实证明为不可能的错误方案。