Javaでコード書くプロジェクトの個人的反省会

こんにちは、kisseです。

先日、大学でプロジェクト形式でプログラムを1つ組むという授業がありまして、ちょうどそれが終わったので反省を個人的なノートを兼ねて記そうと思います。
同じような授業がある学生さんなどの参考にでもなればいいなー。

背景

  • 学部3年
  • ランダムな4人でチームを編成
  • JavaでGUIソフトウェアの作成を行う

反省概要

ざっくりまとめると、

良かった点

  • 付け焼き刃でも、デザインパターンを採用したこと
  • 信頼できるモジュールを作ったことによって、他のモジュールの開発が容易になった

悪かった点

  • 1人で作業しなければいけない量が多くなってしまった
  • デザインの重要性の理解が足りなかった

以上の4点に集約されるかなといった感じです。
4点について反省します。



付け焼き刃でも、デザインパターンを意識しながら開発を行なったことが、スムーズな開発に繋がった

まず、良かった点です。
今回、私たちのチームではMVCモデルを採用しました。
Java開発で一般的なのかは知りませんが、とりあえずデザインパターンを1つ決めておくことで開発の助けになることを期待したからです。
結果として、この方針は大成功しました。
それぞれの部分を明確に分離して開発することにより、処理とそのコードが記載されている位置の関係が明確になったからです。
そのため、ある場所でバグが発生した場合でも、原因となっている箇所の特定が容易であったために、時間をかけずに問題の解決策を生み出すことができました。

また、私の書いたコードを他のチームメンバーが読んだときにも理解されやすく、解決策の提案やフィードバックを受けることができました。

信頼できるモジュールを作ったことにより、他のモジュールの開発が容易になった

今回、MVCモデルを採用したのは前述した通りです。
そのなかで、一番最初に開発に着手したのは、モデル部分でした。
今回作成したソフトウェアでは、モデル部分が完成されていればそれに従ってビュー構成を行い、モデル部分を正確に制御するようなコントローラを作成するだけで良かったのです。
なので、モデル部分のテストは厳重に行い、信頼度の高いモジュールとしました。
その後、その他の部分の開発を進めている際にバグが発生した場合でも、モデル部分に原因が存在する確率が低いことがわかっていたので、コードの探索範囲が少なくてすみました。
実際、徹夜続きでバグが多発した開発後半でも、モデル部分までコード探索する必要がないので、デバックが短時間で済みました。

このような理由から、信頼できるモジュールを作成してそれを中心に開発を進めていくことによって、スムーズな開発ができると考えられます。

1人で作業しなければならない量が多くなってしまった

チームメンバーは4人だったのですが、その中でコード書けるのが2人で(一応プログラムが専門なんだけど…?)、どうしたってコードを書く量が増えてしまいました。
しかも、作業分担の関係でコードの記述量が多い部分の開発が私の方に寄ってしまい…などなどの理由があり負担が多くなってしまいました。
コードが書けない人にも、うまく仕事を切り分けることで作業を切り分ける必要があったかなと思います。
具体的にどうするかは難しいですけど。

それでも、片方の1人には開発以外のタスクを集中して処理してもらえたので、少し楽ではありましたね。

デザインの重要性の理解が足りなかった

今回作成したソフトウェアに対して、学部の上級生からフィードバックをもらえるのですが、口を揃えて言われたのが、
Javaデフォルトのデザインを使用するのはあまり良くないという点でした。
やはり、デフォルトのデザインをそのまま利用すると、安っぽい出来になってしまいました。
ボタン1つとっても、ちゃんと部品となる画像を用意するべきだったようです。

手の空いてるチームメンバーにデザインをさせるとか、自分がデザインするとかで少しでもデザインに力を入れるべきだったなという反省です。



まとめ


しっかりと、ソフトウェアの構成を考えながら開発することが大事であること、開発作業の分散、デザインの重要性がわかりました。

もう一個別のチームでプロジェクトを行うことになるので、この反省を生かしてやっていきたいなーって思います。

完全に自分の反省を書いたわけですが、誰かの役に立てば幸いです。

最後まで読んでいただきありがとうございます!

あわせて読みたい