掘友等级
Kubernetes | Containers | Cloud Developer | Smart work,Not hard 
获得徽章 0
“代码应该易于理解，只是机器恰好可以执行”。—— 《计算机程序的构造和解释》
体会越来越深刻，写好代码是一件很艺术的事情，因为这个是偏向于语文 抽象 概括能力的 感性思维，不是计算机技术能解决的工科思维。
即使是一个看似职业素养沟通能力良好的人去搞代码层次，抽象命名，文档书写，都没眼看的。
跟技术实现都是两回事。
论单打独斗各个都是英雄，论团队协作，你输出的质量不行。
实现 和 实现好 是两回事。
人渐渐地发现，这个世界上有很多问题就像翘翘板一样，只能要一边，这一边上去了，另边就下来了。就像要么用空间换时间，要么用时间换空间一样，你很难同时满足空间和时间要求的“双利解”；就像CAP的三选二的理论一样，这个世界不存在完美的解方案无论什么方案都有好的一面和不好的一面。而且这些工程师还还渐渐发现，每当引入一个新的技术来解決一个已有的问题时，这个新的技术就会带来更多的问题，问题就像有一个生命体一样，它们会不断地繁殖和进化。--《架构整洁之道》
看到 很多人 喜欢用 switch ，
其实并且有的时候 只走到一个 case 的 其实用 if 就足够了。 用 swich 非常啰嗦
还有一个很抓狂的操作是 在 case 里 写几十行 几百行 代码……😩
个别情况下 用switch case 来维持键值对类似的关系，用 map 是不是更好？
如果一定要用 switch case 理想的 情况是这样，反正就是少些点逻辑
switch ($command) {
case 'action':
startRecording();
break;
case 'cut':
stopRecording();
break;
case 'lights':
adjustLighting();
break;
}
软件的核心是其为用户解决领域相关的问题的能力，所有其他特性，都要服务于这个基本目的。开发人员必须钻研领域已获取业务知识。他们必须魔力其建模技巧，并精通领域设计。然而，大部分有才能的开发人员对学习与他们的工作领域有关的知识不感兴趣，更不会下大力气去扩展自己的领域建模技巧，他们更愿意从事精细的框架工作，试图用技术来解决领域问题，他们把学习领域知识和领域建模的工作留给别人去做，软件核心的复杂性需要我们直接去面对和解决，如果不这么做，则可能导致工作重心的偏离。《领域驱动设计-软件核心复杂性应对之道》#划重点
分布式、缓存、异步和多线程被称为互联网开发的四大法宝。
网关会挂掉吗？
1、网关本身多节点，并且本身是无状态的非常轻量，前面可能会再有一个DNS解析多个IP 或者直接 弹性负载均衡ELB；2、网关一般都会限流。如果担心过重，可以根据业务划分不同的网关，有点类似 BFF，但通常来说都是一个大网关。#划重点
