t/719560#reply24

11 楼，和 23 楼， 虽然题目是提高自己，但是实际上，code review 的时候，附上设计文档的内部 wiki 链接之类的。。。是一个很友好的做法， 很容易让大佬挑刺。
最后看看设计文档没问题， 实现大约 1：1 就可以过了。

最小费用最大流

@solider245 后缀的目的是人为表述规则，也就是人为规定就行，但是 linux 的文件管理不是强依赖后缀名。
用过 git 吧？ .gitignore 这文件类型是啥？ 前面的. 就是表示这是个隐藏文件，linux 规定以.为开头的是隐藏文件， 那么请问后缀是啥？ 因为文件名本身已经是规则了，那后缀就没啥意义。

或者你看一下 Makefile，请问后缀名是啥？ 又一个文件名本身就是规则的。

windows 里表述可执行的后缀是 exe 么？ 那 linux 里可执行是怎么表示的？ ls -l 看一下，有没有可执行权限就好。

综上，个人观点：“后缀名只是文件用来表述规则的一种方法而已， 而不是后缀名就是一切的规则。”

===========================================

以下是一些可能是错误的认知经验：

愿你能理解我的表述。另外，理解系统的设计哲学之后再对比映射就好。
比如 linux 的设计哲学之一就是“一切皆文件”， 设备也是文件（ cat /dev/ttyusb0 就可以读取 usb 串口，而不是 windows 那种打开一个程序-比如串口大师什么的，然后再解析），属性也是文件（"cat /proc/cpuinfo" 就是查看 cpu 属性）
诸如此类的还有流这个概念，引发出管道，也就是 UNIX 设计哲学里一切都是精简的可服用的小的模块，这个看看《 UNIX 设计哲学》还有一些相关的材料，愿你可以很快理解

windows 设计哲学比较复杂，但是有一个是“所见即所得”，一个是窗口化，所以有了常见文件类型映射固定图标，以完成这件事儿，即见到这图标，就知道这是个什么类型的文件。 （这是一种感知 /交互的 规则）

如果这个事儿，换到 ios 上，你会发现，又不一样了。。。。

操作系统是门设计艺术。 套用不同体系下的规则去相互理解，有很多时候百害而无一利。

@DarkCat123
方法不绝对，我只是说其中之一，还有一个东西就是，提前写设计文档画 UML
我一般要求自己和带的人用 markdown + mermaid 反复画状态转移图， 和状态流程图，和业务流程图。

第一步 ， 后先审图， 一般一个事情， 三图合一（互相验证没有明显看出来 bug 就基本 ok ），但是一般 3 年以内工作经验的， 都不用 review code，直接 review 这种图，就能发现一堆未考虑的点以及 bug，或者 case by case，抽象做的不好， 图巨大务必还很难看。 这是第一步。 把东西想清楚想明白。 一般都是 keep it simple （设计可读性 + 设计复杂度）的一个 trade off
新人 审 5 轮，老人审 3 轮。 防止出现设计完全是 bug，或者实现出来，没几天就推翻重写重设计（这个很多软件工程的书里都写的很明白，比如人月神话之类的，越早期的投入，越降低之后的投入，这里越少的投入，后面投入是指数级上升）

第二部， 写代码，写完代码 review， 一般来说 5 年以内的工程师，自己熟悉的领域不会出大问题（ 3 年左右，还是会出现设计没考虑到实现不好做，或者写代码的时候发现欠考虑了），能做到设计文档和代码 1：1， 但是， 如果有新领域和跨部门配合，还是会出问题。 review 代码的时候，让其自己的设计文档和最后的代码实现进行 PK 。

一般来说，会出现几种情况（设计文档里命名和代码里不一致这种低级错误，推荐第一次提示，第 N > 3 次直接考虑劝退或劝跳槽, 态度问题无关工作经验，起名都没法 1：1，我怎么能信得过代码实现和设计 1：1 ？）
1. 手懒，实现的简单，设计了但是没实现或者弱实现
2. 想多了，代码实现的时候，过度设计
3.设计能力大于实现能力， 设计的很好实现不出来 =>增强一些奇淫巧技和代码套路的学习
4.实现能力大于设计能力， 代码里充满了奇淫巧技，做复杂了 ， 很难和 2 区分，需要 review 的人个人能力碾压，才能识别出来， 这里需要考察代码 readable，更高维度的 readable 就是看了设计文档很轻松能对应上代码段， 这里一般是更高维度的 DRY， 因为他们 Repeat 的是之前的小范围的实现方式

