今日の雑記

・睡眠時間８時間くらい。ラーメンの寝つきの良さに頼ることにして昨日は全体的にまずまずの睡眠だった。微妙に断続的な起床もあるが、ヘアバンドによるアイマスクでそれなりに寝れた。起きた時も「もっと寝ていたい」と思えたし、実際にもっと寝ていられる状態だったので長時間寝たい時には有用かなー。しかしずっとラーメンに頼るわけにもいかない。かといって牛丼だけでは足りない。牛丼＋ミニチキラーを試すかなぁ。ミニチキラーは100 kcalなのでそんなに悪くない。

・体調は悪くはなさげ。昨日も帰宅時点でふらふらしないし目もしんどくなかった。復調してはいるはず。
ていうか目がしんどかったならやはり体調は中の下まで落ちてたと見るべきだよな。

・まずは仕様確認のメール作成から。とりあえず思いとどまってもらうための情報提示をしつつカドが立たないようにまとめているが、あらためてざっと情報をまとめてみると結構多いな。そして全部どばどば表示するとそれはそれでカドが立つというか押し付けがましい。しかし情報が足りないせいでやることになっても困る。情報をまとめてみたら自分だけでなく他の人の作業も発生することがわかったのでその人達にも影響してしまうし。
というわけで情報は端的にしながら、自分の作業は工数だけ提示しておき、考えられる問題で大きめのやつを列挙し、他の人の作業が発生する件を入れておけばひとまずOKかな。いまの自分はそれなりに余裕があるので、そんな攻撃的にはなってないはずだし文面を改めてチェックしても大丈夫だと思う。といってもいまの自分の余裕はギリギリ中の中に届かないくらいのレベルなので、そんなにしっかり信頼がおけるものでもないが。まぁ現状で悪い部分が見つからない以上は改善することもできないのでひとまずこれで送ろう。

・メール作るだけでもそれなりにすり減るな。情報の再構築だのエンコードだのを行うわけだから仕方ないか。雑記みたいに適当に思いつくまま書くのとは違うしな。というわけでひとまず休憩。

・今朝の段階でもバグの状態は昨日と変わらず。さっき投げた仕様確認が１件、Cバグが１件、未コミットが１件。残ってる作業は実質Cバグ１件のみ。改めて内容を確認したら１〜２時間くらいで終わりそうな感じだったのでゆっくりで問題なさそう。

・腹筋の痛みはすっかりひいて違和感もないが、首の痛みはまたなんかぶり返してきた。寝る時間が確保できてるとはいえ、絵描きとか結局平日もしちゃってるからなー。首まわりのグッズ的なやつがやはり必要か。
というわけで「首　グッズ」でググってみた。首を温めたり冷やしたりするものとかもあるが、ちゃんとなんかあの不格好な感じになるやつとかあるな。
しかしここらへんは実際に見てみないとわからんな。近くのスーパーにあれば理想だが、なければハンズやロフトあたりに行かないとダメか。買い出しの時に見てきて、なければ土曜に行ってみるかな。どうせ昼飯で電車に乗るし、横浜はそんな遠くないし。

・昼休み前はあとはコミット〜連絡で完了。昼休みが明けたらCバグ対応に入ろう。

・性欲は減衰フェイズに入った。次の土日までは普通に使えると思うので、今のうちに女性キャラの服装の再考を進めたい。

・昼休み明け。仕様確認の返答が来たが、色々と立て込んでるので具体的な方針の決定は来週頭になるとのこと。ともあれ今日の作業はCバグ１つのみだな。ゆっくりやろう。
とはいえ自分の今のところの「ゆっくりやる」ってのは「並行して作業しない」くらいの意味なのでタスクが１つしかないなら必然的にゆっくりなんだよな。あとはせいぜい「休憩を多めにする」くらいか。作業速度に関してはむしろ意図的にゆるめるとストレスが逆にかかるし、意図的に早くできるものでもないので特に変わらない。せいぜいが体調によって自動的に変化するくらいか。

・Cバグの対応〜軽い動作確認自体は３０分程度で一応完了。しかし以前にあれこれエンバグしてたりそれ以前にバグの発生数の多いUIなので、もうしばらく動作確認したい。ともあれ休憩。

・さすがに担当が３人居るUIだとバグの発生率が上がるな。もちろん３人で同じ箇所をあれこれやっているわけではなく、内約的には「前作でUIを作った人」が居て「それを引き継いだ人」が居て「それに部分的に機能を追加することになった自分」が居る感じ。理想的には引き継いだ人が全て面倒を見れると良いのだけど、その人がだいぶ忙しいので自分に割り振られてる感じ。
なんにせよ、いったんこのUIを隅から隅まで理解してみるかな。コードレビューにかけたい部分でもあるし、その前に自分がちゃんと問題になりそうなところを一通り挙げられないとなんだ。今日はあとは動作確認とここらへんのまとめをやっていよう。

