レッスン12「プログラマへの学生から5分」。
バグやリワークを削減しながら、最後の時間は、我々は単にコードを終えた後、下に置く関数にしようと、自分の満足の機能は、ユーザーが、満足されます。あなたとこのレッスンの私のシェアはどのように自分の能力を向上させるためにテストを使用するには、さらにその位置を向上させます。
1.この記事では、あなたの決断は何ですか
我々は多くの技術的、どのようなスキルを持っていませんどのような位置、決めるが、何私たちの心はでいっぱい！心、エンジニア、そして私の心の主な機能は、中堅技術者、心のアプリケーションのモジュールで満たされている、シニアエンジニアである、と私の心は、企業の経営者で満たされています。
あなたはMyBatisの、彼は、Javaの、springboot、springcloud、MySQLで堪能非常に強力であると言う。でも、フロントエンドのHTML、CSS、JSも堪能。他の人はそれを信じますか？あなたは信じたり信じられないことがあり、その理由は？その他には判断できません。
労働のジュニアエンジニア果物主な機能は、平均以下のバグ率関数ならば、あなたの能力に非常に時間を示す、バグの機能が平均よりも高い場合、最も重要な指標を設計する能力をテストすることですので、あなたのことを示す、機能です非常に良いです。
平均バグ率関数が2である場合、あなたはひどい感じ、人々は親指う、あなたのバグ率が1であると言います。
2.職場の話は、原因と結果を表示するには
1話：私はチームがちょうどプロジェクトをやって設定するには、いくつかのチームを設定し、テストが私に訴え、多くの場合があることをスモークテストも機能しなかった測定を、提供渡すバグ、特に多数それはテストを投げた、とそうで行わ。私の懸念があるため、コードの品質が悪い、テストエンジニアは、より懸念し、単に品質の関数ではありませんので、それは彼らの仕事量が増加します。
2少し話：私は人々がこのプロジェクトに関わっ何議論するプロジェクトチーム、プロジェクトのビジネスリーダーの一般に、第1の決定、および、それらからを設定した場合。テクニカルマネージャーは、言った：私はジョン・ドウ彼ら二人を求めています。テストマネージャーは言う：ジョン・ドウはありませんが、彼は非常に真剣に物事を行い、彼はほとんど、我々は彼を望んでいない、常にバグを、私はそれが王5であることをと思い、彼は彼と非常に快適で、非常に厳格なやっています。
あなたが見るものは、ほとんどの人はまだあなたを望んでいない深刻なバグではありません。同社は排除の終わりを行う必要がある場合、第三行く排除するオブジェクトです。同社はちょうど完全に転送コング場所を持っているだけでなく、非クォータ王5場合。だから、あなたは、表面とテストの開発を参照し、8本のポールは彼らの後ろの事、原因と結果のロジックを打つことができなかったので、複雑です。
前面讲的都是职场上的故事，下面我们来看测试对我们技能提升会带来的帮助。
3. 技术的提升
你多测试，多试用，你就会发现，类似的界面，为什么师傅写出来的就比我好看？分析界面，甚至去看师傅的代码，发现原来是师傅采用统一的UI风格，自己是按UI设计图来做，UI上有标注的就做的好，UI上没标注的，自己瞎做。发现差距了，后面就懂得用UI规范了。
你可能又发现，同样的界面切换，我自己做的一闪就过去了，而师傅的是很平滑的切换，再一看代码，或向师傅请教，原来是他在切换的时候加了动画效果，后面就懂得交互效果的处理。
4. 产品理解的提升
像上节课发送文字的例子，在试用的时候，你可能就发现，app端做设计的时候，写的是4步，但是在第三步，我退出了聊天界面，那这个要怎么处理？试用的时候就发现，少了一个步骤，在还没提交测试前，那赶快添加对这个操作的处理，功能的完成度就更好。
之前分析的时候，暂时说这个功能跟其它功能没有关系，试用时就发现，在聊天界面，除了要发送文字，还要发送表情、图片等，那就跟其它功能有关系。在一对一聊天中，还可以调用通讯录，添加好友群聊，这些都有关系。
然后，就感悟到原来产品逻辑是这样设计的，师傅接到这个模块，他是怎么样把这个模块分成各个功能，然后再分给我们不同人做的。
这样，你对产品、对模块就了解了，是不是比你做完一个功能，丢给测试，等他反馈bug，再改bug好多了？
5. 我是做开发的，为什么要理解产品？
你可能会说，我是做开发的，为什么要理解产品？我们借用叮当猫的小口袋，把时间往后拉一年，张三成为了中级工程师，也开始带徒弟了，好兴奋的感觉。现在参与一个新项目，技术经理把中、高级工程师张三、李四、王五拉一起：“张三，你负责用户模块；李四，你负责商品模块；王五，你负责支付模块。这样安排有没有问题？” 然后张三站起来说：“老大，用户模块有哪些功能啊？”
これは楽しみに起こる、我々はシーンが面白かったか想像することができます。ミッドレベルのエンジニアが製品を理解している、一つの関数の中にモジュールを打破する方法を知っていることです。能力がどのように来ますか？一部の人々はそれを教えて？この機能は、ティーチに誰もありません、実際のアウト機能遊びの両方から、経験の蓄積です。
また、バーを備えた製品の開発の背後にある因果関係を見て、テスト、との因果研究開発の背後にあるこの顔トーク！一部は不快な因果単語を見たかもしれない、これは何の原因でないと効果があるif文、条件が満たされた場合、コードセグメントの実行が、これは原因と結果呼び出された場合。
6.バグが低自信をもたらす、自信、責任の範囲を拡大します
あなたが機能を実行する場合は、バグ率は、もっと自信他より少ないですね。これは確かにあります。あなたが自信を持って、彼らはより多くの責任を取って喜んではありません。そして、私たちが前に言っている、意思決定は、技術的なレベルのエンジニアのレベルではありませんが、彼は側面の責任を引き受けました。この関数はもっとゆっくり取るモジュールからの責任を想定し、限り、あなたはモジュールの責任を取って、それが中間レベルのエンジニアです。
転送コングリットルの給与バーを待っています。
7.まとめ
このレッスンでは、我々は裁判とテストを通じて、持参するプログラマのためのテストの価値を共有し、プログラマがプログラマの信頼性を高めることができる機能のバグ、バグや低金利の率を減らすことができ、製品の理解の技術レベルを向上させることができます、より多くの責任を、より多くの責任を取るし、モジュールレベルに到達するより自信を持って、彼は中間レベルのプログラマのレベルに上昇します。