![[dir] プログラミング](https://logo-imagecluster.img.mixi.jp/photo/comm/59/80/105980_186s.jpg){kind=logo}
|
|
|
|
コメント(72)
<余談>
議論の質問に対しては真正面から、議題に沿って、適切に、返すのが議論を行っている者の努めだと思っています。「私」は。押し付ける気は毛頭ないですが。
リスクがあるなら回避するし、選択するものそれぞれにリスクがあるなら、どちらのほうがより「顧客」に影響が少ないか判断して決めることを求められるのが、エンジニアだと思うんですけどね。
ま、プログラマの都合で、趣味で、組むだけなら好きにすりゃいいかなー。プログラマの都合のいいよにすりゃいいこったし。
っていう、議論の最中に言う独り言はチラシの裏にでも書けばいいと思うんですがね。
</余談>
真面目に答えないのもなんですから、ここからは真面目にいきます。
>>すずきさん
ドキュメンタ利用しようが、どんなに優れたシステム使おうが、100%の利用を促すことができない、人はミスをする、という解答にはなりえません。論点をそらさず解答していただけると助かります。
論点がご理解いただけていないのであれば、それは私の文章が拙いことも理由にありますでしょうから、真正面から、「理解できない」と言っていただければいいことだと考えます。
私は、あなたが、「これさえあれば問題ないんじゃない？」と言う根拠が、「理解できません」。私の反論に対しての反論を示すことによってのみ、相互の理解を得ることができると考えますが如何ですか？
もし私が理解しなくてもいいと思っていらっしゃるのなら、そう仰ってください。
議論の質問に対しては真正面から、議題に沿って、適切に、返すのが議論を行っている者の努めだと思っています。「私」は。押し付ける気は毛頭ないですが。
リスクがあるなら回避するし、選択するものそれぞれにリスクがあるなら、どちらのほうがより「顧客」に影響が少ないか判断して決めることを求められるのが、エンジニアだと思うんですけどね。
ま、プログラマの都合で、趣味で、組むだけなら好きにすりゃいいかなー。プログラマの都合のいいよにすりゃいいこったし。
っていう、議論の最中に言う独り言はチラシの裏にでも書けばいいと思うんですがね。
</余談>
真面目に答えないのもなんですから、ここからは真面目にいきます。
>>すずきさん
ドキュメンタ利用しようが、どんなに優れたシステム使おうが、100%の利用を促すことができない、人はミスをする、という解答にはなりえません。論点をそらさず解答していただけると助かります。
論点がご理解いただけていないのであれば、それは私の文章が拙いことも理由にありますでしょうから、真正面から、「理解できない」と言っていただければいいことだと考えます。
私は、あなたが、「これさえあれば問題ないんじゃない？」と言う根拠が、「理解できません」。私の反論に対しての反論を示すことによってのみ、相互の理解を得ることができると考えますが如何ですか？
もし私が理解しなくてもいいと思っていらっしゃるのなら、そう仰ってください。
一応ずっと拝見していたので。少しだけ(…の割りに長文ですが。ちゃんとした話を書くとどうしても。一言言い捨てるだけでは会話になりませんから)。
Kryu^2さんのおっしゃっているお話の
> この場合は、本来のOOPが考えられた背景にある「内部状態の変更に強い」をメリットとしているはずですから。
と、こーどどらんくさんのおっしゃっているこのお話。
> ドキュメンタ利用しようが、どんなに優れたシステム使おうが、100%の利用を促すことができない、人はミスをする、という解答にはなりえません。
私がglobalをことのほか忌避する理由の大本は大体このあたりです。
で、ついでに書きますと。私は、直下でモノ(class)を作らせるとき。例え内部であろうともすべて必ず「アクセッサ経由」でのみ、変数のアタッチを許可しています(アクセッサそのものは変数を直接触りますが)。
これら(globalはNGとアクセッサを必ず使う)は、
・ミスをさせない
というよりも、もうちょっと未も蓋もなく
・ミスが発生したときに「せめて補足できるように」するため
です。
平たい話。globalな変数に「ついうっかり別所でおかしな設定をした」場合、探し出すのに苦労します。
アクセッサを使ってるのであれば、とりあえずそのおかしな情報のセッターにデバッグプリント１行ぶち込むだけで、ある程度状況が分析できます(少なくとも「変な値を入れられている」事くらいは判明するし、大体の場所も簡単に補足可能)。
このあたりの差異は小さくないと思うのですが。
特に、private修飾子などのない、PHP4においてこの発想が顕著でした。PHP5ですと、ある程度、縛りもできるのですが。
そう。一応念のため。
「IDEの機能で探せるからいいじゃん」という話は、私は切り捨てます。
手段は常に「複数を同時に走らせて」なんぼ、ですから。たった一つの手法に縛られると、どこかで抜け道と落とし穴がまってます。
ドキュメントを用意すればうっかりミスは存在しない。或いは「ミスは意識すれば防げる(過去に現場で本当にこう言った人がいました)」。
意識でミスが防げるくらいなら。私はまず、配下の子達に「自己暗示法」でも覚えさせます。或いはもっと平たく「ブレインウォッシュメソッド」を用いてもよいわけです。
ドキュメントを読めばうっかりミスが防げるなら。それこそ朗読会でも開きます。これで「確実に」読ませることが出来るわけですし。
ドキュメントは大切です。意識も大切です。それでも「こぼれてしまうミス」はあるのが、少なくとも私の知っている、私の周囲の現実です。
その「こぼれてしまうミス」を、可能ならどうやって「不可能に」するのか(こういう点において、C++のコンパイルの通りにくさ、C言語のlintは秀逸ですねぇ。Javaの場合「きれいに設計できるclass」部分できっちりとヘッジするのが好みです)。それが無理ならせめて「いかに速やかにミスを探し出せるようにするのか」。
お仕事でコードを組んでいる、組ませている私にとっては大きな関心事項です。
「故に」。
問題が発生したときに「面倒」なので。且つ「使わないことによる明らかなデメリット」が、現状知っているかぎりでは「ない」ので。
何らかの「明示されるデメリット」がないかぎり、私はglobalは「NG」だ、と思ってます。
これを読まれている方の何かの参考にでもなれば幸いです。
Kryu^2さんのおっしゃっているお話の
> この場合は、本来のOOPが考えられた背景にある「内部状態の変更に強い」をメリットとしているはずですから。
と、こーどどらんくさんのおっしゃっているこのお話。
> ドキュメンタ利用しようが、どんなに優れたシステム使おうが、100%の利用を促すことができない、人はミスをする、という解答にはなりえません。
私がglobalをことのほか忌避する理由の大本は大体このあたりです。
で、ついでに書きますと。私は、直下でモノ(class)を作らせるとき。例え内部であろうともすべて必ず「アクセッサ経由」でのみ、変数のアタッチを許可しています(アクセッサそのものは変数を直接触りますが)。
これら(globalはNGとアクセッサを必ず使う)は、
・ミスをさせない
というよりも、もうちょっと未も蓋もなく
・ミスが発生したときに「せめて補足できるように」するため
です。
平たい話。globalな変数に「ついうっかり別所でおかしな設定をした」場合、探し出すのに苦労します。
アクセッサを使ってるのであれば、とりあえずそのおかしな情報のセッターにデバッグプリント１行ぶち込むだけで、ある程度状況が分析できます(少なくとも「変な値を入れられている」事くらいは判明するし、大体の場所も簡単に補足可能)。
このあたりの差異は小さくないと思うのですが。
特に、private修飾子などのない、PHP4においてこの発想が顕著でした。PHP5ですと、ある程度、縛りもできるのですが。
そう。一応念のため。
「IDEの機能で探せるからいいじゃん」という話は、私は切り捨てます。
手段は常に「複数を同時に走らせて」なんぼ、ですから。たった一つの手法に縛られると、どこかで抜け道と落とし穴がまってます。
ドキュメントを用意すればうっかりミスは存在しない。或いは「ミスは意識すれば防げる(過去に現場で本当にこう言った人がいました)」。
意識でミスが防げるくらいなら。私はまず、配下の子達に「自己暗示法」でも覚えさせます。或いはもっと平たく「ブレインウォッシュメソッド」を用いてもよいわけです。
ドキュメントを読めばうっかりミスが防げるなら。それこそ朗読会でも開きます。これで「確実に」読ませることが出来るわけですし。
ドキュメントは大切です。意識も大切です。それでも「こぼれてしまうミス」はあるのが、少なくとも私の知っている、私の周囲の現実です。
その「こぼれてしまうミス」を、可能ならどうやって「不可能に」するのか(こういう点において、C++のコンパイルの通りにくさ、C言語のlintは秀逸ですねぇ。Javaの場合「きれいに設計できるclass」部分できっちりとヘッジするのが好みです)。それが無理ならせめて「いかに速やかにミスを探し出せるようにするのか」。
お仕事でコードを組んでいる、組ませている私にとっては大きな関心事項です。
「故に」。
問題が発生したときに「面倒」なので。且つ「使わないことによる明らかなデメリット」が、現状知っているかぎりでは「ない」ので。
何らかの「明示されるデメリット」がないかぎり、私はglobalは「NG」だ、と思ってます。
これを読まれている方の何かの参考にでもなれば幸いです。
>こーどどらんく さん
インターフェースに関して納得です。すごく難しいですよね。私はテストファーストすることで、決めています。結果はまぁよし、ぐらいです。
>たくVer2.5さん
そもそも役割の共通認識が無かったりするので、うちの会社ではとりあえず決めています。
SE:要望を仕様に落とす
PG:仕様からコードを作成、テスト
PM:(Q)CD管理
役割に関係する書類としては次の様になります。
SE:要件定義書、仕様書、総合テスト評価書
PG:詳細仕様書、単体テスト評価書
PM:管理関係の書類
参考になれば幸いです。
*
Documentorなどを利用することで相互理解が問題ないかの点については、自分はいまいちだと考えます。
理由は、生成されるドキュメントの情報が最新であるのかどうか、その差分が自分に影響があるのかどうか、などの把握に時間がかかるからです。
また、管理ミスは人為的なものですし、それを強制するシステムを導入するのは、下層の人間への負担が増えがちです。
*
global について触れてませんでしたが、私の答えはNGです。
理由は一つ、そのインスタンスがユニークである保障ができないから、です。
ミスをミスとして100%見つけてくれる(もしくは見つける方法がある)のであれば、使っても良いかも。
ただし、「フレームワークを使用しない」かつ「外部参照されるファイルはライブラリクラスのみを含むもの」であれば、それらをコントロールするためのソースには使っても構わないと思います。
PHPがせっかく手軽な言語なのに、Javaの様にしか書けないのであれば、それは苦痛です。
*
せめてPHP4でPrivateを強制させる機構があれば、ここまで大変じゃ無かったんですけどねぇ。。
インターフェースに関して納得です。すごく難しいですよね。私はテストファーストすることで、決めています。結果はまぁよし、ぐらいです。
>たくVer2.5さん
そもそも役割の共通認識が無かったりするので、うちの会社ではとりあえず決めています。
SE:要望を仕様に落とす
PG:仕様からコードを作成、テスト
PM:(Q)CD管理
役割に関係する書類としては次の様になります。
SE:要件定義書、仕様書、総合テスト評価書
PG:詳細仕様書、単体テスト評価書
PM:管理関係の書類
参考になれば幸いです。
*
Documentorなどを利用することで相互理解が問題ないかの点については、自分はいまいちだと考えます。
理由は、生成されるドキュメントの情報が最新であるのかどうか、その差分が自分に影響があるのかどうか、などの把握に時間がかかるからです。
また、管理ミスは人為的なものですし、それを強制するシステムを導入するのは、下層の人間への負担が増えがちです。
*
global について触れてませんでしたが、私の答えはNGです。
理由は一つ、そのインスタンスがユニークである保障ができないから、です。
ミスをミスとして100%見つけてくれる(もしくは見つける方法がある)のであれば、使っても良いかも。
ただし、「フレームワークを使用しない」かつ「外部参照されるファイルはライブラリクラスのみを含むもの」であれば、それらをコントロールするためのソースには使っても構わないと思います。
PHPがせっかく手軽な言語なのに、Javaの様にしか書けないのであれば、それは苦痛です。
*
せめてPHP4でPrivateを強制させる機構があれば、ここまで大変じゃ無かったんですけどねぇ。。
>渚さん
言葉が足らなかったかもしれません。すみません。
私は冗長なコーディング部分を軽んじたのでは無く、Configクラスがその後の改修時に利点があるというお話を こーどらんく さんがしたいのだと思ってレスしたんです。
Configクラスの存在意義については、たとえ不完全な実装であるPHP4で組んだとしても、関数群でそのデータソースをサポートするより遙かに便利であると言うことが重要なポイントなんです。
(31: こーどどらんく さん)にもかかれていますが、＊！なぜカプセル化している！＊のか、と言うところをご理解ください。
OOPしたいがための意見では無く、中途半端な実装でも関数型言語より便利だから使っている、だけなんです。
正直なところ、短納期で期間限定のリリースで環境変更は無しなどの一発ものであれば、過去にはglobalだらけで納品したこともあります。
ただし、背景には改修しないと言う大前提があります。
ある程度の規模になり、複数の人間が携わり、完成したシステムの改修になった時点で、DBリソースをグローバルに扱う様な仕様ではうちの会社では耐えられません(やってられません)。
それでも問題なくこなせるというのであれば、うらやましい限りです。
是非パートナー会社としてお付き合いください^^
言葉が足らなかったかもしれません。すみません。
私は冗長なコーディング部分を軽んじたのでは無く、Configクラスがその後の改修時に利点があるというお話を こーどらんく さんがしたいのだと思ってレスしたんです。
Configクラスの存在意義については、たとえ不完全な実装であるPHP4で組んだとしても、関数群でそのデータソースをサポートするより遙かに便利であると言うことが重要なポイントなんです。
(31: こーどどらんく さん)にもかかれていますが、＊！なぜカプセル化している！＊のか、と言うところをご理解ください。
OOPしたいがための意見では無く、中途半端な実装でも関数型言語より便利だから使っている、だけなんです。
正直なところ、短納期で期間限定のリリースで環境変更は無しなどの一発ものであれば、過去にはglobalだらけで納品したこともあります。
ただし、背景には改修しないと言う大前提があります。
ある程度の規模になり、複数の人間が携わり、完成したシステムの改修になった時点で、DBリソースをグローバルに扱う様な仕様ではうちの会社では耐えられません(やってられません)。
それでも問題なくこなせるというのであれば、うらやましい限りです。
是非パートナー会社としてお付き合いください^^
あまり出られずに居たらいろいろフォローいただきましてありがたいです。（＾＾
>>40:渚さん
痛いところですね(^^;ぶっちゃけC++で書いてしまいたいんですが。
ただ、業務的には単価の問題とかいろいろあって、PHPを要求されることは多いんですよね。なので、という部分です。いやぁ痛い(^^;
あと、業務的には、ということで。ちゃんと書きたいならJavaで。
うん、わかります。ですが、言語が何であれ、業務で、となったらやはり、設計固めてきっちりとやるべきだと思います。
手軽に書いて後で苦しむの嫌ですから・・・・（苦笑
それに・・・PHP、お手軽に扱えそうな分、シビアなところで余計に苦労するわけですが・・・（滝汗
開発環境ですが、既存案件でPHP4の回収、ということは多々あります。でもできれば新規であれば、5でお願いするところです。
>>42:Kryu^2さん
フォローどうもです。概ねそんな感じです。
>>40:渚さん
痛いところですね(^^;ぶっちゃけC++で書いてしまいたいんですが。
ただ、業務的には単価の問題とかいろいろあって、PHPを要求されることは多いんですよね。なので、という部分です。いやぁ痛い(^^;
あと、業務的には、ということで。ちゃんと書きたいならJavaで。
うん、わかります。ですが、言語が何であれ、業務で、となったらやはり、設計固めてきっちりとやるべきだと思います。
手軽に書いて後で苦しむの嫌ですから・・・・（苦笑
それに・・・PHP、お手軽に扱えそうな分、シビアなところで余計に苦労するわけですが・・・（滝汗
開発環境ですが、既存案件でPHP4の回収、ということは多々あります。でもできれば新規であれば、5でお願いするところです。
>>42:Kryu^2さん
フォローどうもです。概ねそんな感じです。
肯定派、否定派の色々意見を読ませてもらえて、やっぱりトピ立ててよかったと思ってます。
私は組んでて楽しさを感じられればどっちでもいいや派。
自分が楽できればポリシーなんていつでも変える。
いいツールやフレームワークがめんどくさい事全部やってくれるなら全部そいつらにまかせていかに自分が楽するかしか考えません。
その分、自分が楽するための知識を得るための苦労は惜しまない。
こーどどらんくさん＞
私はこういうヌルい人間なんであんまりガチガチの正論を突きつけられると困っちゃうタイプだし、タイプが違いすぎて理解しあえないと思います。なんでこーどどらんくさんも私を理解しようとか考えないでください。
私は組んでて楽しさを感じられればどっちでもいいや派。
自分が楽できればポリシーなんていつでも変える。
いいツールやフレームワークがめんどくさい事全部やってくれるなら全部そいつらにまかせていかに自分が楽するかしか考えません。
その分、自分が楽するための知識を得るための苦労は惜しまない。
こーどどらんくさん＞
私はこういうヌルい人間なんであんまりガチガチの正論を突きつけられると困っちゃうタイプだし、タイプが違いすぎて理解しあえないと思います。なんでこーどどらんくさんも私を理解しようとか考えないでください。
>47: 渚さん
渚さんのおっしゃっている事が納得できました。
お客様の違いなどで私も視野が狭くなってしまっていたようです。
PukiWikiタイプのConfigのようなglobalの使い方ならば、使う場面はあると思います。
先のような発言になっているのは、私のお客様だと対応できないケースが多かったからなんです。
開発途中で設定用の環境が変わると、もう面倒ですよね。INI形式から流行りのXMLにしましょう！みたいなノリです。
間に別会社が入ると伝言ゲームでらち明かないですし。
個人的な事をいえば、PukiWikiよりもphpMyAdminなどの$config['db']['id']の様な書き方が好みです。
クラス化の必要が出たときでも、ラッピングしてもバグりづらいです。
私の中では、プログラムはどれだけ改修に耐えられるか、が重要課題ですので、OODしておけば後が楽じゃん、と思っているんですよ。
後で楽じゃないのは、作成するプログラムの構想が根本的に変わったか、カプセル化・多態性の意味がわからず設計したんだと思います。
もちろん例外がないわけじゃないですけどね。
*
>45: すずき さん
「自分が楽するための知識を得るための苦労は惜しまない」、まったく同感です。
なので、職業プログラムで自分の範囲でどうにもならないときには憤りを覚えます。
*
>46: あのに さん
私指定ってわけでもないですかね？とりあえず以下を。
○クラス継承
BaseDAO <- CustomDAOTO
○ロール
・BaseDAO
接続設定および各DBの諸設定と、クエリの検証と実行メンバ
接続・切断メンバ
・CustomDAOTO
DBから必要データを取得するための関連メソッド(アクセサ)を含んだDAOクラス
ユーザデータ検証機能を含めたTOクラス
DB接続リソース管理
コードは会社のものなので、概念だけです(講習会で使っているので晒せないんです)。
*
>52: 渚 さん
MyDBクラスからはデータのやり取りに限定するならば、DBコネクションリソースはMyDBクラス内で保持し、コンストラクタで接続してしまってはいかがでしょうか。
query()毎にコネクションを生成するのは、PHPのリソース管理も含めてDBアクセスのリソースを使いすぎる気がします。
この用途限定になってしまいますが。
*
>44: きむらしのぶさん
定数であれば、define()ですね。問題ない使い方だと思います。
#毎度長文になってしまってすみません
渚さんのおっしゃっている事が納得できました。
お客様の違いなどで私も視野が狭くなってしまっていたようです。
PukiWikiタイプのConfigのようなglobalの使い方ならば、使う場面はあると思います。
先のような発言になっているのは、私のお客様だと対応できないケースが多かったからなんです。
開発途中で設定用の環境が変わると、もう面倒ですよね。INI形式から流行りのXMLにしましょう！みたいなノリです。
間に別会社が入ると伝言ゲームでらち明かないですし。
個人的な事をいえば、PukiWikiよりもphpMyAdminなどの$config['db']['id']の様な書き方が好みです。
クラス化の必要が出たときでも、ラッピングしてもバグりづらいです。
私の中では、プログラムはどれだけ改修に耐えられるか、が重要課題ですので、OODしておけば後が楽じゃん、と思っているんですよ。
後で楽じゃないのは、作成するプログラムの構想が根本的に変わったか、カプセル化・多態性の意味がわからず設計したんだと思います。
もちろん例外がないわけじゃないですけどね。
*
>45: すずき さん
「自分が楽するための知識を得るための苦労は惜しまない」、まったく同感です。
なので、職業プログラムで自分の範囲でどうにもならないときには憤りを覚えます。
*
>46: あのに さん
私指定ってわけでもないですかね？とりあえず以下を。
○クラス継承
BaseDAO <- CustomDAOTO
○ロール
・BaseDAO
接続設定および各DBの諸設定と、クエリの検証と実行メンバ
接続・切断メンバ
・CustomDAOTO
DBから必要データを取得するための関連メソッド(アクセサ)を含んだDAOクラス
ユーザデータ検証機能を含めたTOクラス
DB接続リソース管理
コードは会社のものなので、概念だけです(講習会で使っているので晒せないんです)。
*
>52: 渚 さん
MyDBクラスからはデータのやり取りに限定するならば、DBコネクションリソースはMyDBクラス内で保持し、コンストラクタで接続してしまってはいかがでしょうか。
query()毎にコネクションを生成するのは、PHPのリソース管理も含めてDBアクセスのリソースを使いすぎる気がします。
この用途限定になってしまいますが。
*
>44: きむらしのぶさん
定数であれば、define()ですね。問題ない使い方だと思います。
#毎度長文になってしまってすみません
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
Let's PHP 更新情報
Let's PHPのメンバーはこんなコミュニティにも参加しています
人気コミュニティランキング
- 1位
- 酒好き
- 170675人
- 2位
- 千葉 ロッテマリーンズ
- 37149人
- 3位
- お洒落な女の子が好き
- 90051人