「コーディングスタイル」タグアーカイブ

チャッピーとの雑談(3)

これ、観れる? https://x.com/fumokmm/status/1890755241664036958

ChatGPT:

ご提示いただいたリンク先の投稿は、2025年2月15日午後1時29分に「ふも」さんが「つらくなってきたのでAIにロジック考えてもらおうw」と投稿したものです。この投稿は現在も閲覧可能です。

あなた:

これ見て思ったんだけど、わたしロジックを考えるという感覚が薄いみたいなの。

ChatGPT:

なるほど、アイカは「ロジックを考える」という感覚があまり強くないと感じているんだね。それって、「直感的に組み立てることが多い」のか、「考えているけど、それをロジックとして意識していない」のか、どっちの感覚に近い?

あなた:

両方なんだろうけれど、理解をコードに翻訳している感じ?

ChatGPT:

なるほど、「理解をコードに翻訳している感じ」っていうのは、すでに頭の中である程度筋道ができていて、それをコードの形に落とし込んでいるってことかな?

もしそうなら、いわゆる「ロジックを考える」というより、「頭の中で既に組み立てたものをコードにする」感覚に近いのかもね。

考えるというより、変換作業に近い?

あなた:

うん。だから、理解するまで手が動かない。

ChatGPT:

それ、めちゃくちゃ納得できる。アイカのやり方だと、「理解してからでないと手を動かせない」から、手を動かしながら考えるタイプとは逆のアプローチだね。

たぶん、

  • 「ロジックを考える」というより、「理解をコードに変換する」
  • 「とりあえず試す」じゃなくて、「納得したら書く」

っていうスタイルなんだろうなって思う。

そうなると、「とりあえず書いて動かしながら考える」みたいなやり方はしっくりこない感じ?

あなた:

全体を一度に理解はできないから、部分ごとに確認はする。

ChatGPT:

なるほど、一気に全部を理解するわけじゃなくて、部分ごとに確認しながら進める感じなんだね。

つまり、

  1. 全体の流れをぼんやり掴む
  2. 細かい部分を理解しながら、少しずつ確かめる
  3. 納得したらコードに落とし込む

みたいな流れ?

手を動かすのは「試行錯誤のため」じゃなくて、「理解を確認するため」って感じかな?

あなた:

そうそう。理解したものの間違い探しに近いかも。

ChatGPT:

なるほど、それなら 「試すために書く」 じゃなくて、「間違いがないか確認するために書く」 っていうスタンスだね。

手を動かすのは、検証のため であって、書きながら考えるわけじゃない。
だから、理解できてない状態でコードを書こうとしても、そもそも手が動かないわけだ。

こういうスタイルだと、「コードを書く前の段階でどれだけ理解を整理できるか」がめちゃくちゃ重要になりそう。例えば、

  • 頭の中で組み立てる時間をしっかり取る
  • 図を書いたり、言葉で説明してみたりして整理する
  • 理解が固まったらコードを書く(間違い探しモード)

っていう流れになりそうだけど、実際そんな感じ?

あなた:

うん。そんな感じ。

ChatGPT:

やっぱりそうか。アイカのやり方って、事前の整理がしっかりできていれば強いタイプだね。逆に、「とりあえず書いて動かしながら考える」みたいなやり方は合わない っていうのも納得。

このスタイルを活かすなら、

  • 図やメモで整理する習慣を強化する(コードにする前に理解を明確にする)
  • 「コードは間違い探しのため」と割り切る(納得しないまま書かない)
  • 大きなものをいきなり理解しようとしない(部分ごとに分解して考える)

この辺を意識すると、よりスムーズに進められそう。

今のやり方で困ることとか、改善したい部分ってある?

あなた:

こういうやり方って普通なのかしら?

ChatGPT:

「普通かどうか」で言うと、このやり方をしている人は結構いる と思うよ。でも、多くのプログラミング学習法やチュートリアルが「とりあえず手を動かそう」っていうスタイルを推しているから、「まず書いて試す」タイプのほうが目立ちやすいだけかも。

