はてなキーワード: grepとは
Claude Codeを使いはじめてから仕事のやり方ががらっと変わった。
ちょっと前に見かけたガチ勢のように、エージェントを複数起動したり「高速目grep」で大幅に生産性を上げるなんてことはしていない。
エージェントにやらせて、1ファイルずつ提案されたコードを見て、Yesにカーソルがある状態でエンターキーを押す。
手を動かす時間も考える時間も劇的に減った。こっちは基本的に待っていればいい。
たまに画面を見て変なコードになっていないか判断すれば進む。数分に1回ちょっとだけ注意を向ける。自分で書いていた頃と比べると注意の使い方がまるで違う。
1日中やったら終わる頃にはもう何も考えられないくらい疲れている。
タスクを1つ終えたらまた次、っていう流れを繰り返すとどんどん消耗していく。
作業の流れが一気に分散されて、自分が集中しなきゃいけない場面が減る。
Claudeが考えてる間はこちらはぼーっとしててもいい。あるいはコーヒーを淹れてもいいし、別のことを考えていてもいい。その時間に脳が勝手に回復する。これはかなり大きい。
言い換えると、注意力を節約できるのだ。
前はただの怠け者だと思ってた。しかし今は、やり方さえ変えれば全然やっていける自信が少しついた。
無理して集中し続けるよりも、エージェントをうまく使って自分らしいペースでやっていく方が合っている。
注意力は限りある資源だ。それを節約してくれるツールがあるなら使わない手はない。
世の中的には生成AIに要件伝えて生成させたコードをコピペして動かして「はい！生産性爆増！」っぽいけど、生成AIが吐き出したコード読むだけじゃ全然分からん。
Clineで使い慣れた言語・フレームワークのコードを生成させたら見たことがないエラーが出て面食らった。
原因はフレームワークのnewコマンドで自動生成される設定ファイルが全然違う書式で書かれてた。
(どうやら遥か昔のバージョンだとその書式だった模様)
GitHub CopilotやCursorだったら確認しながらtab押してくからこれなら予測変換みたいなものだし大丈夫だろう、おお便利便利……
と思って使ってたのだが、テストするとデータ作成時にフィールドに抜けがある…。
確認したらPOSTするJSONに存在しないkeyが含まれてた。それっぽい名前がサジェストされてそのままtabを押してしまったらしい。
手動でテストしてたから助かったが、この手の外部API使って更新する系はテストをモックしてたりするので危うく本番障害になるところだった。
それこそ特にこれまで触ったことない言語・フレームワーク・ツールを使ったコードを生成AIに吐き出させてもさっぱり分からん。
読むだけだとさっぱり分からないので結局生成されたコードを写経しながら、分からないところをググったり生成AIに質問したりでやってるんだが、まあコピペ勢が40秒でPR上げてるところを、2時間・3時間とかけてるからまあ生産性が悪い悪い。
昔から書かないと覚えられなくて、学生時代もテスト前は過去問解く前にまずは授業中に取ってたノートをとにかく写経してた。
友人からは「過去問だけやって、よく分からなかったとこだけ該当部分をノート見れば分かるじゃん」と言われたが分からないのでしょうがない。
あとプログラミングだけじゃなくて、議事録も最近はZoomとかが自動生成してくれるようになった。
が、こいつがとにかく俺と相性が悪い。
これまでは自分で会議中に議事メモを書いて、終わった後に手直しして論点やToDoをまとめてたので会議の流れややるべきことが頭というか体に入ってきてた感じだった。
それが自動生成されるようになって、確かに時間はかからなくなったかもしれないが、流れとかやることとかが全然頭にも体にも入ってこなくなってしまった。
議事録については結局自分用にメモを取って、あとで自分用に論点やToDoをまとめるというのをやってるが、正直会社から見ると「生産性が低い奴」なんだろう。
おそらく元々読めば理解できるタイプ、それこそ教科書を何回か読めばテストで点を取れるタイプはコード生成AI時代に大活躍できるのだろう。
あるいは今後出てくるコード生成AIネイティブ世代は書かなくても理解できるのが当たり前になったりするのだろう。
……いやそんなことあるか？
これそもそも生成AI以前から「手を動かさなくても公式のREADME読めばすぐ使える」みたいな能力で、そんな奴ごく一部だろう。
教科書何回か読めばテストで点が取れるのも塾行かなくても東大合格できるみたいな特異点みたいな人間だろう。
これまでは結局のところ人海戦術で各言語・フレームワークなどを理解して、大量に書く必要があったから書かないと理解できない俺のようなオールドタイプもプログラマーになれた。
しかし今後はコード生成AIが言語・フレームワークは理解しててすごい勢いでコードを生成してで生産性は爆上がりするから、読めば理解できるニュータイプしか生き残れないのかもしれん。
それこそビル・ゲイツ氏はExcelのレビュー時に仕様書500ページを読み込んで1900年閏日問題について的確に指摘したり、岩田聡氏は任天堂取締役室長時代に週末でNINTENDO64のグラフィックスチップの制御命令コードを完成させたりしたそうだ。
そういった人ならコード生成AIが出したコードについても目grepで瞬時にバグを見つけて直して爆速リリースとかできるのだろう。
……凡人には無理ゲーすぎるな。
なんてか、最初は教訓的に
「良い子の諸君！書かないと覚えられないと詰むから、読んで覚える力を強化したほうが良いぞ」
的なことを着地点で考えてたけど、これもはや地頭が良いとか先天的にニュータイプしか生き残れないやつや。
生成AIがコードを産むなら、みんな死ぬしかないじゃない！(読んで覚えられる)あなたも、(書いてしか覚えられない)私も…（錯乱）
https://type.jp/et/feature/26796/
この発言にもあるように「コードを綺麗にする＝読みやすくする」ってことだと勘違いしてる
コードを綺麗にするのは「バグを少なくする」ためであって読み手のためじゃない
グローバルに一文字変数を使って困るのは「どこでそれを触ってるか分からないから」であって「読みにくいから」ではない（まぁ読みにくいけど）
特に昔だとLintもないし変数の参照先を探すのはgrepぐらいしかなくて
$iとかだと$iiもひっかかるし$iの後ろにスペースがあったり無かったりするともう探すのは不可能に近くなる
それでも動いているなら最悪問題無いんだがバグの修正時にめちゃくちゃ困って
「作り直すしか無いな」
ってなるのでビジネス的にも大きな影響が出る
「どんなコードでも動くコードを作るのが正しい」「done is better than perfect（完璧を目指すよりも、まずは終わらせることが重要） 」のスタンスが効率的だろうなぁ、、と思うおいらです。
これも元の言葉の意味を曲解していて、「終わらせることが重要」というのはバグがあって良いわけじゃない
例えばログインボタンを実装したときに、ユーザー名とパスワードに何を入れてもログインできる状態にするのも「終わらせること」だし
ただこのままリリースできるわけではないし、プロダクトとしては「終わっていない」
パスワードを平文で保存して実装するのも「終わらせること」ではあるけれどそのままリリースしていいわけではないし
下手に動いてしまうとそのままリリースされたりもするのでよりタチが悪い
この言葉の重要なのは「better than perfect」の方であって「done」の方ではない
全てを完璧にする必要は無い（し、そもそも完璧は定義できない）ので「perfectでなくていいよ」というだけ
バグがあったり不十分だったりセキュリティ不備があって良いわけではない
毎日論理構成の中に浸ってる人は、推理小説は向いてるかもしれないですね。初期にちょろっと設定したグローバル変数が、最終的な結果に大きく影響してくるとか、「ここで使われてるのかー」みたいな感慨とか。
残念ながら「ああ、まともなコードしか読んできてないんだな」としか思えない
例えば「ユーザーの名前と住所は設定できてるから、性別を設定できるようにして」という依頼があって
コードを確認してみるとuser1, user2, user3という変数が100個用意されていて、user1.name = 'hoge', user2.name = 'gaga' って感じで100行書いてあって、更に住所で100行あって、性別も同じように100行追加しろっていうコードを読んだことが無いんだろう
そしてそのコードのどこかで住所設定が間違えているから確認しないといけないような作業をしてないんだと思う
小説で言うと同じ文章が100ページ続いていて、その中のどこかの漢字が違っていて、そいつが犯人、みたいな推理小説、面白いか？
他にも足したり引いたりこねくり回された変数値が最後に定数値で上書きされてたり、UserのオブジェクトがいきなりWeatherのオブジェクトに置き換えられていて、name属性に晴れとか雨のデータが入ってたりしたことがないんだと思う
汚いコードは伏線を回収しないし最終的に犯人も分からないし無駄に長いので推理小説には全く向いてない
で、やっぱりこういう汚いコードの問題は「バグが混入しやすいかどうか」であって「読みやすいかどうか」ではない
下手するとuserオブジェクトを100行ずつ書いてくれてる方が読みやすさはあるかもしれないが
「user36だけ住所が設定されていない」といったバグが混入し得るし、それを確認するのに多大な労力を必要とする
人間は誰もが間違いを犯すので誰もがバグを混入させる危険性があるんだけれど
その危険性は最大限まで下げるように努力するべきだし、インシデントを引き起こすことでビジネス的なインパクトも大きい
拡張子については、例えば Excel の拡張子が変わったとき一括対応できる、とか？
あとは普通に".txt" で取り扱ってるファイルはどれだ、って時にその定数の参照箇所を見ればもれなく分かるとか、
取り扱うファイルの種別を段階的に変えようってときも、どのファイルは変え終わっててどのファイルはまだ、とかも同じように分かる
あとはあれだ、どのスコープにおける分類なんだって話を明確にする事も出来るだろうな。
とか。
パラメータについては、複数の選択肢から選ぶ奴は enum にしろよ、とは思うが、
文字コードも大体同じような話か。
ここに定義したもの以外は登場しないよ、という保証をする事は出来るわな。
あと日本によるロシア下院議員384人に対する措置っぽいので、必ずしもBANされてない＝露探というわけでもなさそうではある。
AISAWA Ichiro
ESAKI Tetsuma
ETO Seishiro
FUJIMARU Satoshi
FUKAZAWA Yoichi
FUNADA Hajime
GOTO Shigeyuki
GOTODA Masazumi
HAGIUDA Koichi
HATOYAMA Jiro
HAYASHI Motoo
HIRASAWA Katsuei
HORIUCHI Noriko
ITO Yoshitaka
IWAYA Takeshi
KAIEDA Banri
KAJIYAMA Hiroshi
KAMIKAWA Yoko
KANEKO Yasushi
KATO Ayuko
KATO Katsunobu
KIUCHI Minoru
KOBAYASHI Fumiaki
KOBAYASHI Takayuki
KUSHIBUCHI Mari
MAEHARA Seiji
MAKI Yoshio
MITAZONO Satoshi
MOTEGI Toshimitsu
NAKASONE Yasutaka
NAKATANI Kazuma
NIKAI Toshihiro
NIKI Hirobumi
NISHIMURA Akihiro
NISHINO Daisuke
NODA Seiko
OBUCHI Yuko
OGATA Rintaro
OISHI Akiko
OMI Asako
ONODERA Itsunori
SAITO Tetsuo
SHIMOMURA Hakubun
SUZUKI Takako
TACHIBANA Keiichiro
TAGAYA Ryo
TAKEBE Arata
TAKEDA Ryota
TSUCHIYA Shinako
TSUKADA Ichiro
WAKAMIYA Kenji
WASHIO Eiichiro
YAMAGIWA Daishiro
YAMASHITA Takashi
YANAGIMOTO Akira
YONEYAMA Ryuichi