新人プログラマさんに贈る、よりよいプログラミングのための7つのポイント

こんにちは、inoueです。GWが終わったばかりなのに今週末は母の日ですよ。みなさんカーネーション用意しました？

さて、この春からプログラミングを始められたかたもスタートから1カ月が経過しましたね。
プログラミングに慣れてきましたか？できることは順調に増えてきましたか？
そんな方にぜひ気にしていただきたい、プログラミングのちょっとしたポイントを7つ今日はお話したいと思います。

1. 何を作るのか、を把握する

作業指示や仕様書をしっかりと理解する、というのがまずやるべきことになります。
「こうだと『思っていました』」で作業を進めてしまっては、手痛いしっぺ返しを食う可能性大です。
指示されたもの以外にも確認できる資料があれば、積極的に読みましょう。
それによって、これから作るものが含まれるシステム全体の理解が深まり、よりよいプログラムを作ることができます。

2. わからないことは、すぐ聞く

不明点、疑問点はすぐ先輩など周囲に聞きましょう。
これはプログラマに限ったことではないですが、わかったふりをしていて実はわかっていない、というのは非常に周りに迷惑をかけます。
「聞くは一時の恥、聞かぬは一生の恥」は常に心に留めておきましょう。
聞けば数秒でわかることで一時間も二時間も考え込む必要はないですよ。
先輩もあなたの質問に答えることで知識が再定着するのです。お互いに得、なのです。

そしてもちろん質問した内容と得られた回答はメモしておきましょう。
何度も同じことを聞くのはもちろんタブーですからね。

3. みんながどう作っているのか、を知る

現在、まったくのゼロからプログラミングを開始することは皆無に等しいと思います。
新機能の追加部分を指示されたとしても、それの元になる既存の似たようなプログラムが存在するはずです。

まずは、それがどのように書かれているのか、じっくり目を通しましょう。
類似のものが複数ある場合、それらの作成者が異るならばさらに読み比べてみてください。
「この人のプログラム、読みやすいな」「この処理の仕方、スマートだな」など発見がいくつもあるはずです。

また、システム全体を通して、ベースとなるプログラミングの処理構成があることも多いです。
それにうまく沿った形で自分の担当分を作成するように心がけるのをおすすめします。
独自性の強すぎるプログラムがシステムの中に点在すると、仕様変更の際の思わぬ障壁になってしまうことがあります。
個性の発揮は別の場で存分にどうぞ。

4. どう作るのか、図にしてみる

何を作るのか、把握できたところですぐにプログラミングに入るのは危険です。
複数の処理の連携があったり、条件分岐やループが必要だな、と分かった時点で一度作るべきものを図化することをおすすめします。
図にすることで、頭の中では理解した『つもり』になっていた仕様にあいまいな点が残っていた、など気づくことも多いです。

また、プログラミング中に気付いたこと、確認しなければいけないことが出た場合、最初に作った図にそれらを書きこんで具体的に質問や相談することができます。
自分の手で書き出したものは、今後の参考資料にも、記憶をたどる際のキーにもなる貴重な資源になります。

5. どうすれば楽できるか、を真剣に考える

機能追加や仕様変更の際、特に気をつけたいのがこの部分です。

すでに同じことをやっている関数が存在しないか、それをすぐ利用することは可能か。
別のところにある機能を共通部品化して利用することは可能か。
…まずは「極力プログラミングしないでよい方法がないか」探ってみてください。
既存のものを呼び出すだけで作業完了、ならばテストも簡単です。
次の分担を割り当てられ、担当箇所が増えることで「できるやつ」と評価が上がるかもしれません。

また、既存の流用で済ませられなかった場合も、とことん楽に作業を完了させる方法を検討しましょう。
データを追加取得する際、必要なものを一発ですべて取得できる方法があるか、などデータアクセス関連は特に重要です。

初心者がやりがちなミスとして、ループ処理内にデータの追加取得処理を記述してしまい、機能追加後に全体の処理スピードを大幅に悪化させてしまう、というものがあります。
こういったものも、デバッグ時にデータアクセス回数がわかる状態（CakePHPでいうとデバッグモード 2 の状態）にすると何が原因か一目瞭然なので、無駄な処理をさせていないかよく確認しましょう。

コンピュータに任せて楽をするのがプログラミングですが、そのコンピュータにも楽をさせてあげる心遣いも重要だと思います。

6. 何を作ったのか、を説明できるようにする

自分が作ったプログラムの処理概要や機能を説明できるようにしましょう。
口頭で説明できるようにすることで、自分が作ったプログラムの内容が深く理解でき、今度とっさにその部分の説明を求められた際にも役立ちます。
作業完了を指示者に報告する際、これらを説明するくせをつけるとよいかもしれません。
ただ「終わりました」「作りました」と報告されるより、指示者も作業者の理解度や作業内容が把握できて安心です。

7. 周りが何をやっているか、常に気にしておく

自分の作業に没頭するあまり、プロジェクト全体で何が起きているのか、同じ部署の他のプロジェクトがどういった状況なのか、といったことに無関心になるのはよくありません。
他で発生しているトラブルに自分の知識や作業内容が解決策として活きる事もありますし、単純に人海戦術要員としてフォローに入る必要があるかもしれません。
また、自身に割り当てられた作業が他プロジェクトの流用で済む場合も多々あります。
周りの人と助け合いながら作業を進める事が、効率よく作業を進めるカギとなる場合もあると心に留めておきましょう。

さいごに

以上、7点日頃から思っていることを挙げてみました。
若干説教ババアですかね。プログラマに限ったことではないものもいくつか含んでいます。
書きながら、自分自身でも反すうしたい基本的なことばかりです。

シーブレインもそうですが、少人数の組織での仕事は、個々の分担も多く自分の仕事に没頭しがちです。
また、それゆえに「先輩に聞きづらい」という環境になりやすいかな、とも思います。
だからこそ、周囲の人の力を借りて作業を進めるということを積極的に新人さんにはやってもらいたいな、と感じています。
ほんの少しでもこのエントリーがそんな新人さんの力になれれば幸いです。