如题,一些小结:

软硬实力 #

软实力: 沟通是为了解决问题,不是为了解决人, 如果问题出在人身上,则要看到是不是制度上存在问题进而更好的完善制度; 如果纯粹是为了解决人而气急败坏大概率得不尝失(以自身经历看,更会失去人心)
硬实力: 从开源中学习,身边的同事请教(可遇不可求),多留意观察, 理解,体会,输出,反馈开源; 思路是这样,比如WAL,promethues metrics监控

一个技术人员应该把解决问题的原理讲得简单易懂 #

如果一个技术人员不能把解决问题的原理讲得简单易懂,那么还可能他对这个技术并不了解或者说对其中的应用场景,并不了解,大多数要么只是照搬书上的言论,要么没有实际应用经验,要么没有结合这两者实操(多数人可能属于这种)。
比如一个正面的例子,拿WAL(write ahead log)来说

“如果每次写的log都在,怎么做到基于这些log做回放的问题？
其实就是redo-log + checkpoint + LSMT.
redo解决数据不丟,checkpoint解决,
recovery的时候扫描的redo尽量少,
LSMT解决每次写入后新的page不会覆盖老的数据,
这类实现是比较简单可行,也是目前的主流做法”

来源博主
短短一句话道出了日志在数据库中重要作用的实现原理。

对比来说,拿自己来说目前在项目已经实现使用的先写日志再入库的方式,其实用专业的名词就是WAL但是我之前并不知晓,这也是摸着石头过河不多参考行业资料的一个弊端,双说,自己满足了解决数据同步异常可恢复的情况,但是要想我更专业的方向去看待的话,还是得多看多参考行业的说法,然后总结加以引用,其实做技术落地研究就像写论文那样专业。

也比如 都说raft比paxos理解容易，但是我比较认同，这篇文章中的观点可靠分布式系统-paxos的直观解释.

有一句古话叫做：”学而不思则罔,思而不学则殆”,多思考,安排好,有目的的去行动和效率大增,有安排,哪怕只有30%或者70%的安排,比没有安排的去做,要好得多省时省力。

先解决主流问题,未想到或者其他边缘的问题后面再优化 #

像这种情况可能是大多数人(特别是部分外包以及中小公司)的实际操作,目前的主要问题解决了后面的问题,受限于当事人的事野或者认知能力,可能会存在一些隐患,但也是一件不可避免的事情,但是那些未想到或者边缘问题如果在当前场景下产生致命的缺陷,就是当事人的责任了。所以每一种解决问题的方案,都应该加上应用场景和限制以及不可预知的提示说明。
比如说,像产品预研多数只是想把功能做出来能演示的一个程度,而其他的一些bug,或者应对大迸发的问题那就是跟往后面的事情了,像一些大的产品发布会apple上面的功能演示,主要功能先出来而小问题很可能就出现在当时的现场中,但是人家也会标明,这只是一个beta 版,或者preview的版本。
技术是解决特定场景下的问题,没有最好的技术,只有最适合的技术。在满足需求和场景的情况下,技术实现越简单越好。

项目上的技术原理不总是最难的,归结于制度上的灰色操作,难的是沟通对接环境数据打通 #

投像gov类的2B项目,投标只是一个过场, 关系利益才是魔鬼,这种现像不管慢大城市还是小乡镇,到处存在。在这种环境下积累技术比较很务实以至于平庸得不像软件工程: 特别是对于小公司(做事讲究效率)去对接大集团(沟通成本很高,层层传递) 以至于小公司里面搞得 说要就要,多数没有合理的安排可言,搞得做事的人身心容易疲惫,不全是,但比较普遍