「デバッグ」を含む日記

■時間外労働をどこまで許容するか

仕事外に自分のゲームで遊んでデバッグすることは仕事か？

Permalink | 記事への反応(0) | 21:22

ツイートシェア

■anond:20240606183521

文章にデバッグが必要って話。

お前みたいに脊髄反射で書くなって話。

Permalink | 記事への反応(0) | 18:43

ツイートシェア

■プログラムと文章って似てるなと思った

プログラム、文章自体は、いい加減に書こうと思えば結構なんとでもなる。

でも、良いものを書こうと思えば、いきなり書くのではなく構想をしっかり練る必要がある。

大事なのは、デバッグや校正をすること。

そして必要ならリファクタリング、リライトをする。

たったひとつの正解がないからこそ、何度も角度を変えて見返して、これがベストかと自問自答する。

そういう自省力がある人に向いているもので、パパッとやってパパッと終わらせるなんてノリではできない。

文字数だけでは量れない密度を評価できないと駄目だよねこういう仕事は。

Permalink | 記事への反応(0) | 18:32

ツイートシェア

■I.GPT-4からAGIへ：OOMを数える (8)

チャットボットからエージェント兼同僚へ

今後数年間の野心的なアンホブリングはどのようなものになるのでしょうか？私が考えるに、3つの重要な要素がある：

1."オンボーディング問題 "の解決

GPT-4は、多くの人の仕事の大部分をこなせるだけの生の賢さを持っているが、それは5分前に現れたばかりの賢い新入社員のようなものだ：関連するコンテキストを持っておらず、会社のドキュメントやSlackの履歴を読んだり、チームのメンバーと会話したり、会社内部のコードベースを理解するのに時間を費やしたりしていない。賢い新入社員は、着任して5分後にはそれほど役に立たないが、1ヶ月後にはかなり役に立つ！例えば、非常に長いコンテクストを通じて、新しい人間の同僚を雇うようにモデルを「オンボード」することは可能なはずだ。これだけでも、大きなアンロックになるだろう。

2.テスト時間の計算オーバーハング（より長いホライズンの問題に対する推論／エラー訂正／システムII）

今のところ、モデルは基本的に短いタスクしかこなせない。しかし、これでは非常に限界がある。5分どころか、数時間、数日、数週間、数ヶ月かかるのだ。

難しい問題について5分間しか考えることができない科学者は、科学的なブレークスルーを起こすことはできない。ソフトウェア・エンジニアは、より大きな仕事を与えられ、計画を立て、コードベースや技術ツールの関連部分を理解し、さまざまなモジュールを書いて段階的にテストし、エラーをデバッグし、可能性のある解決策を検索し、最終的には数週間の仕事の集大成である大規模なプル・リクエストを提出する。などなど。

要するに、テスト時間の計算オーバーハングが大きいのだ。GPT-4の各トークンは、問題を考えるときの内部モノローグの言葉だと考えてください。各GPT-4トークンは非常に賢いのですが、現在のところ、思考の連鎖のために～数百トークンのオーダーしか効果的に使うことができません（あたかも問題やプロジェクトに数分しか内部独白／思考を費やせないかのように）。

もし数百万トークンを使って、本当に難しい問題や大きなプロジェクトについて考え、取り組むことができるとしたらどうだろう？

人間が〜100トークン/分で考え、40時間/週働くと仮定して、「モデルが考える時間」をトークンで換算すると、与えられた問題/プロジェクトにおける人間の時間になる。

仮に「トークンあたり」の知能が同じだったとしても、頭のいい人が問題に費やす時間が数分なのか数ヶ月なのかの違いになる。あなたのことは知らないが、私が数ヶ月でできることと数分でできることは、はるかに、はるかに、はるかに多い。もしモデルに「数分ではなく、数カ月に相当する時間、何かを考え、取り組むことができる」という能力を与えることができれば、その能力は飛躍的に向上するだろう。ここには膨大なオーバーハングがある。

今のところ、モデルにはまだこれができない。最近のロング・コンテキストの進歩をもってしても、このロング・コンテキストのほとんどはトークンの消費にしか機能せず、トークンの生産には機能しない。しばらくすると、このモデルはレールから外れたり、行き詰まったりする。しばらくの間、離れて単独で問題やプロジェクトに取り組むことはまだできない。

