新的思维方式
代码行数，确实会影响项目的健康程序，团队的健康程序。
如果将 Linux 视为一个开源项目，那么今天该项目中约有 2400 万行代码，这非常庞大，需要一个庞大的团队来处理。
成为质量，效率和简单性的拥护者。
是什么推动了我做出的工程决策? 作为开发人员，我在进步吗?
采用新技术总是很容易，但是采用新的思维方式却很难。
少即是多
如果你的工作做得很好，没人应该知道你的名字。
如果有人知道你的名字，可能意味着你的软件出现故障或导致问题。
你想让别人知道你的名字吗? 成为前端开发者。那你会花两周的时间在屏幕上工作，会有人看着你的页面指出了他们不喜欢的东西。啊，这曾经让我发疯。
不管是什么行业，不管软件是否正确，人们的生活，他们的幸福，一切都依赖于你正在构建的技术。我们必须认真对待，保持软件的完整性。
完整性有两个地方，一个微观层面和一个宏观层面。
在微观层面，需要明白你写的每一行代码。每一行代码要么做三件事之一，它分配内存，读取内存，写入内存。使用 Go 语言，我们在代码中所需要做的只是读取并写入内存，所有这些读取和写入都会导致我们周围的一切发生: 灯亮了。你正在阅读这篇文章。
上面提到过，一般开发者面对超过 10000 行代码，会产生严重的心智负担。而且平均每 100 行代码有可能会产生 10-20 个错误。当代码比预估需要的多时，就会有更多的地方可以隐藏错误，这也意味着有更多不完整的测试。
除了编写更少的代码之外，完整性的另一个重要部分是错误处理。你的软件必须保持稳定，而不是增加危机，应该试图从错误中恢复。
less is always more
完整性是首要的，次要的是可读性。要以一种易于理解的方式构建我们的软件。
抽象的目的不是模糊，而是创造一个新的语义层次，一个可以绝对精确的层次。
封装不仅仅是可测试的，要确保它们提供了一种语义精确的层次，而不是隐藏复杂性。
性能
软件的性能不足，有可能来自四个地方。
- 延迟，网络，IO，磁盘 IO 等类型的延迟
- 垃圾回收和内存分配
- 访问数据的方式，效率
- 算法效率，是否可以优化算法以采取更少的步骤而不是更多的步骤
让它正确，让它清晰，让它简洁，让它快速
面向数据的设计
Go 语言的特性，它要求你必须把自己的思维方式，从 面向对象的设计 到 面向数据的设计。
怎么才能将代码和有可能改变的数据相解耦呢? 如何可以解耦，那就可以尽量降低由于数据改动造成的连锁反应。
总是在做抽象，在抽象上面做另一层抽象，那么就会离上面说的解耦越来越远，而且很难保证代码准确无误，清晰易读，因为这样写出来的代码太过抽象，让我们很难理解其中的思路。
代码要针对当下来写，架构要面向未来设计。不要写出目前根本用不到的代码，那样写只会产生更多的 bug。因为代码越多，越容易出 bug。
面向数据的设计，是要求必须将数据搞懂，要求我们只编写必须用到的代码和算法，要对算法解耦，以降低数据发生变化时整个项目受到的影响。我们要做是，怎样做到数量最少写法最清晰的代码把问题解决。
数据应该在特定的情况下才有行为，如果你是从面向对象的编程语言切换到 Go，那可能不太容易接受这种理念。因为 OOP 总是要求你考虑数据的状态，以及数据会有怎样的行为。面向对象并不是 Go 语言里面最好的编程思路，Go 语言在大多数情况下追求的其实是把状态跟行为分开，做到这点可以少写一点代码，并且可以简化编程工作。
首先应该考虑函数，只有在不该用或不方便使用函数的情况下，才可以考虑方法。
遗留代码
我们认为糟糕的代码是由糟糕的开发人员编写的，但实际上，它是由合适的开发人员在’糟糕的情况下’编写的。
总会有人请你帮他看代码，你可能会觉得写代码的人是不是出了什么问题，怎么会写出这样的东西呢?
其实这背后是有原因的，他们没有办法告诉你，遇到这种代码的时候千万别急。先冷静下来，别急着去责怪写它的那个人，我们应该问问自己，这种代码是在什么样的环境或什么样的情况下写出来的。
现在既然交给自己来维护，那有没有什么办法能把它改的好一些呢?
无论面对什么事都应该有同理心，因为做那件事的人所处的情况可能和你现在不一样，现在是把别人写过的代码交给你来维护，反过来你的代码也有可能交给别人来维护。如果能够换位思考，那么跟遗留代码有关的许多问题或许就能够解决。
如果你想一开始就把代码写好，而不想写出那种留有很有问题的代码，那么首先要注意的，就是提醒自己，这套代码优采用什么样的方式来写，写代码的思路特别关键，每天重构代码，其实都是按这样的思路进行修改的。
在开发者脑子里，通常没办法容下超过 10000 行代码，这里的容下不是指将每行代码都背下来。而是如果有人问你某个函数在什么地方，或是某项功能的实现代码在哪里，你可以很快的找出来。也就是说，你能够弄清代码的流程，对代码非常的熟悉。如果程序发生错误，很快就能知道自己应该从哪块代码入手。
我们要关注代码行数，把它降低，这样才能保证团队合作顺利。每位程序员所需要把控的代码不应超过 10000 行，这种认知方面的负担必须引起重视。
最难对付的 bug 是思路上的 bug，因为你根本看不出问题在哪。
不应该第一时间使用调试器，如果正式的软件产品里面出现了错误，那你只应该通过整理思路，或者查看日志来解决问题，如果这些方法还是不能帮你找到 bug，那就说明这段代码的写法出了问题。如果需要调试器才能解决问题，可能这段代码需要重构。因为根本问题在于修正思路上的错误。要在日志里面多记录一些有用的信息，帮助我们还原当时出错的过程。
Go 是我见过的力量和表现力之间的最佳平衡，通过简单直接的编程，你几乎可以做任何你想做的事情。并且，对机器上将要发生的事情有一个良好的心理模型