  |
はてなキーワード:コメントアウトとは
昔の慣習に倣ってコメントを丁寧に書く人がいまだに居るけれど
以前のコードをコメントアウトしているようなソースは論外として
例えばメソッド・関数の頭にそれが何をする関数なのかを書いている人が多いけれど
メソッド名や引数名、戻り値の型をキッチリ付けておけば分からないことなんて無い
それ以上の複雑な処理をするなら機能分解するべきだし名前を付けにくい処理の場合はそもそもの設計がおかしい
昔は便利な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な記述が残る。
「人材が不足しているから、経験者である増田くんに是非ジョインして欲しい。言語は**で、これこれこういうことがやりたい。」ぐらいのレベルまでしか話せてなかった。
https://ja.wikipedia.org/wiki/%E3%83%8E%E3%83%BC%E3%83%88:%E8%91%89%E6%A2%A8%E5%BA%B7%E5%BC%98
正確性に関する外部からの指摘
現時点での最新版（2022年8月10日 (水)10:15 (UTC) の版番90910796）の「発言要旨」節の記述（2010年5月8日 (土) 16:46 (UTC) の版番31998247の加筆に由来するが、それ以前の2009年6月28日 (日) 05:14 (UTC) の版番26642282や2009年6月29日 (月) 14:01 (UTC) の版番26666330にほぼ同内容の加筆あり）について、以下の外部サイトで不正確との指摘がありました。
RStudioがPC内から気がついたら消滅していたので何回もやり直すのが面倒で書いた
コメントアウトをいじればFedoraやmacOSでも動くと思う
https://pastebin.com/HiPqLVq7 (6/4shコマンドでも動くように修正 以前はbash hogehoge起動していたので動作確認していなかった)
エラーでここに貼れなかった
util-linux(rev) libxml2-utils(xmllint) gpgcurlcoreutils(sha256sum)とR関連
echo"$HTML"|xmllint--nowarning--xpath hogehoge--html - | hogehoge
こうしないとxmllintがエラーでhtlmなどをうまく読み取らない
sed's/href="//g;s/"//g;s/\s/\n/g;s/^.?$//g;s/^\n//g'
href="hogehoge"の形で出てxmllint内で除去出来なかったのでsedで妥協
hrefが1回しか出ないのでひとまとめにできそうだが面倒なので分けた
この書き方なら複数回出ても除去できるはず
先頭の謎のスペースの除去が面倒だった
echo"$HASH""$FIELNAME"|sha256sum--status-c ;echo$?
スペースが2つないと書式で怒れられてハッシュ値が合っていてもsha256sumが終了ステータス0で正常終了を返してくれない
VScodium
ShellCheck
https://open-vsx.org/vscode/item?itemName=timonwong.shellcheck
XPath Helper
https://chrome.google.com/webstore/detail/xpath-helper/hgimnogjllphhhkhlmebbmlgjoejdpjl
zenn.devに書こうか迷ったがどちらの方が良かったのだろうか…
ダウンロードしたサーバーがやられてるならハッシュ値も改ざんするだろうgpgで確認しないと意味ないでしょとかsudoでやったらディレクトリがとか色々ガバあるから誰かいい感じに改良して
https://cran.rstudio.com/bin/linux/debian/
https://www.rstudio.com/code-signing/
