https://zhuanlan.zhihu.com/p/68012293
REVIEW：この記事では、専門家のエンジニア劉テンセント超著者である、我々はこの記事によって認可公開し、シニアエンジニアの考え方を紹介を取る、私はあなたのインスピレーションを願っています。
我々は、我々はファームヤードを求めているしているが、私たちのラインと農業は程遠い、私たちはプログラマを求めているが、私たちの仕事は、書き込み処理中だけではありません。私たちは自分自身を呼び出すことを好む：エンジニア。
我々は、それが基盤だった、それが行うように設計された、このライン及び伝統産業における分業が好きなフレームワークが行われていた、それが注ぐ行われた、一部の人々は芸術を行います。私たちは、人々の生活を変えるために、仮想世界で高層ビルを建設、世界を変えます。
世界の急速な変化の顔は、我々は混乱を持っています。
彼らは価値を創造し、コア競争力を維持し続けることができることを保証するために、もし？技術が変化してきますが、物事の態度いるが、実際には常に同じです。
自己修養のエンジニアの過程において、常に態度の3種類保つ必要性：当事者意識、卓越性の追求、議論を。
所有権
所有権のネジVS
私は、ビューのキャリアのポイントを聞いた：「小さな会社は、行使大企業は、ねじを行うことです選択する能力である選択を」
小さな会社の段階では、所有権のない感覚が十分ではないんですが。これほど多くの人々の数は、私たちが模索されているので、誰もが次のステップを取る方法を知っていません。
確かのようなネジで安心「他の誰か、誰か計画プログラムの責任を負う」かのように大企業でも、ステージ、チームリーダー、リーダーがあり、見えました。
しかし、今、全体的な人材環境は、エンジニアにネジのみを許可していません。まず、仕事の分類は、第二は、性能があり、第3は、人の移動です：ネジのみを駆動するエンジニアを満たすことができない、少なくとも3つのものがあります。
ほとんどのシナリオでは、従業員のリーダーとしての当事者意識を持っているのが好き。人のエネルギーが限られているので、考えるシェアこれらの懸念を助けるために誰かを必要とするすべてのものを計画することは不可能です。
成熟したチームは、成熟したピラミッド状の構造体が存在する必要があります。ピラミッドのすべての中間ノードのバックボーンは、あなたが物事を行うためのイニシアチブをとる、彼らが責任を負うために、チームのために、これらの懸念を共有することができ、独立して動作する能力を持っている必要があり、プロジェクトの所有者です。
仕事への所有権の態度
自社製品を設計するだけでなく、製品と、多くの場合、製品をTucao。ビューの所有ポイントに製品がなるように、ユーザーが満足していない場合は、エンジニアとして改善するためのより良い方法を提供するために、どのようにあるべきだと思いますか？
必要性は、データの観点から、ユーザーの行動のより包括的な分析を与えることができるように、補助的な製品の判決、エンジニアは迅速試行錯誤アイデアの様々を試してみプロダクトマネージャーを支援する必要があります。
でも、いくつかの場所では検出プロダクトマネージャーが存在しない、主導権は自分の提案を前方に置きます。多くの場合、知識構造エンジニアやプロダクトマネージャーは非常に異なっている、作るために必要な認知ブラインドエンジニアの製品が存在することになる可能性があります。
深さの研究動向では、多くの製品は、アルゴリズムを駆動しています。所有者のように考えるための角度は、エンジニアが深学習環境にすればよいですか？アルゴリズムは、算出ストリーミングセクション深さ、ならびに分散ストレージ、分散コンピューティングを、学習に加えて、製品を解体するためにドライブ、分散検索、データマイニング、高性能分散サービス、ネットワークセキュリティ、および他の消費者製品フィードバックチャネルでありますそして、非常に多く、多くの側面を検討します。
エンジニアは深い学習支援として活躍されていないが、製品に良く機能するように学習の深さを助けるために。
卓越性の追求
仕事の選択のエンジニアのほとんどは、需要が、そこにある「進歩したいと考えています。」いくつかのエンジニアと私は彼が無駄であることを、理由は特定の理由のチームだったこと、過去に訴えている。私は答える必要があったことは無駄ではありませんした精神で「卓越性の追求」を持っている場合です。「卓越性の追求」するので、個人的な態度です。
継続的な学習は、独自のものです
当社は、情報爆発の時代に住んでいるが、なぜ急成長している業界インチ 新しい技術が登場ほぼ毎年は、その後、彼らはすぐに陳腐化します。インターネット業界は、本当に後ろのボートに乗っています。
だから私たちは学ばなければなりません。最新の論文、最新のオープンソース技術、コミュニティ技術の更新：学習の目標は、いくつかのソースがあります。
研究者のために、紙を読んでありふれたものです。しかし、エンジニアのために、多くの人々が新聞を読むことを知りません。実際には非常に多くの論文毎年エンジニアリングの方向。
そして、記事の古典的な作品方向の一部は、GFSとして、日付に容易ではありません。紙を読むことは良い方法ですが、すべてのエンジニアは、自分の嘘の分野の最新情報を知る義務があります。
Githubにありがとうございました、オープンソース技術は、強制収容所にあります。GitHubの上で高つ星の評価をプロジェクトとコミュニティの形成を議論し、彼らは一見の価値があります。でも復興の古典的なアイデアの新しいオープンソースの後に、新しい外観があるかもしれません。たとえばElasticSearchのために、彼らは技術と何も特別な、分散ストレージを使用し、Luceneのは非常に古いものです。使いやすくelasticsearchに再組み立て、非常に明るい、非常に使いやすいです。
国内现在技术社区非常多，个人比较喜欢的是CSDN和知乎。CSDN是大杂烩什么都有，知乎上经常有一些牛人整理好的某个方向成熟、有条理的好文。常混社区，了解现在流行什么，大家都在讨论什么，有助于开拓思路、开拓视野，获得灵感。
建议大家看一看周围4级以上的同事，看看他们是怎么学习的。如果比你优秀的人比你更努力，那你该怎么做？
打80分还是100分
我们如何衡量一个系统的好与坏？大多数情况下，一个系统满足了现有需求，就是一个好系统。但是在实际工作实践中，并不存在一个“需求封闭集”，需求永远在变。
一个优秀的系统，必定是一个可发展的系统，可以应变的系统。如果给“完成现有需求”打80分，那么“考虑未来需求”才可以给系统打上100分。
有些工程团队发声，手上的事情已经做无可做，想要做新的事。这让我非常的惊讶。怎么可能“做无可做”？
现有工作已经做到非常“卓越”了吗？考虑一下功能可扩展性、考虑一下性能可扩展性、考虑一下运维的复杂性、考虑一下可迁移性和可复制性、考虑一下节省计算资源、考虑一下我们的竞争对手是怎么做的？
在系统中去发现优化点，去探索新技术将其引入系统中。永远不满足于80分，去做100分，是追求卓越的态度。
追根究底
知其然也须知其所以然
大家在工作中是否遇到过如下几个问题：
- 因为历史原因，某程序大家都在用，运行很稳定，但是没有人读过源代码。
- 某个服务，缓慢内存泄漏。于是写了脚本，每天低峰期定时重启。
- 线上报警多了，通常情况下报一阵子自己就恢复了。
- 线上模型修改了某个参数，效果突然就变好了。
如果单纯只看结果，可以知其然不知其所以然，不去深究。这些问题就像是不定时炸弹，可能一直不出问题，也可能在未来的某个时间引爆，影响了工作。积累的类似问题多了，炸弹引爆的概率就会越来越大，偶然变成必然。
我建议大家能够以追根究底的态度去面对每一个问题，在追问题、解决问题的过程中，会学到书本上学习不到的内容，技能（通过实践掌握）得以成长。
下面我举几个案例：
案例一：我追过一个线上偶发Coredump问题。因为Coredump后实例会自动重启，而线上同时有几十个实例，所以优先级不高。
在忙完手上高优问题后，我专门找了一个晚上仔细追查。最后查到是主程序依赖了某个库X的a版本，而动态链接库依赖了该库X的b版本，在某个特定处理逻辑下因为不同版本逻辑不一致会导致Coredump。从那以后，我在使用动态链接库的时候就会非常小心，一定会排查一下主程序和动态链接库的编译依赖，尽量保证主程序和动态链接库在同样的环境下联编。
案例二：线上某个服务缓慢内存泄漏，所有使用指针的地方都是shared_ptr，常规代码Review无法发现原因。
于是我采用了“代码二分查找法”，注释掉程序一半的逻辑，mock掉程序所有后端，然后使用压力工具发压力。最后发现是部分缓存数据在异常情况下缓慢增长，且永不过期导致的。
案例三：线上某个服务，在序列化和反序列化过程中，C++ Client的反序列化很稳定，而Golang通过cgo调用C++ lib的时候反序列化很不稳定。
经过排查代码发现C代码实现里的序列化/反序列化过程是将一段内存直接赋值给了一个结构体。因为内存管理过程中，Golang和C++差异，导致了对这块内存的解析存在不稳定偏差。
每次追问题都学习到了新的知识，并且知道在未来遇到类似情况该怎么办。积累下来的经验与技能，将成为了一个工程师的核心竞争力之一。
Bug侦探
追问题有如探案一般，都是根据现有线索去追寻“真相”。计算机程序的世界是完美的逻辑世界，每个问题、现象都能找到原因。
先要有逻辑的信念，然后要有追根究底的态度，下一步需要的就是具体的“探案”方法了。
前面提到了一个“代码二分查找法”，在很多场景下都适用。还有其他有效的方法：
- 善用各类工具：包括但不限于：代码阅读工具，版本管理工具，代码检查工具，压力测试工具，性能分析工具，内存泄漏检测工具。
- 常用原则：看到递归就要想到用循环去重构；看到循环就要考虑是否会死循环；看到数组就要考虑是否越界；看到指针就要考虑是否正确析构；看到多线程就要考虑是否线程安全；看到频繁内存申请就要想到内存池。
- 了解内在原理：函数调用时栈的状态；对象析构的时机；高级语言中的可变对象与不可变对象；Map/Set/HashMap的存储结构；Map Reduce的原理；文件分布式存储的原理；画出完整的模块关系图和数据流图。
- 不放过任何Warning/异常：写出无Warning的代码，包括编译的Warning和各种检查工具的Warning；合理打印Warning日志。
- 善用搜索：能够从国内/外站中搜索问题。
- 记笔记：将每一个问题的追查过程记录下来，定期回顾与分享。
追根究底的产品观
追根究底的态度不仅仅适用于问题追查，产品上也是一样的。数据浮动的背后是用户行为的变化，这个变化可能存在某种诱因。
熟知的诱因有周末效应、月末效应等，但还有很多诱因是不知道的。对数据、对用户行为追根究底，有可能发现某个新的产品突破点。