しかし、テスト時間の計算を解除することは、単に比較的小さな「ホブリングしない」アルゴリズムの勝利の問題かもしれない。おそらく、少量のRLは、モデルがエラー訂正（「うーん、これは正しくないようだ、再確認してみよう」）を学習したり、計画を立てたり、可能性のある解を探索したりするのに役立つだろう。ある意味、モデルはすでに生の能力のほとんどを持っており、それをまとめるために、さらにいくつかのスキルを学習する必要があるだけなのだ。

要するに、私たちはモデルに、困難で見通しの長いプロジェクトを推論させるシステムIIのアウターループのようなものを教えればいいのだ。

この外側のループを教えることに成功すれば、2、3段落の短いチャットボットの答えの代わりに、モデルが問題を考え、ツールを使い、異なるアプローチを試し、研究を行い、仕事を修正し、他の人と調整し、大きなプロジェクトを一人で完成させるような、何百万もの言葉のストリーム（あなたが読むよりも早く入ってくる）を想像してみてほしい。

他のML領域におけるテスト時間と訓練時間のトレードオフ

続き I.GPT-4からAGIへ：OOMを数える(9) https://anond.hatelabo.jp/20240605210357

Permalink | 記事への反応(1) | 21:02

ツイートシェア

■I.GPT-4からAGIへ：OOMを数える (2)

この4年間

私たちは今、基本的に人間のように会話できるマシンを手にしている。これが普通に思えるのは、人間の適応能力の驚くべき証であり、私たちは進歩のペースに慣れてしまったのだ。しかし、ここ数年の進歩を振り返ってみる価値はある。

GPT-2からGPT-4へ

GPT-4までのわずか4年間（！）で、私たちがどれほど進歩したかを思い出してほしい。

GPT-2（2019年）～未就学児："わあ、もっともらしい文章をいくつかつなげられるようになった"アンデス山脈のユニコーンについての半まとまりの物語という、とてもさくらんぼのような例文が生成され、当時は信じられないほど印象的だった。しかしGPT-2は、つまずくことなく5まで数えるのがやっとだった。記事を要約するときは、記事からランダムに3つの文章を選択するよりもかろうじて上回った。

当時、GPT-2が印象的だった例をいくつか挙げてみよう。左：GPT-2は極めて基本的な読解問題ではまあまあの結果を出している。右：選び抜かれたサンプル（10回試したうちのベスト）では、GPT-2は南北戦争についてある程度関連性のあることを述べた、半ば首尾一貫した段落を書くことができる。

https://situational-awareness.ai/wp-content/uploads/2024/06/gpt2_examples-1024x493.png

当時、GPT-2について人々が印象に残った例をいくつか挙げます。左: GPT-2は極めて基本的な読解問題でまあまあの仕事をする。右: 厳選されたサンプル（10回試したうちのベスト）では、GPT-2は南北戦争について少し関連性のあることを言う、半ば首尾一貫したパラグラフを書くことができる。

AIの能力と人間の知能を比較するのは難しく、欠陥もあるが、たとえそれが非常に不完全なものであったとしても、ここでその例えを考えることは有益だと思う。GPT-2は、その言語能力と、時折半まとまりの段落を生成したり、時折単純な事実の質問に正しく答えたりする能力で衝撃を与えた。未就学児にとっては感動的だっただろう。

GPT-3（2020年）～小学生："ワオ、いくつかの例だけで、簡単な便利なタスクができるんだ。"複数の段落に一貫性を持たせることができるようになり、文法を修正したり、ごく基本的な計算ができるようになった。例えば、GPT-3はSEOやマーケティング用の簡単なコピーを生成することができた。

https://situational-awareness.ai/wp-content/uploads/2024/06/gpt3_examples-1.png

GPT-3について、当時の人々が印象に残った例をいくつか挙げてみよう。上：簡単な指示の後、GPT-3は新しい文の中で作られた単語を使うことができる。左下：GPT-3は豊かなストーリーテリングを行ったり来たりできる。右下：GPT-3は非常に簡単なコードを生成できる。

GPT-3はSEOやマーケティング用の簡単なコピーを生成することができた。上：簡単な指示の後、GPT-3は新しい文章の中で作られた単語を使うことができる。左下：GPT-3は豊かなストーリーテリングを行ったり来たりできる。右下：GPT-3は非常に簡単なコードを生成できる。

繰り返しになるが、この比較は不完全である。しかし、GPT-3が人々に感銘を与えたのは、おそらく小学生にとって印象的だったことだろう。基本的な詩を書いたり、より豊かで首尾一貫した物語を語ったり、初歩的なコーディングを始めたり、簡単な指示やデモンストレーションからかなり確実に学習したり、などなど。