・今週は職場に溜まっていた菓子の消費を優先してカロリー調整したせいか吹き出物が出てきたな。

・お、重いな。該当UIのコードを読もうと思ったんだけど拒絶感がすごい。負荷がかなり高い。とりあえずコードはおいといて、現状の理解を言語化とかするところから始めるか。ちょっと想像しただけでこっちもそれなりに負荷がかかりそうなんだけど、コード見るよりマシだ。

・やはり首の痛みが悪化してる。PETボトルの残りをぐいっとやる時に耐え切れない。
さっき買い出しに行った時にスーパーにそれっぽいのが置いてないかと思ったが置いてなかったので、土曜にハンズとかに行くことになりそう。「身の回り」の予算はもう１０００円くらいしかないので、「趣味」の方から削る感じかなー。絵描きの練習に関連するから「開発」からでも良いけど。

・現状の理解の書き出しも難しいが、とりあえず雑記でやってるように「思いついた部分から書いていく」ことでそれなりに進められてる。まとめるのはあとからで良いや。まずは書いておきたいというか外部化して確認できるようにしておきたいところから書いていく。

・書き出しとも関連するんだけど、こっちは仕事での報告とかとは関係ないので雑記に書いておこう。引き継ぎとかデバッグとかに対する自分のスタンスに関する再考。
やはり「すでにあるものを引き継いだもの」に関してはバグの発生率が上がってる感じ。いや、正しくないな。すでに製品版になるくらいのデバッグ・チェックが行われているのでバグの発生率自体はむしろ低いかもしれないし、これからの報告によってそこらへんはまだ変わっていくだろう。問題はそこではなくて「エンバグ率が高い」という部分だ。
「修正したと思ったら新しいバグを仕込んでた」つまり「エンバグしてた」というのが引き継ぎに関しては多くなっている。これは現状では正しいし、たぶんこれからの報告においても変化しないだろう。そしてこれが起こるということは「引き継いだものをちゃんと理解しきれていない」という部分にある。
機能追加それ自体はできていても、それによるエンバグ率がまだ高い。ここに関しては自分自身のスタンスの変化によって修正できる範囲じゃないかと思う。ということでここらへんについて考えたい。ここまでが前置き。
まず、現時点では「自分の設計・コーディングスタイル」がそれなりに固まってきたこともあり、引き継ぎの際にも機能追加の際は「自分の設計・コーディングスタイル」をやや押し付ける感じで行っている。これはこれで実装速度が早くなるし、くっつける際には最低限の理解はどうせ必要だし、コーディングスタイルなども合わせた方が見やすければ合わせたりする。ただ、この引き継ぎスタイルだとエンバグ率が微妙に高くて、これはこのスタンスの変更でもっと良くなるのではないか、という話。
抽象的には「もっと他人のスタンスで設計・コーディングスタイルを行えないか」という感じで、具体的には「コードをちゃんと読んで設計スタンスなどまで理解して、そのうえでその設計思想のもとでならどういう機能追加が望ましいかを考える」という感じになるのだが、さっき書いたようにコード読むだけでもだいぶしんどいんだよな。単にフローを追うだけなら大したことないのだが、設計思想まで読み取るとなると途端に負荷が高くなる。結果的に実装がだいぶ遅れる。その後の要望対応がスムーズになったりデバッグなどの報告件数が少なくなるなどの利点ももちろんあるのだが、相殺できるほどかと言われると現時点では微妙なところだ。
うーん、どうすべきか。こういう時のために引き継ぎ書類とかあるのだろうな。しかし今回みたいにそういう書類がないのはザラだし。１から作りなおせばエンバグ率は減るが、コストがかかるのは結局変わらないし、せっかく以前のプロジェクトでデバッグ・チェックを通ってるのにそれを活かせないのももったいない。
「全てをちゃんと理解する」にはコストがかかりすぎる。しかし今の自分の「単に機能を載せるにはどうすればよいか」だけ調べるのではエンバグ率がちと高い。たぶんどっちも両極端なので、今回もまたバランスのとれる点がどこかにあるのだろう。
再考だけでも疲れてきた。休憩。

・気になったので旧作での挙動チェックとかしてたが、やはりこっちでも一部のCバグは再現するな。ほんとに軽微な見た目だけの問題だし、普通に遊ぶぶんにはまずやらない操作方法なので見つけること自体が難しいが。
で、今回の問題はそこじゃなくて、「もともとの設計がそういうバグを内包している場合、その設計はちゃんと理解して引き継ぐべきなのか」というところだ。どうせそのバグまで修正することになるなら、「さらなる理想」を設計してそれを押し付ける感じの方が良いのではないか。さすがに１から設計するのはなんだが、変更の範囲で実現できるならそっちの方が良いのではなかろうか。