12 其实是 34 的低级版本，其根源就是设计和实现阶段的脑力和体力的输出配比不均匀，我个人认为工程师代码讲究的是设计和实现的期间脑力和体力的持续稳定输出。 减少心血来潮，和状态不好的随意 /敷衍输出。

做到这点，基本上，代码这边儿就到头了（单纯字面意义的代码，不包含背后业务水平、管理水平、人力架构，项目架构（类似于怎么在合适的时间、合适的项目进度进入合适的人）这些东西）

怎么说呢，时间是检验真理的唯一标准，实践是学习和成长的最好途径。

除了历久弥新的《重构》啊还有《架构即未来》这一类理论书籍，我其实推荐是看完之后，套用一些方法，去整理“屎山”，跨过“屎山”

一般来说，自己的“屎山”最好处理，另外达到什么水平才算满意呢？
长久使用不需要打补丁是一种检验方法，“或者”最好能达到“并且”，升级功能的同时代码量低于线性增加（比如基础版本 5 个 feature，100 行代码， 后续连续 3-4 次升级每次 5 个 feature，代码到 500 行了，然后新增功能前进行重构，能达到代码行数-100，新增功能，5 个 feature 只用了 50 行就搞定了，甚至，最后没增加行数）

另外，强迫自己，任何时候，任何规模都都能做到 KISS，DRY，你会发现越来越费神，来找出来一个优雅的方式，解决当下的问题（重构），久而久之，基本上可以做的很好。

首先如果面向收入编程的话，则“流动性越好，技术越通用越不容易被压价”，“越不容易流动的同时，越容易形成技术壁垒的，越容易产生溢价”，“个人成就随行业有加成 /或 debuff”。 这三条觉得 OK 的话，往下看，否则当我白说

首推，猿辅导 infra
找工作按照之后跳槽普适性，看 3 年后，以发展角度看问题，infra 一般很容易做成，然后跳槽价值可能好一些。
做 infra 可能是最容易后续逐渐成长成架构师得思路

抖音后端和腾讯后端， 通用性也好一些，但是大厂就大螺丝钉，3 年熟练工种的话，运气好小 lead 业务经理，运气不好，hum，熟练工。

网易游戏个人建议不要选，3 年后，头发不保，而且流动性，呵呵，3 年后你平薪或者降薪来转行做别的的时候，呵呵。围城，你知道啥意思吧。游戏行业是个抽奖抽彩票行业。

苏州微软， 如果你现在有 50 左右的副业收入，完全可以考虑（你能这么拿 offer 我觉得有概率可以这么玩的）。 主业的话，去查查苏州微软有多闲，呆 3 年，说实话我觉得自己一直做什么可能还行，否则的话，容易呆废（大概率），当然具体也看谁带你，而且就算苏州微软被裁，好歹吃相也不会太难看

当然如果有一个不错的人带你，而且平台还 OK，以上都是放屁。

另外类似的视野看看 5 年， 或者 10 年。 也要看看你想哪年结婚，哪年达到事业顶峰，哪年要孩子，和哪年 ICU 。

序列化之后对象存储， 有点儿像标注数据的原始数据或者是数据，随便儿用个 HDFS，然后进行块备份就好。
因为搬运和存储是整块数据，copy 起来速度快， 然后直接切片存到冷备份对应机架，然后对应机架只能特定 IP 和端口访问，冷备份就是 copy 完，拔硬盘就完了，当做热备份也行，做好数仓和后端的割裂就行了，我一般做法很土，就是对后端只有写接口，没有读和删改接口。改请人工到另一个内网位置提交修改就好，然后人工审核后 prove 进去（大规模的，就直接敲黑板找老板说行为非法）。
然后如果需要查询，就直接再后一级做一次脱敏， 身份证后 x 位直接抹掉（简单的 opencv+打码），头像打码， 地址打码，打码程度视脱敏规模。