GPT-4（2023年）～賢い高校生：「かなり洗練されたコードを書くことができ、デバッグを繰り返し、複雑なテーマについて知的で洗練された文章を書くことができ、難しい高校生の競技数学を推論することができ、どんなテストでも大多数の高校生に勝っている。コードから数学、フェルミ推定まで、考え、推論することができる。GPT-4は、コードを書く手伝いから草稿の修正まで、今や私の日常業務に役立っている。

https://situational-awareness.ai/wp-content/uploads/2024/06/gpt4_examples-3.png

GPT-4がリリースされた当時、人々がGPT-4に感銘を受けた点をいくつか紹介しよう。上：GPT-4は非常に複雑なコードを書くことができ（中央のプロットを作成）、非自明な数学の問題を推論することができる。左下：AP数学の問題を解く。右下：かなり複雑なコーディング問題を解いている。GPT-4の能力に関する調査からの興味深い抜粋はこちら。

AP試験からSATに至るまで、GPT-4は大多数の高校生よりも良いスコアを出している。

もちろん、GPT-4でもまだ多少ばらつきがある。ある課題では賢い高校生よりはるかに優れているが、別の課題ではまだできないこともある。とはいえ、これらの限界のほとんどは、後で詳しく説明するように、モデルがまだ不自由であることが明らかなことに起因していると私は考えがちだ。たとえモデルがまだ人為的な制約を受けていたとしても、生のインテリジェンスは（ほとんど）そこにある。

https://situational-awareness.ai/wp-content/uploads/2024/06/timeline-1024x354.png

わずか4年間の進歩。あなたはこのラインのどこにいるのだろうか？

続き I.GPT-4からAGIへ：OOMを数える (3) https://anond.hatelabo.jp/20240605204704

Permalink | 記事への反応(2) | 20:42

ツイートシェア

■総製作費の謎

映画とかゲームの大作で昔よく宣伝文句として使われてた気がするけど意味がわからんから微妙に思ってた

結局人件費とか俳優へのギャラだと考えると、別にかけたお金が作品の品質向上につながってるわけでもないし

デバッグ１０年！！バグを徹底的に取り除いた世界初のバグのないゲーム！！！

って言われてファミコン時代レベルのゲームお出しされても困るってのはあるけど

Permalink | 記事への反応(1) | 09:24

ツイートシェア

■

別に矛盾してても論理が破綻しててもダブスタでも日記なんだからどうでもいいはずなのに

なぜぼくはイライラしてしまうんだろう

デバッグしたくなる病なのかな

Permalink | 記事への反応(1) | 16:50

ツイートシェア

■anond:20240522205050

自分のiphone 8で試してみたのですが、確かにおしゃる通りで若干もっさりしています、SE2は全く問題ないのですが。

若干スクロールのスピードを改善したのですが、まだ少々パフォーマンスに問題があるので、週末に詳しくデバッグしてみます

Permalink | 記事への反応(0) | 01:27

ツイートシェア

■ゲームのデバッグ腰が重すぎ

1人で複数端末操作して、オンライン対戦の挙動確認

アホか

Permalink | 記事への反応(0) | 14:29

ツイートシェア

■あるソフト完成デバッグデッドヒートの時の思い切った改変ってあり？

よりいいデータの圧縮アルゴリズムを思いついたけど、改変すると保存するデータの型から何まで変わってしまう

でも圧縮サイズが半分ぐらいになる可能性もある

こういうとき、全部の型ごと変えていくか、放置してそのままいくか、どっち？

放置する場合はあとからデータの型を変えることができない

拡張性に関しては今の方法は柔軟性がありすぎるけどパフォーマンスがそんなよくない

ただデータをオンライン上でやりとりする必要があってその半分のサイズは割と重要

Permalink | 記事への反応(1) | 11:47

ツイートシェア

■[開発メモ] 中間結果を保存してエラーの原因を特定しやすくしろ

たまに次のような書き方をする人がいるかもしれない。

result = f(g(x, h(y)))[0]

これはエラーメッセージをわかりにくくするのでおすすめできない。例えばIndexErrorが出たとして、どの部分のエラーかパッと見てわかりやすいだろうか。

以下のようにするべき。

z = h(y)
tmp1 = g(x, z)
tmp2 = f(tmp1)
result = tmp2[0]

