とあるソフトウェアエンジニアのブログ へのコメント http://www.ohfuji.name/ I Love AWPLOG Tue Oct 19 03:04:05 2021 hourly 1 http://www.ohfuji.name/ RYZEN へのコメント http://www.ohfuji.name/?p=3160&#comment_1931 ohfuji 2020-12-30 12:50:18 http://www.ohfuji.name/?p=3160#comment_1931 お久しぶりです。 確かにココ十数年間はIntelでした。 のでそのようなイメージがあったかと思います。 RYZEN へのコメント http://www.ohfuji.name/?p=3160&#comment_1929 G 2020-12-22 02:44:12 http://www.ohfuji.name/?p=3160#comment_1929 お久しぶりです! CPU、AMDに変えたんですね。 OhfujiさんといったらIntelのイメージがありました。 また来まーす! オブジェクト指向おじさん? へのコメント http://www.ohfuji.name/?p=2864&#comment_272 ohfuji 2017-07-22 14:42:15 http://www.ohfuji.name/?p=2864#comment_272 7/11~12までのコメントを非表示対応としました。一連のコメントは以下のページにまとめています。 http://www.ohfuji.name/page.awp?page_id=3071 オブジェクト指向おじさん? へのコメント http://www.ohfuji.name/?p=2864&#comment_216 ohfuji 2017-05-07 10:27:43 http://www.ohfuji.name/?p=2864#comment_216 書き方には気を付けたつもりですが不快に思われた点は申し訳ないです。が有意義に話が出来てよかったです。 私はもともと変数名の付け方はいい加減で昔に本を読んで勉強はしてましたが、今回改めて整理ができました。ので私も勉強になりました。 では、お互いにプロジェクト頑張りましょう。 オブジェクト指向おじさん? へのコメント http://www.ohfuji.name/?p=2864&#comment_215 cshaprdotnet 2017-05-06 21:44:42 http://www.ohfuji.name/?p=2864#comment_215 教育面の補足に関しても同意できる内容です。 これまで話した内容は、自分の考え方を180度変える話でもありました。 自分の意見が否定され、それが正しいと思えたときは不快にもなりましたが、 途中に逃げ出さず、答えを出せてよかったです。 一方、連休中にここまで付き合っていただいた点に関しましては、ありがたいと同時に申し訳なかったです。 ここまで長くお付き合いいただき、ありがとうございました。 オブジェクト指向おじさん? へのコメント http://www.ohfuji.name/?p=2864&#comment_214 ohfuji 2017-05-06 20:52:27 http://www.ohfuji.name/?p=2864#comment_214 cshaprdotnetさん 結論が出たということで私的にも同意できますし、ちょうど連休も終わりになりましたのでこの辺りでお開きが良いかと思います。 恐らくですが技術面な話は私からはもう不要だと思います。教育的な面で少しだけ補足しますと実はプロジェクトメンバに対して上手く教育ができるタイミングがあります。 一つはコードを書く前にプログラマがどうコーディングしようか悩んでいる時に、的を得たアドバイスをすると効果的です。 他には、あまりにもバグが出てそのエンジニアが自信喪失したとき。その他には、担当者間でクロスレビューをさせた時に彼らの間で揉めて判断がつかない時とかです。何れにしても彼らが迷ってアドバイスを欲する時があります。 そういう時の為に彼らに対して有効なコンテンツを作ることには意義があるかと思います。 では、長々とありがとうございました。 オブジェクト指向おじさん? へのコメント http://www.ohfuji.name/?p=2864&#comment_213 cshaprdotnet 2017-05-06 18:33:26 http://www.ohfuji.name/?p=2864#comment_213 ohfujiさん サンプルコードの件、ありがとうございます。 >さて、cshaprdotnetさんは複雑な条件の料理法としてbool式(およびbool型の変数)を駆使することにより、if文を読みやすくするということをされていると理解しました。もちろんこれはこれで良いのですが、実際の業務アプリの開発ではそれでも条件が複雑で厄介だと思います。コードがぐちゃぐちゃになりメンテナンス性や可読性を保つのに苦労されており、コーディング規約を作り、コードレビューを行うことでそれに対応されているということだと思います。 まさにこれです。 >ついでに言いますとそれはあまり効果的でないような気がする >18 Table-Driven Methods(日本語だとテーブル駆動なんたらだったと思います) 実は、Table-Drivenは良く使用するのでサンプルコードは違和感がありません。 そういう意味では、自分のtable-Drivenの使い方は間違っていないということも再確認できました。 一方、ここでのやりとりで気づいたことがあります。 Qiitaの記事は個人の経験にもとづいていることもあり、妥当であるかどうかは判断できません。 そして、100%正しいといえないものをルール化するべきではないことが、良く分かりました。 また、規約を守らせるにはどうするかというより、足かせになるくらいなら無くすという選択肢もあるのだと気づきました。 さらに、スキルミスマッチに関するohfujiさんの回答をみて、分かったことがあります。 私のスキルミスマッチのプログラマはohfujiさんからみると「平凡なプログラマ」です。 しいていうなら、プログラムはかけるが、効率の悪いコードばかりでスケジュールも守れないプログラマをどうするかということですが、私の記事に書いたことを気にしなくても、上手く運用はできるのだろうと推測しました。 たとえば、テーブル駆動にするというのは、規約にしなくても対応できる一つの対応案です。 では、どうするのかということですが、以下の通りです。 1. Qiitaの記事のうち「検討事項」にあたるものは、コードレビュー時の参考にはしても強制はしない。 2. Qiitaの記事のうち「規約」にあたるものは、守ってはほしいが、足かせになるのであればはずす。 3. 「検討事項」は教育目的では使用できるので、活用法は別途考える。 4. コードレビューで指摘するのは、クリティカルになるものだけで、グレーのものは内容次第では指摘しない。 5. 詳細設計の時点で複雑なコードが予想される部分は、複雑さ軽減のため、何かしら対応をする。 英語のリンクもそうですが、自分が良いと思った方法を他人に課すというのは意味がないという結論にいたりました。 しかし、教育目的で話してみるのは価値があり、そこで成長するかどうかはプログラマに任せることにします。 結局のところ、最初にいただいたコメント通りだと思いました。 >逆に言いますとメソッド内のコードの良し悪しはあまり見ていません。もちろん場合によりけりですが何時でも書き換えられるのならもっと別の大きな問題を考えたいです。 私としては、結論が出てしまったので、ここで終わりにするのもありかと思いますが、いかがでしょうか? >技術的な話は次に、教育的な観点ではその次にコメント これは読んでみたいですが、無しでもかまいません。 >ちなみに英語版ではサンプルコードのリスト番号がないですね。 これは日本語版の配慮でしたか。了解しました。 オブジェクト指向おじさん? へのコメント http://www.ohfuji.name/?p=2864&#comment_212 ohfuji 2017-05-06 17:55:01 http://www.ohfuji.name/?p=2864#comment_212 自己レスです。 少し粗削りすぎるので一部コードを修正しました。 ちなみに書いてませんでしたが、以下のコードは、 http://www.ohfuji.name/download/20170506/sample_code.html この『ややこしい条件分岐』を私がリファクタリングしたものになります(他の方への補足です)。 http://qiita.com/csharpisthebest/items/99af9136883f139ad70f オブジェクト指向おじさん? へのコメント http://www.ohfuji.name/?p=2864&#comment_211 ohfuji 2017-05-06 17:09:16 http://www.ohfuji.name/?p=2864#comment_211 返信が遅くなりましてすんません。 状況が飲み込めてきましたのですが、どのように返信をしようか迷っておりました。 先ずは、 >2017-05-05 15:03:42 の件は了解しました。ちなみに英語版ではサンプルコードのリスト番号がないですね。 さて、cshaprdotnetさんは複雑な条件の料理法としてbool式(およびbool型の変数)を駆使することにより、if文を読みやすくするということをされていると理解しました。もちろんこれはこれで良いのですが、実際の業務アプリの開発ではそれでも条件が複雑で厄介だと思います。コードがぐちゃぐちゃになりメンテナンス性や可読性を保つのに苦労されており、コーディング規約を作り、コードレビューを行うことでそれに対応されているということだと思います。ついでに言いますとそれはあまり効果的でないような気がするというのが私のコメントになりますが、『じゃどうするんだ?』というのがあるかと思います。 これが、felisさんのコメントになるのですが、コードコンプリートにもヒントがあり、18 Table-Driven Methods(日本語だとテーブル駆動なんたらだったと思います)。になります。で、能書きを垂れても仕方ないので、サンプルを示します。 http://www.ohfuji.name/download/20170506/sample_code.html になります。で動くコードじゃないと意味がないかと思いますのでC#のプロジェクトファイルを以下に保存します。 http://www.ohfuji.name/download/20170506/sample.zip 先ずは実行したり、コードをみたりして頂ければと思います。もっとも私はC#はネイティブでないですし、せっかくということで勉強の為にWPFプロジェクトを試してみてます。VS2012で作成しております。 オブジェクト指向おじさん? へのコメント http://www.ohfuji.name/?p=2864&#comment_210 cshaprdotnet 2017-05-05 15:03:42 http://www.ohfuji.name/?p=2864#comment_210 ohfujiさん 書き込むタイミングが同じだったようで、続きを書きます。 >ビジネスロジックに限定して話をしますと、私はこのように上手く行く例は少ない 同意です。Tに置き換えれば上手くいくという例は、これまで一機能だけでした。 T自体にも意味がある稀な例でした。 >よろしければプロジェクトメンバの方と話してみてください 機能自体は結局無しになったという点とプロジェクトを移動してしまったので、難しいかもしれません。 >19-32 日本語版だとサンプルコードにリスト19-?という連番がついていました。 英語版だとサンプルコードの連番は違ったりしますか?(章と勘違いされいたら申し訳ない)