方法和实践总是相辅相成的。
粗调与精调
adaptive refinement mesh
https://en.wikipedia.org/wiki/Adaptive_mesh_refinement
简单的问题，如何用最少的次数测一个球在几楼的时候被摔碎
参数调优的问题，先采用大的span确定范围，然后在采用小的span细致调整。
分类的思路
最近上了一些dp的课程，在理解题目背景的情况下，解决dp问题的核心是用到两个思路，一个是后向考虑的思路，也就是说最后一步是什么样的case然后从后往前推理，还有一个是分类的思路，对于最后一步的case采用分情况讨论的方式进行进一步分析，有时候分类讨论可能需要加上更多一个维度的数据。分类讨论常常是能让推理再进行下去的一个常用手段，有的时候找不到方向了，或者不知道当前自己研究的问题到底是个什么，这个时候就把自己已经知道的内容放在大的picture下面捋一捋，然后问问自己每个分叉的枝叶上的内容有没有考虑清楚，这个时候就可以发现没有考虑清楚的枝叶，有的时候甚至会发现一些模糊的枝叶和可能长出新的地方的枝叶，这个时候就容易找到目标和方向了，在科学的大树上的某个细小分叉上，你就可以做出自己的contribution然后为了这个大树的茂盛做出自己的一点微小贡献。再YY一下你可以说自己是人类知识大树的园丁或者是知识之网的编造者，或者有时候想象人类的知识是一个巨大的蜘蛛网，看也看不到边，你是上面的一个小蜘蛛，有的小蜘蛛会学一些捕食技能，利用这个大的蜘蛛网抓一些昆虫，安安稳稳，生活的更好，你更愿意走到蜘蛛网的边界的地方，想办法让这个蜘蛛网变得更牢固一些，或是再把这个网的边界拓展拓展，边界的地方可能不太安全，看不清前面一不小心有个风吹雨打也容易掉下去，可能因为考虑怎么编那个蜘蛛网就耽误了学习打猎技能的时间搞不好还会饿肚子，但总体来看这个工作一旦做出来就是有价值的，可以为更多小蜘蛛来继续服务的。
对一切编号Index
显而易见的地方就是关系型数据库中的主键 就是id 作为index
在分布式系统里或者是多线程的程序 也是习惯上给每一个thread一个id 通过id找到对应的thread 或者 program 之后许多operation都需要在id的基础上进行 比如说partition 某个id对应的thread会去处理某一块的数据 等等
关于手段与目的, 具体技术与使用场景
cs本身的知识 还是说cs在某一个场景下的应用
论文与知识，无限与有限
论文的数量是无限的，只要人类在发展就有新的知识产生，但是知识增加的速度赶不上论文增加的速度，好多论文是在使用过去的知识的基础上然后做了一小步的工作，看论文的过程并不是说看过了就没事了，应该是focuse on constructing knowledge topology然后没看一篇论文把topology更完善一点，这样也能从整个topology的更大的视角上来衡量这个论文的整体价值。
对于考虑某个工作的价值在哪里的时候，最容易的一个问题就是:如果没有这个工作，将会怎么样，是不是某个事情没法做了，是不是某个数据不够好了等等。
量级优化的核心
找出重复的计算，减少重复的计算，具体减少的过程可以通过优化数据结构来达到减枝的效果，或者通过近似计算，降低一些精度来通过牺牲20%的准确度来提升80%的时间效率。优化的目的更care的是数量级的优化，比如从 O(n^2) O(logn) O(n) 这样的优化比较有意义，那种常数项的优化意义并不是很大。特别是并行的case，在很大的input数据下通常才能看出效果，要是数据本身比较小，那时间复杂度就并不是一个有意义的metric
从naive的方式开始
很多时候不知道自己在做什么，特别是某个research方面的问题，然后常常会是止步不前。难以定位问题，move forward 这个时候就回到一个状态就是问问自己，naive的方案是什么。已经用了几次，基本尚可，因为好多时候不是在解决一个新的问题，而是在优化原因的问题，只要往general了说，似乎没有什么问题是新的问题，这样就比较好地能确定下来自己的motivation，之后再考虑考虑naive的方案能不能实现，这算是前进了一步，通过naive的solution大致就能明白自己的task是什么了，然后再想naive的方案中哪里有不足的地方，就能进一步优化，然后明确一些细节，看看距离target的方案在哪里，这样就能一点一点move forward然后明确自己做的东西的大致方向而不至于在原地打转。
就好比你爬一座山一样，站在山顶往山脚下看，感觉是一个巨大的飞跃，但是从山顶的最高一级台阶看倒数第二个的台阶，却又是很微小的提升和改进，所以似乎一下搞个大新闻这种思路并不是很现实，大方向在那里，点滴积累走一步看一步可能是比较显示的改变。
类似的一个是从上一个成功的地方开始，通常我们想build一个复杂的系统，一下走的太多就容易lost control 比如好多错误不知道是从哪里开始的。这个时候就应该简化调一个模块，然后看看是否work，然后再简化掉一个模块，直到系统work为止，然后把这些模块一个一个加回来，这样就容易定位错误原因，不至于迷失在各种bug中。
系统性思维
其实和分类的角度有点类似：
https://thesystemsthinker.com/systems-thinking-what-why-when-where-and-how/
把整体打散成不同的维度 之后从每个维度单个地去看事情 每次只是从一个变量的方向对事情进行比较 之后把不同维度组合起来 从整体的角度来分析一个事情, 好处就是不重不漏比较convincing，特别是对于general的case，和别人讲起来也让人觉得是有章可循，特别是对于research的角度，systemitical的thinking就是容易把所有的cases都平铺地展现在眼前，然后很容易地了解到哪些做了哪些没做，对于问题有全局的把控。
What assumption and using senorios
这也是一个generate new idea or research paper 的角度，特比是system的层面。对于system的层面，好多的系统已经存在了，甚至大部分场景下都有相关的系统，那research如果才能move forward？一个case就是考虑一下这个system的使用场景是什么，还有assumption是什么，vary一下的话看是否能够支持更多的场景。比较typical的例子就是redis distributed design strategy的设计描述。 首先要列出我们这个system是要在什么场景下工作的，所以我们才这样设计。要是想move forward的话，就是横向地扩展，变化了应用场景，类似的system应该怎么样设计，然后就出来了新的paper。
Consider interface first
最近在看一本philisopy of software engineing的书，关于interface的部分大概是讲，interfaces should hide more information and easy to understand。比较好的设计比如最近常使用的adios就符合这样的特点。get put 两个interface简单的很，但是hide了很多complex implementation engine。在和别人讲这个system是怎样怎样的时候，dive into details之前就是具体介绍interface，或者自己首先要把interface想清楚，这样才能让别人很快的明白自己想要做个什么事情。比较好用的方式就是那种time sequence来表现出control flow
Paddding and alignment
比如struct的空间优化问题，本质上是牺牲一点存储空间来达到高效的access的目的。
比如MPI gather message的时候，不同的 process 会使用相同大小的存储空间。
就类似于快递物流都是使用标准化的箱子统一运送，虽然有一些空间上的浪费，但是标准化之后会方便整个流程的操作
This is also typical when we set the header part of the file. For example when we write sth into a file, the length of the header is always fixed. This part can contain more informations about the actual contents. Maybe there are some resoundant space in this part, but it is necessary to make it fixed.
The namespace and the isolation
It is natual to scope your code or things to do into a specific space, or privilage. For the program level, when you create a class, you may make some varaibles or some functinos private and make others public. For the program level, you may need to use the namespace to scope the avaliblity of the varaible to avoid the conflicts with other system library. Even if there is no capability of the namespace for programming language such as c, we may set a scope prefix manually such as projectname_var1. This is because it is easy to confuse the name with other libraraies, there are some common keywords such as file, memory, which are used widely in different libraries.
Load balancing
关于load balancing的思路，能用到的地方确实有很多，这里记录一下常见到的case。generally speaking, we assume that the balanced work for multi process is more efficient 如果每个unit处理的task 都平均，这样就避免了load imbalance 避免了有的process运行的快，有的process运行的慢，这样就容易导致整个system运行的慢。
这样来看, load balancing可以看做是一个goal，之后具体情况来看还有不同的assumption, 比较关键的两个是 task是否均匀，work unit 是否均匀，如果两个都不均匀就是比较复杂的load balancing的操作，如果两个本身都是均匀的，那处理起来就比较容易，只要保证每个process或者work unit处理相同数量的task。比较常见的是work process是相同的,比如都是一样的process或者thread，data或者task的性质不同，这个时候就要根据具体的情况来看，让复杂的task和简易的task能尽量均匀地分发给每个processing unit。
Increase dimention/decrease dimention
通常情况下，想让一个东西变得更复杂或者尝试考虑得更全面一些，就从低维度映射到高纬度，看看是不是有些因素没考虑清楚，在高维度下，不同的分类dimention就变得清晰一些。另外一个就是有时候也用到从高维度到低维度的方式，比如embedding，或者总可以把一个多维的表格在二维的情况下展现出来，这个时候需要考虑的就是，添加冗余信息是否可以忍受，或者是哪些因素是主要的分类因素，映射上去是有一些区分度的等等。
How to understand a new software system or introduce your system to others
The hierarchical architecture is the natural idea in the domain of cs. When you discuss the system, you may first divided it by software system and the hardware system. Then for the software system, you may consider it from the aspects of data flow and control flow (data management layer/middleware layer and application layer). Or maybe there is a lower level layer such as communication layer. Anyway, by describing the system from these aspects, you may figure out it quickly. Or when you try to introduce your system to others, it is natual to consider things by this way. And the introduction can be also in a systamatical way. It is much easier to describe your contribution or what you work on by this way and to see it’s location in the whole system.