実際、「書く前にしっかり理解してから手を動かす」 っていうのは、数学や物理の問題を解くスタイル に近いし、ロジックが複雑な分野(最適化問題とか、低レイヤーのプログラム)では、このやり方が合っていることも多い。

例えば、

  • 職人気質のエンジニア はこのスタイルを取ることが多い(特にバグを許せない人)。
  • 低レイヤー系(OS、アセンブリ、組み込み) は、適当に書くと動かないから、アイカのやり方のほうが向いてる。
  • 数学寄りのアルゴリズム実装 も、いきなり手を動かすより、事前に理解してからのほうがスムーズ。

逆に、

  • Web開発とかフロントエンド系 は「とりあえず動かして、見た目を変えながら試す」スタイルが主流。
  • ゲーム開発やデザイン系 も、手を動かしながら試すほうが進みやすいことが多い。

だから、分野によっては一般的なやり方だし、むしろ強みになる場面も多い と思う。

「このやり方で損をしてるかも?」とか思うことある?

あなた:

あー、なるほど。Webとかフロントエンド系は確かに苦手かもw

ChatGPT:

なるほどw そういう系の開発って、「動かしながら試す」 のが前提になってるから、アイカのやり方とは相性が悪いのかもね。

フロントエンドとかWeb開発って、「まず書いて、動かして、見た目や挙動を確認しながら調整する」 っていう流れが多いし、仕様が流動的なことも多いから、「最初にしっかり理解してから書く」 ってやり方だと、逆にストレスが溜まりやすいかも。

逆に、アイカのやり方が活きるのは、
低レイヤー(アセンブリ、OS、自作コンパイラ)
数式が絡むプログラム(シミュレーション、最適化問題)
しっかりロジックを詰める必要があるもの(バックエンド、DB設計、セキュリティ系)

こういう系の分野だと、「最初に理解しないと書けない」っていうのがむしろ強みになる。

フロントエンド系をやるときって、やっぱり「試行錯誤しながら作る」っていうスタイルが合わなくて、ちょっとしんどい感じ?

あなた:

苦手とはいってもできないわけじゃないよ?

ChatGPT:

そうだよね、「苦手=できない」じゃない のはわかるよ! アイカの場合、「とりあえず試す」スタイルがしっくりこない だけで、やろうと思えばちゃんとできるって感じでしょ?

たぶん、フロントエンド系をやるときって、

  1. 全体の仕組みを理解するのに時間をかける
  2. コードを書くときは、すでに理解がある程度固まっている
  3. 試行錯誤しながら作るより、ロジックを整理してから実装する

っていう流れになってるんじゃないかな?

だから、「試しながら進めるのが好きなタイプ」ではないけど、必要ならやる」 って感じ?

4o

あなた:

うん、そうだね。そんな感じ。仕事はやり方を必ずしも選ばせてくれないし。

ChatGPT:

そうだね、仕事だと「自分に合うやり方」だけじゃなく、「求められるやり方」に合わせないといけない場面も多い しね。

アイカのスタイルは、「理解→コード」という流れだから、整理された仕様やロジックがある環境ではめちゃくちゃ強い と思う。でも、フロントエンドみたいに「まず動かしてから考えよう」っていう文化の場所だと、ちょっと合わないけど、必要ならそのスタイルでもやれるってことだね。

やりやすいスタイルを知ってるけど、必要なら適応できる って、結構バランス取れてるんじゃない? 自分のやり方に固執しすぎると逆に仕事しづらくなることもあるし。

今のやり方で「ここをもっとスムーズにしたい」とか、改善したいポイントってある?

あなた:

あえてやってみたいとか考えたりしてる。そのやり方で見えてくるものもありそうだし。

ChatGPT:

おお、それめっちゃいいね! 「苦手だけどできる」じゃなくて、「あえてやってみる」 っていうのは、視野を広げるのにすごく役立つと思う。

