- ベストアンサー
プログラミング作業効率を上げる工夫、テクニックについて
PHP（ver.4)からプログラミングを独学で始めた者です。 職業プログラマーではありません。 C言語、JAVAの知識はほとんどありません。 HTML、CSSはある程度分かります。 PHPの習熟度について、どう説明してよいか悩みますが、 オブジェクト指向（※クラスを使ったスクリプト作成…？）にはまだ手を出せていないレベルとでも言いましょうか…。 自作関数をまとめたファイル、定数を定義したファイルを、config.incに入れて、それをrequire_onceで読み込み、というようなことをしています。 クッキーや、セッションもまだあまり使えていません。 データベースはSQLite2を少々使えます。 MySQLなどは今のところ使えません。 <form>で値をGETやPOSTで受け取って処理するということを頻繁にしています。 レンタルサーバを利用してサイトを制作中です。 程度は低いですが、今までに作ったもの、作ろうとしたものは、 ブログシステム（６割完成）、チャット（８割完成）、アクセス解析（６割完成）、といった感じです。 当面は、これらをそれぞれ完成させる作業をしていきたいと思っています。 エディタはdreamweaverCS3をメインに使っています。 他に、FFFTP、TepaEditorを使うこともあります。 秀丸は持っていませんし、また、使ったこともありません。 こんな私ですが、 スクリプトファイルが多くなってきたり、１ファイルのコード行数が300を越えてきたりすると、もう頭の中がごちゃごちゃしてきて、どこに何が書かれていて、、、とか、このコードはどういう意味だったかな、、、とか、これを書き換えたら、他のどの部分に影響が出るだろうか、とか、ファイルの配置、ディレクトリ構造はどうすべきか、どのようにしたら効率的か、など、そういうものの明確なルールが私の中で出来ていない状況です。 どう学んだら良いものだろうかと思い、質問をさせて頂きました。 もし、オススメのサイトや書籍がありましたら、そちらも教えて下さい。 というわけでして、 スクリプト作成前の心得とか、サイト設計、作成計画や作成順序、などといったものを考える際の指針のようなものを、経験者の方に示して頂けたら嬉しく思います。 効率よく言語を習得するための方法論を展開されても結構です。 根本的かつ大きく漠然としたテーマについて、質問しているということは分かっています。 全てを完璧に答えて頂こうとは思っていません。 この質問をお読み頂き、 「この点については、かなりタメになりそうなことが言えそうだ、自分も苦労したし。」 というようなスタンスでアドバイスして頂ければと思っています。 なお、他のプログラミング言語にも興味があるので、 PHPを理解する上で、C言語やJAVAの考え方が分かっていた方がいい、 ということであれば、学ぼうと思いますし、 MySQLも使えた方がPHPの利用の幅が格段にアップするはず！ ということでしたら、MySQLを是非習得したいと思います。 そういうアドバイスも大歓迎です。 「できない、しない、無理、あきらめます」は、言わないつもりです！笑 すべて前向きに、乗り越えていくつもりです！ ですので、思い切ったアドバイス・回答をお待ちしております。 頂いたレスポンスには、必ずお返事します。 以上、よろしくお願い致します。
- みんなの回答 （6）
- 専門家の回答
質問者が選んだベストアンサー
その他の回答 (5)
- hogehoge78
- ベストアンサー率80% (433/539)
＞hogehoge78さんは、頭の中に設計図を書けてしまうから、これまで書く必要性を感じなかっただけなのでは？笑 こちらの件に関しては、一度ある程度フレームワークなどを使うようになると、フレームワークはアプリケーションの「骨組み/枠組み」を提供してくれるものですので、ソースコードが書き始める時点で既に整理されており、設計図を書かずとも、後でソースを見ても大体把握できるかなと、思います。 （ついでに同じアプリケーションについて何度も書き直しているとやりたいことがかなり頭に入ってくるという・・・） 設計書や設計図を引くというのは、自分自身でまとめる為、という意味合いのほかに、他者にそのアプリケーションの内容を伝える意味合いもあります。 また、仕事上アプリケーションを作成する場合、かなり巨大なものを作成することになることがあった場合は、後で確認できるドキュメントがないと、修正するのが困難になるということもあるのだと思います。 日曜webプログラマということであれば、作成するのは自分自身で、使用するのも自分自身、且つ、一人で作成出来る程度の規模感となるので、ソースコード中にコメントを書くことぐらいでよいのではないかな、というのが私の考えです。 ただ、学習という意味合いでも、今後もし仕事でPHPを使う場合でも、これから作成するものと直接関係のないところで役に立つことがあると思いますので、 是非設計書を書くということは行って見て下さい。 設計書を書く癖をつければきっとPHP以外でも仕事が速くなると思います。 ※今私は無計画に回答文を作成しており、見直しながら何度も調整している為、時間がかかってしまってます（笑）
お礼
ありがとうございました（＾＾） また何かありましたら、教えて下さいね。
補足
アドバイスありがとうございます。 ＞こちらの件に関しては、一度ある程度フレームワークなどを使うようになると…（略）…設計図を書かずとも、後でソースを見ても大体把握できるかなと おそらく、そういうことなんだろうなと思っていました。（＾＾ ＞ただ、学習という意味合いでも、今後もし仕事でPHPを使う場合でも、これから作成するものと直接関係のないところで役に立つことがあると思いますので、是非設計書を書くということは行って見て下さい。 はい＾＾ 設計図・設計書の威力を知ることも大事だろうなと思っています。 ただ、具体的な書き方がよく分かっていないので、それをなんとかしたいな、、、と思っています。 どうせなら、業界標準の方法で習得したいですね。 皆さんの言われている設計図・設計書というのは、どのようなものなのでしょうね？ 例の、あれですかね、、、□とか◇を書いてその中に文字を書き、さらに、それらを線で結んだり…分岐点では二股にしてみたり…という。 やっぱり、あれなんでしょうかね。。（＾＾； ＞※今私は無計画に回答文を作成しており、見直しながら何度も調整している為、時間がかかってしまってます（笑） 私の質疑応答ではしばしば補足が長いので、レスポンスに時間を要しますよね。（＾＾； 毎回、ごめんなさい。そして、ありがとうございます。＾＾
- Tasuke22
- ベストアンサー率33% (1799/5383)
ANo.3です。追加です。 小さな問題かもしれませんが「システム」という言葉の 概念をきっちり勉強することをお奨めします。 うーん、そういうと「情報」も重要かも。 「システム」は巷で使われている意味は、正しさでは ほぼ全滅です。 辞書的に書くと-複数の独立した要素が、お互いの関連を 持って、1つの目的を実現するもの- ますます抽象化されたような説明ですね。解説にはやはり 本1冊必要でしょう。 「情報」も効率の良いプログラミングや間違えにくいプロ グラムには欠かせない概念のベースです。
補足
言葉の概念を正確に捉えることの重要性について意識させられました。 今後、より一層、気をつけて読んだり書いたりしていかなければと思いました。 補足、ありがとうございました。
- Tasuke22
- ベストアンサー率33% (1799/5383)
結論から先に書くと、オブジェクト指向を理解し活用する ことになろうかと思います。 ご質問内容を読むと、ご自身をかなり客観的に分析されて おり、それがあまりに完璧なので、ご質問自体が何かワナ ではないか、と疑ってしまうくらいです。プロでもここま で分かる人は、そうそう居ますまい。 あなたが開発を行う上で悩まれていることは、数十年も前 からの悩みです。そこから「構造化設計」とか「複合設計」 などの概念が生まれ、所謂、プログラムを「モジュール」化 し、1つのモジュールの性質を分析し、如何に良いモジュー ルを作るか研究されてきました。 そのモジュールの性質がどうしてもあるケースにおいて完璧 な理論が当てはまらなくて壁にぶつかっていた時に、オブジ ェクト指向の概念が生まれ、モジュール化設計の概念が完成 されたと言ってもいいくらいです。 モジュールとはPHPで言えば「関数」に当てはまります。 1つ1つの関数の性質を、そのインターフェイスと機能で分析 します。 インターフェイスとは、引数と関数値と副作用の内容と性質。 機能は、そのものズバリ、何をするのか、です。 機能がその関数で閉じて、他に影響を与えない性質ほど機能 的強度を持つ、とし、インターフェイスも必要最小限である ほど独立性が高いし、両方を兼ね備えたモジュールを情報的 強度を持ったモジュールと捉えますが、例えば、入出力などの、 open,read,write,closeなどの1連の関数群がうまく設計でき ません。 そこで、そのopen,read,write,closeなどを1つのオブジェク トとのメンバー関数とすることにより、機能的にもインター フェイス的にも強いモジュールになる訳です。 それらの強度を持ったオブジェクト群は理論的にも、人の 思考の中にでも強い独立性を持ち、とても考えやすいツール に発展するでしょう。 マイヤー著の「オブジェクト指向入門」を私はお奨めしたい です。
お礼
ありがとうございました（＾＾） また何かありましたら、教えて下さいね。
補足
アドバイスありがとうございます。 ＞オブジェクト指向を理解し活用することになろうかと思います。 私もそのような気がしています。 ただ、よく分からない世界なので、二の足を踏んでいます。笑 ＞それがあまりに完璧なので、ご質問自体が何かワナではないか、と疑ってしまうくらいです。 私には、この評価こそワナなのではないかと思えてなりません。笑 私は本当に未熟な一介の日曜webプログラマーです。 種も仕掛けもありませんので、どうぞよろしくお願いします。 ＞所謂、プログラムを「モジュール」化し、1つのモジュールの性質を分析し、如何に良いモジュールを作るか 聞いていて気持ちの良い話ですね。笑 機能のまとまりごとにプログラムを独立させ、汎用性を高め、 自由に入れたり、取り除いたりして、1つの大きな機能が作られるという考え方にとても興味があります。 モジュール化、していきたいですね～。 （過去にお世話になっていたXOOPSを思い出しました。） 日頃、散らかったコードに苦しめられているので、早くスッキリしたい～。苦笑 ＞それらの強度を持ったオブジェクト群は理論的にも、人の 思考の中にでも強い独立性を持ち、とても考えやすいツール に発展するでしょう。 そんな夢のような世界が「オブジェクト指向」の扉の向こうにあるのだとしたら、今すぐ飛び込まない手はないですね。 ＞マイヤー著の「オブジェクト指向入門」 早速調べてみましたが、かなり難解そうな本ですね。笑 入門と書いてはあるが、初心者には難しいだろう、 というような書評を読んだ感想です。 お値段はまぁ、素晴らしい世界への入場料だと思えばそれほど気にはならない価格ですね。 オブジェクト指向というものを、自分なりにもう少し掘り下げてみようと思います。
- aigaion
- ベストアンサー率47% (287/608)
コメントを書くことが重要です。 変数であれば ・何のためのものか ・どこで使われるのか 関数であれば、 ・入力の値 ・関数内の処理 ・関数の戻り値 を中心に書く。 入出力を明確にしておけば後から依存関係で困ることも少ないはずです。 // 引数２つを足し合わせる // $i 足し算の左辺であり、0～65535 の範囲の整数を想定 // $j 足し算の右辺辺であり、0～65535 の範囲の整数を想定 // 戻り値 $i + $j を行った結果であり 0 ～ 65535 の範囲の整数 function sum ($i, $j); プログラムの中で気になる部分があればそれもコメントで書いておく。 また、あとからみてどうすれば良いかを記号とか使ってわかりやすくする。 $a = $b + $c ; //FIXME ここは足し算をする ファイルの先頭には、そのファイルが何をするためのもので 中にはどんな関数があるかの一覧を書くなど後から見て一目で判断できるようにする。 コメントはあくまで自分が見るものだと思って簡易に書くのではなく あとから他人が見てもわかるように意識をして書くようにしましょう。 なぜって、プログラムを書いた１月後くらいにはそのプログラムは自分で 書いたにもかかわらず他人が書いたかのように意味不明に見えるからです。 ・プログラムの書き方を自分の中で決める コメントと似たようことですが、自分の中で例えば「 if 文の｛｝の対応はこう書く」 あとから見てわかりやすいようにプログラムを書いておくことですね。 職業プログラマーでないなら自分で作ったプログラムをＷＥＢ公開しても支障は あまりないとおもうので、それをＷＥＢにアップして意見を求めるという形もよいかも知れませんね。 おそらく質問者さんはまともな設計図書いてなく直感でプログラム書いていますね。 熟練者でもない限りこういったことは避けた方が良いですね。 設計図を書いてその通りに作り、うまくいかなければ設計図を練り直し・・・とやっていた方が良いかと思います。
お礼
ありがとうございました（＾＾） また何かありましたら、教えて下さいね。
補足
アドバイスありがとうございます。 「コメントの重要性」について、改めて痛感させられました。 駆け出しの頃に比べ、やや詳細にコメントを書くようになったとは言え、 今回アドバイス頂いた内容を読み、まだまだ至らない部分が多いことに気付かされました。 ＞なぜって、プログラムを書いた１月後くらいにはそのプログラムは自分で書いたにもかかわらず他人が書いたかのように意味不明に見えるからです。 私にも経験があるので、ちょっと笑ってしまいました。笑 自分が書いたというのに自分に優しくないコードを見ると、 「なんでぇ。。。涙笑」って思えてきますよね。 ＞職業プログラマーでないなら自分で作ったプログラムをＷＥＢ公開しても支障はあまりないとおもうので、それをＷＥＢにアップして意見を求めるという形もよいかも知れませんね。 んー、恥ずかしい。笑 でも、そういうお尋ねの仕方もあるんだな、ということを知りました。 機会があれば、そういう方法も今後検討してみたいと思います。 ＞おそらく質問者さんはまともな設計図書いてなく直感でプログラム書いていますね。 まさに、その通りです。笑 ＞設計図を書いてその通りに作り、うまくいかなければ設計図を練り直し・・・とやっていた方が良いかと思います。 設計図の上手な書き方というのは、やはり、数多くの試行錯誤を経て 身につくものなのでしょうか？ 痛い目に沢山合うことが良薬なのでしょうが、出来る限り、効率よく（時間をあまり掛けずに）学べたらなと思っているので、設計図作成に関する参考になる資料や考え方をもしご存知でしたら教えて頂けるとありがたいです。 私の誤解かもしれませんが、 プログラミング言語は、CかJAVAからスタートする人が多く、 そこで皆、基本的な土台を学んでいるような気がしています。 なので、そうした人たちがPHPを学ぶ場合、すぐに構文やルールの習得に取りかかれると思うのですが、PHPからスタートする私のような人間は、基本的な土台の部分を学ぶ機会を持たずにPHPを学ぼうとするので、こうした悩みというか問題が発生するのではないかと思うのです。 現在出版されているPHPの本の多くが、土台部分をスキップした構成になっているように思います。 よって、CやJAVAで１度しっかり土台を学んで来るというのも、1つの方法なのかなとも思っていたりするのですが、それは考えすぎでしょうか。苦笑
- phoenix343
- ベストアンサー率15% (296/1946)
|ブログシステム（６割完成）、チャット（８割完成）、アクセス解析（６割完成）、といった感じです。 凄いがソースを見ない限りはちとアドバイスできないな しかしちゃんと設計書は作っているのか？ 個人的なもので単純な動作をさせるだけなら、設計書書かなくても出来るであろうが、大規模なものになれば設計書をきちんと作成するべきだ。
お礼
ありがとうございました（＾＾） また何かありましたら、教えて下さいね。
補足
アドバイスありがとうございます。 ＞凄いがソースを見ない限りはちとアドバイスできないな いや！誤解ですったら！笑 自分が使う機能しか実装していない、限定的なシステムです！ この質問に回答をして下さる方達の想像するソレとは、雲泥の差がありますので、そこのところは誤解なきようにお願いします！ それがどの程度の差なのか、については、私の質問文から分かるその力量からご判断下さい。。。苦笑 ＞しかしちゃんと設計書は作っているのか？ キーワード１「設計書」。 まず、プログラミングの際には、「設計書」なるものを作成すると良いわけなんですね！？ 考え方として、そういうものが有った方が確かに良さそうだなぁという反応を、今しているような私ですので、もちろん、そういったものをちゃんと考えたことはありません。 ただ、似たようなことはしているかもしれません。 ノートにざっと落書きをして、ファイルはこんな機能のものと、あんな機能のものが必要なのだろうなー、ディレクトリはこっちがここで、あっちはあの中だなー、というようなことを直感でやっています。 そう、直感なんです。 だから、毎回、1から考えているようで効率が悪いのです。 そして、度々修正しては、時間を浪費している気がします。 ＞大規模なものになれば設計書をきちんと作成するべき はい、私もそう思います。その結果の、この質問なのだと思います。 そこで！ 設計書というのは、皆さん、どのように学ばれたのでしょうか。 プログラミングの本はかなり読みましたが、そうした設計書の書き方について書かれた本に未だ出会ったことがなくて、、、。 もし、どなたかお分かりになりましたらご教授下さい。
お礼
ありがとうございました（＾＾） また何かありましたら、教えて下さいね。
補足
目から鱗が落ちるようなアドバイスをありがとうございます。 とても親しみやすい内容だなと感じました。 まず、紹介して頂いたURLは、みっちり読ませて頂こうと思います。笑 読む前からワクワクしています。 お察しの通り、私は「命名規則」など、自分の中で確立すべきものが、まだ確立できていなく、それらについてもどうしようかと思案していました。 そこへこのアドバイスですから、とても助かります。 hogehoge78さんの回答は、毎回、読んでいて頭の中が整理されていくようで、不思議なんですよね。 私の向いている先を一回り大きな視野で眺め、その中から私に必要な用語や概念を拾ってきて、整理して提示してくれる、そんな印象です。 それはさておき、 ＞以前自分の作成したプログラムをもう一度（とはいわず二度三度）書き直す、 こういうことは結構していますね。（苦笑） 改良しては、 「あっ、こんな方法も知っちゃったから、また改良しなきゃ、でも、そうなると、全体的にグレードを底上げしたほうが良さそうだな、って、どのファイルのドコを変えれば、、、？！ぐはっ。」 を繰り返していましたし、今でも繰り返しています。笑 このようなことを繰り返している自分を、 「自分って、、、もしかして、相当なお馬鹿なのでは…。（今更ｗ）」 と思ったり、また、目の前の整頓されていないコードやファイル群を眺め、 「いつになったら、この作ろうとしているスクリプトは完成するのだろうか…。」 と脱力感に襲われたりして、精神的にまいってしまいそうになることが多々あります。 でも、プログラミングの楽しさの方がそれらを上回るので、このように、 続けてこられているのだと思いますが、やはり辛いものは辛いです。 無駄話が過ぎました。次へ進みます。笑 ＞そのついでにクラスの書き方や利便性を知る おそらく、今自分は、まさにこの段階なのだと思います。 ＞ここまできたら、今度はフレームワークを触ってみるとして、 この考えは、今の私には全くありませんでした。 そもそも、ほとんどこの「フレームワーク」という言葉の意味を知らないので、良いも悪いも判断できない、というのが正確な所ですね。 待ってろよフレームワーク！と、今の段階では思っておきます。笑 以前、本屋さんでCakePHPに関する本を読み、「なんだかこれは自分には関係なさそうだな」ポイっと、本をすぐに戻したことがありますが、その段階ではまだ早すぎたのでしょうね～。 （もっとも、今でもまだ早そうですが～。笑） ＞導入が比較的楽な、CakePHP、CodeIgniterあたりでブログサイトなどを書き直し。 一般化された言葉の後に、それを受けて、具体的な例を挙げて頂く… この流れに、いつも助けられております。 モヤモヤが少し晴れてきましたよ～。（＾＾ ＞そうするとフレームワークの動きが気になって ～～～（中略） ～～～ 処理の流れを追うという勉強もすることになります。 ここ！ 今から楽しみです！ とても現実的かつ具体的なお話でイメージしやすく助かりました。 この段階を乗り越えられたら、相当な使い手になれているように思います。ムフフ。 ＞私の場合、最初に触ったプログラムはPerlでした。 私の場合は、XOOPSでした。（言語じゃない 笑） XOOPSで動的サイトを、プログラミング知識抜きで作ろう！なんて思って手を出したのですが、触っていくうちに、PHPファイルの中身が気になるようになり、また、作ったXOOPSサイトがやたら重くて、これでは使い物にならないと感じ、ならば、自分に必要なものだけを集めた軽くて使い勝手の良いサイトをPHPを使って作れないものだろうか、と思ってこの道に飛び込みました。 それからはもう、数多くのプログラミング本を読みあさりましたね…。 長い道のりでした。。（それでこの実力かよ、というツッコミは抜きでｗ） もっとも、XOOPSがPerlで書かれていたら、今頃、Perlを勉強していたのではないかと思います。 ＞実際設計図なんかは引いたことはありません（笑） えっ？！ そうなんですか。笑 私は設計図を書く気満々でいたんですけども！ hogehoge78さんは、頭の中に設計図を書けてしまうから、これまで書く必要性を感じなかっただけなのでは？笑 私のような人間には、（略）…笑 って、話が毎回長くなり、申し訳ありませ～ん。＾＾；