濃縮ソフトウェアエンジニア研修：職務プログラミングで重要な心構え+お勧め書籍

エンジニア プログラミング

はじめに

この記事の目的は、新しく職務としてプログラミングをすることになった人に、一生忘れないでほしい考え方や姿勢を身につけてもらうことです。
ソフトウェア開発で気をつけるべきことは細かいこと言い出すとキリがないですが、これぐらいは開発者全員が心と体に叩き込んでおいて欲しいという内容を凝縮してあります。

職務プログラミングの趣味プログラミングとの違い

まず、職務でプログラミングをすることは、趣味（や学校の課題や研究室で論文のために作るものも含めて）でプログラミングすることは全然違うという話です。

趣味プログラミングの特徴

趣味プログラミングは、自分のためのものなので、やりたい放題

  • 自分で作りたいものを決める
  • 自分で作る
  • 自分で使う（運用する）
    • エラーで落ちたりフリーズしても、データや動作環境をいじってやりなおせばよい
  • 自分で作り直す（直さないのも自分の勝手）

職務プログラミング

プロダクトやプログラムは、組織（会社やプロジェクトチーム）のために存在し、自分のものではない

  • 他人(経営者、プロジェクトオーナー)の作りたいものを作る
    • だから、対価として給料がもらえる
  • 他人と（場合によってはチームや会社の垣根を越えて）強調して作る
    • 大きな成果を期限内に作るためには多人数でやる必要がある。ビジネス的な価値や責任も大きくなる
  • 他人がそのプロダクトを使う
    • 簡単にフリーズしたりエラーで落ちたりしてはいけない
  • 他人が運用する（してくれる）
    • 自分には休日がもらえることになる。問題が起きた時に自分しか対応できないときついよ
  • 他人にテストされ、ソースを読まれ、バグを発見され、修正される（してもらえる）

職務プログラミングにあたっての心構え

  • 何を作るべきなのか（必要十分な機能）、自分の担当範囲を明確にしておく
    • 限られた時間と人数で成果を上げる必要があるので、余計な機能を勝手に追加しないこと
    • エラー処理をどれぐらい丁寧にやるべきかを明確にしておくこともわりと重要
    • 開発の終盤で作り漏れに気づくと締め切りを守れなくなるので、漏れもないように気をつける
  • いつまでに開発終了させるべきか、間に合わなさそうになったどうするべきかを把握しておく
    • ビジネスにおいて時間や時期は最重要事項なので、進捗によってプロジェクトの変更（締め切りを伸ばす、機能を減らす、仕事の分配を修正する）の判断に迫られる
    • 判断のタイミングが遅いと取り返しがつかなくなる。間に合わなさそうなものを一人でなんとか頑張ったけど挽回できなかったというのは最悪。できるだけ予兆の段階で報告すること
  • 開発の成果物（プログラムやデータ、ドキュメント）をきちんと管理する
    • ソースコード管理ツールに習熟しておきましょう
    • 開発ドキュメントやテストデータなどもメンテナンス時に必要になるので、ぬかりなく
  • 運用の手間を減らすようにUI設計を工夫する
    • 何十年間も無駄な運用コストが発生することにもなりかねない
  • テストしやすいよう設計、プログラミングする
  • プログラムを他の人に読んでもらいやすいように書く
  • プログラムを修正しやすいように予め構成しておく

どう設計すればいいか

テストやデバッグ、修正が簡単になるようにしましょう

  • 重複を避ける
    • 重複箇所にバグがあったり修正が発生した場合、テストやデバッグの手間が倍になる
  • 機能のはっきりしたコンポーネント、クラス、関数に分解しておく
    • 関係あるものをまとめる/関係ないものを分離する
  • 意味的/機能的に（あるいは他の合理的な指針で）、階層構造/木構造になるように構成する
  • 分割したもの同士が必要以上に影響し合わないようにする
    • 余計な依存をなくしたり、一方通行にする
    • 例：関係するモジュール(とかクラスとか関数)A0とB0がある場合
      • AをA1に取り替えようとするとBも変更しなければならず、BをB1に取り替えようとするとAも変更しなければならない→よくない
      • AをA1に取り替えようとするとBも変更しなければならないが、 BをB1に取り替えようとしてもAはそのままでよい→よい
      • AもBもそれぞれ独立に代替物に取り替えれる→とてもよい

よい設計のためのキーワード

よい設計が出来るようなるための参考書籍

どうすれば良いコードになるの？

〜名前編〜

変数名、関数名、クラス名、ファイル名などに気をつけましょう

  • 名前で中身がわかるようにする（変な名前をつけてコメントで説明したりしないこと）
    • 駄目な名前 x、u　（ループ変数のようなちょっとしたローカル変数ならOK）
    • 良い名前 user_id、uid　（コード以外でも使われる略語はOKだが独自略語は避ける）
  • 命名方針を統一する
    • convert_to_eucとかconvertToUTF8とかconv2sjisとかを混ぜない

〜見栄え編〜

読んでもらいやすく、修正しやすいプログラムを書く

  • 重複を避ける
    • 読む量が増えるし、同じっぽく見えて微妙に違うのかなとか無駄な混乱が起きる
  • 出来る限り短くする
    • 分かりにくくならない範囲で、行数も１行の文字数も減らすこと
  • 構造を見た目で表す
    • きれいにインデントする
    • 必要十分な空白を入れる
    • 必要十分な括弧を入れる

よいコーディングのためのキーワード

  • コーディングスタイル
  • 防御的プログラミング
  • 各言語の仕様を読むこと
  • 言語の機能の意義を理解すること

コーディングのスキルアップのための参考書籍

時間・タスク管理もしっかり

ソフトウェア開発は、試行錯誤の繰り返しで、人によって作業効率もぜんぜん違う。
作るべき内容が途中で変更されることもしばしばある。
計画当初の通りに進むことはまずない。
→　個人でも、時間管理とタスク（の優先度）の管理が超重要になってくる。

時間管理力アップのための参考書籍

エンジニアのための時間管理術

エンジニアのための時間管理術

おまけのアドバイス：英語も勉強しよう

余力があれば（というか余力のある今のうちに）英語の勉強をしましょう。ソフトウェアの技術や文化はほぼ全て英語に基づいています。英語力があると、適切な関数名・変数名を付けるといった細かい話から、最先端の技術を身につけたり、海外出張に行ったり、転職したりといったエンジニア人生に関わる大きな話まで、色々な点でとても有利になります

あとがき

先輩面したようなことを書いていますが、自分もまだまだ理想のエンジニアにはほど遠いので、これからも頑張り続ける所存です。