  |
はてなキーワード: デグレとは
こういう仕事は割とあるんだがなかなかのヤバさだったので紹介したい
ちなみにサービスの内容は非常に良くてユーザーも万単位で付いているらしい
バックエンドはAWS EC2で動作しているがログインアカウントは共通化されていてパスワードを全員で共有している
ユーザーを追加しようとしたら「そのような勝手な行為はセキュリティ上許可されていません」とのこと
本番環境とStagingはインスタンスが分かれているが運用は同じ方法
Staging上で5人ぐらいが作業しているが、ホームの下にそれぞれのユーザーが自分の名前でディレクトリを作って作業している
バックエンド側のシステムは詳細は伏せるが、某システムで動いている
仮にNode.js系だとすると、package.jsonがあってnpm run installでインストールするのだが、普通にインストールしようとするとエラーになる
内容は依存関係で失敗しているのだが、本番も同じソースで動作している
動作させるにはnode_modulesをまるっとコピーして、とのこと
さっきの自分の名前のディレクトリ配下にコピーしてきて、適当なポート番号でサーバを立ち上げれば一応は動く
このため、新しいモジュールを入れようとすると依存関係で失敗するため、便利なモジュールがあってもインストールできないし
セキュリティアップデートも当てることはできない（現にバージョンがすごく古い）
ソースコードはGitHub管理されているがセーブポイント感覚でcommitされているのでコミットログを見ても何が起きているのかさっぱり分からない
おまけにPRも使わずにmainにマージしまくっていてわけがわからない
加えてソースコードはコメントアウトの嵐でどこに何が書いてあるのかさっぱりわからない
データベースはPostgreSQLだが山ほどテーブルがあるのに外部キー依存は入っていないしVIEWも作られていない
まぁ、他にもテーブルを見ていくとアンチパターンのオンパレードで、EAV、ジェイウォークあたりは確認できたしHTMLやSQLが格納されているテーブルも見つけた
ソース上でクエリを作ってAPIを作っているが、ザッと見ただけでもインジェクションし放題の状態になっていた
フロントエンドも詳細は伏せるが、いわゆるReact的なものを利用している
こちらは npm run installでインストールできるし npm run devでちゃんと動く
ただ前述の通りバックエンドはローカルで構築できないのでEC2を利用するしかなく、CORS対応のためのプロキシを自前で用意する必要があった
バックエンド同様にGitHub管理されているが、管理しているだけ
バックエンドは5人ぐらいが利用しているが、ソースコードを編集するのは実質1人なのでコンフリクトはほとんど起こさないらしいが
フロントエンドは5人ぐらいが編集するのでコンフリクトしまくっている
解消するときにデグレすることが日常茶飯事でその都度Hotfixしている
コードもコメントアウトだらけなのに加えて、不必要なコードが大量にあるので可読性が著しく低い
（難しい処理を読み解いて追いかけていったら最終的に使われていない、などが大量にある）
2000行ぐらいあるコードとかChatGPTに突っ込んだら20行ぐらいになる予感がある
また、DBがご覧の状態なので取得されるデータも全然抽象化できておらず、コードが膨れ上がっている
例えばProductの一覧データをサーバから取得して、ユーザーがクリックしたProductをCartに投入するのだが、投入する情報はProductではなく、CartItemにする必要があるし
OrderするときはOrderItemにしてAPIを叩く必要がある
ほとんど同じ情報なのだが微妙に変わっていたりKey名が違っていたりするのでそれぞれ変換する
他にも数え上げればキリがないが、コピペして少しだけ改変している部分などが大量にあってバグがあるのかどうかすら判別できない
DBにHTMLやSQLが入っていると言ったが、調べて見るとDBから取得したHTMLをそのまま埋め込んで表示していたりした
SQLについてはフロントエンド側でSQL生成しており、そのテキストをAPIに送り込んでサーバ側で実行して貰った上で格納とかしていたので
「ここにDROP TABLEとか書けばTABLE消えるんですか？」
と聞くと
とか言われたのでことの重大さを伝えたが、まだ対処できていないようだった
認証等はOAuth2を使っていたので大丈夫そうだったが、本当に大丈夫かどうかは自信がもてない
システム内容はゴミのような状態だがサービス的には良いので、幹部やプロダクトオーナーからは追加要望が山盛り来ている
開発チームが「稼働が足りない」という理由で断ったので「じゃぁ支援して」ということで自分のところに来たのだが
「申し訳ないが、そもそもそういうレベルに無いし、全て作り直しが必要」
と伝えてもどうやら伝わっていない様子
ちなみに元々の開発チームは過去にもこんな感じでサービス作ってたらしいが売れないので問題になってなかった様子
ぱっと見は動いているように見えるのが厄介なところ
正直逃げたいところではある
問題はこっちだと思う。前者は多かれ少なかれどこにでもあるものだが、後者はその開発スタイル自体がすでに割れ窓に近い。
ぐちゃぐちゃなコードベースができてしまった場合、影響範囲を局所化して、確実に安全だと分かる小さな変更を積み上げながら直していくように移行ステップを立てるのがセオリーだ。延期できないバグ修正や機能追加ならまだ理解できるが、割れ窓直し程度のことでリスクのある変更を日常的に繰り返させる体制はやばい。実際に事故ってるし。
今回のケースは他人が埋めた地雷を踏んだようなものだから、気に病みすぎることはない。
ただ、レビュアーがバグチェックをしてるとしても、実装者としての責任を持つ気持ちはあったほうがいいと思う。責任を自信と言い換えてもいいけど、自分が手を動かした仕事に責任を持てるように動いていかないと、結果として遠回りになる。
その辺りでようやくうっすら気づいてきた。コードレビューはデグレが起きないようにしてくれるものじゃないって。コードにより引き起こされるバグの責任はレビュアーじゃなくて俺にあるんだって。
たとえばこのあたり、メンバーの中でコードレビューの目的が共有できてないのは組織の落ち度もあるけど、何かずれてるかもと思った時点で自分からすり合わせしたほうがいい。
いや、単体テストはそこそこ書かれてたし、バグ修正の際はリグレッションテストもちゃんと書いてた。
だから全てのテストも通ったからヨシ！的な流れでテストに含まれていなかったところに足を掬われたんよ。
筆者のプロジェクトの詳しい状況は知らんが、恐らくドキュメントどころかテストコードすらまともに書かれていないんだと思う。
「このバグを直したつもりだったんだけど、そこのコードは別の機能にも影響していた」なんてことを防ぐためにテストコードは書く必要があるし、それがデグレを防ぐことにも繋がる。
筆者が今の環境でできることは、あまり無理をせずに仕事をこなしつつバグが発生したら適当に頭を下げ、1年くらい勤務した後に転職をすることだと思う。
無職が転生してプログラマになったんですよ。運よく雇ってくれる会社が見つかった。
それまで一人でしかプログラムを書いたことがなかったから、コードレビューをしてもらえるということにとても期待していたし、それで安心して仕事ができると思っていた。
しかし、コードレビューは俺が期待していたものとは違うらしいと気づくまで、ものすごく時間がかかった。そんな話。
無職転生してプログラマになって、もちろん新規開発にアサインされるわけがなく既存のコードの保守が仕事となった。そのコードはなかなか大規模なもので、その全てを把握するなんて到底無理なものだった。
うん、ここですでに結論が出てるんだけど、当時の俺はそれに気がつかなった。
んで、割れ窓を直していくのが仕事なんだけど、俺がデグレが起こるようなことをしようとしていたら先輩が気づいて止めてくれる。それがコードレビューをしてもらえるってことだと思っていたわけだ。
でも、全然そうじゃなかった。
先輩がしてくれるコードレビューは追加されるコードの品質を見るというもので、デグレの可能性に気づいてくれるなんてものじゃなかった。
そりゃそうだ。コードの全貌を把握している人間はいないのだから。
その辺りでようやくうっすら気づいてきた。コードレビューはデグレが起きないようにしてくれるものじゃないって。コードにより引き起こされるバグの責任はレビュアーじゃなくて俺にあるんだって。
レビュアーもこのコードの全貌を把握していない以上、当然の帰結だった。
それはとても怖いことだったけど、でももう乗ってしまった馬車だ。俺は俺なりに仕事をするしかなかった。
そうして仕事をしているうちに、そこそこデカい不具合を出した。
不具合の原因は、影響範囲がそこそこ広い割れ窓の修正手段をとってしまったことだった。そのそこそこ広い影響範囲の中に、作られたのが昔すぎてドキュメントも残っていないのに今だにユーザーが使っている機能があって、そこがデグレた。しかもそのデグレによって出た損失は、回復不可能なものだった。
もちろん、レビュアーがそれに気づく事はなかった。
https://splatoon3.toriikengo.com/?p=2333 を読ませて頂いた。
上記記事の原文にも目を通して頂きたいが、内容としては、 「"長射程”に対するメタが“さらなる長射程しか存在しないことが現状の課題(そのため、相手に長射程を押し付ける能力に優れるカ二環境に行き着いた)であり、解決手段と起動性や体力のある要素を追加するべきである。」と整理でき、個人的には概ね同意している。
この記事が正しいことは、リッター⇒マルチミサイル⇒カニ（スクスロを添えて）の環境の変遷を見れば明らかだろう。
しかし、「Splatoonにおいて長射程が有利であることは開発者も流石に自覚しているはずではないか？」とも考えられる。
シリーズ３部作目なのだから、流石にこの程度は気づいているはずと仮定するのが適切と思われる（頼む、そうであってくれ）。
例えば、本作のエクスプロッシャーやオーバーフロッシャー、ハイドラント、ジェットスイーパー、トライストリンガー等の長射程ブキは、メインウェポンそれ自体の性能で短射程に近づかれればほぼ撃ち負けることが想定されるようにデザインされていると言える。また、サブウェポン、スペシャルウェポンも短射程に対して有利となるものがセットされているわけではない。これらのメイン・サブ・スペシャルウェポンの調整は、ほぼ完璧と言って良いと個人的には考えている。これは、開発者が長射程有利のゲーム性を理解していることの一例として挙げられる印象だ。
しかし、ゲーム性を理解しつつも、「一部のブキについては、長射程であるにも関わらず短射程に対しても有利な性能を付加」してしまった。これが、開発者の失敗なのではないかと個人的には考えている。
「大きな方針については理解しており、一部の運用に失敗してしまった」というだけであれば、失敗した部分についてパラメータ調整を付加することで解決できるのではないかと考える。
現状問題とされるべきブキはリッター４Ｋ、シャープマーカー、スクリュースロッシャーであって、これらのパラメータ調整で解決できる部分も大きいのではないかと考えている。シャープマーカーとスクリュースロッシャーを長射程ブキとして挙げることに違和感のある方もおられるだろうが、メインウエポンだけでなくサブ・スペシャルウェポンとセットで考えた時に、"実質的に長射程"ブキであると扱っている（若干無理やり感はあるが、ここでは言い切ることとする。）。
ちなみに、弱体化によって評価が落ち着いたラクトやヴァリアブルローラーも、マルチミサイルによって長射程（無限）であるにも関わらず短射程に対しても強い性能であり、しかも発動機会が多すぎることが問題であったと言える。現在は発動機会が抑えられたことでかなり弱体化されている（適切な強さに落ち着いた程度とも言える）。射程無限で全ブキに対して効果的で、キル性能も高いスぺシャルであったため、何かしらのデメリットが付加されるのは当然の帰結と言える。
改めて、「Splatoonにおいて長射程が有利であることは開発者も流石に自覚している」ものの、「一部のブキについては調整を単に誤ってしまった」のではないか、と考えている。
長射程は中射程に有利で、
中射程は短射程に有利で、
短射程は長射程には有利…
との３すくみの関係性が構築されていることと思われるところ、一部のブキについては、メイン・サブ・スペシャルウェポンのセットとして見た時に上記関係性を無視することが可能となっていることが問題と思われる。
上記関係性が正しく構築されることで、すべてのブキが活躍の機会を得ることで、多様な対戦環境を生み出すことができ、多くのプレイヤが幸せにプレイできるゲームに成長していくのではないかと考えている。
Splatoonは個人的にはかなり好きな作品なので、より良い方向に進化していって欲しい。本記事がSplatoon3の発展に寄与することを願っている。
（余談）
大抵不老不死を達成するために他の人間を平気で殺すような邪悪な存在として描かれる。
ドラゴンボールのフリーザ、鬼滅の刃の無惨、ジョジョのディオ、ゲド戦記のクモなどがその例だ。
一方で現実で不老不死を目指している人間は不老不死を達成するために他の人間を殺したりはしない。
現実で不老不死を目指している人物としては、レイ・カーツワイル、オーブリー・デグレイ、渡辺正峰、久保田信などがいるが彼らは不老不死になるために他の人間を殺したり犯罪行為をしたりはしていない。
ではなぜ漫画やアニメの不老不死を目指す人間が他の人間を平気で殺すような悪人に描かれるのかというと
制作者側に「不老不死を目指す奴は平気で人を殺す悪人に違いない」という偏見や差別意識があるからだと思う。
このような偏見や差別意識を無くすためにも、不老不死を目指す人間を平気で人を殺すような悪人に描く行為は規制するべきだと思う。
