编程是一种技艺，一种需要用心学习的技艺。
用最简单的话表述，编程可归结为让计算机做你或你的用户想要它做的事情。作为程序员，你既是倾听者，又是顾问；既是解释者，又是发号施令者。你设法捕捉难以捕捉的需求，并找到表达它们的方式，让一台纯粹的机器能够合理地处理它们。你设法为你的工作建立文档，以使他人能够理解它；你还设法使你的工作工程化，以使他人能够以它为基础进行构建。
你不应该局限于任何特定的技术，而是应该拥有足够广博的背景和经验基础，以让你能在特定情况下选择好的解决方案。
你的背景源自对计算机科学的基本原理的理解，而你的经验来自广泛的实际项目。理论与实践的结合使你强大起来。
学习技术之后，还需要将其“内化”。
两个都了解KISS原则的程序员在一起写代码，高手的代码必然为自然流露出KISS的优雅，而中手或需要别人的提醒和多次重构，才能达到理想的状态。出现这个问题的原因-没有内化KISS原则。如何快速达到高手的境界，可以肯定的说，光靠对自己说“下次我一定按照这个原则这样做”是不行的。认知科学认为，频繁的高强度的外部刺激和自主的有意识的反复提醒是加速内化的两个重要方法。
在所有的弱点中，最大的弱点就是害怕暴露弱点。
依据你的职业发展、你的项目和你每天的工作，为你自己和你的行为负责这样一种观念，是注重实效的哲学的一块基石。注重实效的程序员对他或她自己的职业生涯负责，并且不害怕承认无知或错误。这肯定并非是编程最令人愉悦的方面，但它肯定会发生--即使是在最好的项目中。尽管有彻底的测试、良好的文档以及足够的自动化，事情还是会出错。交付晚了，出现了未曾预见到的技术问题。发生这样的事情，我们要设法尽可能职业地处理它们。这意味着诚实和坦率。我们可以为我们的能力自豪，但对于我们的缺点--还有我们的无知和我们的错误--我们必须诚实。
提供选择，别找借口。
不要把问题归咎于别人或其他什么事情上，也不要寻找借口。不要把所有问题都归咎于供应商、编程语言、管理或是同事。这些因素都可能是问题的一部分。它们的确会对解决方案造成影响，但不是给你的借口。如果你打算跟别人解释为什么做不完、为什么延期、为什么搞砸，在此之前先等等，听一下自己的内心。你的那些借口听起来合理吗？还是很愚蠢？你的老板听到会怎样？给出选择，而不是找借口。不要说搞不定，解释一下要做些什么才能挽回这个局面。
当你意识到自己在说“我不知道”时，一定要接着说“--但是我会去搞清楚”。
用这样的方式来表达你不知道是非常好的，因为接着你就可以像一个专家一样承担起责任。
虽然软件开发不受绝大多数物理法则的约束，但我们无法躲避来自熵的增加的重击。
熵是一个物理学术语，它定义了一个系统的“无序”总量。不幸的是，热力学法则决定了宇宙中的熵会趋向最大化。当软件中的无序化增加时，程序员会说“软件在腐烂”。有些人可能会用更乐观的术语来称呼它，即“技术债”，潜台词是说他们总有一天会偿还的--恐怕不会还了。
漠视会加速腐烂的过程。
不要搁置“破窗”（糟糕的设计、错误的决定、低劣的代码）不去修理。每发现一个就赶紧修一个。如果没有足够的时间完全修好，那么就把它钉起来。也许你可以注释掉那些糟糕的代码，显示一行“尚未实现”的信息，或用假数据先替代一下。采取行动，预防进一步的损害发生，表明一起尽在你的掌握中。
不是所有程序员都叫工程师。
程序员只让代码跑起来是不够的，因为这个世界是不断变化的。需要花更多的时间来维护代码：增加新的需求，扩展原有的流程，修改已有的功能，优化性能......一个人完全维护不过来，还需要更多的人，于是代码还需要在不同人之间轮转。代码除了要跑起来，还需要易读、易扩展、易维护，甚至可以直接重用。于是，开始使用各种各样的手段和技术不断提高代码的易读性、可扩展性、可维护性和重用性。人们把这些有“洁癖”、有工匠精神、有有修养的程序员叫做工程师。
程序员的三书：
《代码整洁之道》教你写出易读、可扩展、可维护、可重用的代码，《代码整洁之道：程序员的职业素养》教你怎样变成一个有修养的程序员，《架构整洁之道》教你描述软件设计的理论知识。
无论代码与架构都在解决一个问题，那就是分离控制和逻辑。
无论是微观世界的代码，还是宏观层面的架构，无论是三种编程范式还是微服务架构，它们都在解决一个问题--分离控制和逻辑。所谓控制就是对程序流转的与业务逻辑无关的代码或系统的控制（如多线程、异步、服务发现、部署、弹性伸缩等），所谓逻辑则是实实在在的业务逻辑，是解决用户问题的逻辑。控制和逻辑构成了整体的软件复杂度，有效地分离控制和逻辑会让你的系统得到最大的简化。--陈皓
学习参考资料：
《程序员修炼之道》
《架构整洁之道》
----END----
这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。
