設計方法を学ぶ必要性をひしひしと感じる

この記事は最終更新から3ヶ月以上が経過しています。情報が古い可能性があります。

今までプログラムの全体像を頭の中でイメージし、後は勢いでコーディングして完成させるという作り方をしてきていました。大規模なプログラムを作ることがなかったので、今まではそれで何とかなっていたのですが、最近それも限界を感じています。

Androidのアプリを作るのに、画面がどう遷移してどういう処理が必要で・・・なんていうことを頭の中だけでは把握できません。

それに勢いだけでコーディングしていると、このクラスが一体何の働きをしているのかが分からなくなってきます。作成中はまだ大丈夫なのですが、時間が経つともうわけがわからなくなります。

1分間タイマーは勢いだけで作り上げましたが、もう機能修正とか追加とかやりたくありません。どこで何やっているか自分でも訳がわからないからです。

そんなわけで、設計方法を学ぼうかななんて思って行動を始めました。

頭の中だけでプログラムをイメージするのには限界があるので、少なくとも設計図を用意したい。設計図を作るには、どういうふうにプログラムを組み上げていくのがいいのか、その手法を知る必要がある。という感じです。

とりあえずUMLの書き方さえ知らないので、UMLの入門書を読んで、ついで実践UMLという本を図書館で借りてきて読みました。

とりあえずわかったのはこんな感じですかね。

  • UMLが書けることとクラス設計ができることは別の話
  • 最初に完璧な設計書を用意するという考えは間違ってる
  • とりあえずやってみないと始まらない

UMLの書き方をマスターしたからといって、それだけでは設計書を作ることはできません。個人開発で使う分には、最低限自分が分かればいいので、細かいUMLの書き方をマスターしようとするのはちょっと脱線しすぎかもしれません。

プログラムの設計図を完璧に仕上げてからコーディングをしていくというのはウォーターフォール的発想だからやめろと実践UMLには書いてありました(意訳)。オブジェクト指向開発的には、もっとフレキシブルに設計とコーディングを行き来しながら開発していくんだそうで。

確かに、どういう作りにすればいいのかと完璧な設計を求めるあまりに、プログラムが完成しなければなんのための設計なんだという話になりますもんね。まあ今の私がそうなんですけど。

実践UMLを読んで感じたのは、内容がかなり濃い&難しいので、とりあえず前半くらいの内容を利用して実際に設計→コーディングのサイクルを回していくのがいいのだろうと思いました。どう作っていけばスマートなのかを考えだすとキリがないので、とりあえずやってみなければ始まらない。

アプリの機能、要件を定義して、そこからどういうクラスが必要なのかを検討して、実際に作ってみる。上手くいかなければ設計しなおして、やり直す。もっといい作り方がないかなとか追い求めると何もできなくなってしまうので、とりあえず作る。そんな方針で進めてみようと思います。

それと並行して設計方法についても勉強したいなと思っています。何かおすすめがあれば教えていただきたいです。

スポンサーリンク
  • このエントリーをはてなブックマークに追加

フォローする