【51CTO译文】告别这些常见但却糟糕的编码实践方式能够让我们的工作更为轻松——而开发出的软件也将更安全且更具可扩展性。
根据“帕累托原则”的说法，特定事件最终结果当中的八成往往由由占二成的随机性因素所决定。这种划分方式被称为二八开原则，而且几乎影响到了人类生产生活当中的每一个领域。
在软件开发领域，该原则也可以这样进行解读：大部分问题实际都是由一小部分不良编码实践所引发。只要消除这部分因素，我们的工作就能变得更轻松也更加富有成效。
在今天的文章中，我们将一同了解十大给软件开发工作带来无穷困扰的糟糕编码实践活动。
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.明知时间规划无法实现却仍勉力苦撑
与此同时，我们还应该保持清醒的头脑、意识到在团队规模不变的前提下进度滞后的情况根本无法扭转——这样的理性思维能力非常重要。如果大家没能完成原有时间表，那很可能是因为这份进度规划在制定时存在着失误。换句话来说，大家需要出台一份新的项目时间表而非盲目坚持原先这份已经被现实证明为不可能的错误方案。
