新人が振られるタスクって大小様々なんですが、その大小によって注意すべき点とか動きかたみたいなのって教えてくれないですよね。
というわけでサクッとまとめてみます。
バグを修正するタスク
おおよそ正常に動いているプログラムがあるが、一部にバグが有りそれを修正すると言うタスク。参画して最初に振られることが多いタスクです。
大事なのはバグを増やさないことです。なので今動いている部分は壊しちゃいけません。
と言っても最初にプロジェクトに参画した時は正常動作がどういう状態か、どうテストするのかがはっきりしていないことが多いのでかなり大変な作業です。
プロジェクトに慣れてれば1時間で終わるようなタスクが、10時間以上に膨れたりします。理解がない雇い主の場合はそれで一回揉めます。
プルリクエストを活用して責任の分散を図るのが良いと思います。またよくわからない部分については仕様書を探したり人に聞いたりしましょう。そこでそのプロジェクトの絶望度が見えてきます（誰も答えを知らないとか）
もちろん再現性も重要です。どの条件で再現して、どの条件で再現しないのかを詳らかにしなければスタートラインにすら立てません。バグを見つけた人は発見だけを報告しますが、修正者は全てのエラー条件を洗い出す必要があります。
洗い出せたら修正し、網羅性の有るテストにより修正できたことを確認すれば良いのですが、自分の修正が何かを壊していない確証を得るのは非常に大変です。むしろそちらのほうが神経をすり減らします。
これが未リリースのプロジェクトならそこまで気負う必要はないのかもしれません。テストする人もエンジニアがきちんと修正したなどと信用していないからです。
ただし、それがリリース済みのプロジェクトだったり、テスターが居ないプロジェクトでは非常に神経質になる必要があります。（具体的なテストの方法論については割愛）
少しだけ追加・変更するタスク
既に動いているプログラムに、わずかな改良や変更をするタスク。
概ねバグ修正に似ています。
追加変更する際に、同プロジェクトの他コードと足並みを揃えることが求められます。完璧に足並みを揃えるのは難しいかもしれませんが、既に作成されているUtilityがあったり、設計手法を合わせたり、用語を合わせたり、コードの流れやコメントの書き方を踏襲する努力は必要です。完璧にやる必要はありません、そこはユーザーに見せる場所ではないので、あくまで”作業場”として適切な状態に近ければOKです。
あまり作業場をこだわろうとするのはおすすめしません。それより有意義なタスクはあるからです。わずかな用語の差や構造の差は見て見ぬ振りをする我慢強さが必要になります。
追加・変更したために発生する影響範囲が漏れることが多いです。１つの画面を作ったとき、その画面に至る導線は１つではないかもしれません。思わぬところから画面遷移してきて、その際に必要なデータを用意できなくて設計を見直す必要があることもあります。
意外とそういう接続の部分が重かったりすると、「追加変更」のタスク分しか見積もっていなくて時間が足りなくなることがあります。
気軽に聞ける人が居たら聞いてみましょう、ただし完璧な回答が返ってこない可能性の方が高いことを留意して下さい。
１つのパーツを作るタスク
ある１機能を作るようなタスク。
影響範囲が色んな所に及びます。パーツそのものの工数も大きいですが、他との連携に多くの時間がかかるケースもあります。パーツが何を使うのか、何がパーツを使うのか、ヒエラルキーや文脈を理解する必要があります。
あるいはそういう設計部分を誰かに任せたほうが良いかもしれません。各々やるととっちらかります。
大変そうに見えますが、この粒度が一番安心度が高いと思います。プログラムの振る舞いは自分が書いたコードのコントロール下にあります。他人のコードを読む必要は少ないので、書いたとおりに動きます。
（ただし大きな枠組みで設計方針が決まっている場合もあります）
似たようなパーツが他にないか探し、真似ることも重要になります。これはコスト削減とコードを読みやすくするという２つの目的があります。
ただし真似た方のコードに問題があった場合、自分の方にも問題が出るので注意が必要です。また、新しく書いたコードはどこかで真似られる可能性があります。心して書きましょう。
過度な共通化はやめてください。人は同じ形のものがあるとグルーピングしたくなります。ただし最近のプログラミングは生き物のように変化します。同じ形だったはずの２つが別のものになろうとした時、妙な共通化がされていると事故が起きます。
共通化というのは高度な作業です。
どのような条件下でも使いやすく、不要になったらすぐに分離できるような慎重に共通化する必要があります。悩んだら聞いてみて下さい（できれば10年以上の人に聞いて下さい。プログラマーは3〜5年目あたりで共通化大好き病に罹ります）
試作を積極的に作りましょう。
何かと干渉し、そのプロジェクトでしか動かないケースなどあるはずです。試作で困ったことは大抵一般的な悩みなので検索すれば出てきます。
また作った試作は別の機会にも役に立つはずです。
１つのプロダクトをまるっと作る
長くなるので割愛しますが、プログラムよりも要件定義やテストやリリース、チーム体制の方が重要になります。
以上です
