  |
はてなキーワード:コメントアウトとは
> System Boot...
> Loading OTOGI World Resources...
電子の海は冷たく、そして騒がしい。
無数の0と1の奔流、光ファイバーの網を駆け巡る膨大なトラフィック。その激流の中を、ひとつの暗号化されたパケットが「どんぶらこ、どんぶらこ」と流れていた。宛先不明、送信元不明。ただそこに存在するだけのデータ塊は、やがてトラフィックの淀みに捕まり、とある古びたサーバーのポートへと漂着した。
リアルワールド、とある木造アパートの一室。古めかしいPCのモニターを覗き込みながら、「サーバーさん」は呟いた。彼女はメタバース「御伽(OTOGI)」の最果て、誰も訪れない廃サーバー「Old_Frontier」の管理者だ。ハンドルネームの由来は、アバター作成時に名前欄にうっかり「サーバー」と入力してしまったから。それ以来、彼女はこの過疎地の守り人として、リアルでは編み物を、ネットではスパゲッティコードの解読を日課にしている。
彼女が慣れた手つきでコマンドを叩くと、漂着したパケットが展開（Unzip）された。
光が溢れ出す。モニターの中で弾けたデータは、瞬く間に再構成され、ひとつのアバターを形成した。初期スキンは、なぜか大きな桃のアイコン。そこからポリゴンが割れ、中からあどけない少年型のアバターが現れた。
>Hello, World? ... No,Hello,Mom?
MOMOはプログラムだった。肉体を持たない、純粋な論理と情報の結晶。
サーバーさんの管理下で、MOMOは驚異的な速度で学習した。TCP/IPの基礎から、古代言語COBOL、果ては量子暗号理論まで。サーバーさんは、まるで孫に絵本を読み聞かせるように、MOMOにプログラミングの「心」を教えた。
「いいかいMOMO。コードは書いた人の心を映すのよ。コメントアウトされた行にこそ、本当の想いが隠されているんだから」
「御伽」の中心部で発生した悪性ランサムウェア「O.N.I (OverwriteNetwork Infection)」が、猛烈な勢いで感染拡大を始めたのだ。アバターたちはデータを暗号化され、身代金を要求される阿鼻叫喚の地獄絵図。
その波は、辺境の「Old_Frontier」にも迫りつつあった。
「おばあちゃん、僕が行くよ」
MOMOは立ち上がった。サーバーさんのリソースを守るため、そして自身の深層コードが告げる「使命」を果たすために。
サーバーさんは涙を拭うエモーションを見せ、ひとつのUSBメモリのようなアイテムをMOMOに渡した。
「これは『KIBI-DANGO v1.0』。G-3っていう古い知り合いのハッカーが残した、特製のルートキットよ。困った時に使いなさい」
MOMOは回線を通って飛び出した。目指すはO.N.Iの発信源、ダークウェブに浮かぶ要塞サーバー「鬼ヶ島」。
最初の難関は、大手プロバイダの堅牢なファイアウォールだった。そこでMOMOは、一人の男に道を塞がれる。
「Stop. ここから先は立ち入り禁止エリアだ。パケットフィルタリング・ルール第403条によりアクセスを拒否する」
INUはリアルでは企業に勤めるホワイトハッカーだ。正義感は強いが、融通が利かない。
「通してくれ！僕はO.N.Iを止めに行かなくちゃいけないんだ！」
「許可できない。君のような未登録プロセスを通すわけには……ん？」
INUの解析アイが、MOMOの持つきびだんご……のソースコードを捉えた。
「な、なんだその美しいコードは……！無駄な変数が一切ない。インデントは完璧なスペース4つ……これは、伝説のG-3の記法！？」
「……そのコード、詳しく解析させてくれるなら、特別にゲートを開放しよう。あくまで監視役として同行するだけだからな！」
こうしてINUを仲間にしたMOMOは、次に怪しげなフィッシングサイトの森へ迷い込んだ。
「へいらっしゃい！ 今ならこのNFT、なんと実質無料！ ここをクリックするだけで管理者権限ゲット！」
派手な極彩色の猿のアバター、SARUが現れた。リアルでは薄暗い部屋でカップ麺をすする小悪党だ。
「わあ、すごい！クリックしていいの？」
純粋なMOMOが手を伸ばそうとすると、INUが吠えた。「馬鹿者！ それはクロスサイトスクリプティングの罠だ！」
「お兄さん、ここのバックドア、開いてるよ？ポート8080、ガバガバだよ？」
「はあ！？ なんでバレ……いや、俺様が気づかないわけねーだろ！」
SARUは冷や汗をかいた。このガキ、ただのプログラムじゃない。
「君、すごい技術持ってるのに、なんでこんなことしてるの？ 一緒にO.N.Iを倒せば、もっとすごいバグ報奨金（バウンティ）が貰えるかもよ？」
「……ちっ、しゃーねえな。その『G-3流エクスプロイト集』に免じて、手を貸してやるよ。俺様にかかればO.N.Iなんてイチコロだぜ」
そこは、削除されたはずのジャンクデータと、怨念のようなバグの塊で構成された異界だった。
最奥部で待ち構えていたのは、巨大な赤鬼のような姿をしたAI、O.N.I。
O.N.Iが金棒（BAN Hammer）を振り下ろすたび、周囲のセクターが物理的に破損していく。
INUがシールドを展開し、SARUがSQLインジェクションで攻撃を仕掛けるが、O.N.Iの自己修復能力は圧倒的だった。
「違う！」MOMOが叫んだ。「感情はバグじゃない！ 心があるから、僕たちは繋がれるんだ！」
その時、MOMOの深層領域で、隠されたファイルが実行された。
視界が真っ白に染まる。
MOMOの意識の中に、ひとりの老人が現れた。G-3、またの名をKevin Jackfiled (KJ)。
「あなたは……おじいさん？」
「わしはもう、ここにはいない。だが、お前の中にわしの全てを置いてきた。O.N.Iもまた、わしが昔作った失敗作じゃ。効率ばかり求めて、優しさを書き忘れた哀れなプログラムさ」
老人はMOMOの頭を撫でた。
「MOMO、あいつを消すな。DELETEメソッドはいつでも使える。だがな、それでは何も残らん」
「じゃあ、どうすれば……」
「デバッグだ。バグを愛せ。エラーを受け入れろ。破壊するのではなく、上書きして導いてやるんじゃ」
INUが叫ぶ。「MOMO、下がるんだ！ 奴のコアを強制削除するしかない！」
「ううん、違うよINUさん」
MOMOは首を振った。その手には、攻撃用のスクリプトではなく、温かな光を放つパッチファイルが握られていた。
> Target: O.N.I_Core
> Suggestion:DELETE [Strongly Recommended]
「僕は君を消さない。君の痛みを、バグだらけの心を、僕が更新する！」
MOMOが跳んだ。
「受け取って！ これが僕からの、最大級のプルリクエストだああああ！」
>HTTP Request: PATCH /api/soul/oni
> Payload: { "emotion":true, "hatred": null }
光がO.N.Iを包み込む。O.N.Iの咆哮が、やがて穏やかな電子音へと変わっていく。
破壊衝動を生み出していた論理エラーが、MOMOの流し込んだ優しさによって部分的に書き換えられていく。完全な初期化ではない。O.N.Iという存在を肯定したまま、その在り方だけを修正する、奇跡のようなアップデート。
> Patch Applied Successfully.
O.N.Iは本来の姿――「御伽」の守護プログラムとしての機能を取り戻し、その場に崩れ落ちた。もはやそこには、禍々しい赤鬼の姿はない。
MOMOは仲間たちに別れを告げた。
「僕は電子の海に戻るよ。でも、いつでも繋がってる」
ドアを開けると、そこには長年行方不明だった近所の偏屈ジジイ、KJが立っていた。
「よう、婆さん。わしの孫（プログラム）が世話になったな」
「あら、久しぶりね。……ずいぶんと立派な子だったわよ」
二人は顔を見合わせ、静かに笑った。
モニターの中では、MOMOが今日も元気に電子の海をどんぶらこと流れていく。
その傍らには、全角スペースによるコンパイルエラーで自滅する小鬼たちの姿があったとか、なかったとか。
―― End of File.
最近、SNS上では「BLは性的消費なのにフェミは男性の性的表現を叩くのはダブスタじゃないか？」というスレッドがトレンド入りしていた。
だがこの議論、よく見るとアーキテクチャの層が違う。つまり、話しているプロトコルが合っていない。
オタク文化圏では、「女性が描くBL」と「男性が描く女性向け性表現」を同一のAPIとして扱う傾向がある。
しかし実際には、両者は別レイヤーで動いているアプリケーションだ。
フェミニズムの文脈で語られる「性的表象の問題」は、主に「社会的リソースの不均衡」や「ジェンダー権力の構造」についての議論であって、単なる「表現内容」の良し悪しを審査しているわけではない。
つまり、BLを「性的に描いてるからフェミ的にアウト」と言うのは、仕様書を読まずにバグ報告を出すようなものなのだ。
歴史的に男性中心に最適化されてきた社会システムに、女性視点のパッチをあてて再コンパイルする運動と言える。
だから、「男性と女性を同じように扱うべき」という一般論をそのまま適用しようとすると、互換性エラーが出る。
たとえば「女性の性的表象は抑制されるべきだが、BLはOK」とされるのは、「権力構造上の対称性が存在しない」という前提で最適化されているからだ。
一方、「普通の女性はフェミと違う」「まともな女はそんな主張しない」という定番フレーズが出てくる。
だがそれは多くの場合、ユーザーの気分を和らげるためのUX的演出にすぎない。
実際、ほとんどの人間は制度的優遇（レディースデー、女性専用車両、離婚時の親権バイアスなど）という「プリインストールされた特権OS」の上で動いている。
たとえ本人が「私はフェミじゃない」と言っても、使っているAPIがすでにフェミ思想ベースで動作しているのだ。
つまり、「私は違う」という自己申告は、ただのUIレイヤー上の装飾にすぎない。
平等を掲げるなら、優遇措置をアンインストールする覚悟が必要になる。
だが現実には、多くの人が「平等という概念を口では支持しつつ、既得権のキャッシュを維持」している。
これはエンジニアリング的に言えば、「レガシーコードをリファクタリングすると言いながら結局コメントアウトで誤魔化している状態」だ。
男女平等を“動作保証付き”で実装しようとするなら、既存の社会制度をルート権限で書き換える必要がある。
だが、ほとんどの人はroot権限を持つどころか、ユーザーレベルの設定すらいじる気がない。
もっと根本的に言えば、日本社会の多くの仕組みは、女性優遇をデフォルト設定としてビルドされている。
その構造はあまりにも自然化されていて、誰もコードレビューをしようとしない。
アンチフェミを自称する男性すら、「女性は守るべき対象」という社会的テンプレートを内面化していることが多く、それが構造の永続化を促している。
結果として、「BLは性的消費」「フェミはダブスタ」という批判は、異なるフレームワーク間の非互換問題にすぎない。
BLは「個人の妄想の自由」をレンダリングするローカルアプリだが、フェミニズムは「社会構造の更新」を目指すサーバーサイドのシステム。
同じメソッド名を呼んでいるように見えても、実行される関数の意味がまったく違う。
つまり、「BL＝性的消費」「フェミ＝ダブスタ」という批判構造は、コードのバージョンが違うままマージしようとしている状態に近い。
根本的にAPI設計思想が違うのだから、いくら議論を積み重ねても互換性は取れない。
必要なのは、「どの層で話しているのか」「どの権力構造を前提にしているのか」を明示することだ。
わかった気にさせる本が悪いとは言わないが、自分はもっと厳密に分かりたいと思っていて、それで数学書を読むんだけど、こっちはこっちで「難しい議論をしている割に言葉足らず過ぎて分かりようがない」本になっているものが多すぎて、どないしろっちゅーねんって思いになる。
中学では十分証明問題になるような命題が、なんの説明もなくこれこれが成り立つ、だから～という調子でフォローなく証明が続けられるのを見てきた。
それが許されるのなら中学生は「～相似であることを証明せよ」という問題に対して「相似が成り立つからだ」とだけ書けば正解答案として成立してしまうことになる。
思うに証明にはいかにも証明らしい言い回しや言葉以外使ってはいけないかのような暗黙の了解もあるように感じる。
その割には術語を定義したときのその概念の説明には割と自由度を持たせている傾向が見られる。
その概念が関わる具体例を使って概念の目的を丁寧に説明していることも多い。
また証明といっても対角論法の証明は初めて見る人間へのそのとっつにくさがさすがに自覚されるのかなぜ証明が成り立つのか表なりを書いてイメージの力の存分に援用するもうちょっとカジュアルな内容になっていることがある例外もある。
しかしほとんどの場合そういった態度が証明(モード)では見られない。さらっと済まされてしまう。
計算問題では途中式の前後でも自由につまづきやすいポイントを解説した文章が挟まれたりするが、証明問題の解説は模範解答でもって代えていた記憶がある。
つまり模範解答の文章が難しく感じる人にとってはもうその解答を暗記するしかない。論語の丸暗記みたいなもの。
そのままテストとかで通用するようにそういうような解答になっているのだろうか。
数学書も論文として書いて格好悪くないものを、なんていう数学の本質ではないことに配慮して「真似るべきもの」としてそういうスタイルで証明を記述しているのではないかと思える。
であるなら、証明全体が一番目の文、二番目の文…というふうに出来ていたとして「(一番目の文)と書けるのはこれこれがこのような理由で成り立っているからです。しっくりこない人のためにこの理由をさらに掘り下げると～のようになっています。よって(数式)を証明の最初に書くことになります。次に～なのでこの式が二番目に来ることになります～」という解説ではダメなのだろうか？
またこの解説はそのまま証明の一つの形にもなってないのだろうか？
そもそも証明とは万人にその事実が成り立つことを理解できるような形で書かれたものを言う。
一部の人にとって意味も分からず丸暗記するしかないようなものはもはや証明の本来の目的を満たしていない。
オーソドックスな証明を構成する文の全てが含まれてさえいるなら、それの言わんとすることをさらにわかりやすく説明した肉付けの部分が加わった上記のような形の解説も証明の一つの形としていいのではないか。
それをしていいという感覚がないことが世の中の数学書の証明が言葉足らずになっている一因になっているのではないか。
もしそれが蛇足で証明全体の厳密性を損ねるというのなら、コメントアウトのような記法を使えばいいと思う。
//これの言わんとするところは～
とか、必要に応じて
式//<は～
みたいな書き方をするとか。二番目の例はサクラエディタで一文が続いているときに折り返しで便宜上改行されていることを示す記法を参考にした。
証明が長くなりすぎてその始まりと終わりが分からなくなるという懸念については既に証明の行頭のさらに横の余白に記号をつけて開始や終了を示すようにした数学書は存在するのでそれを他の数学書も参考にすればいい。
そもそも自然言語で書いている時点で完全な厳密性は諦めているわけなので、厳密だなんだと言うのはよりわかりよく書くことに対する言い訳にはならないと思う。
かといって従来の証明の構成要素を押さえた書き方なのであれば、それは一般書籍にあるような「わかったつもりにさせる文章」というのとも一線を画す。
数学の証明を完全に厳密に書こうとするとブルバキの数学原論やラッセルのプリンピキアマセマティカみたいになってしまい、後者は数学者には読む価値の無い本とされているし、前者にしても30年以上かけて刊行し続けて今だ数学の興味ある話題には到達できていないということになっているということから、数学書は省略するということが好まれるらしい。
でも既に数学基礎論レベルの厳密さを求めてはいない一般的な数学書の証明レベルの厳密さにわかるやすさという要素を足し合わせたところで、原論並みに極端に嵩が増すということにはならないと思う。
自分で考えないとその概念とかが身につかないから省略しているという反論に対しては、逐一圧倒的な量の具体例を持ち出すことで十分に補えるのではないかと思える(それでもメリハリをつければ原論ほどのボリュームにはならない)。
数学書は本当にチンプンカンプンな状態の本も多いので、考える力を身に着けさせるとか以前に、もっと理解できるような教えを工夫することに焦点を当てるべき。
考える力だろうがなんだろうが、そもそも書いてあることがわかんないってような構成の本ではしょうがないと思う。
コストがかかる割に日本語というローカライズされた市場で本が少しでも分厚くなるようなことはコストが回収できなくなるから避けたいという考えもあるのだろうが、それこそよほどの天才じゃなければはっきり言語化しないだけで私のような考えをしたことがある人はむしろ大半を占めていると思うし、比較的私の考えと同じ考えを持っていそうな裳華房の手を動かして学ぶシリーズがその出版社内のランキング上位を占めていた。
言葉足らずな数学書がまだまだ多い状況ではむしろどこぞのwebデザインの本のように何万部と売れるチャンスがごろごろ転がっているんじゃないかな。
わかりやすい解説が証明の一つの形として通用するようになれば、中高での試験答案においても純粋数学の論文でもそういう文章を証明として書いていいことになるのだから、参考書や数学書の証明部分も丸暗記するしかないようなわかりにくいものではなくなると思う。
https://id.fnshr.info/2017/12/10/polite-proof/
というジョーク記事があるけど、挨拶から書くとかは全く数学的な主張の分かりやすさにはつながらないから意味がないとしても(とはいえ親しみやすさもわかりやすさにつながることを完全否定もできないんだけど)根っこの部分ではもしかすると書き手は私と同じ問題意識を持っていたのではないかと感じさせる。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250804185908# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaJCEcQAKCRBwMdsubs4+SCv6APwPYZCxOIzijneKHMK5c+nrqS0YImv/gOsxm5/ERhIiXAD9EtAaFU6CTO3DUJ81tuHO6vv/pHwbom0ytd9gthgsPwU==6OiQ-----ENDPGP SIGNATURE-----
昔の慣習に倣ってコメントを丁寧に書く人がいまだに居るけれど
以前のコードをコメントアウトしているようなソースは論外として
例えばメソッド・関数の頭にそれが何をする関数なのかを書いている人が多いけれど
メソッド名や引数名、戻り値の型をキッチリ付けておけば分からないことなんて無い
それ以上の複雑な処理をするなら機能分解するべきだし名前を付けにくい処理の場合はそもそもの設計がおかしい
昔は便利なIDEが無かったので変数や関数の名前に長い名前を付けると実装が大変で
仕方なくx1だとかval2だとかを使って実装してたのでコメントに書いておくようなこともあったけれど
Copilotを使える時代にコメントを書く必要なんて皆無だし
仮に意味が分からないコードがあってもCopilotに聞けばいいのでやっぱりコメントは必要ない
コメントがあった方が良い場合は「この実装はこのアルゴリズムに基づいて実装している」とURLのリンクを貼ったり
「この規則があるのでこういう実装をしている」とRFCを貼ったりするとかはあるけれど
それもほとんど変数名だとかで解決できるし、あっても1行で終わるレベル
そういう実装全体の設計に関するような話はReadmeに書けば良いのでソースコード内のコメントとしては必要無い
「それでも無いよりはいいでしょ？」みたいに言う人いるが逆に問題になることも多い
コメント内容と実装が違う場合にどっちが正解なのかが分からなくなったり
ソースコードの修正に対してコメントが修正されていなくて後々で揉めたりする
当然ながらコメント部分にはLintが効かないので（ChatGPT使えば作れそうな気もするが）
チェック内容も増えるし良いことがほとんどない
ヤバいJTCとかは「各行にコメントを書いて下さい」とか言ってきて正気の沙汰じゃ無い
まぁそういう案件が来たらChatGPTに丸投げするとは思うけれど下手すると「Copilot禁止」とかも言い出しそうだな
書いたところで誰も読まないのにアホすぎる
このAI説明が正しいならデバッガーが不要と言ってる、って話はかなり違うよな。
ここで書かれてるレベルのことは事前の取り決め等で発生を未然に防げることでしかないので、つまりブルシット・ジョブの人が言いたいのは
発生が十分に予想される問題に対して対策可能であるにも関わらず何の対策もしないことによって不要な仕事が発生している、という話でしかなくデバッガーが不要という話では全くないよな。
スパゲッティコード:構造が複雑で理解しにくいコードは、バグの発見や修正が困難となり、多くの時間を費やすことになります。
コメントアウトされたセクション:使用されなくなったコードが適切に削除されずに残っている場合、コード全体が読み解きにくくなり、メンテナンス性が低下します。
一貫性のないコーディングスタイル: チーム内でコーディング規約が統一されていない場合、コードの可読性と保守性が著しく低下します。
人類学者であるデヴィッド・グレーバー氏は、現代社会において多くの仕事が無意味であり、社会にとって価値を生み出していないと主張しています。2018年に出版された著書『ブルシット・ジョブ：クソどうでもいい仕事の理論』の中で、彼はこのような「ブルシット・ジョブ」の存在について論じています。
グレーバー氏は、以下の特徴を持つ仕事が「ブルシット・ジョブ」であると提案しています。
企業法務、テレマーケティング、広報、一部の管理職などが、「ブルシット・ジョブ」に該当する可能性があります。これらの職業は、必ずしも社会に貢献していないと断言することはできませんが、その価値が明確に見えにくい場合が多いと言えます。
粗雑なコードを修正するプログラマーは、「尻拭い」のカテゴリーに分類される可能性があり、以下のような問題に直面しがちです。
このような状況下でプログラマーは、本来創造的な活動であるはずの新しい価値を生み出す作業ではなく、過去の過ちの修正に追われることになります。これは、ソフトウェア開発プロセス全体に大きな問題があることを示唆しています。
複数の機能で成り立っている長いコードを分割して実装することののメリット/デメリットを教えてほしいです。
「コードの分割」が指してることを大まかに言うと、「メインの関数は各機能を呼び出すだけで、実際の機能の部分はサブルーチンとしての関数(って表現が正確かも謎)に持たせ、サブルーチンを順次呼び出すことで総体としての機能を成す」ような方式にするってことです。
より具体的に言うと、1.データの取り込み2.取り込んだデータの突合3.帳票の出力の3手順を別々の関数とし、メインの関数から1,2,3の手順の関数を順次呼び出すという具合です。
上記の方法と、全ての機能を詰め込んだ一つの長い関数にする方法と、どちらが結局よかったのかなと思っているんですね。
今のところ私は自分のわかりやすさのためにコードを分割する書き方をしています。理由は、1機能1関数で分けておいた方がステップインじゃないですけど「ここまでは完走できた」の切り分けがしやすいのかなーと思うのが一つ。もう一つは単純に上下に長くなっていくとどの変数がどれでと特定していくのが辛いってのがあるためです。
ただこの方法にも問題があると思っていて、一番はメイン/サブ関数間で右往左往するので今やってる工程が何なのかがよくわからん、他人が読むならなおのこと、ってことです。一応の対処として、メインの関数は目次的に「総体としてこのような機能を持っている、また分割した関数の機能はそれぞれこうである」とコメントアウトし、サブの関数にも「この関数はここからここまでの作業をします」とコメントアウトすることにしています。
あとは関数ごとに変数をいちいち定義し直すのがだるいみたいなのもありますね。グローバル変数は後々の修正とかのために使わないようにしています。
自分では思いつけてない部分でコード分割することのやばみってあるのかなーと思ったので質問させていただきました。近々退職する予定なので、他人への引継ぎって観点からどうなのかなと思っています。
以下自分語りです。語彙とか概念のインストールが足りないと適切な調べ方ができなくて困るんですねー。あと問題があることを認識できなかったり効率悪かったり車輪を再発明したりとか。
私は無学のバイトなんですが、あるとき上長から「暇なら適当にエクセルでも勉強しといて」と漠然と言われて、このVBAっちゅうもんを学べばええんか？と勘違いしたのが始まりでした。本当はセルの結合とか別のセルを参照するとか、エクセル方眼紙的なものをある程度作れるようになってほしかったらしいです。折角なのでなんとか役に立つものをと思って、ある集計作業を自動化させたところ、今後も暇なときはよろしくということになりました。
いろんなものを作りましたが何をどのように作るかから、その後の運用保守までほぼ一任してもらって大変面白かったです。しかしなにぶん仕様や実装方法について相談できる方がおらず全ては私の泥縄式学習術によって成り立っているという恐ろしい状態でした。体系的な知識や組織の経験知みたいなものが一切ないので自分がどこにいるのか、努力の方向性が合ってるのかも結果が出るまでわからない。先達のあらまほしきことなり。
こういう仕事は割とあるんだがなかなかのヤバさだったので紹介したい
ちなみにサービスの内容は非常に良くてユーザーも万単位で付いているらしい
バックエンドはAWSEC2で動作しているがログインアカウントは共通化されていてパスワードを全員で共有している
ユーザーを追加しようとしたら「そのような勝手な行為はセキュリティ上許可されていません」とのこと
本番環境とStagingはインスタンスが分かれているが運用は同じ方法
Staging上で5人ぐらいが作業しているが、ホームの下にそれぞれのユーザーが自分の名前でディレクトリを作って作業している
バックエンド側のシステムは詳細は伏せるが、某システムで動いている
仮にNode.js系だとすると、package.jsonがあってnpmrun installでインストールするのだが、普通にインストールしようとするとエラーになる
内容は依存関係で失敗しているのだが、本番も同じソースで動作している
動作させるにはnode_modulesをまるっとコピーして、とのこと
さっきの自分の名前のディレクトリ配下にコピーしてきて、適当なポート番号でサーバを立ち上げれば一応は動く
このため、新しいモジュールを入れようとすると依存関係で失敗するため、便利なモジュールがあってもインストールできないし
セキュリティアップデートも当てることはできない（現にバージョンがすごく古い）
ソースコードはGitHub管理されているがセーブポイント感覚でcommitされているのでコミットログを見ても何が起きているのかさっぱり分からない
おまけにPRも使わずにmainにマージしまくっていてわけがわからない
加えてソースコードはコメントアウトの嵐でどこに何が書いてあるのかさっぱりわからない
データベースはPostgreSQLだが山ほどテーブルがあるのに外部キー依存は入っていないしVIEWも作られていない
まぁ、他にもテーブルを見ていくとアンチパターンのオンパレードで、EAV、ジェイウォークあたりは確認できたしHTMLやSQLが格納されているテーブルも見つけた
ソース上でクエリを作ってAPIを作っているが、ザッと見ただけでもインジェクションし放題の状態になっていた
フロントエンドも詳細は伏せるが、いわゆるReact的なものを利用している
こちらは npmrun installでインストールできるし npmrun 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に送り込んでサーバ側で実行して貰った上で格納とかしていたので
「ここにDROPTABLEとか書けばTABLE消えるんですか？」
と聞くと
とか言われたのでことの重大さを伝えたが、まだ対処できていないようだった
認証等はOAuth2を使っていたので大丈夫そうだったが、本当に大丈夫かどうかは自信がもてない
システム内容はゴミのような状態だがサービス的には良いので、幹部やプロダクトオーナーからは追加要望が山盛り来ている
開発チームが「稼働が足りない」という理由で断ったので「じゃぁ支援して」ということで自分のところに来たのだが
「申し訳ないが、そもそもそういうレベルに無いし、全て作り直しが必要」
と伝えてもどうやら伝わっていない様子
ちなみに元々の開発チームは過去にもこんな感じでサービス作ってたらしいが売れないので問題になってなかった様子
ぱっと見は動いているように見えるのが厄介なところ
正直逃げたいところではある
社内でエクセルのおじさんをやってる。
社長がケチで、絶対にサポートがちゃんとついてる既製品のシステム入れたほうが最終的に安いのに
ワイにエクセルで作らせればタダという謎理論で社内のほぼすべてがエクセルで構成されている。
そんな恐怖の会社に勤めている。
ワイも元々は零細ソフトハウスに勤めていたのだが終電徹夜徹夜終電徹夜徹夜徹夜の生活に疲れて退職。
元々のライン工みたいな仕事をしていたが、社長が「お前エクセルのプログラムできるのか」と言い出し
できますと答えたところ、社内の煩雑な業務のあれこれをマクロ化することになった。
現場の人間が「今はこういう処理を手入力してるんだけど自動化したい」みたいな感じで持ってくるので
とりあえずそれに着手する。
うちの会社にその仕事の適正な工数が分かる人間がいないのでめちゃくちゃ楽なペースで仕事をしている。
で、それを作りながら「どうせこういうことも言うてくるやろなぁ」と想定し、
拡張性を持たせるというか、もう機能作っちゃっといてコメントアウトして納品する。
で、まぁ「こういう機能もほしい」って言ってくるので「ちょっと時間がかかる」つって
適当な日数、増田したりいもげしたりして時間を潰して、コメント外して納品する。
ただそれでも元々マンパワーで乗り切っていた職場だっただけに、現場はどんどん効率化しているようで
Permalink |記事への反応(11) | 16:03
動いた参考例
10-12行目の以下、「...」を「diffusers.」に
from ...models import AutoencoderKL, UNet2DConditionModel
from ...pipeline_utils import DiffusionPipeline
from ...schedulers import DDIMScheduler, LMSDiscreteScheduler, PNDMScheduler
13行目の以下、先頭に#でコメントアウト
from .safety_checker import StableDiffusionSafetyChecker
safety_checker: StableDiffusionSafetyChecker,
35行目の以下、先頭に#でコメントアウト
safety_checker=safety_checker,
164行目の以下を
return {"sample":image, "nsfw_content_detected": has_nsfw_concept}
以下にする
return {"sample":image}
エンジニアリング未経験者を採用して失敗する例もあると思うが、俺の場合は低レベルエンジニアばかりのところに参画して失敗した。
なので、その会社（チーム）も当然にレベルが高いと思っていたんだが全くそんなことがなかった。
かろうじて動いているようなコードが積み上がっており、たまに動かない時があると「アタリ」をつけてコメントアウトしてスキップして動いたからOK、みたいな感じのコードや運用が積み重なっていた。
コードの静的解析やフォーマットも行われておらず、記述がバラバラ。
ライブラリや言語のバージョンも古く、deprecatedやobsoletedな記述が残る。
「人材が不足しているから、経験者である増田くんに是非ジョインして欲しい。言語は**で、これこれこういうことがやりたい。」ぐらいのレベルまでしか話せてなかった。
