Q&A
適当に行き当たりばったりで書いてみて、気持ち酷くなってきたと思ったらリファクタリングしてます。
フローチャートとか書いたことないわ。
直接プログラムの質問ではないのですが、是非プログラマーの方々の
意見を聞いてみたいと思ったため、ここで質問をさせていただきます。
検索して確認はしたのですが過去に似たような質問があった場合はすみません。
聞いてみたい事はタイトルの通り、「プログラムを組む前の準備」についてです。
以下、思い立った経緯なので読み飛ばしていただいても構いません。
プログラムのプの字も知らない初心者から、
有志の方が作られた既存のプログラムのオプション等を弄ってみる、を経て
1つの処理ごとに調べながらなんとか1からプログラムを組み立てる
くらいまでにはなんとかレベルアップ出来てきたと思います。
（まだまだ初心者のままではありますが...）
ただ、単純なプログラムならそこまで問題は出ないのですが、
複数の処理を組み合わせる必要が出てくると、
同じ処理を何回も書いたり、ifがどんどん入れ子になってしまったり、
完成した後で「○○のパターンがある事を考えていなかった」など
行き当たりばったりでプログラムを組んでしまっているなと感じます。
単純に勉強＆経験不足で作る前に完成イメージが出来ていない、
もっとたくさん組んだらマシになるだろう。と思っていたのですが、
昔学校でプログラムを組む授業の時（※完全触り程度のものです）、
プログラムを組む前にフローチャートを書いたことを思い出し、目から鱗が落ちました。
思えば、初心者向けのプログラムの本や記事では、最初の方にフローチャートを見せながら
概念等を説明しているものが多いように感じます。
ベテランになれば脳内で想像できるようになるのかな...？と思いながらも、
まだまだ初心者なので効率良く出来るよう、
これからはプログラムの前にイメージをしっかり落とし込みたいと思っています。
そこで最初の質問なのですが、みなさんはプログラムを組む前に
どのように考えたり、準備（それこそフローチャートなど）をしているのでしょうか？
その人々によってやりやすい形は違うと思うので、
正解を求めているというよりは、色んな方のパターンを知ってみたいという気持ちです。
恥ずかしながらプログラムよりも前に勉強しなければいけない基礎中の基礎だと思いますが、
ざっくりでも全然かまわないので、もしよければ教えていただけないでしょうか。
長くなってしまい申し訳ございませんが、どうぞよろしくお願いいたします。
【2019.2.18 追記】
皆様の教え全て勉強になることばかりでとても迷ったのですが、
他の方からも高評価を多くされていたtacsheavenさんをBAとさせていただきます。
質問時点で思っていた以上に沢山の事を教えていただき、
いっぺんに頭に入れようとしてちょっと混乱している最中ではありますが、
1つ1つ自分の中に落とし込み、成長できるよう努力していきます。
沢山ご回答いただき、本当にありがとうございました！
また、過去にも似たような記事があったとご指摘をいただいておりまして、
リンクを貼ってよいのか分からなかったので直接リンクは貼りませんが、
この記事内で教えていただいた単語を絡めて検索すると同じような質問がありました！
（最初の検索の仕方が下手くそでした...）
もし私と同じ悩みを持ってクリップしてくれた方がいらっしゃれば、
ぜひそちらも参考にしてみてください。
メンテナンス性を高める観点から、ネストは少なく、メソッドの長さもできるだけ短く簡潔に書くこと、スコープの広い変数も極力使わないことを心がけて開発に取り組んでます。
私もフローチャートを書いてから作業するような余裕がないので、一先ず組む所からスタートしてます。
簡潔なコードを書くにはパターンがあるので、リーダブルコードという本がおすすめですよ
https://www.amazon.co.jp/dp/4873115655
JavaScriptは直接関係なさそうなのでタグから外されては。
内容が近い質問が過去にあったと思うので、そちらを一通り読んでからそれでも何も進まなかった場合に質問してください。
早速のご回答ありがとうございます！
>stdioさん、n_takapyonさん
フローチャートに気づいた時はこれだ！と思ったんですが、別にみなさんやってることでは無かったんですね...
ただリファクタリングするにはまだ効率の良い処理の知識がないのと、
まだ全体の流れを想像するチカラが無いので、一度やってみようと思います。
ネストとメソッドとスコープは私も心がけていきます！
ご回答ありがとうございました！
>tiitoiさん
どの本を読んで勉強したらいいかというのは迷っていたので助かります！
「シンプルで実践的」との文言とても惹かれますので一度読んでみたいと思います。
ご紹介いただきありがとうございました！
>mts10806さん
おっしゃる通り直接の関係はありませんでしたので削除しました。失礼いたしました。
また、過去の記事の探し方が悪かったようなので、キーワードを色々変えて探してみます！
探すのとは別に、こちらの記事はクリップされてる方もいるため、もう少し閉じずにいたいと思います。すみません。
ご指摘いただきありがとうございました！
質問へのご回答をいただき大変ありがたいのですが、
こちらのエリアは「質問への追記・修正」のようなので、
もし他にご意見いただける方は下の回答の方にいただけると助かります！
回答7件
0
ベストアンサー
例えば○○祭、というものだと、進行表としての「プログラム」がありますね。（あるいは幼稚園のお遊戯会なんかでもありますね）。
つまりプログラムとは、もともと行うべき事を順番に記述した物なのです。
逆に言うと、何を行うのかを書き記すことができれば、プログラムができるのです。
そのためには、大きな作業の塊を、より小さな作業の集まりに分解する作業が出てきます。
そのための道具として、古くはフローチャートが考えられ、いくつかの改善を経て UML のシーケンス図などに受け継がれていますが、基本的には やることを箇条書きで順に記す ことができれば、あとは言語に落とし込むことができます。
大きな作業を小さな作業の集まりに分解するのは、それだけ聞くと難しいことをしているように思います。
ですが、日常生活を考えてみてください。例えば「朝、会社に行く」という一つの作業は、実際には
- 起床する
- 身だしなみを整える
- 朝食を取る
- 戸締まりをする
- 電車に乗る
といった、いくつかの作業になります（そしてこの作業は、並行できる部分もあれば順番にこなさねばならないこともあるし、処理しないこともありますね。起床しないで電車に乗るとかできませんし、場合によっては朝食を取らないかも知れません）。
さらにこのいくつかの作業も、例えば「身だしなみを整える」は、
- 服を着替える
- 顔を洗う
- 髪を整える
- 歯を磨く
のように、さらに細かくすることができます。（さらに言えば、「歯を磨く」も、歯ブラシを取り、歯磨き粉を付け、歯を磨く……とさらに細分化ができます）
プログラムの設計も、基本的にはこれと同じです。意識して手順を構築する必要があるだけです。
投稿2019/02/13 09:00
総合スコア13703
「行うべき事を順番に記述した物」をいう説明がとても自分の中でストンと落ちてきました！
UML のシーケンス図を見てみたのですが、こちらは見るのも書くのもちょっと慣れが必要そうですね。
箇条書きで順に記す、大きな作業→さらに細分化というのはすぐ挑戦できることと思いますので、自分で整理する意味でも取り組んでいってみます！
ただ、箇条書きをした時に順番に抜け漏れが出てしまったりするのは、やはり経験や慣れでしょうか。練習あるのみですね。。
全体的にとても分かりやすく説明をいただきありがとうございました！
経験を積んでいても、箇条書きをした時に漏れや順番違いなどは日常茶飯事ですよ（ｗ どれだけ慣れていても、ある程度の確率で発生します。
※もっとも業務なんかだと、あとから「ゴメン、ここ仕様がこうだった」とか設計の前提条件をひっくり返されることも日常茶飯事ですが
ですから間違いを恐れてはいけません。最終的に正しくできあがればいいのであって、最初から正しいものである必要はないのです。
なるほど、幸い私はほぼ社内用なのである程度融通が利きますが、もしこれが先方からの仕事で仕様変更などあったらと思うと想像しただけでも頭抱えそうです...！笑
最初から完璧なものを作れるようにならなくてはという気持ちでいましたが、
tacsheavenさんのお言葉のおかげで、良い意味で気が抜けました。ありがとうございます！
0
これからはプログラムの前にイメージをしっかり落とし込みたいと思っています。
「ソフトウェア設計」について学習・習得されると良いのではないでしょうか。一口に 設計(Design) といっても、作りたいプログラムの規模や種類によって必要な道具(表現方法)やスキルは異なります。
設計フェーズは必ず トップダウン方式 になると思います。つまり大きな目的「これは何を解決するプログラムなのか？」から始まり、次に「このプログラムの入出力データは何か」「ユーザから何を受け取る／何を見せるか」「どんなアルゴリズム・データ構造を使うか」のように詳細化していきます。特殊ケースへの対処についてあれこれ考えるのは、これらの基本方針が固まった後が望ましいです。
一方で、「ソフトウェア設計を隅々まで終わらせてから、具体的なプログラム実装を始める」というやり方は大抵上手く行きません。プログラムを作り始めるまで設計上の問題に気づかない、ということはよくあります。ソフトウェア設計は、あくまでも これから自分が何を作ろうとしているのか見失わない ための道具として捉えるべきです。
（※ 本回答ではSI企業で行われるような大規模システム開発は想定しません。）
フローチャート(Flowchart)は、まさにソフトウェア設計の道具の1つです。ただし、最近のプログラミング言語では必ずしもフローチャートを作る意義は薄くなっているように思います。というのも、フローチャートはプログラミング言語自身の表現能力が貧弱な時代に開発された道具であり、モダンなプログラミング言語ではあえて図示しなくともプログラム処理の流れ（＝フローチャートが表現する情報）を簡潔に記述できます。
一般に、文字（プログラム）よりも図の方が大まかな構造を表現するのに向いていますから、初心者向けの説明ではとっつきやすさを重視してフローチャートが良く用いられるようです。
（※ 個人差や好みがありますから、フローチャートを全否定する意図はありません。）
下記の読み物（記事）もご参考にどうぞ：
投稿2019/02/15 09:12
編集2019/02/15 09:27
総合スコア6191
私の脳内にあった（閃いた？）プログラムの前の準備というイメージが、
まさにこの「ソフトウェア設計」の通りでした。
ですが、yohhoyさんのお言葉と教えていただいた記事を拝見したところ、
何分自分はすぐに仕様を忘れたりマルチタスクで物事を考えていくのが苦手なので、
思っていた以上に今後もっと複雑なプログラムを開発することになった場合必須になってくるのではと感じました。
（ソフトウェア設計もほどほどにするのが大切のようですが...！）
フローチャートの件もとても納得できました！
たしかに視覚的に分かりやすいので知識が無い方への大雑把な説明等が必要になった時にピッタリですね。
ご回答と記事のご紹介ありがとうございました！
綺麗に整形されたドキュメントでなくても、チラシ裏に書きなぐるメモでも十分と思います。
仕様や設計を文書化や図示する行為は、自分自身の中で情報整理するうえできっと役立ちますから。
0
... 聞いてみたい事はタイトルの通り、「プログラムを組む前の準備」についてです ...
プログラムには、作成前、作成中、作成後 という時間の流れがあります。
実は 作成前のことより、作成後が実は大事なのです。
最初に作ったプログラムの版はバグがあったり効率が悪かったりするでしょう。
それに気づき、改善していくサイクルを回すことこそがプログラミングといえます。
- アジャイル開発の本命!? スクラム開発とは何か - DX時代に脚光を浴びる開発チーム運営のベストプラクティス
https://it.impressbm.co.jp/articles/-/16155
- アジャイル開発とウォーターフォール開発の本質的な違いは何？
投稿2019/02/14 13:55
総合スコア22324
「作成後が実は大事」とのこと、たしかにお恥ずかしながら私の現状は、
あまり結果に影響の無いエラーが出たり効率が悪い場合でも最初に作った状態のまま、になっている事が多いです。
教えていただいた記事を拝見し、自分は「プロジェクト」といえるほどの規模のものではないので萎縮してしまいましたが、各中身を自分個人として置き換えてみると、とても勉強になることばかりでした。
例えば、色々盛り込んだ最初の仕様から最後まで突っ切るのではなく、優先順位を決めて段階的に開発＆テスト、その都度柔軟に変更。ということであればすぐに取り組めることと思います。
出来ればせめてもう一人、一緒に出来るメンバーがいれば良いのですが現時点だと難しい課題のため、
それ以外のところで吸収出来そうなところを探して挑戦していきたいと思います！
ご回答いただきありがとうございました！
0
複雑な/やることが多い関数を書くときという認識で回答してみます。
- まずはコメントで大まかにやることを書いていきます。tacsheavenさんがかいているような手順ですね。
- 書いている手順を実装していきます。このとき、いくつか選択肢があります。
-その関数にそのまま実装する
-別の関数に分ける
-クラスを作る
たった2ステップですが、2つめが試行錯誤の連続です。
選択基準は、 他人（もしくは未来の自分）がコード理解できるまでの時間が短いかどうか。
すべてを1つの関数に実装してしまうと何をしているのか読むのが辛くなってしまうので、小分けにする必要が出てきますが、どのように分けるのかは腕の見せ所です。
関数に分けるにしても、正しい名前を付ける、再利用性を考える、1つのことだけをやる、など考える必要がありますし、
クラスにしても、１つのものだけ管理させる、関数を分けるのと同じように適切にメソッドを作るなど、考えることはたくさんあります。
tiitoiさんが書いてくれているように、リーダブルコードは読んでおいたほうがいいと思います。たしかこのあたりのことも書いていたはずです。
また、もう一つ別のやり方を紹介しておくと、TDDというものがあります。
ざっくりいえば、最初にテストを書き、そのテストが通るように実装していくやり方です。
https://www.valtes.co.jp/qbookplus/1069
下手に導入すると却って大変になってしまったりするので、ひとまずはこういうやり方があるんだ、ぐらいでいいと思いますが、テストを意識してコードを書くという視点は持っておくといいと思います。
投稿2019/02/14 03:08
総合スコア456
今まで1つ目の大まかにやることがまず「脳内でぼんやり」という状態でしたので論外ではありましたが、
Kta-Mさんのおっしゃっている通り、2つ目で泥沼にハマってしまいます。
全部を1つの関数で実装しようとして、読みづらく、
さらに修正しずらいコードになってしまっているのが現状です。
関数を分ける、クラスを作るをまず覚えるところからですが、
それぞれKta-Mさんのお言葉にある事を気を付けていきます！
「腕の見せ所」というのは心惹かれますね！
リーダブルコードも早速通販で購入しましたので、
シンプルで分かりやすいコードが書けるよう精進します。
記事のご紹介もありがとうございます！
TDDを知らなかったため早速読ませていただきました。
「必ず失敗するテストコードを書く」とあって驚いて笑ってしまいましたが、
最後まで読み、こんな方法もあるのかと感服いたしました。
導入の見極めが難しそうですが、幸い私がプログラムする時は
時間に限りが無い場合が多いので、いつか挑戦してみたいと思います。
ご回答いただきありがとうございました！
自分の課題をしっかりと認識して、普遍的なノウハウを尋ねる質問に落とし込んでいるのは素晴らしいなと思いました。とても大事な姿勢だと思います。
良いコードを書くには、書く量(経験)も大事ですが、どうすればより良くなるか常に考える姿勢はもっと大事だと思います。私も日々試行錯誤です。
満足のいくコードが書けたときはとても楽しいものです。がんばっていきましょう！
教えて貰えるような方もおらず、本やネット上の記事で調べながら右往左往している状態なので大変恐縮です..！
最初はプログラムに苦手意識を持っていたのですが、少しずつですが自分で書けるようになってきた今、その楽しさが分かってきました。
良いコードを書けることを目標に成長していきたいですね..！ありがとうございます頑張ります！
0
擬似コードを書いてます。
単純に勉強＆経験不足で作る前に完成イメージが出来ていない、
……といいますが、具体的にどうやって実現するのかは調べるのは後回しにして、まずプログラムの大枠の完成イメージを(日本語で)書いてしまいましょう。
日本語で書いておいた1つ1つの処理の実現方法は、その後で調べればよいのです。
ちなみにフローチャートで書く必要はありません。
フローチャートは、実行中の行を自由にジャンプ出来ていた時代にあえて２次元に書ける処理の流れしか許さない制約を入れる為にあったものだと思います。
構造化言語が普及した現在では処理の流れが分からなくなることは通常ありませんので、さらに「２次元で書ける」という制約を入れて処理を作る必要はありません。
投稿2019/02/16 04:21
総合スコア4524
仕様が出たらまず調べる！をしてごちゃごちゃと混乱してしまっていたので、
「まずプログラムの大枠の完成イメージを書く」は本当に大切だなと感じています。
完成をイメージで書く、1つずつ処理を調べる、疑似コードでテストする、
私の知識では都度躓くと思いますが、一番理解も深まり近道になりそうです！
実行中の行を自由にジャンプ出来ていた時代があったんですね..！？
あんまりその時代のイメージができませんが、古い手法だということは理解できました。
他にもっと手軽だったり便利だったりな手法があるようなので、
フローチャートには拘らず、色々試してみようと思います。
ご回答ありがとうございました！
0
やりたいことができていれば（要件を満たしていれば）、それは「とりあえず立派」なプログラムです。
本当に大丈夫（ちゃんとできている）か、問題の規模や複雑性が大きくなったときに今のやり方が破綻しないか、といった懸念はありますが、まずは自信を持ちましょう。
「とりあえず立派」なものを書いてから「あっ、ここの書き方はダサい」とか思ったら、そこは手直ししましょう。katoyさんも仰っていますが、「作成後が実は大事」です。
もちろんお仕事なら無限にリファクタリングできる訳ではないし、「ここ変えるとシステムの根幹が覆ってまるごと作り直し・・・」みたいな部分に限ってイケてない設計が埋まってたりするものですが、それは苦い経験として記憶に刻み込みましょう。
でも、
同じ処理を何回も書いたり、ifがどんどん入れ子になってしまったり、
完成した後で「○○のパターンがある事を考えていなかった」など
みたいな粒度の話なら、影響範囲は関数・メソッド1つとか内部的に使うクラスとかその程度だと思うので、直そうと思えば割と自由に直せるはずです。
そうやってコードをリファクタリングする経験を積むうちに、最初からうまくやる方法論がわかってくるかもしれないし、なんかよくわからないけどうまくできるようになるかもしれないし、そういう得られるものがなくても最悪リファクタリングすれば良いと達観することはできます。
ただし、リファクタリングするベネフィットとコストは考慮すること。
投稿2019/02/15 19:39
総合スコア30933
「とりあえず立派」なプログラムは現時点でも出来ているんだと少し自信が持てました！
hayataka2049さんのお言葉を見て、スマートに書けるようになるにはまず
「どこの書き方がイケてない」か気づけるのも必要だなと感じました。
書く前の諸々の準備の練習と並行して、他の方の書き方をもっと沢山見ることを強化していきたいと思います。
おっしゃる通り、恐らく最終的にあまり影響の無い部分だけど「なんか気持ち悪い..」という感じなので、
他の方のコードを参考にしつつ、リファクタリングの経験を積んでいきます。
また、「ベネフィットとコストは考慮」は心に刻んでいきます...！笑
ご回答ありがとうございました！
0
フローチャートでは具体的すぎて設計にならないのでもっと抽象的な部分を考えましょう。
まずやりたいこと、必要な機能をもれなく列挙することが必要です。
次にデータベースが必要なのか、サーバークライアント通信が発生するのか、単体で完結するのかを確認します。
そしてプログラム中でのデータ形式を決定していきます。設定ファイルや通信データ、データベースとの対応データなどに始まって各状態ごとに持っているべきデータなどいろいろありますね。
あとはこれに対する操作や順序、遷移をまとめて
単体テストを書きます。まずテストです。
テストが落ちることを確認したら実装を始めます。
もちろんどういう分野/レイヤーのプログラムなのかによるとは思いますが。
投稿2019/02/15 10:09
総合スコア5850
フローチャート、たしかにおっしゃる通りです。
他の方の回答からも、最初にまず目的を箇条書きでも何でも列挙する事を学びましたが、
次の「データベースが必要か」等の確認は頭から抜けていたため、
また躓くところでした。ありがとうございます！
各項目に対してそれぞれ単体テストは必須ですね...！
ご回答ありがとうございました！
あなたの回答
tips
プレビュー