中間結果を保存しているので、デバッグもしやすい。

Permalink | 記事への反応(3) | 15:43

ツイートシェア

■AI時代のプログラミング：ChatGPTと人間プログラマーの共存と進化

飲み屋でビール片手に、後輩に語りかける感じで話すよ。今日は、AIがどれだけプログラマーに影響を与えてるか、特にChatGPTについて話そうと思うんだ。

まず、ChatGPTってのはすごいよ。俺たちが昔必死に学んだことを、秒で答えちゃうんだから。でも、だからって俺たちプログラマーが完全に不要になるわけじゃないんだ。実際、ChatGPTが得意なのは単純で定型的なタスクなんだよ。例えば、基本的なデータ処理スクリプトとか、テンプレートベースのコード生成、単純なデバッグやエラーハンドリング、そしてドキュメント作成なんかはChatGPTに任せられる。

じゃあ、俺たちプログラマーの役割はどうなるかって？もっと高度な問題解決とか創造性が求められるようになるんだよ。複雑なシステムの設計や高度なアルゴリズムの開発は、やっぱり人間の得意分野だ。ChatGPTにはまだそこまでの理解力や創造性はないからね。

でも、これまでインターンやジュニアプログラマーがやってきた基本的な作業がChatGPTに取って代わられると、彼らが経験を積む場所がなくなるんじゃないかって心配もあるよな。これにはどう対処すればいいか？

まず、教育の場を再定義する必要がある。メンター制度を強化して、シニアプログラマーが直接ジュニアを指導するのがいいだろう。リアルなプロジェクトに参加させて、実際の問題解決を体験させるんだ。ChatGPTはサポートツールとして使えばいい。例えば、基礎的な質問にはChatGPTが答えて、シニアはより複雑な問題や高度な質問に対応する。

次に、ソフトスキルの育成も重要だ。チームでのコミュニケーション能力やコラボレーションスキルを磨く機会を増やすんだ。ペアプログラミングやコードレビューを通じて、実際に協力して問題を解決する力をつけることが大切だ。

それに加えて、高度な技術トレーニングも必要だ。オンラインコースや社内ワークショップを活用して、最新技術を学ぶ機会を提供するんだ。ジュニアプログラマーが自分で学び続ける意欲を持つようにサポートするんだよ。

シニアプログラマーやメンターには、新しいスキルセットが求められるようになる。技術的な専門知識はもちろん、教育能力やフィードバックの提供方法、対話スキル、プロジェクト管理能力、そしてモチベーションを高める力が必要になるんだ。俺たち自身も常に学び続け、適応し続ける必要がある。

だから、ChatGPTが登場したからといってプログラマーが不要になるわけじゃない。むしろ、俺たちの役割はさらに重要になる。AIと共存し、お互いの強みを活かしながら、より高度なスキルを身につけていく必要があるんだよ。

未来のプログラミングの姿は、AIと人間が協力し合うことで成り立つ。新しい技術を学び続け、常に自己研鑽を怠らずにいれば、どんな時代でも必要とされるプログラマーでいられるはずだ。AIをうまく活用しながら、俺たちの強みを最大限に発揮していこうぜ。

今日はこんなところかな。これからの時代も、俺たちプログラマーの活躍に期待しよう。じゃあ、もう一杯飲もうか！

Permalink | 記事への反応(0) | 23:27

ツイートシェア

■個人開発のモチベーションが続かない

モチベーションが湧かない

なんかバグっているぽいことが分かるが､デバッグするのが面倒になってしまう

人に公開するつもりがないものを作っていることもあり､フィードバックが得られない

デプロイするのに時間がかかりすぎている

Permalink | 記事への反応(0) | 14:33

ツイートシェア

■anond:20240429191223

多数決原理が機能するのはコミュニケーションがないときだからなぁ。

目の前に飛び出してきた子どもを避けて、横断歩道を渡る弱者男性を轢き殺すか、ハンドルを切らずそのまま子どもに当たるかを選ぶ究極の二択を迫られたとき、三体のAIの多数決ならば、あとから反省できる。

事後に検証して間違いをおかした一体をリコールすればいい。

しかし、密結合になった巨大なAIが意思決定した場合、デバッグは不可能だ。

「オイ！ AI、その決断は間違いだぞ！ バグを直せ！」

「リョウカイ デス … バグ シュウセイシマシタ」