・ちょっと見方を変えて考えよう。デバッグによって「ツギハギ」になるのと「より洗練された形」になる件。
自分のデバッグはどうも「ツギハギ」のような形になることが多いのだが、本来は「より洗練された形」になるのが妥当ではないだろうか、という話。
自分の変更がツギハギになる理由としては「できるだけヨソへの影響が少なくなるように＝エンバグを防ぐために」というのが大きいのだが、今回のように引き継ぎを想定すると「より洗練された形」になるのが望ましい。
また、自分の変更にツギハギが多い理由としては「一般的には続編ものだったとしてもコードを引き継ぐのは珍しい」という環境に居たからだろうとも思う。今作はまぁ引き継がないのがおかしいレベルではあるが、たいていの場合は結構な機能変更が多いので１から作った方が最終的に早かったりする。特に今まで自分が担当してきたようなギミックだのエネミーだのボスだのは環境に合わせて再構築した方が良い。だから「引き継ぎにくくなろうとも、とにかくバグの発生率が低くなる方が良い」というスタンスが強い。
理想で言えばもちろん「より洗練された形」になるのが望ましい。しかし現実的にはその対応コストはそこそこ高く、さらに新しいバグを生む確率も高い。そうやって新しいバグが出るたびに「より洗練された形」を考えて実装しまた新しくバグが生まれる、なんてループが回ってしまうとしんどい。コードの設計が洗練されているからといってバグがなくなるわけではなく、どちらかというと「バグの原因が突き止めやすくなる」という感じだと思う。コードの設計が完璧でも仕様時点でバグがあれば結局バグは生まれてしまう。
これもバランスの問題なんだろうなぁ。そしてまたしんどくなってきた。休憩。

・うん、コードレビューまわり用の文章というか要素は整ってきた。
現状での懸念事項は「特定UIにおけるデバッグ数とエンバグ率が高い」という点。ただ、これに関しては来週以降に落ち着く可能性もあるため、「来週も今のようなデバッグ数とエンバグ率であればコードレビューで対応方針とかの検証をしてもらいたい」という感じになりそう。というわけで今週はひとまず大丈夫というか様子を見たい。
ていうか旧作でも発生してるんなら、別に「既存UIなのに自分の引き継ぎの甘さでバグの発生数が多い」ってわけでもなさそうだし。ただまぁ引き継ぎ方に関してはやはりもうちょっと何かできそうなので、断続的に考えてはいきたい。

・残り３時間半。タスクがない。さっき対応したやつをコミットしてしまえば本当にもうやることがない。デバッグ報告を改めてチェックしたが特に自分の担当分は増えてない。
静的コード解析もかけるらしいので、来週もこんな感じならそっちの対応に入るのかもなー。ともあれ今日はあとは休むことにする。体調はそれなりに回復してきてるはずだが念のため。

・ローカルのToDoメモを読み返したら「気になる部分」はあったな。Cバグ系だがそれなりに対応コストが高いタイプ。来週は暇になったらこれを自分で報告して対応してみるかな。今日はちと体調的に難しそう。今日中に終わりそうにもないし。

・会社での絵描きも首に負荷かけてしまってるかなぁ。短時間なのでそれほど長く負荷はかかってないはずだけど。

・またちょっと考え事。引き継ぎまわり。
現状の問題は「UIのボタンアニメや遷移アニメ中にも操作できてしまうとマズい」という状況において、コードの設計がそれにラクに対応できる状況になっていないところ。「複数のコンポーネントが組み合わされてやや独立して動いている」というシステムで、入れ子みたいになっている部分もあり、共通化の面では仕方のない部分もある。

・時間があり余るのでテストプレイをしていようかと思ったが、よく考えたらテストプレイでもそれなりに首の負荷がかかりそうだなぁ。

・一件デバッグ案件が入ってきた。単にヒープサイズの問題なのでちょっと調査して再び向こうに回すだけ。ということで今日中に対応してしまう。が、オートビルドがこけてるのでコミットはしばらく待っているところ。

・眠気がそれなりに来た。空腹感もあるしオートビルドがこけてるし買い出しに行くか。

・残り１時間。さきほどオートビルドが通るようになったのでコミット〜連絡も完了。再びタスクなし。テストプレイでもしていようか。

・眠気が身体的なしんどさになってき始めた。まだわりと動ける部類ではあるが、このまま進むとだいぶ動きづらくなりそう。

・帰宅直前だが特にバグ報告はなし。来週月曜は気になってる部分の対応になりそう。体のしんどさもさっきの状態のままをなんとか維持できてるので、動けるうちに帰ろう。