コピペプログラマの明日はどっちだ?

技術,プログラミング言語

TL;DR

正論も結構だけど、それだけじゃつまらないよね。

コピペプログラマの末路

発端になったのは以下の記事。

無料ですが登録しなきゃ読めない記事のリンクを貼ってすみません。1ページ目だけは登録しなくても読めるので勘弁してください。2ページ目以降読みたくなったら、無料登録すれば良いと思います。

でも、自分に読解力がないせいか、同じようなことを繰り返し書いてる上に、特に3ページ目とか余計な枝に飛んだりして、わかりにくく感じました。正直、口述筆記かと思ったくらいです。まあ、自分もあまり人のことは言えない(書けない)のですが。

コピペプログラミングの何が悪いのか

いろいろな事例を挙げて解説してくれているのでしょうが、読解力が足りないので話が発散しているように感じてしまいます。きっと意識の高い方々は問題なく理解できるのでしょう。

コピペプログラミングの良くない点として、中身を理解しないことを挙げているものとみえます。読解力がないのでそこまで把握するのが精一杯でした。

で、ほぼ同じようなことを書いているよな、と自分が思ったのが、これを読んでもやもやして検索して見つけた以下の記事。

こちらは無料、無登録で全文読めるので、こちらを読んで貰えば良いかと思います。

百聞は1件にしかず、コピペしたら動かそう

こちらはそもそもページ区切りがないので読みやすいというのもありますが、セクション毎に重要なところは体裁を変え、適宜ポイントはそれとわかるようにして、と全体構成をちゃんと考えて書かれていると感じます。
こういうところは真似しないといけないですね。

その中でもやはりそうだよな、と思った部分がこれ。

コードをぱつと理解できなかった場合はコピペした後で理解を深めよう

単に説明できるように心がけたり、理解するように努めるのではなく、以下のようなことをしましょうと言ってます。ほんとこれ。

例えば先ほどの例であれば、途中でprint_r($array)などを出力して順番が変わっていく様子を1つずつ見ていくことで理解の助けに繋がります。

と背景網かけて書いてくれた上に、太字で

頻繁に状況を確認しながら進めるというのは必須スキルでして、理解を深めつつちょっとずつ進んでいくというのが基本です。

と続きます。全くもって、その通りだと感じます。多分、この方は実際に開発経験あるよな、と感じさせます。

コピペプログラミングの良し悪しを語るとしたら、これなんですよね。

ポイント

どう動くのかわからないなら動かしてみる。単に動かしても状況が分からないから、デバッグ出力とかデバッガ使って変数をウォッチしたり、ログを見たり、ファイルに出して確認する。

検証用プログラムを動かそう

もちろん、観賞用じゃないのでコピペしたコードを動かしはするでしょう。でも、目的のコードの中に組み込んでああだこうだすることを「動かす」とは自分は言いません。まずはそれ単体でどう動くか確認します。
必要なら、目的のコードの一部を切り出してきてその中に埋め込みます。

何かコードに問題が発生した場合、それを再現できる最小コードを検証用に作ったりしますが、それと同様です。問題の本質部分はどこかをはっきりさせるには、巨大なソースの中に埋もれたコードではなくて、エッセンスだけ抜き出したものが必要になります。

まあ、単に自分の預かり知らぬところに影響が出るかもしれないものをそのまま使うのが怖いだけですけど。

そして、動いたらOKじゃないの?という素朴な疑問に対しても、ちゃんと次のセクションで回答しています。正論は正論ですが、納得できる理由がないと、やはり難しいですよね。

なぜ理解しなきゃいけないかということについても3つの理由を挙げています。

  • 大規模開発では、同じ部分を見直す機会が頻発する
  • 自分が何を書いたのか理解できていないと、バグが多くなる
  • 自分が理解しにくいコード=他人も理解しにくいコードなので改善が必要

いや、おっしゃる通りです。

良薬口に苦し、でも飴も必要だよね

最初の記事は結局、王道はないから基礎を積み重ねて「先端IT技術者」を目指そうというオチで終わっています。それはそれで正しいし、間違ってはいません。

でもね。コピペプログラマにだって言い分はあると思います。

  • 忙しすぎてそんなことしている暇がない
  • とりあえず動かすことが最優先、だって納期があるのだから
  • 理解しなくたって動けばそれでいいじゃん

それに対して上から目線で「学問に王道なし(だからやれ)」じゃ、何も解決しないですよね。

2番目の記事では、それに対して明確に

  • 楽できるところはガンガン楽して良いじゃない
  • 良いコードを見れば経験値も上がるし、引き出しも広がるよ
  • でも分からないところはちゃんと試して理解しようね

と、少しはモチベーションを上げるような書き方をしています。コンサル目線と現場目線の差とでもいうべきでしょうか。

うちの祖母がよく言っていたのが山本五十六の以下の訓えです。

やってみせ 言って聞かせて させてみて 誉めてやらねば人は動かじ

ほんこれ。

ちなみに、これには続きがあります。祖母はそこまで教えてくれませんでしたけど。

話し合い 耳を傾け 承認し 任せてやらねば人は育たず
やっている姿を感謝で見守って 信頼せねば人は実らず

蛇足

最初のセクションにTL;DRというセクションを書きましたが、実はQiitaとかでよく見かけるけどなんだろうな?と思ってました。

そんなわけでちょっと調べてみましたが、あまり公式な文章では使わないようですし、そもそも一部の界隈でしか通じない表現のようで。

このTL;DRについても、Googleで検索した結果のサイトを3つくらいは最低開いて確認しています。1箇所の記述だけでは抜け漏れあるかもしれないので、複数当たってみるのは当然ですよね。

コメント欄にTL;DRと書かれないように気をつけたいところですが、どうも性格的にあれこれ書き足したくなってしまうのが難点です。

そんなわけで、発端はコピペプログラマは良くないのはわかってるけど、具体的にはどうしたら良いかもうちょっと書いてないと途方に暮れるんじゃない?と思ったことでした。
それに対して色々見ているとその答えとともに、情報発信は受け取る側のことを考えてしないと意味はないよな、と再確認。

人の振り見て我が振り直せ。良いところはどんどん真似しよう。ビバコピペ。

技術コピペ,プログラミング言語

Posted by woinary