質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.12%

プログラムを書き始める前に考えることについて

解決済

回答 6

投稿

  • 評価
  • クリップ 2
  • VIEW 1,445

omikuji

score 58

こんにちは。当方プログラミング初心者です。

最近、こちらで色々質問させてもらいながらオセロプログラムを完成させました。
しかしながら、設計図を全く作らなかったこともあり、変数やメソッドなど当初の予定にはなかったものを様々に書き加える必要があったせいで非常に読みづらくわかりにくいコードになってしまいました。

そこで、次は設計図を作って読みやすいプログラムを書き直そうと考えているのですが設計図といってもどう書き始めていいかわかりません。
皆さんはプログラムを書き始める前にどのようなことを考えていますか?

さらに読みやすいコードを書くためにどのような工夫をしているでしょうか。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 6

checkベストアンサー

+4

プロであれば標準規格の設計方式などを身に着ける必要がありますが、
そうでなければ、設計図はまず、フリーフォーマットで書いてみてはいかがでしょうか。

無地の紙(ちらしの裏とかでOK)にそのプログラムに必要なことを書き出していきます。
最初はラフでかまいませんので、いったん書き出せたら、それを清書します。
ラフも清書も何かのエディターを使って書いても良いです。最初は自分のやりやすい方法で。エディターの方が手直しが楽なので慣れてきたらそちらのほうが良いと思います。

あとはそれを一定の法則にしたがってコードに起こしていきます。

「下書き」のようなものと思っていただければ良いです。

書き方が分からなければ、ユースケース図のようなものを参考にしてみると良いでしょう。

2.ユースケース図 2 | TECHSCORE(テックスコア)
http://www.techscore.com/tech/UML/UML2/2-3.html/


読みやすいコードを書くというのは、
設計とはまた違うテクニックだと思います。

ここには書ききれないのでポイントだけ。
それは「統一されている」ことです。
あるルールに従って書かれていて、それが徹底されていること。
特に、そのプログラミング言語で標準的である書き方をすることです。
Javaであれば、IDEの自動フォーマッターやコーディングルール支援プラグインなどを使うのも良いです。

参考リンク:

GoogleのJavaコーディング規約
http://www.infoq.com/jp/news/2014/02/google-java-coding-standards

各プログラミング言語のコーディング規約まとめ - Qiita
http://qiita.com/__moai/items/134329123074337913fb

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

「後から予定になかったものを追加したから読みにくいコードになってしまった」というのは、そもそも追加しにくい書き方を最初からしてしまったか、追加の仕方がまずかったか、のいずれかだと思います。
プログラムは、後から色々と追加するのものです。設計書通りに作って一発で動くものなんてよほど簡単な物以外まず無理でしょう。つまり、プログラムは後から追加修正することはまず避けられないということです。
一般的にはモジュール化を心がけることとクラス定義を十分吟味しながらコーディングを行うことが大切です。

どうすればそれが身につくかですが、個人的には良い手本(サンプルプログラム)をたくさん読むことと、数多くのコードを書くことだと思っています。プログラミング知識はもちろん必要ですが、経験も必要です。読むことと書くことが経験や知識になります。

プログラミングに王道は無いと思います。(一部の天才を除けば)

今回できたプログラムも、もし気に入らないのであれば、どうしたら読みやすくなるかを考えて書き直してみてもいいかもしれません。その場合、一から書きなおすのではなく「リファクタリング」を行えば、動作はそのままで読みやすいコードにできるかもしれません。「リファクタリング」については長くなるのでググってください(笑)

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

その質問をなさるにはまだ失敗の数が足りないかもしれません、とお答えします。
すごい上から目線っぽくてごめんなさい。でも自分が技術を習得してきた軌跡を振り返るに、たぶん段階というものがあります。

今はまだ、良い設計のプログラムを書くことより作りたいものを作って、(そのこと自体を楽しみつつ)その中でプログラムが汚く扱いにくいものに変容していく負けパターンも体感していく段階ではないかと思うのです。
(その意味では、以前回答した「インターフェースの分離」についてご案内は、早すぎたかもしれません)

さんざん残念な経験をしてからyamagenさんご推薦の「リーダブルコード」を読むですとか、arguiusさん、ayumuさんご紹介のUMLについて、またリファクタリングについて勉強してみると感動と発見と圧倒的成長の嵐であるかと思います。

これらにプラスして勉強するトピックをご紹介するならデザインパターンですかね。結城浩「増補改訂版Java言語で学ぶデザインパターン入門」がスタンダードな入門書になります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/01/08 13:00

    付記しますと、私自身は設計図をあまりというか全然重視していません。
    実際にコードを書くのが最良の設計手段だと思っており、書いては消し書いては消しで試行錯誤しながら良い構造を探していくというやり方を取ることが多いです。

    残すコード量より消すコード量の方が圧倒的に多いスタイルなので、このやり方で最も大事なのはタイピング速度ってことになりますかね。

    このやり方が一般的な正義だとは思っていません。計画を立てて行動するのが苦手な自分のキャラクターにあわせたやり方です。

    キャンセル

0

自分はプログラムの設計ではUMLをよく使っています。
まずはユースケースを書いてそれをもとにクラス図などを書けばいいのではないかと

UMLのソフトは無料でastah-communityがダウンロードができるのでそれでいいと思います

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

個人的な意見ですが「読みやすいコード」を書くためには設計図などは必要ありません。
読みやすいコードについては、下記の本が有名なので一度読んでみたほうが良いかもしれません。
リーダブルコード

ちなみに設計図などの各種ドキュメントは、下記のような理由で作成することがほとんどだと思います。

  •  チームで大規模な開発を行う際に新しく入った人や、他の人が書いたプログラムの理解を早めるため
  •  他の人にドキュメントを読んでもらうことで仕様の認識の違いがないか確認してもらうため

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

設計書を書くことは今後もっと大きなプログラムを書くときの練習となるので、おすすめします。

ただし、設計書がきちんとかければ行き当たりのコードがなくなるかというとそうでもありません。設計時に些細な事として見落としてしまったことが、後でソースコードに大きな変更をもたらすこともあります。
だからと言って、設計書の精度を上げるのに時間をかけても、完成が遅くなるだけだったりします。設計書で見つけるのが得意な問題とそうでない問題があることを理解しておいてください。

私の場合は、作るものによってどの設計書を作るかは毎回検討します。設計書を作らない場合もおおいですし、チームで作る際はかなり詳細なものを作ります。また手さぐりのため、作れないこともありますし、分かりきっているから作らないこともあります。

きれいなコードにするためには、後で必要だと分かった仕様を組み込んだ後で、どうあるべきだったかをきちんと検討し、あるべき姿に変更することです。これは、きれいな設計書を各場合でも同じで、どのレベルでどの試行錯誤を行うかということを計画することです。

コードをきれいにすることで、動くコードを動かないコードにする心配があります。そのため、すこしずつ修正し、テストし、失敗したらもとしもどしてください。

そのための技術として、リファクタリングと呼ばれるものがあります。他の技術も要求されるので、習得には時間がかかりますが、非常に効果的です。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.12%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

同じタグがついた質問を見る