theme: awesome-green
这是我参与8月更文挑战的第2天，活动详情查看：8月更文挑战 本系列共 5 篇，通译自：97-things-every-x-should-know License：由 CC BY-SA 3.0 获得许可； 欢迎点赞、收藏、评论~ O(∩_∩)O
- 本瓜并未逐字逐句翻译，而是取其精要、理解抽象，结合自身进行撰文表达，与各位看官分享。认知好的编程概念，走向优秀~
- 传送门：《程序员优秀之路：认知 97 个好的编程概念（1）》
区分异常
程序运行时出现异常通常可以归为：技术异常和业务异常，区分二者有利于我们更好的捕获它们。
技术异常：比如，在长度为 17 的数组访问第 83 位元素，应该将它冒泡到架构设计级别进行统一捕获处理，记录日志、警报管理、输出报告等；
另一种技术异常是由于执行环境的影响。比如数据库无响应了等，应该设有一套基础机制来进行重连，重连合理的次数后仍报失败，再冒泡到统一的技术异常捕获进行处理。
业务异常：比如，尝试从资金不足的账户中取款，客户端应该创建特定、单独的异常层级进行处理，客户端还可以作更多自定义的处理；
混淆二者会让调用者感觉不清晰。
针对训练
“针对训练”与“完成任务”相对立，针对训练可以提高执行任务的技巧和能力；
我们都知道 10000 小时定律。Mary Poppendieck 指出：要经历 10000 小时的针对练习才能成为专家！
10000 小时有多长？每周 20 小时，坚持 10 年！（确实还挺久的~）
其实关键不是 1 万小时，而是 1 万小时有针对的训练，刻意的选择能才让你伟大！
针对训练不是训练你擅长做的事情，它意味着挑战，意味着不断失败，再不断吸取经验、不断成长~
行业黑话
Domain-Specific Languages（DSL）表明：每个领域都有着属于他们独特的语言，本瓜译为 —— 行业“黑话”~
对于开发人员来说，DSL 分为内部和外部：
- 内部 DSL 是用通用编程语言编写的；
- 外部 DSL 用文本或图形表达；
我们必须考虑 DSL 的目标受众，他们是开发、还是经理、或是客户？
针对不同的用户需调整不同的语言技术说法、工具名称、语法说明等。同时，借助 DSL 我们还可以隐藏一些技术细节，也能帮助在用户和开发人员之间搭建起一座沟通的桥梁。
语言在逐渐进化，表达方式也会有不同的发展！
勇于打破
我们都接手过一些糟糕的代码，讲道理是：想动，不敢动！
不动，在上面叠加逻辑，可能导致它越来越恶化。就像是医生看病，当病情愈发恶化，你再不动手术的话，就要出大事。
动手术是一时的疼痛，但它会不断往好的方向发展，最终愈合。
当我们再面对槽糕代码时，不要害怕！勇敢牛牛，不怕重构！！
如果能完整的处理它，会帮助你获得很多经验，这都是不可多得的！
重新定义接口、重构模块、重复复制粘贴的代码、减少依赖，加入设计思想......你一定会遇到很多问题，但坚持下来，你最终一定会胜利！
“成为不怕切除肿瘤的外科医生”等于“成为不怕重构槽糕代码的程序猿”。
当然，在这之前，你需要足够的理由说服自己、说服“管理层”。
严于测试
不管是开发做自测，还是测试人员做版本测试，我们可能会随意的写测试数据：123123、testtest、13433334444......有时甚至会将一些私密信息作测试数据~
我们要做这样的考虑：如果这些测试数据被公开了，会不会造成一些麻烦和尴尬？
包括一些提示语也是同样，测试的提示语可能在正式线没有进行替换，导致尴尬。
还包括一些测试的地址在上线前也忘了替换，导致麻烦。
所以，在开发过程中编写的任何测试数据，我们都得尽力严格把控。
别放过错误
如果一个错误不太严重，我们往往会选择忽略，而这往往会带来一些不自知的风险。
代码语言：javascript复制try {
// ...do something...
}
catch (...) {} // ignore errors说中了，catch 里面的内容本瓜有时会忽略，通常加一句 console.log(err)。
不处理错误会导致：
- 代码脆弱；
- 代码不安全；
- 代码结构差；
别放过错误，别欺骗自己程序总能正常运行、始终有效！
了解语言文化
计算机语言和自然语言一样，我们不仅仅要学它的语法知识，还要学习它背后的文化。
The Pragmatic Programmer 鼓励我们每年学一门新的语言~
了解语言背后的文化是非常有趣的，旦当涉猎，触类旁通。
u1s1，一年学一门，这个想法真的挺大胆的！
一旦你学会了一门新语言的诀窍，它还会反哺你重新认识之前一直在使用的语言。
作者从 Ruby 编程中学会了如何在 C# 中有效地使用委托，在 .NETs 对泛型的使用启发了 Java 中泛型的用法，学习 LINQ 让 Scala 变得轻而易举......
捕获错误
作者为了防止应用程序的终止，用了大量的 try...catch....，却为此付出了代价。
他的团队自制了一个 C 的基本应用程序类，它处理了所有转义异常的代码，这导致了每当出现问题时，错误会像在黑帮片被杀的人一样消失，没有留下任何痕迹。
用多次的 try...catch 捕获错误表面上看取代了系统的混乱，但实际上也会产生难以排查的崩溃。
- 此点存疑：本瓜猜测作者想表达有些错误需要暴露出来在错误处理机制中进行统一处理，而不是写很多 try...catch... 来掩盖。
不相信假设
没有开发经验的管理者觉得程序猿的工作很简单，同样，没有管理经验的开发者，认为管理的工作很简单（不就是合周报吗？
