ウチの会社ではトップエンジニアはよく、「this has a bad code smell」と言います。意味は、「証拠はまだないんだけど、こういう形のコードには問題がよくあります」っと。アンチパターンよりは弱い言い方だけど、経験がある人しか使えないな感じがするので、皆は彼の「bad code smell」に注意します。例えば、ちゃんと動くけど「magic number」が沢山入ってる長い関数には「bad code smell」が着く：テストし難いし、分かり難いし、そもそも「modular」じゃないから書き直すべきだと。
【参考文献のリンク】
◯『プリンシプルオブプログラミング』
amzn.to/3yg9KNW
→今回のメイン種本。おもしろいし読みやすいしためになる。人生の役に立つかどうかは分からない。
◯『最速の仕事術はプログラマーが知っている』
amzn.to/3NjPEGI
→プログラミング技術を仕事全般に活かそう、みたいな本。非プログラマーでも全然読める。直接は参考にしていないが、アイデアを参考にさせてもらいました。今回の動画シリーズに似ているので、お好きな方は読んでみるといいかも。
◯『人月の神話 [プリント・レプリカ]』
amzn.to/3bt0HAs
→『銀の弾などない』などが収録されている著作集。「再発射」の方も入っているし、表題作『人月の神話』も超有名な論文なので、合わせて読みたい方にピッタリ。
◯『Code Complete 第2版 完全なプログラミングを目指して』
amzn.to/3OdlfLH
→情報隠蔽やリファクタリングについての思想で参考にした。有名なプログラミング方法論本。長いし骨太だし本質的なので、非プログラマーは読まない方がいい。
【サポーターコミュニティ加入はこちらから】
yurugengo.com/support
【親チャンネル：ゆる言語学ラジオ】
ruclips.net/channel/UCmpkIzF3xFzhPez7gXOyhVg
プログラマあるある 「前任者どころか半月前の自分自身からも引き継ぎがない」
プログラマの三大美徳:
怠惰 (Laziness)
短気 (Impatience)
傲慢 (Hubris)
を提唱したラリー・ウォール (Larry Wall) はプログラミング言語Perlの開発者としても有名ですが、実は言語学徒でもあったというところに踏み込むと、水野さんの食いつきポイントが増えて面白かったかもしれないと思いました。
七つの大罪かの流用かと思っていたから興味深い。
臭いコードは仲間にとっても当然臭いコードですから他者に「臭い」とはわざわざ伝えないですね。
どう悪くて、どう解決するべきかという一歩先の話をしないとただの愚痴になってしまいます。
コードにも著者がいて、その単純な否定は軋轢を生みます。然るべき改善案を持って臨む方が、建設的で優しいですから。
Rubyを作った「まつもとゆきひろ」氏も「適切な名前をつけることができた機能については、その設計の8割が完成したと考えても言い過ぎでない」と語っているので命名は本当に大事ですね
8:43
エンジニアじゃないのに想像でこの大変さに思い至れる水野さんすげえ...
私が好きなプログラマ三大美徳に関する格言は
「手を抜くためならどんな苦労でもする」
ですかね。
いろいろな試行錯誤を経た結果スッキリしたコードを書けるとめっちゃ気持ちいいですね。
得てしてそういうコードは短くて、読みやすくて、メンテしやすいのに
ステップ数がすくないから工数単価が高く見られてしまうのがなんとも・・・・・
「このコード臭うな」と思うことは結構ありますが
それを直接人に言うとどうしても作者への攻撃のように取られるので
伝えるときは具体的な詳細の話にしてますね
水野さんのリファクタリングの例えとしてのExcel、私も感激しました。聞いた瞬間「リファクタリングそのものやん！」
TeX、Knuthの原本もってるオールドユーザーなので、むっちゃ楽しみです。
堀本さんの作ったサイトを本職の方とコードレビューするの面白そうw
観る人を選ぶかもしれないけど、それこそがゆるラジっぽい。
JavaScriptのゆるさは群を抜いていると思うので、
これからはJavaScriptのことを「ゆるプログラミング言語」と呼ぶことにします。
となるとTypeScriptとかCみたいな静的型付け言語は「ガチプログラミング言語」になったり…？
@@tsuyuki007つ「void*」
@@kettle9265 あっという間にゆるプログラミング言語に…
コードレビューのエンタメ化は期待です。
持ち回りレビューで数多の指摘が入ってくる
あの悪夢を再現してくれるとうれしいですね。
また、レビューも一つの開発工程の重要なフェーズなので、
トピックの一つとしても上がるとうれしいです。
余談ですが、最近のレビュー(コード、設計)では、
コードの誤字脱字や"てにをは"のミスは指摘しないという進化を遂げてます。
また、レビューにもコーディングや設計と同じようにハウツーやノウハウがあるので、
ぜひ調べてみてくれるとうれしみです
条件分岐の話、怖いのは「え、テーブル構造的にこのカラムにこの値入るわけないだろ」って思って直したら2週間後ぐらいにエラー吐いて「え、その値入って来んの？マジで？なんで？」ってのがありうること
関係者に聞き回ると「実はこういう場合にこういう値入れてます」って頭を抱えたり……
SERIAL_NO「シリアルナンバーのカラムです」
ワイ「お、整数型か」
SERIAL_NO「文字列(半角英数)です」
ワイ「えぇ…」
TeX回やるの！！！！
数学科出身なのでめっちゃ楽しみにしてます！！！
同期に論文に使う概念図を全てTeXで作る職人がいました！！
21:03 大学時代のブログをみられるよりも、読める人にコードをみられる方がより恥ずかしいはず
という考えに至ったら突然プログラミングの勉強したくなってる水野さんに草。
黒歴史漁り等、堀元さんをただ辱めることに余念がなく「そのために勉強したくなってきましたねー」を
「そうですねー」って他人事のように肯定してる堀元さんにも草。
「傲慢」という考え方もありますが「駄作を作る勇気」というものもありますね
当方国語教師、生徒の記述答案を添削しているときに「臭い」はよく使いますね。
おかげで生徒も「ここ臭いんですけど、どう直せばいいかわかんなくて、、、」と段々感染しています。
僕も教室入ると「何か臭いですね」ってよく言われます。同じですね☆
code smellですが、コード解析ツールの結果の区分としてよく登場しますね。（ネストの数が多いとか、条件分岐が網羅されてないとか）
人じゃなくて機械から指摘されるときの命名としてよく使われてる気がします。
鼻がない機械に言われているとはね。
「コードが臭い」は使わないが、「コードが汚い」「コードが長い」をよく使います。
とても面白かったです！
文系で事務職ですが、エクセルのマクロが便利すぎて少しずつ勉強中です。
1年前に自分が書いた処理のタイトルを見ても？？？になるので、
後日の自分のためにもうほぼ話ことばで説明するようなタイトルになっちゃってます。
私も全く同じです!反省して今作っているものは綺麗に書くも、来年には(ry
リファクタリングの例えをリファクタリングされているミスターホリモト
JavaScriptは型を意識しなくていいから簡単だけど、
JavaScriptは型を意識しないといけないから難しい
？
ﾜｹｶﾞﾜｶﾗﾅｲﾖ
自由度が高いからこそ、こっちで気を付けないといけないってことかな？
うーんこの、矛盾というか、天邪鬼というか…
@@mahoror エラーが出ないからとりあえず動きはする。
規模大きくなった時に急にそのエラーが噛み合って全然思ってた動きと違う動きをしだすことがある。
エラー出ないから動くのはありがたいけど小さいミスに気付かなかったりすることから取り返しのつかないバグを生み出すから気にすることが多い
TypeScriptかな？
@@RIAFeed ？？？？
サムネがあまりにも「インターネット」で笑っちゃった
メソッドの命名難しいですよね。
例えば例に上がったregisterCustomerInfomationは
登録と検証の機能を持っていると思います。
堀元さんの言うようにvalidateCustomerInfomationに変更するのもいいですが。
メソッドの適切な分割や
将来的に顧客情報編集や顧客情報削除が追加されることを見込んで
registerCustomerInfomationと
validateCustomerInfomationに分割することで拡張性上げるのも良きかもですね。
水野さんの補完能力が凄すぎます
Typescriptの話をエクセルの話に落としこめるなんて…！
飲み込みが早すぎてたまに台本ブレイクしまうこともあるようですが😂
水野さんが「not」の命名に納得いってないようだけど、論理演算を学べば違和感が解消されるはず
あと、reverseじゃなくてinverseって単語がありますよね
堀本さん、あなたが書いているのはTypeScriptではなくAnyScriptですよ
凄腕プログラマーさんにコードをレビューしてもらう際に、例えて説明することお願いしても、きっと円卓を囲む哲学者を通ってきた人たちだからトランジスタプリン亜種が生まれそうな気が
水野さんが「傲慢」に引っ掛かってるんですが、亡くなられた岩田聡さんのエピソード聞くと、プログラマーとして如何に必要な資質なのか腑に落ちました。
MOTHER2を建て直した有名なエピソードは、普通に考えたら凄い傲慢な表現なんですが、実現する高いスキルも持っているので、説得力となっているように思います。
5:15 例え話が芯食わなくていつも堀本さんに一蹴されている水野さんが、完璧な例えで台本アシストする名場面
なんか今回、特にすごく良いです！ゆるコンから「こういうの聞きたかった」って話が聞けてる気がして超楽しかった！
33:10
水野さんが「傲慢か？プライドとかのほうが良い」とおっしゃっていますが
傲慢は英語でprideです
プチ堀元さんがおる～
東村アキコ回は漫勉(無印)のシーズン1ですね。
浦沢直樹との対談ではバーのママ風に登場されてて、それも素敵でした。
無印はその前にシーズン0、かわぐちかいじ回と山下和美回があり、シーズン1からシーズン4まで4人ずつ取り上げています。
その後の漫勉neo は現在まで14人放送されています。
定点カメラで3日間密着し、息遣いを感じる仕事場、埋まっていく原稿、浦沢直樹との会話、第一線のクリエイターがもがく様子を堪能できる他にない番組です。
三大美徳の傲慢は、日本語的にしっくりくるのは「職人気質」だと思う。
(La)texは数式使わない本でも縦書きの本とか言語関係の本で組版によく使われるらしいから
水野さんにはオススメ
「コードが臭い」は使っています。
臭いのもと（バグ）は目の前には見えないけど、
この周辺（整理されていないコード、リファクタリングされていないコード）が臭うから
ここにバグが隠されているんじゃないか？と怪しむことを指して、
「このあたりのコードが臭そうだから、バグ起こしてそう」というような用例で使っています。
部屋で異臭がしたときに周囲を臭って、この辺りから臭いがしてくるなと探すと思いますが、
そのときと同じような「このあたりが臭うぞ」という感覚になります。
TeX!!!!
楽しみすぎる…
堀元さんの言うこと全て経験していて、しかもトラウマになっているので胃が痛くなります
プログラムで命名が大事なのはその通りだけど、わかりやすいと感じる命名は人によって全然違うので、コードレビューで不毛な争いに発展しやすいんですよねー
いわゆる自転車置き場の議論
多分、語彙力の問題も絡んでいると思います
俺自身では「よし、良い名前付たぞ」と思ってもレビューしてもらうと「んだこれ!? これより○○の方がいいんじゃね?」みたいに自分では思いつかなかった名前が提案されることもある…と思います
自分がコンピュータの勉強したときになかったものに例えるのはなかなか思いつかないんですよね。
リファクタリング(refactoring)はMartin Fowler先生が作った言葉で、ソフトウェアの対外的な動作を保ちながら内部構造を改善する作業を指すんやで。
コードレビューのエンタメ化、期待してます！
私はプログラミングできませんが、
主人がエンジニアしてて、前任から引き継いだコードを書き直す作業をしてるとき、よく「コードが汚い」「これは直すの大変だ...」って呟いてます。
傲慢って何のことかなと思えば、まるで、せっかく焼き上がった作品を全て割ってしまう陶芸家じゃないですか。
「水野笑顔」3個で何が出来上がるのか気になる…
5:15 台本ブレイカー水野、今回は台本クリエイターとなる。
堀元さんがコードレビューされて恥ずかしがってるエンタメ是非見たいです！！
新人の頃、同じ処理を何回も書いてるコードにぶち当たって必死に直してたら漏れがあってインシデント発生。
スーツ着た大人がぞろぞろ謝罪に向かったことを思い出して胃が痛くなりました…。
昔の人がその場しのぎで書いたコードに苦しめられるのはあるあるですね。
3つの美徳は7つの大罪に対応させてラリー・ウォールは考えたのだと思います。なので、傲慢はプライドで多分あってますね。短気は憤怒と同じかと。
命名あるある: 悩んだ末に、結局 i,j,x,y あたりになってしまうループ用変数
「変数名には全て意味をつけるべき」派と「ループ変数等の一時利用のものにはむしろ意味を持たせるべきではない」派があるのがなんとも...
個人的には1、せいぜい2ループは許しても、3ループはちゃんと変数つけるべき派ですね。あとよく知られているアルゴリズムであれば自明なので適当でも良いと思います。
（そもそも多重ループするのはどうなのよ？っていう意見は受け付けておりません（笑））
リファクタリングあるある
リファクタリングの本を読んで実践するも過度に共通化したり滅茶苦茶分割したりしてかえって汚くなる
TeX回がち楽しみなのでまじで待ってます（組版大好きコンピュータ・サイエンスの民）
命名はプログラムにおいて重要であるのもそうですが難しい作業であると実感しますね。
変数などでは規則性が欲しいですしかといって見分けが付きにくくても困る、詳細に書こうものならソースコードが汚くなる・下手すれば使った名前を探すのが面倒になるなど、もうどうすればいいか分からなくなった覚えがあります。
こういうシーンにおいて三代美徳が湧き起こってくるのですが、アレは美徳でもありつつ呪いでもあるなぁと絶望しますね。
命名が重要なのは孔子が論語の中で「正名」として立項するほど重要な概念
つまり孔子はプログラマーだった？
飲みながらウンコードみるの楽しい
33:12
傲慢は英語で pride だからプライドで合ってるのよね
21:14 新しいおもちゃを見つけた水野
LaTeXは20年ほど前に使いまくってました。
TeXの回、楽しみにしてます。
プログラマの三大美徳、完璧に備えているのですが、プログラマじゃないので非効率なシステムをあげつらうだけの面倒な人間になってしまってます
堀元さんがクリエイターには傲慢さが必要とおっしゃられたのが、結構刺さりました。私は個人のアニメーターとして仕事をしています。ある意味クリエイターですが、傲慢さを発揮できるクラスのクリエイターは本の一握りの強い立場だけで大勢の名もなきクリエイターはクライアントからの制約の中で最大限に良いものを出すことでもがいていて決して傲慢にはなれないなあ、と感じます。矜持はあれどなかなかそれを押し通す立場に上がるのは険しい道だなと感じているのでこの言葉が耳に痛く、印象に残りました。
傲慢は正しく英文でプライド、なので。さらに言うとキリスト教の大罪「傲慢」は虚栄と合流した存在なので……。
「ゆる」とか頭冠につけて傲慢から逃げているコンテンツから聞くとゾクゾクしますね！
職業がエンジニアなので分かりみが深すぎて、終始頷いていたらちょっと首が痛くなってきた
かじったぐらいですけど
3Dモデリングでもあるやつですね…
力技でもいけちゃうけどっていうのは
キョロキョロして誰にも見られていないことを確認してササッとやるやつですね、モデリングは作る過程を見られなければバカにされないので
今回のサムネ好きです
このシリーズ好きだから再開してほしい
ええ！TeX 特集あるんですね！昔は使いまくってましたけど、ここ10年以上全く使ってないので、楽しみです
あと、リアルで「匂いますね」とか「臭いですね」は自分は言わないですし、あんまり聞かないです
楽しみに待ってました
命名の難しさは、Excelファイルのファイル名で理解してもらえそう
多分「臭い」っていう時は「吐き出す結果見る限りこのあたりが臭いなと思ったので精査した」みたいに
「このあたりっぽい」を「このあたりくさい」っていうのと言葉の上では一緒だと思うんですよね。
誰かに向けていう言葉ではなくてブログにまとめるとか独り言とか。
水野さんの察する力？えぎちぃ
rubyのmatzもゆる言語見てるらしいから是非出演していただきたい
まじっすか！？
@@HANEKAWAhaorenoyome matzは言語オタクだからある意味当然ですね。
10:51 「マイナスの値入れたら終わった」については「核ガンジー」を参照ください。
22:50 ご所望のとは違うかもですが、ドラクエのプログラマがデバッグ作業の実況をしてたりします。ruclips.net/video/sRzrznAzv9U/видео.html
漫画の神様、手塚治虫先生、
第一回二十四時間テレビに作成した二時間アニメ「ハンターブック」のオンエアを見て一言！
「全部！リテイクです！」
命名は設計と同義だと思っている
コードの臭いの話題で神オブジェクトが出なかったのが意外でした。お二人とも好きそうなネーミングなのに。
私はマジシャンですが、めっちゃわかります！！
マジシャンは（マジック業界内で）オープンソースになっているトリックを引っ張ってきて
それを自分なりに最適化するのですが
このときにめちゃくちゃ非合理になるときがあるのです
でも、表向きには現象は起きるし
関係者以外はその汚さはわからないので
「そのままいっちゃえ！」
ってやって、あとで後悔したりしますw
もっと傲慢にならないと・・・。
おもしろかったです！
タイトルの話、参考になりました。
「コードの臭い」とは微妙に違うような気がするけども、「機能の横恋慕」や「相続拒否」など他者の機能を利用するものは「行儀が悪いコード」と表現することはあると思う
口に出して「臭い」ということあんまり無いけど、バグを追ってるときに「この辺臭うなぁ」と思うことはよくある
6:57 「タックス？」ってヒントだけでよくTeX出てきたね
「この辺が匂いますね」はよく使います。
「不吉な匂い」って意訳（？）が秀逸だなと思った記憶
こう汚さからくる「臭い」ばっかりじゃないと思うので。
そしてこれは割と汎用性ある感覚じゃないかなと
リファクタリングはやってて楽しいので好きなのですが、どうやっても工数に積んでくれないので、疲れたときフィジェット回すかのように散発的にやってます。
コードを臭いで判断するってのは、数学者は数式のホクロの部分がわかるみたいな話だなと。
ソースに出てくる物の命名は毎回かなり時間を使っちゃいますね
例えば全体としてあるものを作成するような処理を作る時、
その処理の中に実際にその物を作る処理とその前準備処理を含める場合に全体処理と中の処理で命名被るな・・・ってなる
昔、初めて制御系の職場で働いたとき、シリアル通信の制御で以下のような処理をしているコードを見つけました。
①データ列からパリティビットを計算
②計算された各パリティビットを16ビット変数に格納
③その16ビット変数に対して 0x0F0F の XOR(排他的論理和) を求める
④データ列の末尾にその16ビットを付加する
「あれ？処理③は要らないんじゃ…？」と思ったんですが、
制御系の職場で働いていないと気付けない理由でしたが、必要な処理でした。
何か通信規則みたいなのに抵触するんですか？
@@zaoxingshuzhi3779
データ列が全て 0 だった場合、16ビット変数も 0 になります。つまり受信側では全て 0 のデータを受け取ることになります。
ただ、回路に不備があると、マイコンから出力された信号がすべて Low (電圧 0) に張り付いてしまうことがあります。
③の処理は、受信側でこの 2 つの状態を区別できるようにするためのものでした。
@@Fnak202 なるほど！ 無指示か止まれかは違いますね。勝手な解釈ですが…
ウチの会社ではトップエンジニアはよく、「this has a bad code smell」と言います。意味は、「証拠はまだないんだけど、こういう形のコードには問題がよくあります」っと。アンチパターンよりは弱い言い方だけど、経験がある人しか使えないな感じがするので、皆は彼の「bad code smell」に注意します。例えば、ちゃんと動くけど「magic number」が沢山入ってる長い関数には「bad code smell」が着く：テストし難いし、分かり難いし、そもそも「modular」じゃないから書き直すべきだと。
出、出〜〜〜〜〜〜 型エラーany回避奴〜〜〜〜〜〜
一年前書いたこのコードきたねーなー、リファクタリングしよ！と思って作業開始したら特殊要件があって仕方なくその処理にしたことに気づくパターン多いですね
リファクタリング
foctorを動詞で使うと、因数分解する以外に、代理人を務めるという意味がある。ファクタリングというと、金融サービスの売掛債権買取のことが思い浮かぶ。債権者の売掛債権を買い取るサービスのことだが、言わば債務者に対して資金回収をする「代理人」となる権利を、債権者に現金を払うことで獲得することを言う。（債権者は期日より早く資金化でき、ファクタリング会社は手数料で利益を得る）
リファクタリングは、関係要素を整理することが１番の意味だとは思うが、単に自分でリライトするというより、他人が書いたプログラムを外部的振る舞いは変えないまま、ソースコードの内部構造を整理することなので、代理人となって両者の関係性は崩さず、かつ両者にとって最適になるように管財整理をするという意味が込められた「ファクタリング」という言葉がとても合っていると思う。
29:52
小論文とかレポートの書き方の指南書でよく説かれてるよね。
「〇〇について」みたいな漠然としたテーマをつけてはいけないって。
「怠慢、短期、意地っ張り」一票
3大美徳は、七つの大罪にかけた表現で、傲慢は英語だとPrideで、それを日本語に訳しただけなので、そこでニュアンスがずれていますね。
短気は関西だとせっかちにあたりますね。短気は七つの大罪にはないので、元の英語では何と表現されていたのでしょうか？気になりますね。
元は
怠惰 (Laziness)
短気 (Impatience)
傲慢 (Hubris)
ですね。
サムネ大好き
普段プログラミングしている者です。「俺が作ったものがこれで良いはずがない」とは常々思うものの、納期と費用対効果もあるので・・・どこまでやるかは、いつも悩みます。
ラバーダックデバッグ用にゴム製の水野さんの人形をグッズで作って欲しいですね
33:13 まあ7つの大罪の「傲慢」の英語はprideなので…
true姑息なコードを書きやがって…
臭いに関しては「サスペンスドラマでの刑事のセリフ」にもありますよね
「俺の長年の経験が『コイツぁくせぇな』と告げている」みたいなセリフを刑事役や主人公が言っているシーンを数回ぐらい見た記憶がありますね 「あ、なんかヤベェ…」と直感的にわかる感じですかね
俺はC++周辺から来たのでむしろ静的型付けの言語の方が楽ですね… TypeScriptでanyって…(苦笑)
確かに命名は相当悩みますね… 長すぎると関数名を読む気無くしますし、短すぎると「なんだこれ」感が半端ないですし…