我们一定要善于从信息中去挖掘问题，发现矛盾。进而更好的定义它的优先级和重要性，继而更好的去总结归纳。总结归纳反过来又会帮助我们更好的从信息中是挖掘问题本源。
放到程序媛的成长上来看，初期我们认为“我是个女孩子，我和他们不一样”。就是“看山就是山”，等到后期慢慢发现，女程序员和男程序员一样，我不是柔柔弱弱的女孩子，我也要像男生那样去拼搏，去夺取更多的荣誉。
如果一个人有野心，又有执行力，那就是真的有格局。可如果一个人只有野心，没有魄力，那真的就只能等天上掉馅饼才能成功了……更好的总结自我、认真做好未来规划，以身作则，带头拼搏，才能带领大家将梦想变为现实。
一次采访中，阿里巴巴高级技术专家张磊分析了 Kubernetes 的本质，他指出，“Kubernetes 本身是一个分布式系统而不是一个简单的 SDK 或者编程框架，这本身已经将其复杂度提升到了系统级分布式开源项目的位置。
而对于 Serverless Kubernetes 而言，最重要的一个概念是将容器的运行时和具体的节点运行环境解耦。用户无需关注 node 运维和安全，降低运维成本；而且极大简化了容器弹性实现，
那我们再看
一下每个对象的业务操作和其本身的一些行为是否会影响其他对象，是不是强关
联的。很多业务对象事实上都有关联关系，但是在业务流程和交互上有先有后，
在用户操作的这个领域
来说他就只有几个节点，这些节点还包括商家接单，商家把单子告诉厨房，厨
房准备菜品，做好了外卖员要么在取餐的路上要么在等餐的路上，
然而，当我们稍微想让我们的命令行功能丰富一些，问题开始变得复杂起来，比如，我们要考虑如何处理可选项和必选项，对于可选项，如何设置其默认值，如何处理子命令，以及子命令的子命令，如何处理子命令的参数等等。
在开发有子命令甚至多级子命令的工具时，我们经常面临到底是选择 cmd {resource} {action}还是 cmd {action} {resource}的问题，也就是 resource 和 action 谁是子命令谁是参数的问题，比如 Kubernetes 的设计，就是 action 作为子命令:kubectl get pods ... kubectl get deploy ...，而对于 action 因不同 resource 而差别很大时，则往往选择 resource 作为子命令， 比如阿里云的命令行工具: aliyun ecs ... aliyun ram ...
回想一下，os.Args 这个数组里的参数有很多，这些参数跟命令中的变量是没有直接关系的，而 flag 提供的本质上是一个键值对，我们的代码中，通过把键跟某个变量关联起来，从而实现了对这个变量赋值的功能。
