(ソレを信じてるし、やりたいんだだけなんだ!)・誤解されるだけ。(捨てられた犬を見るような目で見られるだけ。)・つまり議論は無理。け・れ・ど!あなたは黙っちゃいない!真摯に議論をしようとする。発言内容に感心したのでした。(残念ながら・・・相手は聞いちゃいないけど・・・)とりとめもなく書きましたけど、つまり応援しています。これからも勉強させてください。留学生活楽しんできてくださいね。10:23:12あいださん感想ありがとうございます。純粋な感想・応援でしたら主観でも問題ないかと思います。この歳になっていうのも恥ずかしいのですが、今週と来週ですが勉強が忙しくちょっと返事が遅れるかもしれませんのでとりあえずお礼をいたします。ちなみに、以下の私の記事はお読みになられたでしょうか?http://www.ohfuji.name/?p=1902コメント欄がものすごいことになっていますが、後半は面白い議論になっているかと思います。>私の立場は2-2で特に(私や多くのプログラマが属する?)>SIの現場では長所より短所を感じているのですが。2-2の方がおそらくマジョリティを占めているかと思いますが『声が小さい』のでいまいちネットの世界では浸透していないようですね(なのでこのようなコメントは励みになります)。声が小さい理由は『オブジェクト指向を完全に否定できない』ということがあり、『オブジェクト指向の何処に欠点があるのか見極めが難しい』というのもあるかと思います。これは私自身、日々追い求めているテーマでもあります。ここ数年すっかり英語学習ブログになってしまいましたが、読者の方がいると知ったのでちょいちょい書くようにします。実は、オブジェクト指向で書きたいテーマがいくつかあるのですが、構想段階で終わってしまってます・・・。15:54:35以前の記事。読ませていただいてました。少々過剰な中傷を受けていたみながわさんの救出劇!ですよね。読ませていただきましたけど圧巻です。私にとってのハイライトは・「ビジネスロジックレイヤーではOOは使い物にならないと思っている。・「gethtml」の例でした。ここに、私がオブジェクト指向を懐疑的に思う根拠(答え)のほとんどがつまってると思いました。それ以外の観点では、こんなふうにも思います。・上手いヤツは上手いなりに下手なヤツは下手なりに実戦的でないものをつくる。・オブジェクト指向の学習/設計/実装コストは高いが効果は低い。(ほとんどの技術者にはもっと低コスト高リターンな技術習得の余地がある。必要性が希薄の仕様(ビジネスアプリケーション)にオブジェクト指向を使ってるのが原因な可能性もあって、やはりofujiさんの例が答え(すべて)かもしれませんが。パロディというか悪口がみながわさんに向けられている/いないの論争は、私にはくだらない。(相手を言い負かすことに注力するより、相手を低俗と思い込んで考えたくない。)でも、胸の中に違和感というか棘のようなものが残っていたようで、ofujiさんの生き様は好ましく見えました。私もofujiさんがおっしゃるように謙虚である必要性を考えます。謙虚であれば思いもよらなかったような考えを自分のものにできるかもしれない。人間社会ってこんなのばかり。相手は絶対的な自信をもって自説を語ってくれる。根拠を聞くと妙な話になる。(ないならないでも良いし、大した根拠じゃなくても良いのだけど、ホント妙な話に。)なかなかあなたのようにはなれそうもありませんね。>2-2の方がおそらくマジョリティを占めているかと思いますがなるほど!私は知らないうちにサイレントマジョリティーだったんですね。ネットではギークの声が大きいだけで、彼らこそマイノリティーだったんですね。現場(SI)では3が急拡大しているように感じていて不気味です。・良いも悪いもなくソレしか知らない。・過去のgoto文と同じようにstaticは使ってはならないと教え込まれてる。(もちろん私は使うべき時がきたらgoto文だって使いますよ。break句の無い言語だってあるし。)・newすると(あるいはフレームワークからインジェクションされたオブジェクトを使うと)仕事をしたような気になる・・・>『オブジェクト指向を完全に否定できない』まったくそのとうりですね。昔大好きだった、今でも嫌いじゃない彼女ですもんね。良い噂を聞かせて欲しい、そしてできるならやり直したいんですけど・・・。新しい彼は妙なことばかり言うんですよね。ホント嫉妬じゃなくて。09:14:09ご返信ありがとうございます。思わず返信がしたくなりましたので簡単ですが返信いたします。した話もしたいのですが、インスピレーションを感じましたので。以前の記事はお読みになられてましたか、まぁ、例の小説のコメント欄にも書き込みましたが、まぁ確かに変な人が多い印象はあります。>パロディというか悪口がみながわさんに向けられている/いないの論争は、私にはくだらない。(相手を言い負かすことに注力するより、相手を低俗と思い込んで考えたくない。)>でも、胸の中に違和感というか棘のようなものが残っていたようで、>ofujiさんの生き様は好ましく見えました。同様の理由で書き込んだというのもあるのですが、恥ずかしながら、私自身がちょっと喧嘩してでも自己主張をしたくなったというのもあります・・・。ここのコメント欄の変な人もそうですし、あの小説の熱心な読者も他人に対しては『謙虚であれ』と言っているにも関わらず自分自身ではまったく謙虚になれないというパラドックスを抱えていますね。ちなみに、以前の記事を出して、軽く炎上して以降、多くのサイレントマジョリティの方は、考えるとことがあったようです。以下のブログhttp://d.hatena.ne.jp/busaikuro/ここも、もともと程度の低い批判のみを行う掲示板と成り下がっていましたが、以前の記事以降は程度の低い発言は次第に減りましたね。私の影響という訳でもないでしょうが、ネット上の程度の低い書き込みについては、一部を除いてみなさん考えることがあったのでしょう。>現場(SI)では3が急拡大しているように感じていて不気味です。考えてみればjavaが出てから20年以上経ちますので3が急拡大しているとういのは理にかなっていますね。私の半径3メートルでは特殊なアプリをメンテしている関係でオブジェクト指向症候群に掛かった人が少ないものでそういう意味では平和なSI生活を送っているかもしれません。3が急拡大しているのなら一層のこと啓蒙記事を書かねばと思っております。ちなみにstaticをつけないだけで事実上staticになっているメソッドとうのも必ずあるかと思います。いう場合に『ここはstaticをつけてもいいのでは?』というと3の方がどういうリアクションをするのか興味深いですね(ちなみにこういう好奇心が私が記事を書くモチベーションになっています)。20:48:17あなたの盟友みながわさんは、相変わらず何の進化もできていませんね。http://ameblo.jp/kenchaz/entry-12241913951.html理解できないものは”使えない技術だ”というスタンスらしいですよ。利点も欠点も知ったうえで”使えない”というならわかります。みながわさんは、理解できない=使えない、と短絡しています。相変わらず高慢と偏見が直っていないようですよ。13:00:27histaticさんURLが入っているので承認待ちになっていました。ワードプレスの不具合か私のところにお知らせが来ていませんでした。教えて頂いてすみませが、>理解できないものは”使えない技術だ”というスタンスらしいですよ。利点も欠点も知ったうえで”使えない”というならわかります。>みながわさんは、理解できない=使えない、と短絡しています。相変わらず高慢と偏見が直っていないようですよ。この指摘は具体的にはみながわさんの記事の何を指して言っているのでしょうか?元の記事を読みましたが、どこが『高慢』なのか私には理解できません。突っ込みたい気持ちは伝わってくるのですが、まぁ論理が飛躍しすぎて返答に困ります。そのままなかったことにしてもよいのですが、まぁ出しておきます。余計なことかもしれませんが一つ指摘します。人に対して「あいつは『高慢』だ」と評価するのは個人の思いとしては勝手にやってもらえればいいのですが客観的に事実として言いたいのならきちんと証拠を上げて相手に伝わるようにした方がよいですよ。そもそも論としてあなたが他人の人格に対して何か評価する資格があるのかどうかも私にはわかりません。17:59:02histaticさんみながわさんのブログとあと以下のにも書かれていたのですね。http://el.jibun.atmarkit.co.jp/pressenter/2017/01/_11.htmlそれでもあなたの書き込みに対して誰も賛同していない理由を考えるとあなた自身が進歩できるかもしれませんね。書き込まれて散らかるのもなんなのでコメントがあれば、先ずはみながわさんのところへお願いします。私の返信が遅れたことはすみませんでした。22:55:42ohfujiさん本日、発端となった記事やohfujiさんの書いた記事http://www.ohfuji.name/?p=1902を読み、最終的にこのページに至りました。ohjujiさんの考え方は大変参考になりました。発端記事のコメント欄には否定的なコメントが多かったですし、私も否定的な意見をもっていました。なると、粗探ばかりしてしまうので、話はなかなか進みません。オブジェクト指向について理解が無かった新人のころを思い出しました。C#で開発する機会があったのに手続き型言語の方がわかりやすいと思い込んで、コードはC風に書いていました。そこには記事で話題となるようなstaticなグローバル変数がたくさん存在しています。このコードの保守性は絶望的で、先輩もお手上げだったようです。その後、先輩からのアドバイスもあって、オブジェクト指向について勉強しました。その結果、考え方が大幅に変わりました。私はコードレビューをしたり共通的な処理を作成することが多いですが、他プログラマの酷いコードに、苛立ちを覚えたりしています。上記の記事を通して自分の新人の頃を思い出し、初心にかえれた気がします。ありがとうございます。13:37:19cshaprdotnetさんコメントありがとうございます。スパムフィルターに引っかかって表示・返信が遅れてしまいました。ご参考になったということで何よりです。レビューや共通的な処理の作成ということで立場的にソフトウェアの品質には敏感なのだと受け取れます。実際の現場を見たわけではないので的外れな返事になるかもしれませんが私自身レビューに参加したりという経験が多いのでコメントします。私は他の人が書いたコードを読むとき『現実と理想』のギャップを意識しています。書籍等ではきれいなコードの例が載っていたり、『コードはこうあるべきだ』という理想像を知ることができますが、私の経験上、残念ながら実戦では、そのようなコードを書くことが厳しいことの方が多いです。これは私自身にも当てはまりまして、私も見た目が酷いコードを書いたこともありました。ある清算に関わる処理を書いた時にエラー処理が多くなり見た目がひどくなりました。他の人が『リファクタリング』と称して書き直したのですが、それをテストするとどうもエラー処理が抜けているらしく「ネットワークエラーの処理はどうしましたか?」と聞いたところ『それはまだ実装していない』という返答でした。残念ながらどれだけ見た目がきれいなコードでも要求仕様を満たしていないコードは落第だと言わざるをえないでしょう。このような『リファクタリング』と称したバグの埋め込みの例(デグレード)はこの例だけでなく私自身が逆の立場になったこともあり、あーだからこんなにややこしい処理が入っているのか。とあとで納得したこともあります。酷いコードを見た時には、コードに対する読解力が自分にあるか?という問いかけも必要かと思います。『酷いコード』という意見はよく聞きますが、先に示したとおり実際にはややこしい処理が入っているだけで、読み手がそのことを理解していないということが往々にしてあります。すると『ドキュメントやコメントを充実させろ。直感的なコードを書け』といろいろご高説が出てくるのですが、逆にいうと、それらは読み手としての能力が無いと言っているようにしか思えないことがあります。いう訳で最近では、他人のコードに対して「酷い」という感想を持った時に「何がひどいのだろうか?」と自問自答するようにしています。直感が当たることもあれば外れることもあります。グローバル変数が出てきたので関連してコメントしますと、グローバル変数が問題をはらんでいることはそのとおりですがでは「なぜグローバル変数がダメなのだろうか?」という問いかけもやはり必要かと思います。どこかで読んだネットの記事になりますが、『DBに格納されている値は結局グローバルだよね』という意見を読んだときに私は妙に納得したのですが、この意見にはグローバル変数のある種の存在理由のヒントが隠されているように思われます。グローバル変数がダメという例もあります。Noの結果をグローバル変数でやり取りしていたコードがあり、さすがにこれについては「やめてくれ」と意見しました。そのプログラマーは頑なに変更を拒否したので、それ以上は言わなかったです。後、手続き型についても意見があるのですが、それは以下の記事に書かれています。http://www.ohfuji.name/page.awp?page_id=2912長々となりましたが思い出すことがありましたので返信しました。コメントありがとうございました。12:28:38ohfujiさんいろいろコメントありがとうございます。同じような考えをもっていることが分かりました。プロジェクトでの立場も違いものを感じました。品質問題にいつも苦しんでいます。入れ替わりも多いので良い人を育てるという選択肢もありません。以下のような記事をQiitaで書いています。http://qiita.com/csharpisthebest/items/57f27a33085f01211166しかし、Qiitaでコメントくれる方は対象読者ではない人が多いため、なかなか話が合わないことが多いです。高度な立場でのコメントをくれるので参考にはなります。プロジェクトメンバーに読んでもらうにはちょうど良い内容だと思っています。グローバル変数の話がでたので、コメントします。結局、グローバル変数の使い方次第ですよね。DTOがクラスのプロパティはpublicにするのが普通です。これ自体に問題が発生するわけではないということだと思います。User情報のDTO(UserDto)を静的領域にもって、どこでも参照と変更ができるようにすると途端によくないグローバル変数になります。静的情報する必要性を検討するべきですね。Noの結果をグローバル変数でやり取りしていたコード>もっともそのプログラマーは頑なに変更を拒否したので便利だからという理由で使う人が多いので、厄介です。この手のプログラマは今後直る見込みがないで、私のプロジェクトでも扱いに困っております。オブジェクト指向があたりまえみたいな風潮がありますが、もっと基本的なところ(Qiitaの記事のレベル)を何とかしてほしいと思う日々です。まとまりがなくなりましたが、思うことがかけて満足です。ohfujiさんとは別で、これまでの経験について話をしてみたくなりました。考え方が近いので、何か得られる気がします。15:53:26さらにご返信ありがとうござます。考えさせられるコメントなので、2回に分けて否定的な意見と肯定的な意見を書きます。グローバル変数の話ですが、>しかし、User情報のDTO(UserDto)を静的領域にもって、どこでも参照と変更ができるようにすると>途端によくないグローバル変数になります。これが場合によりけり(全体的な設計を絡めての判断)になります。グローバル変数というのはプログラム実行時の寿命を持った変数で、一方のDBにあるUser情報というのは寿命がそれよりも長くなります。いう意味ではDBの情報を不用意にグローバル変数に持ってくるのは不適切ということになります。DBとの同期を上手く行えばそれはそれで使えるようになります。具体的にはキャッシュとして持つということになります。パフォーマンスタイトなプログラムで頻繁にDBにアクセスできない場合、頻繁にアクセスする情報についてはグローバル変数で持つということもできるでしょう(アーキテクチャ的にはCPUキャッシュを参考にすればよいかと思います)。DB上のデータは『どこでも参照と変更ができる』ようになっていますがなぜ問題にならないでしょうか?ということを考えるともう少し深いものが見えてくるかもしれません。続いて、Qiitaの記事の全体的な感想になりますが、確かに私の立場では重箱の隅感が否めません(もっとも記事の意義も解りますのでそれについては次にコメントします)。サンプルコードの短さが示しているとおり対象としている問題が小さいです。私自身リファクタリングをする時はもっと規模が大きい変更を行います。逆に言いますとメソッド内のコードの良し悪しはあまり見ていません。場合によりけりですが何時でも書き換えられるのならもっと別の大きな問題を考えたいです。要するに木を見て森を見ずになる恐れを避けるということで、例えばhttp://qiita.com/csharpisthebest/items/99af9136883f139ad70fですが、私もfelisさんのコメントの通り管理テーブルの作成(別の言い方をすると状態遷移を考えた設計)にすべきでありif文の書き方については(今は)些末な話になります。要するに何が重要か?ということで、設計の良し悪しを考える方がコードの記述の良し悪しを考えるより優先順位が高くなるでしょう。その点をごっちゃにすると意図しないツッコミが出てきたり共感が得られなくなるかと思います。製品等、頻繁に保守を行うプログラムということであれば、ある程度統一感をもった記述というのは必要で、人の出入りが激しい場合なおさらで自由すぎるのもどうかと思います。人の読解力には限界があるので縛りは必要かと思います。これもまた昔を思い出すのですが、コーディング規約を作るしかないかと思います。その場合はきちんとドキュメント化し全員に周知した方がよいかと思います。コーディング規約を元にコードを書いたのもバブルの頃でそれ以降は予算の関係でなおざりになっている現場が多いですね。続いて、肯定的な意見を書きます。確かにif文一つとっても色々書き方がある訳でしてどうあるべきかというのはプログラマ人生で一度は考えたいところではあります。if文について気にすることですが、『全ての条件を網羅できているか?、できれば直感的に理解可能か?』になるかと思います。いう意味ではリファクタリング後のコードの方が読みやすいです。ボタンの活性化の条件では3つの要素(loginUserID,firstApproved,secondApproved)がありますが、この3つの要素について機械的に組み合わせを考えると、loginUserIDは4パターン,firstApprovedは2パターン,secondApprovedは2パターンで全体で16パターンになります。連ねたコードの場合、本来なら16パターン分考慮しなければなりませんが、リファクタリング後の場合は、loginUserIDと(firstApproved,secondApproved)に分けてある(つまり4パターン+4パターン)に分けてあるのでややこしさが低減されてます。ちなみに7tsunoさんのコメントのボタン目線のコードも悪くないのです、が、場合によりけりな部分があります。ボタンの活性化だけでなく現在の掲示板の状態を表示する要望が追加された場合、if文を残しておいた方が後からのメンテナンスが楽になるかと思います。if文の場合はコメント状態がコードブロックに収まっていますが、ボタン目線の場合はボタン間の関連が特にないのでそれぞれの条件がきちんと設定されているか気にしてしまいますね(要は16パターンについて、すべてのボタンで検証する必要があるのでさらに複雑さが増える)。考えたり試したりすることには、新人に限らずベテランにも意義がありますし、そういうコメントもついていますので、勉強になる記事だと思います。10:18:56ohfujiさん肯定・否定の意見を両方いただき、ありがとうございます。Qiitaの記事上では、コメントでしか感想を判断できないので、大変参考になりました。グローバル変数の話についてですが、>これが場合によりけり(全体的な設計を絡めての判断)になります。ここはその通りだと思います。そこまで考えてくれる人が増えてほしいものです。>もともとDB上のデータは『どこでも参照と変更ができる』ようになっていますがなぜ問題にならないでしょうか?この辺の話は、社内の勉強会でやってみようかなと思いました。>続いて、Qiitaの記事の全体的な感想になりますが、確かに私の立場では重箱の隅感が否めません(もっとも記事の意義も解りますのでそれについては次にコメントします)。>サンプルコードの短さが示しているとおり対象としている問題が小さいです。私自身リファクタリングをする時はもっと規模が大きい変更を行います。リファクタリングする人の立場では物足りないですよね。このコードの記事の元ネタは、プロジェクトの要員が毎日のように書いてきたコードがほとんどです。コードレビューで毎回指摘しても、次に活かされず、再発していました。規約を書いても守られなかったので、プログラマの質は良くなかったです。いう意味では、重箱の隅という指摘は、その通りだと思います。>その場合はきちんとドキュメント化し全員に周知した方がよいかと思います。コーディング規約を元にコードを書いたのもバブルの頃でそれ以降は予算の関係でなおざりになっている現場が多いですね。記事に書いた内容のいくつかは、コーディング規約にしていました。規約自体にそうする理由も書いていました。口頭で説明したので私もみんな守ると思っていたのですが、意外と難しいようです。半分以上のプログラマが規約をほとんど守れず、コードレビューを完了したくないがスケジュールに遅れがでるので完了にせざるを得ない状況となりました。規約が覚えられないというプログラマが多いのでしょう。自分は覚えているかというと、身についているという感覚なので規約のある別プロジェクトに移っても苦労したことはありませんでした。そのため、規約を守ることの難しさについては甘く見ていました。規約を守らせる一つの案については、Qiitaの最初の記事でコメントされました。http://qiita.com/csharpisthebest/items/90f040ad52c213bd0d64コードレビュー結果を可視化して守らせるようにするという提案でした。普通のプログラマであれば守るし、それでも守らないのであれば、その人に仕事は任せられないと。ここまでやると、ついていけない人は自分からプロジェクトを去りそうです。私は協力会社(プロパーではない)の人間なので、別の協力会社から苦情がくるかもと思いました。結局、コードの質を上げるにはプログラマ自身が自発的になんとかするしか無いという点が難しいところです。>は16パターンについて、すべてのボタンで検証する必要があるのでさらに複雑さが増える>ボタンの活性化の条件が増えた場合、承認者が3人になったりとか、修正が面倒になると思いますが如何でしょうか通常elseで表現できる場合でも、あえてフラグを書かなければいけないので、保守性は落ちますね。if文を読みやすいbool型に書き換えるという点では意義があるので採用しました。保守性の部分について追記するべきかもしれません。考えたり試したりすることには、新人に限らずベテランにも意義がありますし、そういうコメントもついていますので、勉強になる記事だと思います。最近、Qiitaの記事は意味はあるのか懐疑的になっていましたが、とりあえずこのまま頑張ってみます。14:36:38なるほど、工程内にコードレビューがある状況ということですね。私も乗りかかった以上、最後までコメントしたいとこです。実際の現場を見ていないので的外れなところがあるかもしれません。その場合は指摘していただければと思います。いくつかに分けてコメントします。Qiitaの記事を元に私がレビューする場合についていくつか概観します。『ややこしい条件分岐』について、http://qiita.com/csharpisthebest/items/99af9136883f139ad70f私はリファクタリング後が読みやすい(良い)コードだと言いましたが、実際に私がレビューすると、元のコード、リファクタリング後のコード、7tsunoさんのコードすべて合格(acceptable)です。実は7tsunoさんのコードはデグレードしているので本来なら不合格ですが、そこは解消されているとします。デグレードをどこまで深刻に受け取るかですが、前にも指摘しましたがこういうことがあるので不用意なリファクタリングはNGとしたいところで、悩ましいところではあります。何れにしても、良いコード・悪いコードと分けるのではなく、良いコード、悪いコード、普通のコードと分けて悪いコードのみ、ふるいにかけることを考えます。私の前のコメントのように何か意見があればレビュー時の確認事項として担当者に確認します。「こういう問題がありそうですがどう思いますか?」という感じで聞きます。実はこのようなコードを書く場合、私は元のコードのように書く場合があります。理由は、「全部の条件がif文内の一つの行に収まっている」ということで一つの状態に対応してそれを満たす条件を切り出すことが可能になり、そこから状態遷移表を作ることができます。一方で、リファクタリング後のコードも7tsunoさんのコードも書き手の意図が理解できるのオーケーです。この辺りの判断はプログラマの裁量に任せたいところです。一方で、以下の記事、『Getter、Setterを逆にするのは何故か』http://qiita.com/csharpisthebest/items/9e6d6ff9156cfd70b993は、記事にあるとおりGet/Setの意味どおり書いてもらわないと保守担当者(他の人)が困ることになります。変数やメソッドの命名規則は順守するのも簡単なはずなので守ってもらいたいところです。一方で、悩ましいのが以下の記事『流れるようなインターフェースの使い方はこれで正しいのか?』です。http://qiita.com/csharpisthebest/items/403d40374acc70ef24e3私もリファクタリングすべきだと思いますが、『なぜそうか?』というのは少し思いつきません。言うと慣例的ということになりますが、こういうコードもレビューでよく遭遇します。UpdateParameterがDaoを参照している。テーブルが増えたら直す箇所が複数ある。SetHeader1~SetHeader3を必ず呼び出さなければならない。ついては、2.および3.についてはリファクタリング後のコードも同様だと思いますし、1.については何故Daoを参照するのが悪いか私には疑問です。いうコードに遭遇したときは、前に指摘しましたとおり「私の読解力は大丈夫か?」と自問することにしていますが、一方でプログラミングの奥深さを感じます。人間の創造力の豊かさを感じます。最近では、こういう自由度の高さから「オブジェクト指向はビジネスロジックに向かない」という意見も持ち始めました。担当者には「リファクタリング後のコードの方が慣例的なのですが?」と疑問点を述べてできれば修正してもらうようにしたいところではあります。その他に目につくものは、『関数の引数が多すぎる問題』ですが、http://qiita.com/csharpisthebest/items/35ed38c0d3a26dbe8c70これは、正にガイドラインというのはどうあるべきか?を考える例になります。『関数の引数は7個までで、それを超える場合は処理を分割できないか検討してください。レビュー時には検討結果についてお伺いいたします。』ということになるでしょうか?記事にもありますが、>処理の分割をちゃんと考えていれば引数が多くなることは、ほとんどないという点である。このとおり逆説的ですが、恐らくほとんどのプログラマは数については意識していないでしょう。まともなプログラマが書いたコードなら引数が8個になるということはそれなりに理由があるというこで、まともじゃないプログラマが書いたコードなら他に指摘できる点があるということになります。関数の引数の数に制限を付けるのは出来ればという程度(努力目標)ということになり、要は必ず守らせるものではないということになります。以上、4つほど取り上げましたが、もしQiitaの記事がコーディング規約としたら、中にはOKのものもありますが幾つかの規約はその合理性が疑わしいということになります。『高品質のコードを書くためのガイドラインの品質はどうあるべきか?』という話になります。合理性が疑わしいガイドラインを好んで守ろうというエンジニアは居ないわけですが、かと言って、新人や経験不足のプログラマには理屈抜きである程度従ってもらわな困る面もあり悩ましいところです。続いてレビューの必要性と意義等もう少し掘り下げた話と、>コードレビューで毎回指摘しても、次に活かされず、再発していました。ついてのコメントもあるのですが、まぁゴールデンウィークも長いのでゆっくり返信したいと思います。古い本になりますが、もしかしたら以下の本が参考になるかもしれません。(マイクロソフトプレスシリーズ』20年以上前になりますが、この本を読んで感銘を受けた覚えがあります。22:51:57ohfujiさんご意見いただき、ありがとうございます。>元のコード、リファクタリング後のコード、7tsunoさんのコードすべて合格(acceptable)です。>「全部の条件がif文内の一つの行に収まっている」ということで一つの状態に対応してそれを満たす条件を切り出すことが可能になり、そこから状態遷移表を作ることができます。「全部の条件がif文内の一つの行に収まっている」というのは、別プログラマから言われたことがあります。設計書の通りで対応関係も分かりやすいという意見でした。それほど悪いコードでもなさそうですが、if文内の冗長な条件はbool型の変数にしてほしいという思いはあります。)実は、元ネタはif文の中に同じ判定を何回も書いており、テスト不可能なほど複雑でした。そのときもbool型の変数で表現されていれば、OKしたかもしれません。>一方で、悩ましいのが以下の記事『流れるようなインターフェースの使い方はこれで正しいのか?』です。>1.については何故Daoを参照するのが悪いか私には疑問です。サンプルコードを簡略化しすぎて、私が問題だと思った部分が伝わりにくくなってました。元ネタはDaoを画面でも使用しており、更新時のUpdateParameterを生成時に使用しています。これまで画面で使用していたDaoを、このときだけUpdateParameterで使用するのは違和感がありました。UpdateParameterはDTOですので、依存無しの単純なデータ構造にしたいという意図もあります。UpdateParameterBuilderクラスでDaoを内部でnewしているならばOKだったと思います。>こういう自由度の高さから「オブジェクト指向はビジネスロジックに向かない」という意見も持ち始めました。変なクラスが多くて困っている現状があります。>以上、4つほど取り上げましたが、もしQiitaの記事がコーディング規約としたら、中にはOKのものもありますが幾つかの規約はその合理性が疑わしいということになります。>合理性が疑わしいガイドラインを好んで守ろうというエンジニアは居ないわけですが、かと言って、新人や経験不足のプログラマには理屈抜きである程度従ってもらわな困る面もあり悩ましいところです。合理性まで踏み込めるプログラマであれば、問題となるようなコードは書かない、あるいは一見問題があるようなコードでも納得いく説明ができると考えております。悩ましいのは今までやってきたやり方と違いすぎて、合理性まで踏み込めないプログラマです。新人や経験不足のプログラマがこの傾向にあり、規約をとりあえず守ってもらうしかないですが理解できていないので守れずという悪循環です。今でも中古で手に入るようです。購入を検討しています。コードレビューに関しても返信お待ちしております。16:20:49さて、続いてコードレビューと規約の必要性についてプロジェクトマネジメントの観点からコメントします。技術的な話は次に、教育的な観点ではその次にコメントしようかと考えています。コードレビューを行ったりコーディング規約を作成するのは何の為に行うのでしょうか?ここでは技術な観点は除いて、プロジェクトマネジメント上のメリットを考えると『それを実施することにより最終的な工数が減る』とか『人員に対する要求レベルを下げることができる』というのが挙げられるでしょう(もちろん他にもあるかと思いますが)。コードレビューを行い潜在的なバグを取り除けば後のテスト工程で楽ができますし、良いコーディング規約(ガイドライン)があれば(本来なら)経験が足りないプログラマでもプロジェクトに参加することができます。イメージでいうとファストフードチェーンのようにアルバイトでも一定の品質をもった製品を作ることができるということになります。プログラム開発とハンバーガーを作ることを同じテーブルに載せるのは飛躍している面がありますが、ここではコーディング規約やガイドラインを含めたプロジェクトの理想的な(あるべき)体制を考えるとという話になります。いう観点でみると、『良いコード書くきっかけを与えたい。』http://qiita.com/csharpisthebest/items/90f040ad52c213bd0d64にあります、>少なくとも、常駐先で色んなプログラマのコードを見てきたけど、10人中、まともなのは1~2人程度で、その他は論外という印象だった。いう環境は、本来の意味においてコーディング規約が発揮される環境であるとも思えます。『良いコード書くきっかけを与えたい。』のコメント欄にある結論>私の信条として、人は人から言われたことで変わることはまずないと考えています。その通りですが、この結論はある意味でコーディング規約やレビューの存在を否定することになります。繰り返しますが良いガイドラインとは誰がやっても従えるものを指します。そんなものを作るのは絵空事ということもありますが、実際に私が関わったプロジェクトで、コーディング規約ではないですが『平凡なプログラマー』でも上手く行くプロジェクト運営というのは過去にやったことがありますので全くダメということでもないです。言葉を変えると良いガイドラインとはプログラマを良い方向へ導くものであり、まさに『良いコード書くきっかけ』になるものでしょう。話を戻して、なぜ、>コードレビューで毎回指摘しても、次に活かされず、再発していました。いうことが起こるのでしょうか?理由は様々だと思います。>おそらく、規約が覚えられないというプログラマが多いのでしょう。いう人もいるでしょうし。残念ながらそのプログラマがプロジェクトの参加基準に達していないということもあるでしょう。技術力関係なしにそのエンジニアの性格という面もあります。コーディング規約に対する持っているイメージがエンジニアによって異なります。cshaprdotnetさんはコーディング規約を良いものと考えておられますが、全員がそう考えているわけではなくて単なる足かせとかある種の『創造性』を否定するものととらえている方もおられます。前の例でいうと一流のレストランのシェフがはたしてファストフードのマニュアルに従うでしょうか?という話にも通じます。このような人間の性に起因するある種のジレンマは、コーディングレビューにも通じます。コーディングレビューを行って問題点を出しそれを指摘した場合、残念ながら一部のエンジニアは単純に反発しかしません。この記事のコメント欄のnagiさんがそうでしょう散々私に間違いを指摘されながら自説を曲げずにコメントされていましたが、言い逃れできない間違いを指摘されると何処かへ消えました。いう人もいますし、別の例を出せば、例えば私が一流どころのプログラマーにコードの間違いを指摘したところで従ってもらえるか分かりません。『お前が無知なだけだ』と返される可能性もあります。このようにコーディングレビューや規約の持つ欠点を考える必要もあるかと思います。人に対して間違いを指摘するということはある種の軋轢を生みだします。タイミングや言い方に気を遣う必要があります。やり方次第でコーディングレビューをある種の発表会のような晴れやかな場にするか、裁判のように罪人を追求する場にするか、違いが出てきますが、下手をするとプログラマーのモチベーションに影響を与え結果としてプロジェクトの進行を遅らせることになります。おかれた環境(レビュー、規約の必要性、レビューアーとメンバーの関係性)ということを考慮し、対策を練ることになります。実際には相手によって対応を変える必要もありますし、時には規約を変更することもあるでしょうし、と、できることは色々あるかと思います。言うのは簡単でもやるのは面倒で、レビューではないですが、この手のことでは私もちょいちょい悩むことがあります。周りの人に相談したり、他の人はどういう対応をしているのかを見たりしています。21:06:36ohfujiさん昨日投稿した内容が反映されていないのですが、またスパムですかね?それはさておき、コードレビューと規約の必要性についてコメントをいただき、ありがとうございます。>実際には相手によって対応を変える必要もありますし、時には規約を変更することもあるでしょうし、と、できることは色々あるかと思います。1点どうしているのか、お聞きしたいことがあります。スキルミスマッチの人がプロジェクトに配属された場合にどうするかということです。経験年数によらず一定数存在しており、レビューしても品質の問題を全て解決することができません。この場合のスキルミスマッチは、レガシーコードしかかけないプログラマです。いただいたコメントでは>残念ながらそのプログラマがプロジェクトの参加基準を満たしていないプログラマということになります。私のプロジェクトでは、大半の人が該当していました。この種のプログラマは、Qiitaの記事に書いたような書き方ができることを知らず、規約どころではありません。Qiitaの記事を見て、自身のコードを見直してくれれば見込みはあるものの、プロジェクトとしては手遅れです。品質問題が発生する部分でもあるのですが、どうすればよいか見えていません。>良いガイドラインとは誰がやっても従えるものを指しますためしに規約に載せるか、コードを書く上での検討事項となるか分類してみました。検討事項Qiitaの記事は規約にできるものを考えるという面もありますが、プログラマの引き出しを増やすための記事のため、明確な答えが出ないもの(状況によっては正しい)が多いです。それだと話にはならないので、どこが悪いのか指摘した上でリファクタリングしています。実際のプロジェクトでは、「規約」と書いた部分が守られていないため、コードレビューの負担は大きくなっています。この「規約」と書いた部分を守らせるにはどうするかを考えるべきかもしれません。コードレビューをしているとある程度パターンがありました。多少の規約違反も納得できる内容だったりする。ある程度の規約は守れる。ロジックもそれほどおかしくないし、踏み込んだレビューができる。基本的な「規約」が守れない。規約違反を指摘してレビューが終わってしまう。何とか3=>2に引き上げたいのですが、>私の信条として、人は人から言われたことで変わることはまずないと考えています。これに該当する人が多いのが実情です。一日のうちに何度も同じ指摘を受ける人に話を聞いたのですが、「スケジュール遅延でてんぱってました」ということでした。炎上プロジェクトだったので、プログラマには余裕がないのも原因の一つみたいです。以下の2点を考えていくことになりそうです。「検討事項」を活かしてもらうにはどうするか?その他のコメントについていくつか返信します。>このような人間の性に起因するある種のジレンマは、コーディングレビューにも通じます。コーディングレビューを行って問題点を出しそれを指摘した場合、残念ながら一部のエンジニアは単純に反発しかしません。実際のプロジェクトでもありました。レビューイが激怒したことがあります。翌朝お互いに謝ってことなきを得ましたが、なかなか難しいものです。オブジェクト指向設計に知見があるプログラマとも険悪な雰囲気になりかけました。「ビジネスロジックに影響を与えない進捗表示」の元コードを書いた方ですが、2回目のレビゅーということもあり、リファクタリング後のコードにするのはあきらめました。>下手をするとプログラマーのモチベーションに影響を与え結果としてプロジェクトの進行を遅らせることになります。パターン3のプログラマは、これに該当していたと思います。途中であきらめました。考えが整理できました。返信いただきたい内容が先頭にあるので、もう少しお付き合いいただければと思います。11:42:22>もう少しお付き合いいただければと思います。考えたら、この文言はおかしいですね。コメントを書いた後、なんとなく終わった気になっていました。>技術的な話は次に、教育的な観点ではその次にコメントこちらについてもコメントをお待ちしております。11:53:44ご返信ありがとうございます。一昨日のコメントはスパムに入っていましたので復活させました。cshaprdotnetさんの返信を読んで少し状況が飲み込めてきました。私の今後のコメントのいくつかは前のコメントと矛盾するかもしれません。ご質問に答える前に一つWEBページを紹介します。Standards」http://www.richardrodger.com/2012/11/03/why-i-have-given-up-on-coding-standards/#.WQp73_6wd9Mもし英語が読めるのなら今のcshaprdotnetさんにお勧めのページです。誤解してほしくないのはコーディング規約をあきらめろと言いたい訳ではなくコーディング規約信奉者になる危険性を説明しているという風に読んでければと思います。『幾度となく醜いコードにうんざりさせらる中で、あなたは、自分が只の半人前であると気づく。コードコンプリート、プラグマティックプログラマー、ジョエルのコースに出会い、それに没頭し真のエンジニアへの道に進む。貴方の生産性は2倍になりあなたはこの金言を広げる必要性を感じる。あなたは伝道師となり上司にベストプラクティスと規約の必要性を説いたり、それに従わないコードをブログに書いたりする。あなたはコーディング規約という名の法律を作る。いつものようにつらい仕事は続き、デスマーチは続き、バグの発生は同じで、同じ悲劇が起こる。それは銀の弾ではない。訳が怪しいところがありますが、意味はおさえているつもりです、突き刺さるものがあるかと思います。(全てのプログラマーは他人が書いたコードを嫌う。)』というのがありますね。考えさせられないでしょうか?さて、『スキルミスマッチの人がプロジェクトに配属された場合にどうするかということです。』の件ですが、過去の私の経験に基づいて話しますとスキルミスマッチの人は変えてもらうようにその人の上司や私の上司に要望を出します。時には「変えないと会社を辞めるぞ」と言って変えさせたこともありましたし、状況的に変えられない時はその担当者にプレッシャーを与えます(ミス等をしたときに怒ったりして、厳しく対応します)。怒ったりするのはあまり程度が良くないですが現実問題として効き目は効果的で『怒られるからちゃんとする』ようになります。そのエンジニアとの関係は壊れます。私の25年の経験において『プロジェクトメンバーの半数がスキルミスマッチ』ということはありませんでした。私の運がよかったということもあります。スキルミスマッチと判断しません。概ね1.プログラムが書けない2.その状況を変えようと努力しない3.上司や同僚が、私の1.2.の判断を支持する。いう状況下で、私はそのメンバーを追い出すことを検討します。他にも返信したいことがありますが、取り急ぎ質問にお答えします。残りはこの連休にまたということで。>>もう少しお付き合いいただければと思います。>よくよく考えたら、この文言はおかしいですね。>コメントを書いた後、なんとなく終わった気になっていました。細かな言い方はあまり気にならないタイプなので大丈夫です。こちらについてもコメントをお待ちしております。11:04:05連休を満喫してますのであまり多くは書けませんし、こういう指摘をするのも大変気が重いのですが、1点重要な指摘をしなければなりません。>「全部の条件がif文内の一つの行に収まっている」というのは、別プログラマから言われたことがあります。設計書の通りで対応関係も分かりやすいという意見でした。>それほど悪いコードでもなさそうですが、if文内の冗長な条件はbool型の変数にしてほしいという思いはあります。nullとfirstApprovedはコードが述べている内容が同じなので同じコードという認識が必要かと思います。書き換える必要はありません。コードコンプリートを勉強されてブール型変数の効用ということでこの例を出されるのなら、残念ですが充分に理解されていないと指摘せざるを得ません。Complexity』をよく読んで下さい(私が持っているのは英語版なのでタイトルは英語になります)。著者が伝えたいことはこういうことではないことが解るはずです。ちなみに複雑なif文に対する規約としては19.6を参考に書かれることをお勧めします。コードコンプリートを調べた結果をお聞かせいただければと思います。そもそもこのような規約を作ること自体の意義について検討してみてください。そのプロジェクトでブール型変数が使えるプログラマが少数ということでしたら規約を変更することをお勧めします。cshaprdotnetさんが100%理解していないブール変数の効用を他人に紹介してもうまく使いこなしてくれるとは限らないでしょうし、誤解に基づいてレビューをして果たしてメンバーは学んでくれるでしょうか?少ないですが今日のことろはここまでです。11:25:07久しぶりにコードコンプリートを読んでたのですが、もう一つ参考になる部分がありました。if-then-elses』では元のコードの方が良いと解釈できることが書かれていますね。if文から独立している。順番の入れ替えが可能とのことです。こちらも合わせて調べてみてご見解も聞かせて下さい。13:05:50ohfujiさん>if文内の冗長な条件はbool型の変数にしてほしいコードコンプリートを読み返して、これは本来私が伝えたかったことではないことに気づきました。firstApprovedは、bool型変数によって読みやすくするという話ですね。コードの冗長性の話をしたかというと、元ネタの話にひきづられていました。T(変数、あるいはメソッド)にしてほしいということが言いたかったことです。F)ということにも気づきやすいので、さらに簡潔にできます。firstApproved」を出していましたが、可読性を挙げる話だったので的外れでした。上記の可読性を挙げるという話であっても、このままで十分だから書き変える必要はないという指摘をohfujiさんから受けたと思います。if-then-elses』では元のコードの方が良いと解釈できることが書かれていますね。19-32が分かりやすいです。このコードだと、冗長であることは気になりません。if間で依存性が発生してしまい他のif文の影響を受けるので複雑さが増えるだけです。変数にすると分かりにくい例ともいえるので、19-32のままで良いことが分かります。この部分は、今まで間違って解釈していました。コードコンプリートの理解が足りていなかったことは認めます。19-32を意図して書いたプログラマに対して、bool型変数にするという指摘をして納得されないのは理解できました。以上を踏まえると>そもそもこのような規約を作ること自体の意義について検討してみてくださいbool型変数に対して理解不足であるなら、良さを伝えられない可能性を理解できました。読みにくい条件分をbool型変数やメソッドにすることで可読性が上がること自体は知ってほしいですがMustにするべきではありませんね。>ちなみに複雑なif文に対する規約としては19.6この話はすっかり忘れていましたが、客観性があって、よいガイドラインです。13:31:32自己レスです。ばらばらとすみません。>そもそもこのような規約を作ること自体の意義について検討してみてください。おっと、『ややこしい条件分岐』は規約ではなくて検討事項でしたね。『Bool型の扱い』と『ややこしい条件分岐』にあるbool型変数の根っこにある論旨が同じように受け取れたので私の2個前のコメントになります。『Bool型の扱い』http://qiita.com/csharpisthebest/items/b0c44764948e1334e94aせっかくですので『Bool型の扱い』についてコメントしますが、恐らくこの規約はプロジェクトメンバに対しての足かせ以上の効果は期待できないでしょう。Booleanという例があります。これは名詞(句)ですよね?その他コードコンプリートを探せば(規約違反)のコードを見つけることができるでしょう。これは規約が間違っていると判断された方がよろしいかと思います。14:37:05ご返信ありがとうございます。13:05:50ご返信のとおりです。続いてもう少し突っ込んで話します。ご返信のとおり、ブール型の変数の効用は、1.複数の判定をまとめて中間値として保持する2.判定のラベル付け(意味付け)を行うと説明されています。複雑な条件の料理法についてコードコンプリートは一見すると矛盾したアドバイスもしているという話になります。T(変数、あるいはメソッド)>にしてほしいということが言いたかったことです。このような変換がビジネスプログラムで有効かどうか怪しいというのが私の意見になります。D)とした場合にそのT自体に意味がある例をあげています。)という分割もありだと思います。)というのがコードコンプリートの例でしょう。このようなbool値による(条件式の抽象化)はシステムプログラムでは有効だと思います。判定式を読んでもその意味するところが解らないことが良くあるので、変数に保持しながらコメントを入れることは上手い手だと思いますし私もそうしたこともありました。ビジネスロジックに限定して話をしますと、私はこのように上手く行く例は少ないと思っています。あるif文で判定を繰り返しているから一つにまとめるというのが、コードコンプリートでは悪い例としている場合もあり、有効かどうかの判断がつかないです。これ以上は具体的なコードを元に話さないと厳しいので何とも言えない面があります。よろしければプロジェクトメンバの方と話してみてください。よろしければ結果を教えて頂ければ面白かったりします。P.S.ちなみに19-32とういのは私が持っている本では無かったです。日本語版と英語版の違いですかね。14:43:59>これは名詞(句)ですよね?名詞句が抜けていたので修正しました。isをつけるかどうかは慣例的なものなので、意味が通れば問題ないです。legalLineCountでも問題ないですね。bool型なのかどう一見分からないですが、if文とあわせてみると違和感はないです。>この規約はプロジェクトメンバに対しての足かせ以上の効果は期待できないでしょうこれも検討事項にします。15:03:42ohfujiさん書き込むタイミングが同じだったようで、続きを書きます。>ビジネスロジックに限定して話をしますと、私はこのように上手く行く例は少ない同意です。Tに置き換えれば上手くいくという例は、これまで一機能だけでした。T自体にも意味がある稀な例でした。>よろしければプロジェクトメンバの方と話してみてください機能自体は結局無しになったという点とプロジェクトを移動してしまったので、難しいかもしれません。>19-32日本語版だとサンプルコードにリスト19-?という連番がついていました。17:09:16返信が遅くなりましてすんません。状況が飲み込めてきましたのですが、どのように返信をしようか迷っておりました。15:03:42の件は了解しました。ちなみに英語版ではサンプルコードのリスト番号がないですね。cshaprdotnetさんは複雑な条件の料理法としてbool式(およびbool型の変数)を駆使することにより、if文を読みやすくするということをされていると理解しました。これはこれで良いのですが、実際の業務アプリの開発ではそれでも条件が複雑で厄介だと思います。コードがぐちゃぐちゃになりメンテナンス性や可読性を保つのに苦労されており、コーディング規約を作り、コードレビューを行うことでそれに対応されているということだと思います。ついでに言いますとそれはあまり効果的でないような気がするというのが私のコメントになりますが、『じゃどうするんだ?』というのがあるかと思います。Methods(日本語だとテーブル駆動なんたらだったと思います)。能書きを垂れても仕方ないので、サンプルを示します。http://www.ohfuji.name/download/20170506/sample_code.htmlになります。動くコードじゃないと意味がないかと思いますのでC#のプロジェクトファイルを以下に保存します。http://www.ohfuji.name/download/20170506/sample.zip先ずは実行したり、コードをみたりして頂ければと思います。私はC#はネイティブでないですし、せっかくということで勉強の為にWPFプロジェクトを試してみてます。VS2012で作成しております。17:55:01自己レスです。粗削りすぎるので一部コードを修正しました。ちなみに書いてませんでしたが、以下のコードは、http://www.ohfuji.name/download/20170506/sample_code.htmlこの『ややこしい条件分岐』を私がリファクタリングしたものになります(他の方への補足です)。18:33:26ohfujiさんサンプルコードの件、ありがとうございます。>さて、cshaprdotnetさんは複雑な条件の料理法としてbool式(およびbool型の変数)を駆使することにより、if文を読みやすくするということをされていると理解しました。これはこれで良いのですが、実際の業務アプリの開発ではそれでも条件が複雑で厄介だと思います。コードがぐちゃぐちゃになりメンテナンス性や可読性を保つのに苦労されており、コーディング規約を作り、コードレビューを行うことでそれに対応されているということだと思います。Methods(日本語だとテーブル駆動なんたらだったと思います)実は、Table-Drivenは良く使用するのでサンプルコードは違和感がありません。いう意味では、自分のtable-Drivenの使い方は間違っていないということも再確認できました。ここでのやりとりで気づいたことがあります。Qiitaの記事は個人の経験にもとづいていることもあり、妥当であるかどうかは判断できません。100%正しいといえないものをルール化するべきではないことが、良く分かりました。規約を守らせるにはどうするかというより、足かせになるくらいなら無くすという選択肢もあるのだと気づきました。スキルミスマッチに関するohfujiさんの回答をみて、分かったことがあります。私のスキルミスマッチのプログラマはohfujiさんからみると「平凡なプログラマ」です。いうなら、プログラムはかけるが、効率の悪いコードばかりでスケジュールも守れないプログラマをどうするかということですが、私の記事に書いたことを気にしなくても、上手く運用はできるのだろうと推測しました。テーブル駆動にするというのは、規約にしなくても対応できる一つの対応案です。するのかということですが、以下の通りです。Qiitaの記事のうち「検討事項」にあたるものは、コードレビュー時の参考にはしても強制はしない。Qiitaの記事のうち「規約」にあたるものは、守ってはほしいが、足かせになるのであればはずす。「検討事項」は教育目的では使用できるので、活用法は別途考える。コードレビューで指摘するのは、クリティカルになるものだけで、グレーのものは内容次第では指摘しない。詳細設計の時点で複雑なコードが予想される部分は、複雑さ軽減のため、何かしら対応をする。英語のリンクもそうですが、自分が良いと思った方法を他人に課すというのは意味がないという結論にいたりました。教育目的で話してみるのは価値があり、そこで成長するかどうかはプログラマに任せることにします。結局のところ、最初にいただいたコメント通りだと思いました。>逆に言いますとメソッド内のコードの良し悪しはあまり見ていません。場合によりけりですが何時でも書き換えられるのならもっと別の大きな問題を考えたいです。私としては、結論が出てしまったので、ここで終わりにするのもありかと思いますが、いかがでしょうか?>技術的な話は次に、教育的な観点ではその次にコメントこれは読んでみたいですが、無しでもかまいません。>ちなみに英語版ではサンプルコードのリスト番号がないですね。これは日本語版の配慮でしたか。20:52:27cshaprdotnetさん結論が出たということで私的にも同意できますし、ちょうど連休も終わりになりましたのでこの辺りでお開きが良いかと思います。技術面な話は私からはもう不要だと思います。教育的な面で少しだけ補足しますと実はプロジェクトメンバに対して上手く教育ができるタイミングがあります。一つはコードを書く前にプログラマがどうコーディングしようか悩んでいる時に、的を得たアドバイスをすると効果的です。他には、あまりにもバグが出てそのエンジニアが自信喪失したとき。その他には、担当者間でクロスレビューをさせた時に彼らの間で揉めて判断がつかない時とかです。何れにしても彼らが迷ってアドバイスを欲する時があります。いう時の為に彼らに対して有効なコンテンツを作ることには意義があるかと思います。ありがとうございました。21:44:42教育面の補足に関しても同意できる内容です。これまで話した内容は、自分の考え方を180度変える話でもありました。途中に逃げ出さず、答えを出せてよかったです。連休中にここまで付き合っていただいた点に関しましては、ありがたいと同時に申し訳なかったです。ここまで長くお付き合いいただき、ありがとうございました。10:27:43書き方には気を付けたつもりですが不快に思われた点は申し訳ないです。有意義に話が出来てよかったです。私はもともと変数名の付け方はいい加減で昔に本を読んで勉強はしてましたが、今回改めて整理ができました。私も勉強になりました。お互いにプロジェクト頑張りましょう。14:42:157/11~12までのコメントを非表示対応としました。一連のコメントは以下のページにまとめています。(必須)ウェブサイト『不適切なコメントへの対応』を一読下さい。現在コメントは承認制となっております。Constructorテーマエントリー(RSS)とコメント(RSS)です。