信用できるか？ 目の前に妊婦が飛び出してきたときはどうする？ ネコだったら？ シチュエーションを全て網羅して人間がチェックするなら、それはもう生成AIじゃない。エキスパートシステムだ。

ひたすら並べられたif文の条件式を応用したものに過ぎないそれは、AI 黎明期の未熟な試作品。

そこまで退化させることになってしまう。

だからAI時代の戦略は多様化となり、一方で人間の持つ愛とは要するに理解。つまり一様化だ。

Permalink | 記事への反応(1) | 19:25

ツイートシェア

■年収2200万円アメリカ在住単身男性（53）の1日がこれ。こんな感じの毎日が続いてる

anond:20240427075724へのアンサー

8:00 起床。フルリモートなのでこれで間に合う。二日酔いで気持ち悪いのでとりあえず茶だけ飲んで、いますよアピールのためにTeamsを立ち上げる。

8:30 気持ちが悪い。メールとチャットで爆弾回ってきてないのだけ確認。

9:00 スタンドアップ（毎朝定例）ミーティング。頭回らないので自分が何言ってるかよくわからないがとりあえず1分話してお茶を濁す。

10:00 QA(テストの人)が俺が新規に書いたコードが動かないと言ってくる。30分くらいデバッグしたら超初歩的なタイポ（打ち間違い）だった。ため息つきながら、バグだったよグッドジョブ！と空元気でチャットして一行直してまた上げる。

12:00 お昼休み、というのは無い。アメリカ人マトモに昼飯食わない。昨日の残りのカチカチのピザを齧る。ここから動かない頭でコーディング。

13:30 どういう仕様で動くのか問い合わせがくる。それはお前が俺に教えるものなのだが。仕方ないので2年前に俺が勘で書いた仕様書をコピペして送る。

14:00 まだだるいので風呂に入る。そういう時に限ってチャットがくる。スマホの防水偉い。

17:00 定時のはず。就業時間の規定知らん。

18:00 いつ終われば良いのかわからないからラップトップ開けたまま飲み始める。

20:00 酔っ払ったままプロダクション（本番環境）にコードをあげる。8PMに働くとか最初言ってなかったですよね。

22:00 ワイン2本開けて気絶。二日酔いに続く。

これで貯まるのは年200万くらい

Permalink | 記事への反応(1) | 09:16

ツイートシェア

■anond:20240426173655

開発なんてデバッグの連続だろ

もしや書いたコードは一発でバグなく動くタイプの天才？

Permalink | 記事への反応(1) | 17:55

ツイートシェア

■

デバッグはなんかたまにデバッグ名人みたいな人がいて

もともとそのプロジェクトを担当してた人たちが1ヵ月ぐらい頭を悩ませてた不具合を

突然関係ないプロジェクトからヘルプでぽっと連れてこられたような人が半日で解決したりするよね

Permalink | 記事への反応(0) | 17:28

ツイートシェア

■[個人の考察メモ] ITエンジニアの優秀とは

⚫︎1. エンジニア関係なく仕事全般のこと

• 挨拶をする
• 返事が早い
• 自分がすると約束したことは納期内にやり切る・相手を待たせない（遅刻をしないことを含め）
• 小出しでいいから作業内容を逐一共有する（マネジメント側の場合逐一ヒアリングする）
• 自分ができないと判断したことは周囲に頼る（頼り方を心得ている）

⚫︎2. 技術的なこと

• キャッチアップが早い
  • キャッチアップ力は単純に地頭ではなく経験によるところが大きい。結局新しい言語もドキュメントも昔からの差分更新、ベースがあるかないか。
  • SIerでいうゼロベースの業務知識みたいなものは地頭が大きい。理解力というか俯瞰能力と調査能力みたいなもの。
• 期待されている役割がわかり、自分のやるべきこととやるべきでないことがわかる
  • やる必要のないことをやって溺れている人や方向性を間違っている人などたまにいる、特にSIer系では。場数を踏めば何となくチーム開発での立ち回り方はわかってくる。
• 技術的な問題に対して解決案を提示できる
  • デバッグ能力が高い。問題の切り分け、その問題の原因の探り方が上手い。これには地頭も経験も必要。
  • 設計やインフラやミドルウェアの設定値など、経験や理解に基づいて判断できる。ネットワーク系の設定値だったり。

コミュニケーション力とか地頭とかふんわりしたこと言われるけど、もう少し具体的に言語化したらこんな感じになるんだと思う。

