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

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

新規登録して質問してみよう
ただいま回答率
85.50%
Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

Q&A

解決済

6回答

4165閲覧

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

omikuji

総合スコア60

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

0グッド

2クリップ

投稿2016/01/04 06:31

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

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

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

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

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

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

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

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答6

0

ベストアンサー

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

無地の紙(ちらしの裏とかで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

投稿2016/01/04 07:07

argius

総合スコア9388

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

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

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

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

投稿2016/01/08 03:21

yuba

総合スコア5568

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

yuba

2016/01/08 04:00

付記しますと、私自身は設計図をあまりというか全然重視していません。 実際にコードを書くのが最良の設計手段だと思っており、書いては消し書いては消しで試行錯誤しながら良い構造を探していくというやり方を取ることが多いです。 残すコード量より消すコード量の方が圧倒的に多いスタイルなので、このやり方で最も大事なのはタイピング速度ってことになりますかね。 このやり方が一般的な正義だとは思っていません。計画を立てて行動するのが苦手な自分のキャラクターにあわせたやり方です。
guest

0

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

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

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

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

投稿2016/01/05 08:48

PineMatsu

総合スコア3579

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

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

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

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

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

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

投稿2016/01/07 03:44

iwamoto_takaaki

総合スコア2883

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

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

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

投稿2016/01/04 12:01

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

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

投稿2016/01/04 06:40

ayumu

総合スコア86

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問