コーディング初心者が会社の仕事でコーディングする時の注意点
会社の仕事でコーディングを任された間もない方：
・初めて仕事でコーディングすることになったけど、何をどうやったらいいんだろう？
・これまでとりあえず言語の勉強はしてきたけど、仕事としてコーディングするときの注意点ってなんだろう？
今回はこのような悩みについて解説していきます。
これまで個人やスクールでのプログラミング勉強とは違い、会社の仕事としてコーディングするときの注意点を理解することで、開発チームや会社のやり方から逸脱しない、保守性の高いコードを書くきっかけをつかむことができます。
【初めてのコーディング】設計をしてからコーディングに着手しよう
コーディングの仕事を貰えた際、これまで学習段階で行ってきたように、いきなりコーディングを開始するのはNGです。
まずはきちんと設計をした上でコーディングするようにしましょう。
なぜなら、設計をしないままコーディングすると、バグが購入しやすいし、保守性の落ちるソフトとなりやすいからです。
実体験：追加、修正、削除を繰り返してバグが発生
こんな状況でした。
- 最初から計画が破綻している
- 平日の夜や土日を使って、とにかくひたすらコーリング
- 設計をそこそこに、とにかくコーディング
そんな中で作ったコードは本当にひどかった。
- 最初に動かすと、まず動かない
- トライ&エラーの繰り返し
- まともに動く頃には、コードはすっかりスパゲティーコードに
「あ、やっぱあそこはこのほうがいいな」
とか、
「最終的にここはこうすべきだった。でももう動いたからいっか」
ってことになります。
このようにやっつけでコーディングすると、保守性のないソフトが出来上がってしまい、後から困ります。
設計してこそ、「おや？」や「この時どうなるっけ？」が生まれる
例えば、コーディングする前に
- 関数がどれだけ必要か把握するためにクラス図を作ろう
- いくつか状態をわけるために状態遷移図を作ろう
- 関数間のやりとり把握のため、シーケンス図を作ろう
これがすべてではないですが、これをやるだけでも、コーディングする前に、どのようなコードとなるかをある程度想像することが可能になります。
そうなると、
- 自分：コードがイメージできるのでバグコードを埋めにくくなる
- 他者：設計した図があると、内容を理解しやすいので指摘がしやすい
なので、
「おや？コード書いててここがこうだから修正しないとだなぁ」
「ここがこうなってるけど、この場合の挙動が未定義じゃ？」
のように、自分も他者も、設計した内容、即ちこれからコード化しようとしている内容のバグに気づきやすくなります。
なので、コーディング前に設計は大事なのです。
変更点がわかりきった小変更なら設計の必要なし
ここまで書くと、
「それなら、どんな変更に対しても必ず設計が必要なのか」
と、思う方がいるかもですが、変更点がわかりきったような小変更でしたら、もちろん無理に設計をする必要はありません。
例えばこんなもの
- 変数名、定数名の変更
- 固定値を変更
- 巨大関数のサブルーチン化
このような変更でしたら、わざわざ設計の必要はありません。さくっとコーディングしちゃいましょう。
仕事としてコーディングするときの注意点【5つ出してみた】
これまで、コーディングする前にきちんと設計をすることが大事であることを解説しましたが、今度はいざコーディング作業に入った際の注意点を解説致します。
具体的には以下です。
- ベースソフトを尊重した書き方をしよう
- コメントは必要なときに書こう
- コーディング規約を守ろう
- 動くコードを登録しよう
- エラーはじっくり時間をかけて取り組もう
ベースソフトを尊重した書き方をしよう
コーディングする際は、おそらく何かしらのコードをベースにしてコーディングすることが多いでしょう。
その際、既存の書き方をなるべく真似てコーディングするようにしましょう。
なぜなら、既存の書き方を無視してコーディングすると、読み手にストレスがかかってしまうから。
例えばこんな感じ。
} else { —
}
case:
—
break;
default:
break;
}
case:
—
break;
default:
break;
}
このようなものをコード内で混合してしまうと、読みにくい、変更しづらいでストレスだらけです。やめましょう。
コメントは必要なときに書こう
初心者用の本にも「コメント残そうね」的なことが書かれていますが、コメントは必要なときに書きましょう。
なぜなら、わざわざ無理やりコメントを残しても意味はないし、そのコメントを埋める時間も無駄だからです。
具体的でいいますとこんな感じです。
- よろしくない例：a=1；//aに1を代入
- よい例：a=1；//aは1(駆動する側)に設定
よい例のほうは、「ああ、１は駆動する側、0は停止側だな」とわかるので、コメントとしての意味を成します。
よろしくない例のほうは言うまでもなく、無駄ですね。
なので、コメントは必要なときに書くようにしましょう。
コーディング規約を守ろう
会社には、必ずコーディング規約なるものがあります。例えばこんなものです。
- 変数名の最初には型名を入れましょう
- 定数名はすべて大文字にしましょう
- 関数名は”_”で区切って名前をつけましょう
上記の例でいうと、要は、各個人でオリジナリティあふれる名前を付けだすとキリがないので、一定のルールを設けているのです。
なので、このようなコーディング規約をコーディング前に必ず確認し、遵守するようにしましょう。
動くコードを登録しよう
ソフトウェアを作成する会社なら、バージョン管理ツールをもっているはずですが、ツールにコードを登録するときは、それなりに動く状態にしてから登録するようにしましょう。
なぜなら、動かないコードを登録してしまうと、他のメンバーが困ってしまうから。
たとえば
- コンパイルが通らない
- 処理が中途半端なところまでしか実装されていない
このような状態です。これだと、他のコーダーに迷惑がかかること間違いなしです。
なので、コードを登録するときは、動くコードを登録するようにしましょう。
エラーはじっくり時間をかけて取り組もう
コーディングして、いざコンパイルすると、ほとんどの確率でエラーがでることが予想されますが、エラーはじっくり時間をかけて取り組みましょう。
なぜなら、エラーがでた→よーわからん→だれかに聞く、だと、いつまでたっても成長しないし、他人の時間も奪ってしまうから。
- 変更箇所をすべてコメントアウト
- 一部のみコメントを外す
- コンパイルする
これを繰り返しましょう。
そうすると、エラーの箇所の特定がしやすいですので。
本記事の内容は、初めてコーディングする人に関わらず、すべての人が対象かも
ここまで書いて思ったのは、今回の内容は新人のみ対象ではないということ。
社内にいますよね。ここに書いたことすら守れないしょぼい先輩。
こうならないようにしましょう。
今回は以上です。