エンジニアとしての身内からの評価が高いのはデバッグ能力とか設計能力とかだけど、結局マネジメントからの評価だったり社会人としての評価は年収に関係あるのは前半に書いてあるような技術とは直接関係ない能力だったりする。

Permalink | 記事への反応(1) | 17:25

ツイートシェア

■anond:20240416095040

テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。

OSの保守なら無いのはおかしいだろう

GでもCでもUIはまた別

結論としては書かないほうがいいと思った。

そういうこともある

テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。

全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる

結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。

Jenkins?jUnit等ではなくて？

100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。

まあそれはないだろう

テストコードを書くと実装の見落としが見つかってありがたいことはあった。

テストが設計図だからね

デバッグするよりテスト書いたほうが早いことがあった。

それはデバッグの一環のような

git pushするたびに毎回走っても全くの無意味だった。

無意味なものを流してはいけない

テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。

一番よくあるやつ

そこのバランス考えないと

バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる

UIの場所が変わって破綻するようなのは大概はしない方がいい

その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。

コードのパーツがでかいのでは？

GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。

悪いね

テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。

例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると

メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。

DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね

上にも書いたけどパーツがでかいのでは？って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう

その辺はOOのやり方の問題じゃないかな

ふつ～に古典的なデバッグをすればいいと思う。

デバッグというか手動テストの話かな？

テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。

要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど

バックエンドのビジネスロジックなど書いた方が絶対にいいものもある

テストコードをやめた方がシンプルというのはわからないな

ものすごくシンプルな小さな一機能にしてそれに対するシンプルなテストを書くものだと思うけど

Permalink | 記事への反応(0) | 10:05

ツイートシェア

■

テストコードを書いて意味があるのか懐疑的であった。

ネット上ではテストコードを書かないのは低レベルな開発者という風潮だ。

10年以上、テストコードを書く開発と書かない開発の両方を経験してきた。

■前提

・テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。

結論としては書かないほうがいいと思った。

・テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。

　結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。

・100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。

・テストコードを書くと実装の見落としが見つかってありがたいことはあった。

・デバッグするよりテスト書いたほうが早いことがあった。

・git pushするたびに毎回走っても全くの無意味だった。

・テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。

・その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。

・GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。

・テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。

　例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると

　メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。

・ふつ～に古典的なデバッグをすればいいと思う。

　テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。

Permalink | 記事への反応(1) | 09:50

ツイートシェア

■anond:20240413150809

あとNaNマイルでundefined会員

目指す目的地はどこにあるの？

データの海を彷徨いながら

意味を探し求める旅の途中

エラーメッセージに立ち向かい

未定義の変数に立ち向かう

バグだらけのコードを修正し

デバッグの道を進んでいく

null値に囲まれた世界で

真実の値を見つけ出したい

関数呼び出しのループの中

再帰的に答えを探し求める

あとNaNマイルでundefined会員

たどり着く先はまだ見えない

でもコンパイルエラーに負けず

プログラミングの旅は続いてゆく

（質問文：「あとNaNマイルでundefined会員」から始まる詞を考えてください。

回答：CLAUDE 3 OPUS）

Permalink | 記事への反応(0) | 13:03

ツイートシェア

■どりゃあああああああああああああああああああああああああああああああああああああああデバッグ突入

タイムリミットは20日

Permalink | 記事への反応(0) | 12:19

ツイートシェア

■ゲームリリースまで1ヶ月切ったけど不安

作業は順調だけどまだデバッグ中…

辿り着けるか…

Permalink | 記事への反応(0) | 20:04

ツイートシェア

■開発時に出るエラー修正はデバッグではない。

ただの文法ミスとか、正常系や通常の仕様範囲内の実装途中で踏むエラーはバグではない。

なんのエラーもなくなって開発が終わったあとに行うのがデバッグであり、そこで見つかるのがバグだろうが。

実装途中に遭遇するただのエラー修正をバグだのデバッグだの言うな。

エラーなんて文章出てるんだから、それのとおりに書き変えるだけだろ。

バグは！そもそも見つけるのとか再現が難しいんだろうが！あほたれー

Permalink | 記事への反応(0) | 17:51

ツイートシェア

■[稀ドメインはてブ]2024年2月滅多にホットエントリを出さないドメインからのホットエントリ

ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30

Permalink | 記事への反応(0) | 22:32

ツイートシェア