全てがはじめての中、「怒涛」のレビューを終え、「実装」に取り掛かることとなりました。 今まで机上で行われたことが明示的に見えてきます。

基本設計が終了となり、実装が始まりました。
ここからは基本設計までで作成した書類を元に実際にコードを書く作業（以降コーディング）及び詳細設計と、次のプロセスであるテストで使用するテストケース作成を行います。

大量のエラーと競合

実装段階で、まず私達はインターフェースの実装から行いました。5月の開発基礎研修で少しプログラミングの練習をしたとは言え、実際にコーディングを行うのはほぼ初めてのこと。

先輩方はなるべく私達に理解しやすいように指示を出して下さいますが、そもそもインターフェースと呼ばれるものが何なのか把握しきれていません。専門用語が出てくると私達の思考回路が止まってしまいますのでコーディングではひとまず先輩方の指示を理解するところから始まります。

インターフェースは完成しても直接画面に反映されるものではなく、とりあえず作ってみるもののそしてアプリケーションを構築する度に出るエラーにも毎度悩まされました。

少し慣れてきた今ではどこがエラーでどうしてエラーとなっているのか、それとなく解るようになってきましたがこの時はさっぱり理解できなかったのです。

その為エラーが出ると自分達の手には負えません。
エラーが出ないというのはほとんどなかったので新しい部分をコーディングする度に先輩に直してもらっていました。

※インターフェース(interface)とはオブジェクト指向プログラミングの世界においてクラスが実装すべき規約を定め、クラス設計者とクラス利用者の間の仲介役を担うものです。

何とか苦戦しながらも作り上げ、今度は各々のプログラムをチーム全体で共有する為にバージョン管理ツールを利用してサーバにアップするのですがここでも慣れていない私達は大苦戦。

周りの人に確認を取りながらサーバへのアップを行い、やっとアップしたプログラムを別の人がサーバからダウンロードするとダウンロードした人のプログラムと競合を起こすのです。

競合とはサーバにアップされているプログラムをダウンロードする時に、別の人と自分のプログラムで同じファイル・同じ行に違う変更があった場合に起こる現象です。

その時は何が悪いのかさっぱり理解できていなかったので、ファイルの競合が起こる度に先輩を呼んで競合を直していただいていました。

それでもインターフェースの実装は、実態は理解していないながらも２，３実装しているとそれとなくどうやって実装をすればいいのか見えてきて全体としてはそんなに時間のかかるものではありませんでした。

画面設計

実装が始まってから少しして、詳細設計の一部として画面デザインも行いました。

デザイン関係を担当としている先輩に特別講師として教えて頂きながら、フリーの描画ツールを使用して実際のアプリケーションの画面のイメージとアイコンを作成しました。

こちらも5月の開発基礎研修でツールの基本的な使い方は勉強していましたが正直使いこなせるレベルには至っていなかったので、ピクセルの数え方が分からず画面と長時間にらめっこをしたり、コピー＆ペーストが上手くいかずに何度もやり直したりとなかなか苦戦しました。

そして実際のアプリケーションの画面のイメージを作成しながら全員で余白の広さやボタンの大きさ、フォントのサイズや色などを決めていきました。
　
　
　
　

テストケース

そして次に、テストケースの講義を受け実際に作成しました。
テストケースは現在までで作成した諸々の書類を元に、「ここでこれを押したら」「こう動くはず」といったことを書き連ねていきます。

書き連ねた後は次のプロセス、テストで使用します。
言わばテストの前段階になります。

一般的にはコーディングをする人がテストケースを作成するというのはバグの見落としなどが多くなるためにあまりないそうなのですが、今回の研修では全てのプロセスを経験することが目的なので、実装を担当した私達がテストも担当する事になりました。

この作業は書類を見ながら進めるので、基本設計で苦労したのが報われました。
とはいえ、システムどころかアプリケーションを作るのですら初めてなので基本設計の時には結構細かく決めたつもりでも抜けが多く、また全然考えていない部分も発見されたりと仕様を詰めるという意味でもかなり重要な作業となりました。

実装続き

さて、インターフェースの実装も先輩に手伝って頂き一段落し、いよいよアプリケーションの画面の実装に入ります。

ひとまずはログイン画面、メイン画面と作成していき、画面が遷移してログインができることを目標に頑張りました。

この辺りから私達にとっての新たな壁、データベースがお目見えします。
画面の中の一つ一つの制御文ですらちんぷんかんぷんなのに、更にデータベースへデータを出し入れする技術が要求されるようになったのです。

結局データベース関連の制御は先輩に全て教えていただくことが多く、今でもあまり理解できているとは言えません。

一つの処理の流れを追うのに幾つものファイルを読まなければならず、ただでさえコードを読みなれていない私達には理解に至るまでは相当の時間が予想されました。

そこまで突き詰めて理解するには今回は時間が足りないので先輩の見よう見真似でコーディングしてみるというのが基本スタイルになりました。

表示が遅い

また、今回実装を進めていく上で問題となったのが表示の遅さです。

メイン画面に処理に時間のかかる部品を乗せ過ぎたせいで画面の切り替えの表示の処理に時間がかかってしまい、スムーズに表示されないのです。

私達からしてみれば表示が遅いというのは見ていれば解るのですが、では実際どこを直すのかさっぱり解らないどころか、どこが悪いのかすら見当がつきません。

主な原因としてはメイン画面に表示する部品の一部の処理が重く、また数が多かったようなのです。

その部品は1日分として標準3つ、メイン画面には1週間分表示されますから3×7で計21になります。

先輩が対応策を考えた結果、処理に時間のかかっている部品を軽く作り直し、軽くした部品の初期表示の個数を減らしたりなど修正していただきました。

コードレビュー

実装も終わりの方になってくると、コードレビューがあります。

コードレビューというのは今まで自分がコーディングしたものを解説しながら書き方を間違えていないか、また行っている処理に間違いはないかをチームの皆さんに確認してもらう作業です。

本来はその名の通りレビューなのですが、研修中では私達が理解してコーディングできている箇所は少ないのでほぼプログラミングの講義になってしまっていました。

また、直すところを教えていただく作業でありながら、普段はなかなか読まない他の人のコードを解説付きで読めるのでとても勉強になります。

コードレビューの後には書き方を意識しながらコーディングするようにもなりました。

色々な方に教えていただいたり手伝っていただいたりしながらこの１か月半コーディングしてきましたが、私達では必要最低限の機能を実装することすら叶いませんでした。

今は先輩方が実装完了宣言に向けて私達では実装できなかった部分を引き継いでくださっています。

先輩方には申し訳ないと思う反面、もっと実装したいなと思う自分もいました。

実装としてのコーディングはもうありませんが、今度はテストでのデバッグが待っています。

今まで頑張ってきた分、アプリケーションがしっかり動いてくれるのか期待と不安で胸がいっぱいです。