後輩プログラマに入社する前に身につけて欲しい考えと技術要素

はじめに

組織でチームとして開発をすることは、趣味で行うプログラミングをや学生が研究のために開発をするのとはまた異なる知識やスキルが必要となる。本文ではチーム・業務環境での開発に明るくない人を対象としてその考え方の違いや、身につけて欲しい知識としてCI、テスト、DB周りの事を紹介する。

プロフェッショナルとして組織で開発するということ

学生や個人で開発をすることと、企業で開発をすることの大きな違いとして、金銭等を対価にシステムの運営を期待されていることや不特定多数との共同作業が求められることなどが挙げられる。

プロフェッショナルとして

企業で開発をするということは基本的にはお金を対価に製品・サービスを提供することだ。「僕の変更でちょっとシステム止まっちゃった、動くまで1時間待って」では済まないのである(最近たまに見る光景ではある)。"Don't Ship the Shit"だ。貴方の研究のアルゴリズムが間違ってたせいでプレゼン資料に誤ったデータを載せて教授に注意されるのとはわけ違うわけだ。

こういった問題を防ぎ、プロフェッショナルとして製品やサービスを提供するにはコードクオリティの向上が必要だ。今回紹介する技術要素は全てここに関わってくる。

チームとして

組織における開発はとにかく関わる人が多い。大学等での開発はほとんどが個人、もしくは先輩後輩で密にコミュニケーションの小さなチームで異なる部分に着目しての開発だろうか。 その点企業での開発はほとんどがチーム、多きなものでは数十、数百人がひとつのプロダクトを開発するために関わるだろう。 更に貴方のチームメイトは今一緒に働く人達だけじゃなく、将来入ってくる人々も貴方の加える変更の影響を受けるチームメイトなのだ。

この様に企業では不特定多数の人が関わり一つのものをつくり上げることを意識しなければいけない。

身につけて欲しい技術要素

CI (継続的インテグレーション)

CI (継続的インテグレーション)はソフトウェアのビルドやテストを継続的に行い、ソフトウェア品質の維持を保つための仕組みである。ここではgit、svnなどのバージョン管理システムから継続的デリバリなどの一連の流れを含めてCIとして挙げてある。

VCS (バージョン管理システム)

最近は学生等にも広く浸透していると思うがgitやsvnなどのバージョン管理システムは安定した開発を続けるために非常に重要だ。 既存のコードに変更を変更を加えて何かを試したいときにファイルの名前を変えたりコードをコメントアウトするのは筋が悪い。 行うべきはコードのコミットであり、後はツールが履歴の記録やdiffの生成を簡単に行ってくれる。

また、VCSを利用することでコードの共有が圧倒的に容易になる。チームで開発をするときにはひとつのリポジトリからコードを取得しメンバーの開発した成果は最終的にひとつのリポジトリに入れられる。この際は自分の成果が他のモノを壊していないか充分に確認してから行うべきだ。 自分の変更が他の人に共有される事を意識してコミット時のコメントは他のチームメイトや将来自分が見返した時に意図が伝わりやすいものを意識しよう。

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)

Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版)

コードレビュー

コードレビューはその名の通りコードの出来を皆で確認するプロセスだ。ここに辿り着くまでにはたいてい幾つもの苦労があるが、これも大きな関門だ。ある意味自分のデキのshowcaseであり、実力が判断される場だ。見苦しいshitを皆の前に出さないように気をつけよう。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

CI (継続的インテグレーション)

個人での開発のレベルでCIをきっちりと行っている人は多くはないかもしれないが、CIは手間のかかるビルドをビルド自動で定期的に行う事を可能にし、その際ビルド結果に対するテストも可能にする。これを継続的に行うことでコードの異常を素早く発見することができ、自動化されているため一度設定してしまえば手間も少ない。多くの場合、JenkinsやTeamCityなどのツールが使われている。

環境にもよるが、共有リポジトリにコミットがあったらビルドを走らせるという設定をしている場は多いだろう。コミットは必ずビルド・テストが全て適切に行えるとローカルで確認してから行うようにしよう。(万が一共有のビルドをクラッシュさせた場合には直すまで鬼のように電話やメールがくるという可能性も否定出来ない。)

継続的インテグレーション入門

開発ツール徹底攻略 (WEB+DB PRESS plus)

継続的デリバリ

企業文化にもよるだろうが、多くの場合は変更が出来たらすぐに変更をリリースというわけではない。 1週間や1ヶ月に一度プロダクションリリースの日があり、その日を目標にある機能を作成しQA環境でのテスト、ユーザを巻き込んだUATをパスし準備万端の状態でリリースを行うことが望まれている。 きたるその日に備えて我々プログラマは日々コードとにらめっこするのだ。

個人的にはチェックイン後のビルドが走る度に最新のコードがQA環境に自動でデプロイされ、UAT環境には基本的なテストをパスしたRC(Release Candidate)のみがデプロイされるというような設定が好きだ。 UAT後の変更は有り得る話だが、基本的にUATまでには出来る限り全ての確認を終えあとはリリースをするだけだという状態で臨みたい。 最後に急な仕様変更を求めてくるクライアントはクソ食らえだ！

Jenkins実践入門　?ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

テスト

企業での開発はテスト！テスト！テスト！！だ。 学生時代に研究用のコードにテストを書いていた人はあまり見たことがないが、企業ではそうはいかない。 成果の出来を確認し、クライアントのもとに届けるまでにはユニットテスト、レグレッションテスト、インテグレーションテスト等々様々な切り口からのテストが必要となる。(それぞれのテストの意図がわからない人は今すぐググろう) テストを書くことは意図せぬ変更からチームメイトを守り、将来再びそのコードに訪れる自分を守ることに繋がる。

最近はコードの中で完結する従来のようなテストのみでなく、ユーザも巻き込んで仕様書をインプットとしたりテストケースをプログラムに詳しくない人にも書かせることを可能にしたFitnesseや、(マウス)ポインタをハイジャックして実際のGUIを用いてテストをするSikuliといったものまである。 テストに詳しくなって強固な開発基盤を構築する事を意識しよう。

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

DB (SQL)

ここではDBの設計等ではなく、SQLクエリの話だ。(余談だがEnglish SpeakersはSQLを”えすきゅーえる”と発音するのではなく"しーくる"と言う)

アドホックなクエリ、プログラムに組み込むクエリどちらの場合もとにかくパフォーマンスを意識するべきだ。 プロダクションDBでなにか探しものをするときに酷いクエリを走らせてCPUを専有しシステム全体のスループットを落としましたなどとなったら目も当てられない。

クエリの設計・実行を行う場合にはどのインデックスを使用するのか、クエリプランはどのようになるか、充分なフィルタはされているのか、ストアドプロシジャにするべきか否か等をよく考えてから行動をするようにして欲しい。

良記事：開発者のためのSQLパフォーマンスの全て

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

SQLアンチパターン

まとめ

以上で新人のプログラマに働く前に最低限抑えて欲しいことを挙げたが、実際に働き出したらここに挙げたような事でもわからないことに多くぶつかると思う。 そんな場合にはこんなことを聞いてもいいのかと思い悩まずにどんどん先輩に質問して欲しい。 多分先輩社員はなんだかんだ後輩が来るのが楽しみであるだろうし、新人の成長はチーム全体の生産性の向上につながるのでそのための協力は惜しまない。 この文を読んでくれた人が良いデベロッパとして楽しい環境で開発を続けられることを祈っている。