程序员的修养

什么是程序员的修养？换句话说，也就是程序员的工程师文 化，也就是程序员的价值观。

1. 英文能力。
   比如1 坚持 Google 英文关键词，而不是在 Google 里搜中文。 2. 在 GitHub 上只用英文。用英文写代码注释，写 Code Commit 信息，用英文写 Issue 和 Pull Request，以及用英文写 Wiki。

   1. 糟糕的架构比烂代码带来的问题更多。

   2. 思考要比编码花费更多时间。

   3. 最好的程序员一直在构建。

   4. 总有更优的方法。

   5. 代码评审会让每个人都受益。

   6. 最终，更好的代码会胜过更多的特性。

   7. 难以理解的代码也难以维护。

   8. 你总是应该知道你的业务是如何挣钱的，谁付这钱。

   9. 如果你成为重要的软件开发者，请在崇尚技术的公司工作

2. 问问题的能力
   提问的智慧（How To Ask Questions The Smart Way）一文最早是由 Eric Steven Raymond 所撰写的，详细描述了发问者事前应该做好什么，而什么又是不该做的。
   有一个经典的问题叫 X-Y Problem。对我来说，这是一个很容易犯的错误，所 以，你也要小心避免（我曾经在我的 Coolshell 上写过这个事《X-Y 问题》）。
3. 写代码的修养
   推荐几本书：《重构：改善既有代码的设计》，《修改代码的艺术》，这本书是继《重构》之后探讨修改代码技术的又一里程碑式的著 作，而且从涵盖面和深度上都超过了前两部经典（《代码大全》和《重构》）。《代码整洁之道》，《程序员的职业素养》，
   
   作为一个程序员，Code Review 是非常重要的程序员修养。Unit Test 也是程序员的一个很重要的修养。写 Unit Test 的框 架一般来说都是从 JUnit 衍生出来的。
4. 安全防范
   代码中没有最基本的安全漏洞问题，也是我们程序员必须要保证的重要大事，尤其是对外 暴露 Web 服务的软件，其安全性就更为重要了
5. 软件工程和上线
   系统上线是一件比较严肃的事，这表明你写的软件不是跑在自己的机器上的玩具，或是实验 室里的实验品，而是交付给用户使用的，甚至是用户付费的软件。对于这样的软件或系统， 我们需要遵守一些上线规范，比如，需要认真测试，并做上线前检查，以及上线后监控。
   
   关于测试：推荐2本书籍
   
   《完美软件：对软件测试的各种幻想》，这本书重点讨论了与软件测试有关的各种心理 问题及其表现与应对方法。作者首先阐述软件测试之所以如此困难的原因–人的思维不 是完美的，而软件测试的最终目的就是发现对改善软件产品和软件开发过程有益的信 息，故软件测试是一个信息获取的过程.
   《Google 软件测试之道》，描述了测试解决方案，揭示了测试架构是如何设计、实现 和运行的，介绍了软件测试工程师的角色；讲解了技术测试人员应该具有的技术技能； 阐述了测试工程师在产品生命周期中的职责；讲述了测试管理，并对在 Google 的测 试历史上或者主要产品上发挥了重要作用的工程师的访谈
   
   关于上线前检查：
   系统要上线时，有两个 Checklist 供你做上 线前的一些检查：
   Server Side checklist

   对于web应用来说，在发布产品之前，服务器端需要遵守的一系列规则，简单总结如下：
   1、系统要有弹性：不能让应用局部发生的错误影响或者扩散到整个系统，系统在高负载的情况下不会挂掉。
   2、部署对用户透明：应用添加节点的时候不会影响到当前在线的用户。
   3、系统要有监控：http请求超时、500错误、服务重启、服务器资源耗尽。
   4、系统测试：网络分区测试、压力测试。
   5、数据备份：从备份数据恢复系统所有数据。
   6、系统安全：TLS、OWASP TOP 10 Vulnerabilities、HTTP security headers。

   Single Page App Checklist
   
   补充：在面对短时间复杂工作时，一定不要盲目相信自己的大脑的记忆力、应变力和冷静度，而要学会运用cheklist高效快速地管理各种事项，确保标准操作程序的完成和无遗漏执行。
   这个原则是从航空检查单的应用上学习到的，可以在最短时间内完成各种正常和典型应急情况的处理。各种预案制度也和它原理相似。
   在生活中用好 cheklist，不仅能帮助你整理混乱的家居，清爽缠成一团的工作，在旅行时不再遗漏东西，还能在危机时候帮助你，有一次我在高速上目睹车祸并受波及时，脑子完全空白了一分多钟，后来打开手机上的CHECKLIST，才清晰快捷地完成了所有安全和临时处理工作
6. 写代码时，最好参考一些已有的最佳实践：可以让你的代码很规整，这有利于代码易读性，从而可以更容易地维护。 提升开发效率，我们知道，效率来自于结构化，而不是杂乱。可以让你的软件避免一些容易掉坑的陷阱，也让 Bug 更少，质量更高。 可以让团队成员更高效率地协作。