レッスン10「プログラマへの学生から5分」。
コードを見てすることは基本的に関係の企業文化、リーダーシップまたはマスターで、1,2ヶ月より長く、この時間は、すべてのプログラマが経験するであろうが、時間が長いか短い、短い日数プロセスでありながら、クールにリーダーまたはマスター自身がお尻を焼くには、あなたは次の中で自分自身のためにかわす聞かせて、あなたのための時間を持っていませんでした。
能動学習、成長している方法の多くの目の前でシェアするだけでなく、理想的に知って粉々にされるだろう、などのA段階の不満があり、我々は単に次の姿勢の調整を行います。今、実際の作業。
ラインに2つの方法で1プログラマ
ラインへの一般的なプログラマは、2種類の方法があるでしょう。
1）単純な関数を実行します
私はこの方法を好みます。これは、関数から始めて、プログラマーの束の組織の機能が彼を殺すためにある、ラインに加わったことを言っていない、メソッドのセットです。私は、この方法のステップを共有するために、例えば、APPエンジニアで終わります：
ステップ1：最初の表示機能
このような私達についてなどの静的なページなど、インタフェースの呼び出し、インターフェイス内だけで表示、相互作用がない、少し基本的には基本的にそれを行うことができますがあります。
ステップ2：シンプルなビジネス機能を実行します
例えばリストインタフェースのために、インターフェースは、リストを使用してデータが表示制御データを受信します。
ステップ3：次に、単純な機能的相互作用を行います
たとえば、データを修正し、名前を変更します。
関数がゆっくりなプロジェクトで、難易度を増加させることができ、あなたは独立した機能開発を担当することができます。
原則があり、プログラマはラインに加わった、コア機能、ビジネスプロセスの主な機能をスケジュールしていない、我々はプログラマに新規参入して、単純な関数から始めて、受け取ることができるプロジェクトプットを行うことができるようにする必要があり、これは場所があり、コア配置の場合機能と、トラフィックの主な流れは、彼が支払われていないにつながる、処理することはできません。
2）変更BUG
大半は、見習いシェフを養成、私は変更BUGから始めたいです。弟子はそれが働いて得れば危険で、それの機能は、それがプロジェクトのスケジュールに影響を与えますので、しかし、弟子はそれが働いて取得しても変更は、バグの進行には影響しません、彼らは彼がバグがあまりにも多くの時間を自分で取ることはありません変更ヘルプへのショットになります。変更のバグから始まるが、多くの欠点がありますが、最も一般的なエントリー方法として、我々はバグを変更するために始めることができます。
2.正しい姿勢変化バグ
私はラインに比較的小さいので、新しいバグが、このラインから変更、が長く、マルチバグも変更のためにあなたはまだいくつかの勧告を与えることができますので、行います。
1）優先度の低いバグ開始
Bug都有分优先级，优先级1是流程性的、影响大的Bug，优先级4是界面性的、优化的Bug。新入行的工程师，业务的理解能力和流程的把握能力偏弱，所以刚开始不要去改优先级1和2的Bug，先从改优先级3和4的Bug开始。
2）不懂的要多问
中级工程师有独立解决问题的能力要求，初级工程师只有基本解决问题的能力，所以有遇到不懂得就问，特别是代码质量低的项目。
我以前见到一个项目，有个类似朋友圈发布功能，一个函数有三千多行，单单显示发布日期，就有六个地方，后面维护的人看不懂代码，不敢删，有的用透明字，有的把显示区域设成0，有的用隐藏属性，让前面的都显示不出来，再自己重新加一段显示的内容。有经验的都不一定找得到真正显示的那段代码，新人就更别想了。
这个案例比较好玩，我多讲一点，这个项目的负责人能力一般，他担心被老板知道，就想方设法把有经验的人挤走，后面的员工都是他招的，都是刚毕业的程序员。新人都改不动bug，他能改bug，就显示他能力强。我发现跟着他混的新员工，毕业半年，连bug都改不好。
我前面有讲，在一家公司里要工作两三年，才能学会一套完整的项目流程、开发方法和团队协作方式。但是，如果你进到这种公司，那就要赶紧跑，不然会把你的职业生涯搞残。
讲了题外话，我们回到这个话题，遇到问题，经过看代码、调试还是搞不懂，就问开发的人，或师傅。在入行的时候，所有问问题都对成长有帮助，对方会给你讲很多东西，不仅会讲这个问题怎么解决，还顺带会讲很多开发方法。这时，你就把自己当成海绵，拼命吸收他们的经验。
3）培养做记录的习惯
在Bug的过程中，或请教的过程中，会学到很多东西。有项目流程的，有开发方法的，有产品理解的，有写代码的技巧，有实现功能的优质代码，要养成习惯，把这些记录下来。下次再遇到就知道怎么处理，而且这个就是自己的经验库，随着记录量的增加，能力成长会越来越快。
3. 改Bug的目的
你要是问师傅说：“师傅，为什么让我改bug，而不直接带我做功能？”，他通常都会说：“你先别急，现在还没办法做功能，先改改bug，熟悉下业务，熟悉下代码。差不多了，我再带你做功能。”
大部分新入行的程序员也不会去问为什么要先改bug，所以对改bug的目的不了解。反正让我改bug我就改，总比坐在那里看代码来的好，至少不会那么无聊。这样认为也没有什么不对，只是把自己成长的掌控权丢给了命运，这样的操作，基本上都会混的不好，最后就是抱怨自己的运气不好，公司不好，领导不好。
我们要把成长的掌控权拿回来，自己为结果负责任。那我们就得了解改Bug的目的，实际上师傅已经说了很清楚了，熟悉业务，熟悉代码，加上熟悉流程和团队协作方式，这些熟悉了，你就可以开始做功能开发。
所以我们改Bug的时候，不能傻傻的拼命去解决问题，就算你把bug全改好了，也只能得个6分。你要通过Bug去了解业务，不懂的就问师傅或产品经理，去了解代码框架、运行环境、业务流程等开发相关内容，去了解项目不同角色的人是怎么配合的，这样你既把bug改了，又学会了初级工程师必备的能力，就可以得个10分。
4. 这个阶段常见的错误
1）解决不了的问题，不懂得求救
这个是最常见的情况，一个bug在那里搞一天，搞不出来。第二天师傅或项目经理问了，才说没有搞定，而他们经常一句话，就把你点醒，马上就改好。
2）对代码管理不懂，经常跟别人造成代码冲突
虽然git和svn都很好用，但是新生经常会搞不清楚，覆盖别人的代码，或者造成打包的问题。如果出现这种情况，就好好的向同事请教，把这个问题搞定，不然就会挨骂。
シェア例：私はチームビルディングを行うために使用するJavaジュニアエンジニアを、移動する前に、彼は多くの場合、テストマネージャは、先頭を立つことができない、他の人のコードをカバーする、私のところに来て言った：「数回登場陳総統は、特定のカバーするためにケースコードは、我々のテスト合格の良い機能は、だけでなく、問題を思い付く、あなたはそれについて何かをする。」、だけでなく、私が扱います。技術的なボスプロジェクトを我慢することはできません数日は、私のところに来た：「ボス、そうやので、他の誰かのコードでカバーされていることを、ここで行うことはできません」私は彼に冗談を与えた、と彼は尋ねた：「あなたは彼を置きたいですか？は、「彼は言った愚かな瞬間：」解雇。揚げないでください」を これは、あなたはどのように、迷惑な参照、解雇のではなく。
3）バグを変更する純粋な変更のバグです
新しいスタッフが、多くの場合、バグ、次のプロジェクトまたはバージョンを変更するプロジェクトと組み合わされ、それが機能を作り始めます。発生期改革のバグ、インターフェースの一般的な性質、BUGの簡単なビジネスロジックなので、純粋な変更バグ、業務に精通ある程度のと、コードを持っていますが、全体の容量は依然として弱く、機能開発の時間を行うには、より多くなります難しいです。
5.まとめ
我々がない基本の「Hello World！」（ド機能）からのラインに、ラインにプログラマの話をこのレッスンではなく、バグから変更ラインも変更バグ、我々は愚かなバグを変更することはできません、我々は変更する必要がある理由を知りたいですバグは、同時にそうあなただけのバグを変更することはできませんが、またジュニアプログラマの要求する能力を習得し、製品、コードのフレームワーク、動作環境、ビジネスプロセスの内容を理解します。