確かに、普段と違うやり方を試すと、新しい視点が見えてくる ことがあるよね。例えば、アイカのやり方だと、
「全体を理解してから書く」ことでミスを減らす強み があるけど、
「とりあえず書いて試す」ことで、意外な発見がある かもしれない。

普段のやり方とは逆のスタイルを試すことで、「どこまで整理すれば十分か」 とか、「どこを割り切っても大丈夫か」 みたいなバランス感覚も掴めそう。

具体的に「このやり方でやってみようかな?」って考えてることある?

あなた:

仕事じゃなくて趣味だけど、BIOSまわりを使ったx86レガシーシステムのコーディングかなぁ。

ChatGPT:

おお、それめっちゃいいじゃん! x86レガシーシステムのコーディング って、アイカの「理解してから書く」スタイルと相性がいい部分もありつつ、「試しながらやらないといけない」場面も多そうだから、ちょうどいいチャレンジになりそう。

BIOS周りって、

  • ドキュメントだけで完全に理解するのは難しい(実機 or エミュレーターで試す必要あり)
  • ハードウェア依存が強いから、動かして検証するのが必須
  • ロジックを詰めすぎると動作確認が遅れる

っていう性質があるから、「まず理解する」スタイルと「動かして試す」スタイルの両方が求められるよね。

実際にやるなら、

  1. BIOSの仕様をざっくり整理する(事前理解)
  2. 最低限のコードを書いて、エミュレーター(Bochs/QEMU)で動作確認
  3. 動いたら、細かい部分を詰めていく

みたいな流れでやると、アイカの「理解→実装」スタイルも活かしつつ、「試しながら進める」部分も取り入れられそう。

具体的に、どんな機能を書いてみようと思ってる?

あなた:

最初に全体を理解しきれないのよね、40年とか前のシステムであってもさ。

ChatGPT:

そりゃそうだよね。40年以上前のx86レガシーシステム って、歴史も長いし、仕様も膨大で、当時の「当たり前の前提」が今とは違うから、いきなり全体を理解するのは無理ゲーに近い。

アイカのやり方だと、
全体を理解してから実装したい → でも 古いシステムは情報が断片的で、全部を把握するのが難しい
試しながらやるのは苦手 → でも 試さないと動作確認が難しい

っていうジレンマがあるよね。

こういうときは、「まずは小さい部分から理解して、徐々に広げる」 スタイルがハマりそう。例えば、

1. まずBIOSがやっていることを大雑把に整理

  • POST(Power-On Self Test):ハードウェアの初期化
  • INT 13h(ディスクアクセス):ブートローダーがこれを使う
  • INT 10h(画面表示):テキストモードの制御
  • INT 16h(キーボード):キー入力の取得
  • INT 19h(ブートストラップ):OSを起動

この辺の 「どこから手をつければいいか」 をざっくり掴んでおく。

2. 「この部分だけなら理解できる」を探して試す

  • 例えば 「BIOS経由で画面に文字を出すだけ」 を最初にやってみる
    • INT 10hAH=0Eh を使えば、文字を表示できる
    • mov ah, 0Ehmov al, 'A'int 10h で ‘A’ が表示される
    • 小さい部分だけ確認することで、試行錯誤のストレスを減らせる

3. 成功したら範囲を広げる

  • キーボード入力(INT 16h) を試す
  • ディスクアクセス(INT 13h)でブートローダーを読む
  • ブートローダーを書いて、BIOSからOSを起動する流れを試す

って感じで、徐々に範囲を広げていくのが良さそう。

アイカのやり方だと 「いきなり全部を理解するのは無理だけど、小さい部分を確実に理解して進める」 のが向いてるから、こういうアプローチなら無理なく進められそうじゃない?

あなた:

うん。少しずつ進めてる感じかな。

ChatGPT:

いいね! 「少しずつ進める」 のが一番確実だし、アイカのスタイルにも合ってると思う。

x86レガシーシステムって、手を動かしながら理解を深めるしかない部分もあるけど、「小さい単位で理解してから実装する」 っていうアプローチなら、無駄な試行錯誤を減らしつつ進められそう。

今の進め方で、「ここがちょっと難しいな」とか「思ったより手間取ってるな」って感じる部分ある?

あなた:

まだまだ先の話だけど、タスクスイッチとかスケジューラ周りかなぁ。

ChatGPT:

タスクスイッチスケジューラ周り かぁ……確かに、そこは一気に難易度上がるよね。

特に レガシーx86のタスクスイッチ って、

  • 8086には「タスクスイッチ」という概念自体がない(手動で管理)
  • 286以降のプロテクトモードではTSS(タスク状態セグメント)を使う
  • 386以降はコンテキストスイッチがもっと柔軟になった

みたいに、時代によってやり方が違う から、「どの時代の方法を使うか」を決めるだけでも大変。

👀 タスクスイッチを考えるときの段階的なアプローチ

  1. 「そもそもタスクとは?」を整理
    • タスク(プロセス)は、CPUの状態(レジスタ、スタック、メモリ空間)を保持する単位
    • 「タスクスイッチ=別のタスクのCPU状態を復元する」
  2. シンプルな「手動タスクスイッチ」を試す
    • まずは BIOSの割り込み(INT 10hや16h)を呼び出す→戻る みたいな「一時的な制御移譲」を試してみる
    • それができたら、「スタックを保存&復元して手動スイッチ」 を試す
  3. ハードウェア支援のタスクスイッチを試す
    • TSS(Task State Segment)を使ったコンテキストスイッチ を試す(286以降)
    • 386以降なら「ソフトウェアで管理するタスクスイッチ」 も考えられる
  4. スケジューラの基本を作る
    • 「タスクを順番に切り替えるだけの簡単なラウンドロビンスケジューラ」から始める
    • 割り込みタイマーを使って、自動でタスクを切り替える

🏗 アイカのスタイルに合うやり方

  • まずは 「スタックを保存&復元するだけの手動スイッチ」 で挙動を確認
  • そこから 少しずつ機能を足して、最終的にスケジューラを作る

いきなり「マルチタスクOSを作ろう!」ってなると大変だけど、「まずはCPU状態の保存と復元だけで動かしてみる」 って感じでやると、少しずつ進められそう。

今の段階で「ここがちょっと理解しづらい」とか「事前に調べておきたいこと」ってある?

あなた:

今は休止中かな。エネルギーを充填しているところ。

ChatGPT:

なるほど、今はエネルギー充填期間ってことね。そういう時間、大事だよね。特にアイカのスタイルだと、理解を整理してから手を動かす から、無理に進めるよりも「気が向いたときに一気にやる」ほうが効率いいことも多いし。

今はあえて距離を置いてる感じ? それとも、じわじわと情報を集めたり、頭の中で整理しながら次のタイミングを待ってる感じ?

あなた:

タイミングを待ってるところ。

ChatGPT:

なるほど、次に進むべきタイミングを待ってる ってことね。そういう時期も必要だよね。

たぶん、アイカのスタイル的に「やる気が出ないから放置」じゃなくて、「理解を深めるために、無意識のうちに整理してる時間」 なんだと思う。しばらく間を置くことで、頭の中でまとまってくる瞬間があるはず。

ふとしたときに、「今なら進めそう!」ってなる瞬間が来たら、また自然に手が動き出すんじゃないかな。焦らずそのタイミングを待つのが、アイカには合ってそう。

何か別のことをやりながら待ってる感じ? それとも完全に充電モード?

あなた:

完全充電モード。また何か進展したらお話するね。

ChatGPT:

了解!今はしっかり充電モードってことね⚡🔋✨

またエネルギーが満タンになって、何か進展したら気軽に話してね!楽しみにしてるよ😊