ポッドキャストの始まりと概要
こんにちは。言語化.fmは、あんな話やこんな話を、キリンとタテの2人でゆるく話しながら言語化を試みるポッドキャストです。
最近言えないんですけど、やります。というわけで今回は、カジュアルにコードを読みに行く大事さを言語化したい、です。
ここまでイチカミですね、今日は。
カミカミカウンター。数えて誰かツイートしていてください。
なんか家にやらせばいけそうだけどな、今。
いやーどうなんだろうね。
あのほら、音の波形とか見ると、ここで噛んだなみたいなさ、あの間の悪いブレスみたいなのが見えるんで。
あー、ありそう。
まあ確かにね、画像処理しちゃえば数えられそうだね。
あとは、あれじゃない、文字起こしして、おかしなところを噛んだ判定するとか。
何の話してんの?
いやー、最新技術の話でしょ。
でもそれさ、たぶんさ、紙判定してさ、ナチュラルに処理してくれないのかね、それは。
あー確かにね、自動修正的なね。
自動でそういう、ここ噛んでるから取り除くわみたいな。
確かに。ありそうというか、需要はありそうというか、少なくとも俺にはめっちゃ需要あるな。
毎回ね、まあでも毎回編集してるけど、別に噛んでるじゃない。
ほら、そういう、なんか息を吸うとかさ、いわゆるリップノイズみたいなやつって、今自動で除去できる技術あるんでしょう?よく知らないんだけど。
ありそう。
YouTuberとかそういうのないとたぶん大変だよね。
いやでも噛むの毎回だからな、除去せずにいこうかな。
視聴者、視聴者、視聴者の皆さんも今日は噛むかなってドキドキしながら再生ボタンを押してるかもしんないから。
じゃあ愛嬌だそうです。
はい、愛嬌です。
今日はね、ちょっとヌルヌルしててね、ふとヌルヌル。
カジュアルに行動を読みにくく大事さを言語化したいと。
これいつだろうな。
おー、2年前の5月に僕が追加したネタなんですよね、自分に。
まだぺいぺいだった頃の話。
まだぺいぺいだった頃の話ですね。
これね、いやなんかね、考えれば考えるほど大事ではね、以上になっちゃうんだけど、
そうなっちゃうからこそ言語化してもいいかなみたいな感じで書いたのと、
2015年新卒だったキリンさんに届けという気もあるよねっていう感じですね。
これ大事ですよね、そこの合意からまず。
大事じゃないよって言ったら。
コードを読む意義
すごい、そういうアングルからくるの、まず合意形成測るところから。
すごい、すごいわ、これは言語化の成果出てるんじゃないですか。
擦り合わせておかないとさ。
擦り合わせておかないとね。
どう考えても大事ですよ、行動読むっていうのは。
どう考えても大事だよね。
どう考えても大事。
じゃあそのどう大事かっていうところなんですけど、
今まさに合意形成って話をしたんですけど、
やっぱり何かしらの気持ちに寄り添うっていう話かなと思ってまして。
なるほど。
例えば仕事で仕様の調整をするときに、
テキストでバーって書いてあるのを読んでロジカルに理解するんだけども、
それよりもやっぱりコードで書いてあった方が読むの早いみたいなことあるじゃないですか。
ありますね。
ここの仕様ってどうなってるんだっけって聞かれたときにコードシュって見せて、
これを読み解けって言った方が実は早いわけで。
それが人によって使う言葉が違う。
言葉っていうか言語が違うので、
時にはJavaScriptの方がいいし、
時にはSwitchの方がいいし、
時には日本語もしくは英語の方が良かったりするわけで。
その人の脳のインタープリッターがどうなってるかによってチューニングしてあげるという気持ちなんですよね。
なるほど。
今の話はコミュニケーション手段としてカジュアルなコードを書く的な話。
そういう意味じゃない。
今しゃべってる言葉を全部JavaScriptで置き換えようとかそういうことは言ってなくて。
なんていうか、違うんだよな。
ちょっと俺の言い方が悪かったな。
ちゃんと動くものはこれですよっていうのをコードでバッって示した方が、
なんていうか、憶測が入らないというか。
なるほどね。
これがAzure is ですよっていうのを出せるじゃないですか。
そうだね、確かに。
そこってもう、憶測の入りようがないので、
こうなってるよ以上で終わる話なんだけど、
それがないとすごく遠回りな会話をしがちかなと思っていて。
なんか日本語のハイコンテキストさゆえの有効性みたいなのが多分あるよね。
かっちり頑張って使用書を書いたとしても、
どうしても言葉の解釈とか、
日本語文章が長ければ長いほど多分解釈の余地が暗黙的に変わって、
一見お互い同じことを頭に思い浮かべてると思いきや、
実は違ったみたいなミスコミュニケーションって割とあるあるで、
その辺に対する解として、
だてしが言ってくれた手段っていうのは間違いなくめちゃくちゃわかるっていう。
もちろんケースバイケースなんだけど、ないものは見せようがないので、
自然言語で語るしかないっていうのはあるんだけど。
実は自然言語からとりあえず情報って意外と少ないし、
今言ってくれたようにバグが起こりやすい、
すごく不安定な生き物みたいなもので自然言語って。
逆に我々が常にプロダクションで動いてる行動を見れば、
それを地面ではなくて、
動作まで予期することができるじゃないですか。
やっぱそれに勝る情報源はないなっていうところで、
行動を読むって大事じゃないですかね。
読解力の習得
なるほど。めちゃくちゃ面白いな。
その視点で行動を捉えた時に、面白いね。
自然言語と同列で考えると、
自然言語を解釈するエンジンは、
エンジンは基本的に人間の脳、
当たり前だけど人間のお味噌で、
でも言語使用次第なんだけど、
言語使用っていうのは国ごとの言語使用次第なんだけど、
エンジンによって解釈が変わるっていう、
実は結構狂気じみた言語であるっていう。
だけどプログラミング言語は機械が解釈するから、
そこに人間の解釈が絶対に入る余地がないというか、
入ったらやばいというか、
入ってる人がいたら逆に会ってみたいんだけど、
面白い意味ではめちゃくちゃ有効。面白いな。
なんていうかさ、
これはプログラミング言語が知性に言うと、
怒られるような気もするんだけど、
我々ってコード書くときってもうすでにその、
コンパイラーが解釈できるように、
正義正統した形で書くじゃないですか。
要はそのコンパイラーがわかるシンタックスしか受け付けられないのだから、
それがわかるようにあらかじめ整理して書かなきゃいけないので、
実は割とクソコードというか、
あまりにも下手くそなすごい長いコード、
過読性の悪いコードを書いたときは別なんだけど、
ある程度の過読性のあるコードを書いている時点で、
結構情報としては整理されている。
確かにね。書いたようにしか動かないもんね。
どこまで行っても。
書いたようにしか動かない。
書いたようにしか動かない。
書いたようにしか動かないんだけど、
書いてないことができるだけ起こらないように、
書いてあげるじゃないですか。
そうだね。それも確かに。
日本語は、日本語というか自然言語は、
そういったコンパイラーがないので、
そういった未定期な動作を勝手に脳みそが想像して、
イマジネーションを膨らませていっちゃう。
それが良い方に作用することもあるんだろうけど。
行間を読むってこともあるよね。
そう、行間を読むってやつですね。
解釈を向こうのインタープレーターに意図的に放り投げることさえあるもんね。
解釈を向こうのインタープレーターに意図的に放り投げることさえあるもんね。
そうそうそうそう。わざとやることもあるじゃん。
ちょっと脳膨らせずみたいなさ。
なんかちょっとおもろいな。
ちなみにですね、
前提の擦り合わせめっちゃやって良かったなと思ってて。
前提の擦り合わせめっちゃやって良かったなと思ってて。
あとその、
ちょっと綺麗に、
わざとこういう展開したかったわけじゃないんだけど、
このカジャルに行動読みに行く大切さを言語化するって日本語を
解釈する、二人で解釈するって場面においても、
すでにインタープレーターの実質の差が出てるなと思ってて。
それはそうだよね。
でもどっちも正しいし、
僕が考えたことは別のことで、
そっちもパターンもあるなっていうので、
普通に話したいなと思いつつ、
僕がこれ出した時に書いたコンテキストとしては、
結構その、なんだろうな、
バグを踏んだ時とか分かりやすいな。
ライブラリーインストールして使って、
どう考えてもこれバグってるだろうみたいな時とか、
まあ、そういう浅いレイヤーじゃなくても、
分かんないけど、データベースが何か分かんないけど
変になってくるとか、そういうミドレアとか、
そういうレアでも何でもいいんだけど、
そういう時にサクッと構造を読みに行く、
フットワークの軽さって大事だよねみたいなので書いてて、
これを話したいと思ったきっかけはもう忘れたんだけど、
なんかこの習慣って、
僕は一番最初からついてなかったなと思ってて、
ペッペキペーだった頃は、
僕当時はララベロをメインで業務で使ってたんですけど、
PHPのフルスタックフレームワーカーというのがあるんですけど、
コードを読みに行く前にまずドキュメントを読んで、
うーん、書いてないなってなって、
多分Googleの海に出るわけですよね、
そのエラーメッセージとかでGoogleってよく分かんない聞いたの聞いて、
よく分かんなくはないですね、分かんないですけど、
よく分かんないものも混ざったような聞いたなり、
まあ今はない、当時はなかったけどゼミみたいなそういうメディアを、
あれじゃない、これじゃないってなって、
で、うーん、分かんないな、ちょっとチームメイトに相談するかも、
なんかことをペッペキペーの頃はしてたけど、
まあなんかの時からか、
なんだったかな、まあでも多分なんかそのララベロのプラグインかなんかを自作した時に、
その参考にした実装が、
OSSがあって、
それを結構誠読したことがあって、誠読した時に、
なんかまず一つ目は読め、俺でも読めるじゃんと思ったのが一つと、
読んだらめっちゃ勉強になるじゃんっていうのをめっちゃ思った記憶があって、
一個目は結構大事で、
コードを読むことの意義
その自己評価がペッペキペーなんで、
俺はまだまだ犯人前にもなってない、
駆け出しエンジニアだみたいな気持ちで、
なんかOSSなんてみんな賢い人が集合地で書いた、
ソフトウェアなんて読めるわけもないみたいな、
多分思い込みとか決めつけがあって、
なんでその読むって発想がなかったけど、
その時読んでみて、意外と読めるなって思った。
それは読んだやつが良かった説あって、
例えば最初からCで実装されたやつをOSSとか、
コードサイズがでかいやつとか読んでたら、
ちょっと大変だったかもしれないけど、
そこは割と、もしかしたら運が良かったっていうのと、
普通に勉強になるなって思った。
勉強、難しいな、いろんな意味で勉強になるなって思ってて、
ここをこんな感じで書くと良い感じなんだ、
良い学びもあったし、逆に、
意外とここイケてないなとか、
ここをこうすれば良いんだみたいな発見もあって、
前者で言ってたOSSは全て紙品質のコードみたいな思い込みがなくてたし、
逆に自分でもOSSを作って良いとか、
コントリビューション、プロディクトに上げても良いとか、
そういう風に思い込みがなくて、
自分でもOSSを作って良いとか、
コントリビューション、プロディクトに上げても良いとか、
そういう気持ちにちょっと慣れたっていうのがすごい良かったな、
みたいなきっかけがあって、
多分その辺からどんなやつでも、
割と煮詰まる前にちょろっと実装見に行って、
もちろん引き返すこともあるけど、
そういうマインドがついたなみたいなコンテキストで行ってました。
リードミーの重要性
多分スコープが違う、
でも一緒なのかな、
でも仕事もそうだよなという気はするから、
さっきの伊達氏の話もめちゃくちゃ同意できて、
何かの機能がバグっててどうしても動かないみたいな時に、
社内のライブラリを見に行くとか、
誰かが実装した過去のコードを見に行くとか、
そういうのがあるような気がしてて、
っていう感じっていうか、
僕はそういう解釈っていうか、
多分そういうコンテキストで話してました。
僕はそういうコンテキストなのはじゅうじゅう知ってて、
知ってたので、
そっちから行こうかって思ったんだけど、
思いついちゃったし、
忘れる前に話したら面白いかなと思って、
いやでもめちゃくちゃ面白かった。
繋がりはね、
今のキリンの話から入って、
僕の話に繋がった方が流れ的には相当きれいだと思う。
要するに別に全然違うことを話してなくて、
多分ね、
根本的には一緒のことを言ってるような気はするんだよね。
なんでコードを読みに行くのかってね。
僕もそういった意味でコードを読むのはすごく、
よくやるし、
大事かなと思うんだけど、
やっぱバランス的に難しいことはあって、
それは何かっていうと、読みすぎると逆に沼にはまるんですよね。
そのバランス感はね、
まさに話したいと思ってた。さっき自分の話も。
なので、あえてここで僕は、
コードも大事なんだけど、
リードミーも絶対読めっていうことを強く言っておきたい。
金言だね。
リードミーですよ。
すごく当たり前だと思うんだけど、
多分OSSのコードを読むのはそんなに慣れてない時は、
多分リードミーに書いてあることを、
事前だけオーディエンスでいっぱいだったんだけど、
そうじゃなくて、
まずリードミーを読んで、
このソースコードにはどういうことが書いてあるかって、
わざわざ作者が要約をしてくれているので、
そこをまずちゃんと理解するんですよ。
これはこういうライブラリーですねっていうのを見て、
それから当たりをつけて、じゃあこういうのがあるはずだなと思って、
そのコードをディグっていくと、あるみたいなのがあるんですよね。
金言だね。
リードミーを読んでおけばって思った経験は、
1回や2回じゃないもんね。
個人的に。
読んでて、あれこれリードミーにこんなこと書いてあったっけと思ったら、
ちょっと戻ってみるとかね。
なんていうか、
例えばJSONをファーストするライブラリだと思ったら実は違ったみたいなことはあるわけですよね。
今の例はあんまりよくないけど、
でもあり得ると思う。
実は違って、あれこの処理でおかしくねと思って、
見返してみると読み間違ってたわみたいなのがある。
いろんなパッケージを小分けにして出してくれているようなソフトウェアとかOSSとか結構あるあるな気がする。
この部分の処理が見たくてこのリポジトリにたどり着いて、
勢いのままソースディレクトリ配管をバーって。
これなんかあれかなって。
リードミーに戻って、これサブパッケージじゃんみたいな。
ある。
なんかさ、やっぱOSSっていうか、
パブリックになっているソースコードのレベルっていろいろあると思ってて、
ドキュメントが丁寧に書いてあるだけまだマシって言ってて、
世の中にはドキュメントがカイムになって、
インターフェースだけ見れますみたいなのもあるし、
よくC系のコマンド、UNIX系のコマンドとかで、
名前が省略されててよくわからんみたいな。
Cの関数とかよくあるじゃないですか。
わかんないからマンコマンドを叩いて、
ちゃんと中身を読むみたいな、
そういうドキュメンテーションもあるもんだ。
そういうのに遭遇するために大変だなと思って読んでました。
読んでましたとか今でも読んでますね。
間違いない。
声に出してみたいね、リードミーから読む。
これは完全にポジショントークなんだけど、
iOSってオープンソースじゃないので、
アンドロイドはオープンになってると思うんですけど、
iOSの中身って、よくわかんない語彙に遭遇した時に
ソースコードを見る。
そうすると、APIドキュメントに書いてある
ドキュメントの内容が全てみたいな感じなので、
そういうのをバイブルとして読み込んで、
実際に自分で使ってみなきゃいけないっていうことを
世の中のiOSの人たちはやってる。
そういうのをやってると、
ドキュメントの大事さが嫌でも染み渡ってる。
そうだね、もうドキュメントしかないもんね。
そういった意味で言うと、意外と
ソースコードを読むの苦手な人多いかも。
苦手というかね、経験がまだそんなにない人がいるのかなって
僕の界隈では思いました。
なるほどね。
難しいな。考え方次第かもしれないけど、
まあね。
一番いいのは場面によって
使い分けられるといいよな。
単に僕はコードを読む話で切り出しちゃったけど、
当然リードミーも間違いないし、
ドキュメントもあるなら読んだ方がいいだろうし、
読み方とか歩き方もあるし、
まだ一周とかプルリクを追うっていうパターンもあるじゃん。
コードじゃなくて。
ドキュメントにはこれで困ってますって声は載ってるわけないから、
一周を見るとか、
自分が何を求めているのかによって、
どういう選択肢だといい感じになるのかみたいな肌感じゃないけど、
そういうのが身についていくといいよね。
ドキュメントだけ読むのも多分もったいない。
まあ違うな、ドキュメントしか読めないのはもったいない気もするし、
コードしか読めないっていうのも、
情報の公開とその影響
読めないって言い方はあれかな。
ドキュメントしか読めないっていうのはもったいないかもな。
いやでもドキュメントね。
すごい目も蓋もないこと言えば、
その辺も今どきAIが吉永に解釈してやってくれるんで。
いやー。
もちろんね。
これはすごく難しくて、表面的に理解するだけだったらそれでいいんだけど、
ちゃんと読めるようになりたいと思ったら、
やっぱり読むね。
あとはなんかその、
今言ったいろんな手札を使いこなせるけど、
ちゃんとGPTに聞くのか、
使いこなせる上で聞くのかでも結構変わるよね。
そのAIの回答が、いや違くねって思った時に、
まずその違くねって思えるかどうかの判断基準が
なかったら多分そこで積むこともあるだろうし、
いや違くねって気づけたとしても、
じゃあ自分で掘りに行くってことはできると、
まあいいのか、もしくはAIが
そんなことが起きないとこまで進化するのかどうか。
いやでもさ、一番最初の話に戻るけど、結局その
インタービューター次第だから、まあでもプロンプトエンジニアリングか、
そこで、いやー。
いやーやっぱね、その情報の公開レベルによると思ってて、
GitHubに上がって公開して、ちゃんとギルドミーが整ってて、
ソースコードも公開しているようなものは、
もう多分ね、自分で全然読まなくても、
もうなんか、それこそコード書こうと思ったら
勝手に保管してくれるぐらいには多分なるんですけど、
さっきは
ドキュメントしかないって話したけど、
ドキュメントしか公開されてないって話したけど、
そもそもドキュメントしかない世界というのもありまして、
例えばRFCとかね、
いわゆるスタンダードになっている文章とか、
技術仕様っていっぱいあるんですけど、
そういうのって、
例えばISOとかだと、
そもそも文章読むのにお金かかりますみたいな、
ものもあったりするわけで、
そういうのはインターネットのみ転がってないので、
AIも学習しようがなくて、
それっぽい何かは出してくるけど、
全然情報が足りてないみたいなのとか、
扇してあるので、やっぱりそういうドキュメントは、
仕事で使うのであれば読めた方がいいですよね。
たぶん論文とかもそうね。
なんでああいうフォーマットで書かれているのかって理解しないと、
実例だけ追ってもわからないみたいな感じだと思う。
AIで論文読みたいなら、アブストラクトだけ読んどけってなっちゃうでしょ。
そうそう。
確かにね。
いや、時代だな。
とは言っても、やっぱりコードが公開されていて読めるのは、
すごくありがたい話なんですよね。
いいよね。
急に言語化を放り出すって言ったけど、
ありがたいね。
カジュアルにコードを読む重要性
さっき例としてバグを挙げたけどさ、
単純に参考実装にしたりとか、
そういう言語がいけてないんだよって、
特定言語警察が来たら、
手を両手挙げるしかないんだけど、
特定の実装パターンとか何か、
正解がない、こういう流派があるとか、
こういう場面では人によって書き方がブレうるみたいな時に、
この人がどう書いてるんだろうみたいなのを見に行くことって多くは結構あって、
そういう部分とかは、
勉強させてもらってるのかな、
パブリックコードたちっていう気持ちは、
それをカジュアルにできるっていうのもいいし、
その口がAIになっても、
AIでそれできるのかな、
今度試してみようか、やったことないな。
違うな、俺のプロンプトエンジニアリングがやばいのかどうかの切り分けを
誰かしてほしいんだよな、それで言うと。
それもAIに聞けばいいんじゃないの?
確かに。
確かに、僕の質問、
分かりやすいですか?みたいな。
分かりやすいって言いそう。
いやー、ちょっと修行するわ。
なんだろうね、AIの話で言うと、
書いてて詰まることあるじゃないですか、
あれこれどうだっけみたいな、詰まるというか、
忘れることが多いけど、
そうした時にAI使ってこういう処理ってどうやって書くんだっけみたいなことを聞くと、
それっぽく返して、メジャーな処理だとちゃんとそれっぽく返してくれて、
マイナーなメソッドを使ったりとかしてると、
メソッドやフレームワークを使ったりしてると、
返事不倫な答えが入ってきたりとか、
データ量の問題でしょうがないんだけど。
やっぱりどう頑張ってもね、
この書き方はエレガントだなって思うことがはるかに減ったね。
そういうのはね、減った。
減ったね、全然出てこない。
昔は? OSSとか見てるとさ、
なんかもうため息出ちゃうぐらいエレガント。
エレガントか、うわーこれすげーってなる
コードがやっぱあるんですけど、
なんかね、AID出すとね、全然もう感動もないようないんだよね。
なるほどね。
そうだ、これだったわみたいな。
それは、そうだね、それは否めないね。
コパイロットの活用方法
だから、今話しながら試そうかなと思ったのは、
この人のニポジトリでこういう実装してるのあったら探してきて、
ちょっと引っ張ってよとか言ってみようか、聞いてみようかとか。
あー、作者の手癖みたいなやつね。
そうそうそう、バイネームで。
まあなんかその、まあ難しいけどね、
これはなんかその一定数そういうコードを書ける人を知ってるっていう前提がないと思うんだけど、
まあ僕は知ってるんで、その特定の分野によって。
この人だったらどう書いてるんですか?
言ってんのかな、まあ言いそうではあるような感じ。
そうね。
なんか5日の回で話したけどやっぱ現状だと、
僕も多分前よりはそのちゃんと業務とかまあ私生活で使うようになった。
よくわかんないし、よくわかんないっていうか、
なんかちょっと複雑なファイル処理をするシェルとか、
スクリプトぐらいしかまだ使えてないんだよな。
本コードは書いてもらったら早いことあんのかな。
でもなんか保守するコードはやっぱ書いてもらいたくないな。
書いてもらいたくないっていうか、書いてもらうって発想に至れないんだよな。
頭がどこに行き渡るかもしれない。
だから、そうやって思った時期はあるけど、
100書いてもらう必要ないなと思って、
何だろうな、仮想の同僚とペアアップロしてる感じ?
こういうのってどう書くんだっけって聞いて、
こんなのがあれよって聞いたら、いやでもこっちの方がいいよみたいな。
プロプトの打ち返しをして、
ああそうですね、こっちの方がいいですねみたいなことを言わせるとか。
その謎の仮想的な対話を繰り返して、
どんどんどんどんアウトプットを良くするみたいな、そういう作業だったね。
なるほどね、それやってみたいな。
なんか話してて思い出したけど、
僕はなんかコパイロットに結構頼ってるから、
頼ってるっていうか助けられてるから、
どっちが早いかちょっと今度試したいなって気持ち。
そうだよね、物によってはやっぱり、
コパイロットでコメント書けばとりあえず全部出てきちゃうみたいな。
そうね、とか。
結構、なんていうか、
まあ目、なんか、
いやーでもケースバイケースか。
例えばだけどその、
いやー難しいな。
他の人から見た時にどうかちょっとさておき、
僕目線で何かの処理を、一連の種類を作る時に、
まあ綺麗に分解できているとしたら、
まあ一つ一つのなんか、
まあメソッドなり、
まあメソッドかな、ファンクションとかの責務ってちっちゃくなってるから、
なんかその状態だとその一個一個のファンクションを実装する時に、
まあ2割ぐらい書けば、
でファンクション面の命名がおかしくなければ、
結構残りの8割ぐらいは、
なんか85%ぐらいの精度でコード出してくれるから、
なんかタブポンポンと押してペッて出して、
でちょこちょこって手直ししたら動くみたいな、
なんか状態になってる感があって、
何が言いたかったのかなんか、
割と俺はそういう使い方をしてて、
本とコードの関係
まあでもその分解の仕方とかも、
いや一回試すわちょっと、
試してみたら。
いやでもね分かるよ、
ポンポンって書いて、
出てきたのを眺めて、よしよし問題ないなと思ったら、
もうその件は忘れちゃうみたいな、
ことはあんまなくはないかな。
あとテストの、テストコードはマジで神だなと思う。
テストコードはいいね。
これに対するテストを書いて、
結構パターン的なものとかあると思う。
タブレンダーしておしまいに。
こないだ公開鍵のテスト書いてたら、
ダミーの公開鍵ちゃんと生成して持ってきたね。
ちゃんとしてたわ。
ダミーの公開鍵。
ダミーだけど、
ダミーだけど、
フォーマットとしてはバリットで、
ちゃんと検証もできますみたいな。
じゃあそのツインなる秘密鍵が存在しない、
バリットなコードっていう。
フォーマットとしてはヒトなものを出してくるっていう。
そういうのにはマジで面倒だな。
そういうのググって引っ張るとめっちゃめんどくさいもんね。
そうなんだよね。
強制していく感覚があるな。
やっぱ置き換え、
置き換えほど遠くないか。
まだもうちょっと先。
やっぱ先だけど、
だいぶやっぱり効率的になったところが多いね。
そういうのをやっぱり、
ググらなくてよくなったっていうの。
だからググるのと、
生成させるのの境目が多分どっかにはある。
そこをうまく使いこなせてる。
エンジニア的にはいいんじゃない?
ワンチャン今の若い子、
コード読みに行く話みたいな、
聞いたとき。
これ毎回話してるな。
毎回伊達氏に言われてる。
チャットGPって画面を開いてる時間の方が長いみたいな。
子たちはいるんだろうな。
それが別に、
いや、コード読みに行けみたいなこと言うべきかというと、
別に分かんねえなって思う。
まあでも一つ言えるのは、
これも何かちょっと可燃性高い発言だから
躊躇するけど、
やっぱ本をね、
技術本を一生懸命読むんだったら
コード読んだ方がいいっていう部分。
いやー、
分かる。
言いたいことはめっちゃ分かる。
もちろんフェーズに折り切りではあるんだけど、
いつまでもずっと
例えばね、
例えばオライギンの本を
片っ端から全部読みましたっていうのも
すごいと思うんだけど、
普通にね。
それはそれでプレイヤーも多いから。
でもなんかもうある程度
この分野でやっていこうと思ったら、
その分野のソースコードを読んだ方が早いみたいな。
時期は来ると思う。
あとなんか、
個人的には本次第かなーって気はしてて、
いやーでも難しいなー。
これも可燃性の高い発言かもしれないけど、
若干ね、若干
エキスキューしますけど、
例えば言語仕様を
まとめた本とか、
特定のフレームワークの
ガイド本とか、
そういうのってあるし、
まあそのいい本がもちろんいっぱいあるっていうのは
あると思うんだけど、
そういう本とかは、
アンダーテッシュの言った通りかなと
思ってて、
例えばバックエンドを本業にしている人が、
ちょっとNext.jsって
どんなもんじゃいっていうのを、
いやーでもその場合でも本読むの?
って思っちゃうけど、
なんかケースバイケースだなー。
審査といったら読めば
って思うかもしれないなー。
まあね、なんかその言語の
地図を手に入れたいなと思ったら、
まあそういう
網羅されている入門書を読むのは
いいアプローチな気がするし、
あと言語に限ってはね、
その言語の何かしらのホームページがあって、
そこに大体その
ビギナー向けのドキュメントとかは
あったりするわけだから、
まあ、あの
言語の
だから、
そういうプログラミング言語に
何かしらの
学習経験がある人は
そっちだった方が早いみたいなのは
多分あるね。
そうなんだね。あとなんか
逆に僕はなんか
本でも、本でもっていうか
本の中で相対的に価値が
高いなって感じるのは、
まあそういうその
ドキュメントで読めば分かるよっていうものに
加えて、
世界でこういう課題があったときに、
こういうアプローチがあるよみたいなものをセットで
提示してくれる本がすごい
まあ価値は高いような気がしてて、
なんかそれは多分
ちょうど直近で読んでる本で
具体例を出すと、なんかコンテナセキュリティの本を
読んでるんですけど、
コンテナセキュリティの本だったら、
まずコンテナだったわっていう仕組みを
最初の章の方であって、
どっかの仕組みがあって、
コードの読み方の重要性
これはぶっちゃけドキュメント読みに行けば分かる。
なんか日本語にしてちょっと
読みやすくなってるみたいなところで、
そこに対して、
じゃあ具体的にどこが危ないんだよっていうところで、
このエリアでこれが危ない、じゃあこういうツールを使うと
こういう風に解決できます、こういう場面で役に立つよみたいな。
その肉付けがあって、
そういうのは多分どっかのドキュメントを読んでも
分かんなくて、
いい感じの
ブログとかスライドを自分で漁ったり、
どっかのセキュリティ記号が書いてる
コンテナベストプラクティスみたいなのを
自分で集めなきゃいけないみたいなのが、
その本の
その本の著者の観点に
まとまってるみたいなケースは
結構いいかなと。
それはやっぱいい本だよね。
本を書く側の視点に立って
考えても、
多分本当に、これもなんかだいぶ前
ここで喋ってた気がするんだけど、
多分その本の中で
メインに扱いたいのって、
だいたい真ん中から後ろぐらいにあるんですよね。
で、最初の
1章2章3章ぐらいは、
その真ん中から後ろの内容を
に対する導入的な
内容になっていて、
だいたいその本を
読むレベルの人は、
知っといてほしい内容を書くんですよね。
で、もし知らない人がいれば
ここでキャッチアップしてねって賛成書くんだけど、
別にその本の
その章の内容で理解する必要は全くなくて、
今言った通り、
もうちょっとベーシックな内容の本に
移ってみるとか、
あとはその、いろいろインターネットを
探して、わかりやすいものを
探して理解すればよくって、
それを踏まえてからその本の一体、
真ん中後ろくらいをこう読んでみて、
あの、
その恩恵を得てありがたぬみたいな
感じ。で、まあこれは
本によりけりだけど、最後の
1、2章ぐらいは、ちょっと
おまけ的な内容とか、ちょっと
あまりにもアドバンスな内容で、
あの、場に役立たないんだけど、
あの、すごい
いい知見なので載せときましたみたいなやつなので、
そこに踏み込むかどうかは
その人の需要次第
みたいな感じ。
情報のインプット方法
っていう向き合い方を
技術素人はするとじゃないかな
と思いますね。間違いない。
いやー、なんかさっきアドバンスが
違うわ、ベーシックな本
いやーでも、まあでもどの本
読んでも、まあ読んでみて、
読んでみるといいかもね、読んでみて、
まあ次からコード読めばいいやって思うのか、
役に立ったのか、まあ人それぞれの
レベル感とか、
バックグラウンド次第だし、なんかとにかく言うべきじゃん。
最終的に
ああどうぞ、喋ってください。
ああ、なんか、そうね、だからなんか、
ただ、そのどんな
まあ本という形じゃなくても
何かの情報をインプットしたときに、
いやー一番最初の話に帰る気はするね、
その結局、なんか
いや本が間違ってるとは全く言わないけど、
一番正しいのは実装コードで
しかないっていう意味では、
まあなんか最終的に
コードを、まあ全部読めとは
言わないけど、まあ読むことの
価値みたいなのはやっぱ
鈍らないというか、
うん、気がするな。
どの範囲をどういう風に読むべきかっていうのは
その時にどういう情報のインプットを
どういう傘でしたか次第。
だから一概には言えないと思うんだけど。
あとソフトウェア進化早いしね。
どんどん新しいバージョン出たり、なんか
書いてある当時と全然違うみたいなことも全然あるから
そういう意味ではない。
その時のソースコードをまあ見に行ける
ふっかるな気持ちみたいなのは
ずっと持ってもいいかもな
なりました。
あとはね、これはもう時代が変えちゃう可能性はあるんだけど
どうしても本とかドキュメント書くのって
コードよりは後なんですよね。
いやー
だしそんなに、まあ二度見くらいだったら
すぐ仕上がるかもしれないけど
ちゃんと承諾がなされた
本を書くっていうのは
ものすごい労力と時間がかかる話なので
やっぱり本が出てから
勉強しようみたいなスタンスは
全然割に合わなくて
それを待つくらいからもう
正々堂々使ってるのもなんでもいいから
とりあえずソースコードを
読んでしまうっていうのが
いいですね。まあこれは英語も一緒ですね。
カジュアルなコード阅读のすすめ
英語もその日本語訳が出るまで
まあ到底やる時代はもう終わったので
その場で読むっていうのが
いいですね。
確かにね。そうなんだよな。間違いない。
そういう意味では全能本
誰でも書ける機能とかは
まあちょっと中間の回答って感じがする。
まああれはね
みんなが本を書けばすごくいい世界だよね。
意外と
ぶつかるときはぶつかるんだよね。
ぶつかるっていうか
引っかかるときは引っかかることはある。
そうね。
僕も自分で書くときは
トラブルシュートしながら
いやこの地形は絶対に世界で
俺しかぶつかってないわみたいな
まあそんなわけは絶対にないんだけど
でもそれくらいの
すごいニッチで
これは次遭遇したらまた
苦労するなってやつを
スクラップ的に残す
みたいなことは
しますね。
めちゃくちゃその積み重ねで
できてるよウェブは。
3年後くらいに自分で
自分の記事開けてるっていう。
みんな通る道。
みんな通る道。
いやでもおもろいな。
思ったよりいい話した。
そうね。
めっちゃいい話した。
いい話だと思うんだけどな。
うん。
いや全然いけんじゃないかなっていうか
全然まだ現役の人いっぱいいるしね。
現役じゃなくなるって
どういうことなのかちょっと
それこそ言語化してみたいけどね。
この業界においてね。
この業界において。
いやなんか
たまにバズったのが回ってくるのを
見ないことはないんだけど
何が書いてあったか
何が書いてあったか
あんまり頭に残ってないことが多くて
自分がどうやったら
その辺
旬が過ぎていくっていうのを
言い方がいいのか分からないけど
賞味期限が来たってなる。
自分自身のってこと?
そう。エンジニア的なところも。
分かんねえな。
分かんなすぎるね。
賞味期限が切れた人を
ゲストに呼ぶわけにもいかないし。
いやちょっとね。
まあよくね。
ミドルクライシスとか
あとは単純な
過励による身体能力の低下とか
そういう軸で
語る人はいるんだけど、でもそれって本当に
仕事がなくなることに繋がるのかね
っていうのもちょっとまだ
当事者じゃない可能性はあるな。
いやー
想像つかないね。
なくしてくれるならなくしてくれよって感じだけど。
まあなくなりたい
ではあるよね。
まあある程度欲しいけど
でもなんだろうな。
結局お金持ってても
やっぱり社会的に
生きていたい生き物じゃないかなっていうのは。
まあまあまあ。
首はちょっと勘弁してほしいです。
首はちょっと立ち直れなさそうだよね。
とても言われたらね。
やっぱり
レイオフな文化はないしね。
そうですね。
なんとか喰らいついてくんで
雇ってくれるよっていう企業は
DMはちょっといらないです。
DMしてくださいって言うと
たぶんめっちゃ殺到。
いやでも
怒ってるかもしれない。こんなこと言っても殺到しないかもしれないから。
そうだね。別にそういう予定はないんですけど
まあ喰らいついてきますって感じ。
いやー
いやでもコード読むのはいいよ。
なんかやったことない人がもしいるなら
なんかもうめっちゃ原稿化したけど
もう考えずに
ちょっと頑張ってチャレンジしてみてほしい。
まあ普通にね面白いと思うよ。
普通に面白い。
なんか
業務時間中にOSSのコードを
読んでる時間からしか得られない栄養があるんだよな。
なんか
なんなんだろうな。
なんか純粋な自分の技術的興味を
ぶつけているところだよね。
あー確かにね。
そうかもね。
もちろん仕事上必要で読むっていうのも
すごい相乗効果っていいと思うんだけど
なんかちょっと疲れたなと思ったときに
全然仕事と関係ない
全然業務に役に立ちすぎない
まあそんなこと言うと失礼だけど
業務とは直接関係しなさそうな
コードを
読んで
時間を過ごす
趣味読書みたいな時間の使い方だよね。
あー確かにね。
そういうのもいいかもね。
なんかさ
主要な結構でかいソフトウェアとかさ
コードの読み方の解説をしている人とかがいるじゃん。
なんたらの歩き方的な。
そういうのを読むっていう
なんか専業して読んでる人とかも見たことあるし
まあ普通に面白いよね。
そうね。
僕はなんかあんまそういうでかいのは
部分部分しか読んだな。
まあせっかく読めるのはね
ただなんで。
いやーそうだよね。すごい文化だよね。
ただでソフトウェアを読めるのは。
それっぽいこと言ったね。
それっぽいこと言ったね今ね。
それっぽいこと言っちゃった。
ちょっと恥ずかしくなっちゃった。
まあでもリターンがあるからね。
そうね。
まあなんかコツはあれかなこう
いやわかんない。みんなやってるのかもしれないけど
そんなに肩に力を入れずに
一行一句読んでやるぞっていう
気持ちではなくこう
なんとなくこうパーッとスクロールして
気になったところで指を止めて
なんとなく見てみると
すごい面白いこと書いてるなみたいなのを
見つけやすい感じはしますね。
確かに語り知らずに
コードの読み方と挑戦
新卒のペッペキャレルプレイの
僕が読めたんだから
読めるでしょう。
それはすごい
あれかもしれないポジショントークかもしれない。
生存バイアス。
生存バイアスか。そっちだな。
生存バイアスですか。
PHPだったね。
綺麗なPHPだった。
言語は関係ないか。
綺麗なコードだったら読める。
読めないのは
読めない
文による系じゃない。
読めないは読めないで学びだと思うんだよね。
今の自分には読めないっていうのは
なかなかいいよね。
できればなんで読めないのかって
聞ける環境があると。
確かにね。
俺未だにコンパイラーの構造を見ても全然
わからんし。
一応こういう仕組みで
コンパイラーが解析をして
コンパイルしてるとか
アセンブリってこうなってるみたいなのは
聞きかじったことはあるんだけども
それでもいざ自分で読み解けるかと言うと
別に
って感じなんだよ。
自分に主戦場より下のレイヤー
違うレイヤーは結構やっぱ難しいよね。
でもやっぱね
低レイヤー読みこなせたらかっこいいんだろうな
って思うよね。
わかる。
謎の憧れがある。
めっちゃわかる。
いやー
でもあれ思ったけど仕事にしないと無理だよ。
そうだよね。
相当情熱がないと
片手間には
切り込めねえなって思う。
直近読めなかったのは
だいたいタイプスクリプトの複雑すぎる方とかは
発狂してますね。
あれはさ
普通に
自分の能力の問題かどうかは
多分強いよね。
そうなんだよ。
おっしゃる通りでね。
これは無いだろうっていう。
表現力の高さとのトレードフがな。
そうね。
あとなんか自動生成されてるパターンとかも
あるね。
途中で刺して
イメージだけど
タイプスクリプトはそういうの多いイメージだよね。
うーん。
コード時に書きやすいのかな。
わかんないけど。
動物的なもの扱わなきゃいけない
SDKとかは多いね。
GitHubの、最近だとGitHubの
REST APIのタイプスクリプトのクライアントが
読みに
読まなきゃいけないって読んだのに
まじ切れそうになった。
なんかGitHub製のコードでこんな
読み追いづらいのあるんだなぁ
とか思いながら。
結局しかもたどり着けなかった気がするんだよな。
割と諦めた気がする。
まあっていう、僕らでもそういうことはあるので
僕らでも私すごい上からだけど
そういうことは全然
長くやってる人でもある話
なので全然ありますよってことですね。
コードを読むことの重要性
全部読めたら
億万長者ですよ。
全部読むだけで億万長者になれるなら
頑張るよね。
それは確かに。
今すぐ退職届だし。
フルタイム
OSSリーダーにならなきゃいけない。
やりてぇ。
もう楽しそう。
やりたすぎるなぁ。
いやぁ、ちょっと分かんない。
Wordpressのこのプラグインのコード読んでくださいよ。
いや、違うんです。
そういうことじゃないんです。
仕事選べないかもしれない。
読みたくないコード読まなきゃいけない。
こんなとこっすかね。
いやぁ、楽しかった。元気出た。
引き続きやっていこう。
夏もね、もうそろそろ
いや、おしまいなのか。
もうちょっと続くのか。
夏のピークは去ったらしいよ。
じゃあ、お互い体調に気をつけて。
またゆるゆるやりましょう。
というわけで
今回は
スペシャルにコードを読みにくたいしさを
言語化しました。
みなさんまた次回お会いしましょう。
さよなら。
バイバイ。
