大規模なテクノロジー企業は、コーヒーを共有する - ポストスクリプトを
この日の午後は、企業内のバックエンド技術開発者が7人、ないより多くの兵士の合計を共有します開催され、3人のコーヒーHuawei社シニアプログラマーを、それを書き留めて、今私だけの思い出を、私たちと一緒にそれらのものを共有するために、希望をヘルプのキャリアの後。
私は、共有コンテンツは、三つの主要な点に集約することができます思い出してください。
1）それらのものの設計文書について、
開発経験の10年よりも2）大規模なコーヒーを共有すること;
3）お互いに共有することが、意見や提案を前方に置きます。
設計文書についてのそれらの事：
1は、設計文書は罰金に粗いから、出て高速化するためのソフトウェア開発は、確かに、完璧ではない破壊発見・エラー処理ではないという事実を受け入れるようにソフトウェア開発を行う、共通の問題は、その完璧主義（特に初心者です）。
2、ある程度を達成するための設計文書、実際には、次のように、主な構成要素ルーチンである：
アーキテクチャ：データモデル、インターフェース定義、
プロセス：通常の流れ、異常なシーン、デザイン
クロス影響：構成インタフェース、データベース、信頼性、性能、等。
3、設計文書は、最も重要なシーン（プロセス）である：通常のシーン、異常な光景。
4、設計文書には、実現可能性の探求を持つことができます前に。
5、設計ドキュメントの利点：
。混乱をコーディング強制思ったシーン（CASEは、シーンの本質である）、よく書かれドキュメントは、;
Bコーディング、インターフェイスのドキュメントとテストケース、すべての出現などの開発プロセス全体を通じて設計文書を、導くことができます。問題は、バック設計ドキュメントにさかのぼることができる;
。設計ドキュメントのうち、C、エンジニアリングは、（その詳細を達成するために、である）エンコードすることができ、
繰り返し考えて自分自身を思い出させる理解を深め、より良い実装を求めてdが。
6は、設計文書が欠落しているデザインシーンでの最も恐れている、速やかに問題の後、問題が早期に発見することができ、我々は、そのような場面を逃した独自のデザインとして勧告を、読むことができます。
7、文書は完全なガイダンスコーディング、インターフェイスのドキュメントとテストケースを含め、彼らの次のステップを導くために設計されていますが、見てのリーダーシップに対処されていません。
他の人は、彼らが自分をよりよく行うことができます前に、自分自身を楽しみに自分の意見を置くことができる理解できるように、8、詳細に記述された設計文書、さらに少ない異常や設計上の欠陥があります。
図9は、内部の概要設計書によって、深さ、（主要な機能の点の文書のデザインを含む）のリストを概説建築することを忘れないでください。
10、設計文書を書くことは、それを使用していませんか？ドキュメントは、あなたが漏れないポイントを開発確保することができ、設計ドキュメントのハイレベルを書き明確な、高レベルの人々は、そのようなので、上のHTTP、RFCととして最高水準を、書くことです。
11.なぜ調査基準？例えば、二つのドッキングシステムは何に基づいて変更し、変更するには、行う方法の問題、ありますか？契約書を閲覧することで、合意はそう、あなたが変更に合格する必要があり、その後、通過することができないフィールドの定義を定義することが判明しました。
12は、ライティングスキルの設計文書は、まだ自分自身を助けるために、表現の明快さを要求されると、他の人が理解することができ、かつ、タイプミスがあるとは思わないの書き込みは重要ではありませんが、個人的なイメージは、（一つだけで、あなたと上司と一日の書き込みであれば設計文書）。
13は、実際には、設計文書は、ハード物事が設計する正常と異常なシーンに対応し、達成するために些細な事に分解できる分解ステップに対応しています。
14は、設計ドキュメントのエンコードが完了した後も、最初の設計文書、大胆発行済株式彼らの設計文書、その後、簡単な開発を書く機会を持っています。
プロトタイプマップ（ローファイ・インターフェース図）を伴うことが14、設計文書、重要でないこと、また図面が鍵ん、いくつかの方法があります：
。プロトタイプ設計ソフトウェアは
ダウンロード：HTTPSを：// WWW。 mockplus.cn/は、個人のメールボックス無料版に登録する必要があり、
B Excelスプレッドシートを使用すると、プロトタイプマップを描く;.
アップロードするCの手書きドラフト描画、携帯電話のカメラを。
経験共有と意見や提案
1、経験から来る、すべてがうまくいけば、それは良いことですか？
すべてがうまくいっている場合、その値はゼロ成長となりますので、事は良いわけではありません。あなたはいつもCRUDを行っている場合は、作業の重複に自分自身を見つける、そして成長がゼロであり、関連する追加のポイントを吸収するスポンジのようにする必要があります問題が発生し、より多くの、より良いです。
2、知识技能体系，成长体系？
这些知识体系并不会因为你没有掌握和注意，该体系就不存在，体系实际是重要的成长目标牵引；比如MySQL这个体系，你也许会安装和简单的使用Mysql，但是比如Mysql优化和高级搜索里面的某些东西你不一定懂，而他确实是存在的，确实也是有开发人员掌握了的，此时自己要想办法覆盖这整个体系，完善自己的知识技能树。
3、问题处理是练兵的利器？
问题单处理流程实际上是处理问题的通用流程；问题单处理多了，你自然就会思考，这个问题为什么要这样子处理，为何是这个流程呢？然后，慢慢的这个东西就会融入了你的血液，成为你身体的一部分。
4、对于个人成长，当下最重要的是什么？
最重要的是结合当前自己的工作，填充自己欠缺的知识技能，出色的完成上级安排的任务；因为如果连上班8小时，本职的工作都做不好，还能在其他的领域有杰出突破贡献吗？工作的思考：不要重复工作，对于那些必不得已得重复的工作要搞出花来，比如很快地完成或是搞个工具自带完成等待；一些优秀的书籍会限制你认识事物的上限；刚刚毕业1~2年的小伙子，最重要的是自己要学会思考，多上上心；开发人员的基本功最为重要，同时要覆盖自己的知识技能体系，你的对手永远都只是你自己。
5、事务分解能力？
包括问题处理和需求开发，再难的任务都可以分解成一件件小事去完成。
6、作为后台开发人员，要怎么解决问题呢？
首先是问题描述，该问题一定是可以复现的，现象出来后你的定位思路是如何，然后你的定位过程是如何，最终你解决的问题一定是你定位出来的而且是能重现的问题。
开发人员面对问题时有两种态度：
1、遇到问题直接面对他，解决他；
2、遇到问题绕过去，绕过去就是上面所提到的顺不顺利的问题，如果绕过去了，就失去了一个成长的机会。
处理问题：
最重要的一点就是要先把问题复现，然后根据它的现象推测，有可能是哪些问题，再通过日志打印判断大概问题出在哪里，或是根据消息，查看消息里面携带的参数，看书在哪一步出的问题，正常的流程是怎样的，异常的又是怎样的，有可能是几种流程，大胆的猜测验证。
复现--->定界(前后端问题、哪个模块问题)--->推测--->打印、消息、日志、参数--->99%的问题都是可以通过Debug(本地Dubug和远程Debug)和日志解决。
杨总给我的建议是：性格调整下，多与人沟通交流。