  |
はてなキーワード: コメントアウトとは
このAI説明が正しいならデバッガーが不要と言ってる、って話はかなり違うよな。
ここで書かれてるレベルのことは事前の取り決め等で発生を未然に防げることでしかないので、つまりブルシット・ジョブの人が言いたいのは
発生が十分に予想される問題に対して対策可能であるにも関わらず何の対策もしないことによって不要な仕事が発生している、という話でしかなくデバッガーが不要という話では全くないよな。
スパゲッティコード: 構造が複雑で理解しにくいコードは、バグの発見や修正が困難となり、多くの時間を費やすことになります。
コメントアウトされたセクション: 使用されなくなったコードが適切に削除されずに残っている場合、コード全体が読み解きにくくなり、メンテナンス性が低下します。
一貫性のないコーディングスタイル: チーム内でコーディング規約が統一されていない場合、コードの可読性と保守性が著しく低下します。
人類学者であるデヴィッド・グレーバー氏は、現代社会において多くの仕事が無意味であり、社会にとって価値を生み出していないと主張しています。2018年に出版された著書『ブルシット・ジョブ：クソどうでもいい仕事の理論』の中で、彼はこのような「ブルシット・ジョブ」の存在について論じています。
グレーバー氏は、以下の特徴を持つ仕事が「ブルシット・ジョブ」であると提案しています。
企業法務、テレマーケティング、広報、一部の管理職などが、「ブルシット・ジョブ」に該当する可能性があります。これらの職業は、必ずしも社会に貢献していないと断言することはできませんが、その価値が明確に見えにくい場合が多いと言えます。
粗雑なコードを修正するプログラマーは、「尻拭い」のカテゴリーに分類される可能性があり、以下のような問題に直面しがちです。
このような状況下でプログラマーは、本来創造的な活動であるはずの新しい価値を生み出す作業ではなく、過去の過ちの修正に追われることになります。これは、ソフトウェア開発プロセス全体に大きな問題があることを示唆しています。
複数の機能で成り立っている長いコードを分割して実装することののメリット/デメリットを教えてほしいです。
「コードの分割」が指してることを大まかに言うと、「メインの関数は各機能を呼び出すだけで、実際の機能の部分はサブルーチンとしての関数(って表現が正確かも謎)に持たせ、サブルーチンを順次呼び出すことで総体としての機能を成す」ような方式にするってことです。
より具体的に言うと、1.データの取り込み2.取り込んだデータの突合3.帳票の出力の3手順を別々の関数とし、メインの関数から1,2,3の手順の関数を順次呼び出すという具合です。
上記の方法と、全ての機能を詰め込んだ一つの長い関数にする方法と、どちらが結局よかったのかなと思っているんですね。
今のところ私は自分のわかりやすさのためにコードを分割する書き方をしています。理由は、1機能1関数で分けておいた方がステップインじゃないですけど「ここまでは完走できた」の切り分けがしやすいのかなーと思うのが一つ。もう一つは単純に上下に長くなっていくとどの変数がどれでと特定していくのが辛いってのがあるためです。
ただこの方法にも問題があると思っていて、一番はメイン/サブ関数間で右往左往するので今やってる工程が何なのかがよくわからん、他人が読むならなおのこと、ってことです。一応の対処として、メインの関数は目次的に「総体としてこのような機能を持っている、また分割した関数の機能はそれぞれこうである」とコメントアウトし、サブの関数にも「この関数はここからここまでの作業をします」とコメントアウトすることにしています。
あとは関数ごとに変数をいちいち定義し直すのがだるいみたいなのもありますね。グローバル変数は後々の修正とかのために使わないようにしています。
自分では思いつけてない部分でコード分割することのやばみってあるのかなーと思ったので質問させていただきました。近々退職する予定なので、他人への引継ぎって観点からどうなのかなと思っています。
以下自分語りです。語彙とか概念のインストールが足りないと適切な調べ方ができなくて困るんですねー。あと問題があることを認識できなかったり効率悪かったり車輪を再発明したりとか。
私は無学のバイトなんですが、あるとき上長から「暇なら適当にエクセルでも勉強しといて」と漠然と言われて、このVBAっちゅうもんを学べばええんか？と勘違いしたのが始まりでした。本当はセルの結合とか別のセルを参照するとか、エクセル方眼紙的なものをある程度作れるようになってほしかったらしいです。折角なのでなんとか役に立つものをと思って、ある集計作業を自動化させたところ、今後も暇なときはよろしくということになりました。
いろんなものを作りましたが何をどのように作るかから、その後の運用保守までほぼ一任してもらって大変面白かったです。しかしなにぶん仕様や実装方法について相談できる方がおらず全ては私の泥縄式学習術によって成り立っているという恐ろしい状態でした。体系的な知識や組織の経験知みたいなものが一切ないので自分がどこにいるのか、努力の方向性が合ってるのかも結果が出るまでわからない。先達のあらまほしきことなり。
こういう仕事は割とあるんだがなかなかのヤバさだったので紹介したい
ちなみにサービスの内容は非常に良くてユーザーも万単位で付いているらしい
バックエンドは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を使っていたので大丈夫そうだったが、本当に大丈夫かどうかは自信がもてない
システム内容はゴミのような状態だがサービス的には良いので、幹部やプロダクトオーナーからは追加要望が山盛り来ている
開発チームが「稼働が足りない」という理由で断ったので「じゃぁ支援して」ということで自分のところに来たのだが
「申し訳ないが、そもそもそういうレベルに無いし、全て作り直しが必要」
と伝えてもどうやら伝わっていない様子
ちなみに元々の開発チームは過去にもこんな感じでサービス作ってたらしいが売れないので問題になってなかった様子
ぱっと見は動いているように見えるのが厄介なところ
正直逃げたいところではある
社内でエクセルのおじさんをやってる。
社長がケチで、絶対にサポートがちゃんとついてる既製品のシステム入れたほうが最終的に安いのに
ワイにエクセルで作らせればタダという謎理論で社内のほぼすべてがエクセルで構成されている。
そんな恐怖の会社に勤めている。
ワイも元々は零細ソフトハウスに勤めていたのだが終電徹夜徹夜終電徹夜徹夜徹夜の生活に疲れて退職。
元々のライン工みたいな仕事をしていたが、社長が「お前エクセルのプログラムできるのか」と言い出し
できますと答えたところ、社内の煩雑な業務のあれこれをマクロ化することになった。
現場の人間が「今はこういう処理を手入力してるんだけど自動化したい」みたいな感じで持ってくるので
とりあえずそれに着手する。
うちの会社にその仕事の適正な工数が分かる人間がいないのでめちゃくちゃ楽なペースで仕事をしている。
で、それを作りながら「どうせこういうことも言うてくるやろなぁ」と想定し、
拡張性を持たせるというか、もう機能作っちゃっといてコメントアウトして納品する。
で、まぁ「こういう機能もほしい」って言ってくるので「ちょっと時間がかかる」つって
適当な日数、増田したりいもげしたりして時間を潰して、コメント外して納品する。
動いた参考例
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/4 shコマンドでも動くように修正 以前はbash hogehoge起動していたので動作確認していなかった)
エラーでここに貼れなかった
util-linux(rev) libxml2-utils(xmllint) gpg curl coreutils(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/
3年前、世間一般にはメーカー系SIerとして知られている会社を退職した。ただ俺のポジションはパッケージソフト開発であり純粋なSIerとは異なる。
客ともSEとも会話せず、ひたすらドキュメントとプログラムを書く部署だ。といっても別にペーペーではなく主任クラスであり、
会社の業績がとてもよかったこともあり年収は1000万弱はあった。35歳。
これだけ見るととてもいい待遇に見えるだろう。でも耐えられないことがいっぱいあった。
Linuxで動くアプリなのにVMを動かすのも苦労する8GBしかメモリのないWindows PC、紙にコードを印刷して説明しないと納得しない品質保証部、
手作業で実施しExcelにチェックを付けていくテスト、jquery一つ使うのに3ヶ月かかる承認フロー、開発中にバグを一つ出すごとに
ひたすら反省文を求める品質保証部と一緒になって詰めてくるマネージャー、常にコンパイルできないtrunk、
Java 5の時代から進化しないコード、使いにくい社内ミドルウェアの利用を強制される設計、開発期間の半分以上を占める最上流設計、
一旦書いたコードは消してはならずコメントアウトしないといけないコーディング規約など、数を上げればきりがない。
色々改善活動を頑張ったものの、結局Subversionの導入も品質保証部がついていけないから、ということでClearCaseといわれる
今ではほぼ誰も使ってないであろうバージョン管理ツールが使われ続けることになった。使いにくい社内ミドルウェアは
研究所がその道のプロと聞いたので一緒に改善を図った。そしたらRubyしか書いたことがない文系新卒の子が出てきた。
一応研究所の人だし…と思って新バージョンのプロトの開発を依頼したら、1分以上稼働できない状態になって出てきた。
研究開発は準委任相当なのでそれ以上修正を依頼できずに期間が終わった。
また前の会社独特の文化として、大きなバグを出した開発者の反省会（社内ではとある固有名詞で呼ばれている）があった。
この反省会のターゲットになった開発チームはその資料準備で開発が1〜3ヶ月ほど止まるほど大掛かりなイベントだ。
このとき、担当の品質保証部は「連帯責任だから」という理由で資料レビューに大変な精を出す。余計なお世話だ。
このため10〜20ページほどの資料を毎週レビューにかけて最高のものにしていく。でも結局本番では幹部からの怒号が飛んで終わりである。
連帯責任とかいっていた品質保証部は幹部と一緒になって詰めてくる。連帯責任ではなかったのか。
幹部によると、この反省会があるから今の会社があるんだそう。これを経験して一人前らしい。
こんな感じで開発の体制はひどかったが、世間一般ではホワイト企業と見られている通り有休は取りやすかった。
そのため、転職活動を始めた。そしたらなんと「メモリ32GBのマシン」「mavenが気兼ねなく使える回線」「自動テスト」
「GitHub」「CI/CD」 という発言がポンポン出てくる。メルカリだのGoogleだのといったイケイケWeb系ではなく、
いわゆるSIerでもだ。最初は何だこの格差はと思ったが、まぁ営業トークなんだろうな、と思い直した。というわけで
イケイケWeb系も内定は出たものの、つい安定をとってしまい某大企業のDX系の部署に転職した。
そしたら何だこれは。最高スペックのMacBook ProからGitHubにpushするだけで自動デプロイで即サービスイン、
問題が発生したら社用携帯に通知が飛んできて、クラウド監視サービスでログをチェック、即修正即デプロイ。
社内の連絡はSlackで、スタンプを押せばIssueがたち即関連部署が対応に走る。OfficeツールはGoogle Docsで、
計算表はちゃんと表として使っている。開発者はちゃんと開発をしており、反省会の準備や品質保証部の接待なんて業務はなく
純粋にエンドユーザーだけを見ている。ここはなんて最高の環境なんだと歓喜した。また個人的にはおまけ程度であるが、
年収は30万ほど増えて大台に乗った。
さて、それから3年がたった。人間というのはいい環境になれると対して喜びを感じなくなる、というのはそうだと思う。
今では別にdeployブランチにマージされたらCIが走って自動でテストが走りデプロイされるのも、だから何？
って感じだしまぁ普通の仕事として淡々とやっている感じはする。待遇面で悪化した点もちらほらあるし
（例えば年間休日が5日ぐらい減った、残業が月5時間ぐらい増えたなど）などもある。
ただ一つ言えることは前の会社には戻れないな…ということである。人間一度生活レベルを上げてしまうと下げるのは
ただ、一つだけ今の会社に転職してよかったと感じ続けられることが一つある。それは人だ。
前の会社では家でプログラムを書いているなんていった日にはおちょくられたり、人生楽しいの的な目で見られたりした。
芸能人とゴルフの話ができないとコミュ障扱いされた。そのため仕事の話はしても、飲み会にはできるだけ行きたくなかった。
でも今の会社では雑談としてFastlyが落ちても大丈夫なCDN構想とか、AtCoderの話をして盛り上がることができる。
ダイバーシティなんていうが、人間は所詮同質な人間同士で集まったほうが快適なんだな・・・という複雑な思いを抱いている。
皆さん読んでくれてありがとうございます。いくつか質問が出ているので答えられる範囲で答えます。
真面目な疑問なんだけど、Java5のコード書いてる人を1000万で雇う会社があるの？どういうモチベーション？？
製品自体が90年代から脈々とバージョンアップしている企業向けのソフトウェアなので、コードベースが古いというのがあります。
またユーザーからすると中身がJava17だろうがJava5だろうが関係ないわけで、要は業務が滞りなく進めばよいわけです。
そのため昔から受け継がれたスパゲッティコードを地道に解き明かし、新しく出てきた要件を今までのコードベースを壊さずにバグなしで追加していく、
もとからあったバグについては、その他の数百万行のユニットテストもないコードに影響なしで修正を施す、といった技能が必要になります。
こう考えると意外と希少なスキルなんだな・・・と思えるかもしれません。
clearcaseよりもsubversionの方が100億倍導入も運用も簡単だと思うんだけど品管どうなってんの？
ClearCaseご存知な方がいるんですね！一から作る製品だとSubversionのほうが簡単かもしれません。ただ、ClearCase専用の
社内ツールがいくつかあり、そのツールで出力した情報を社内資産として持っているという理由があったりします。
例えばお客さんから「この機能がバグってるっぽい」というクレームを受けた際、その機能周辺の情報をそのツールから検索し、
コードレベルで再発防止策を関係部署総出で練った上でお客さんに回答する、という運用フローになっています。
そのため、Subversionに変えるためには開発陣の一存では無理で、品質保証部やマネージャー層など全ての知識のアップデートが
必要になり、そこまでコストをかけて説得して回る必要はあるのか・・・という話になってしまうわけです。
ただ、社内の生産性を向上させるのが目的の部署としてはSubversionやGitを社内に浸透させたがっているのも事実で、
新規プロダクトなんかはGitを使っていました。ただしGitHubはプロキシでアク禁されているだけでなく、サービス名名指しで使用禁止
になっているので、相当の理由がない限り使えないかと思います。
主任クラスでも1000万円近くもらえるのか。すごい。
1000万という数字に興味のある方が多かったので参考までに書いておくと、等級ランクというものが存在して管理職を除く最上位のランクに
なると2人の子持ち、賃貸住まい、標準評価で大体900万になるという感じです。年功序列だが部署ごとに違うというイメージで、
研究所だと20代で到達する一方、利益を上げていない事業部や間接部署だと定年間際まで到達しない人も多い、ぐらいの感じです。
平均では30代中盤ぐらいでしょうか。
ちなみに私の場合は基本給は33万程度ですが、そこに裁量労働手当と住宅手当、家族手当がついて月給で50万を超えるぐらいでした。
ボーナスは個人評価よりも部門業績に大きく左右されるのですが、部署が最高評価の場合は夏冬とも150万以上でした。
最後の最後のダイバーシティについては、ダイバーシティを勘違いしているように思う
私は理系の男が性的な意味で好きだ。物理数学を愛する理系の男が物理への愛を込めて色気も素っ気もないような無味乾燥な教科書を書き上げたんだと思うとドキドキする。アメリカの生物の教科書とかに比べて圧倒的に分かりづらい不親切な記述。そのくせ書いた本人はとっても分かりやすいと思っている馬鹿さ。物理の教科書はとってもえっち。
【論文】
もう一回言うが私は理系の男が性的な意味で好きだ。若干社会不適合者な一面や、独特の言い回し、そして飛び切り有能な頭脳にきゅんきゅんする。だがしかし彼らの国語力は微妙である。ああ、ここもっと親切な言い回しがあるでしょうに。と読むたびに思う。しかし大切なのは親切であることよりも一意的であり誤読の余地がないことだ。よってそういう言い回しにならざるを得ない。という窮屈な枠組みの中で書かれたちょっと読みづらい文章、堅苦しい言葉選び、あ、この人普段はあんななのに論文だとこんな文章も書けちゃうのね、ってギャップ萌え。全てが愛しい。
理系の男が作るパワーポイントはダサい。学会用スライドから講義資料、メーカーのおじさんが出してくる資料までとってもダサい。色使いもおかしい。情報量を詰めすぎである。そういうところが私は好きだ。そもそも内容上コンサルみたいなスマートな資料を作るのは不可能である。目盛りと単位までばっちり書いたグラフを載せれば資料はダサくなる。ダサいが必要なものは全て揃っている。しかしダサい。だがまあそうとしか言いようがない気もする。実用上十分であるが見た目がヤバい、というのはなんともまあ彼らの存在を象徴しているようで、はあ、好きだなあ。と思いながらいつも見ている。
【授業】
頭のぶっとんだ理系の男が好きだ。教授なんてその最たるである。本人は一生懸命分かりやすい説明をしてるつもりなんだろうけど、全然分かんないよ。なんだお前。本人は分かりやすいと思ってるとこが本当に好き。学生に分かってもらおうと頑張ってるところが好き。その頑張りが全く報われてないとこが好き。応力場が見えるとか言ってくるの意味わからんが。エロい。
【Web授業】
Web授業の何がいいって顔が見えないことだよ。いい声のエリートが耳元で永遠に知的なセリフを囁いてくるとかポルノか？？？？？心がぎゅんぎゅんする。Web授業はアニメと一緒。すなわち二次元。好き。
理系の男が書いた文字はエロい。精緻に並んだ筆記体の数式とかオシャレ過ぎて泣く。いやお前そんな字書くの？？？逆にめちゃくちゃ優秀な人がクソみたいな字を書くのも本当に好き。めちゃくちゃ頭いいのに小学生より字が下手な男。しかしノートのまとめ方って言うのかな、書き方は頭いい人のそれだったりして、ただ字だけがひたすらに小学生。なんだお前は。好き。
あと頭に手が追い付いてない人。こいつのノートは読めない。そういうのもえっちだ。好き。ノートだけで永遠に萌えられる。試験期間中にノート貸してくれた男に何回恋したか。字がエロすぎて。
まあ基本的に学生の書いたプログラムなんてクソクソ読みづらいんだわ。うわー、意味わかんねーって思いながら不親切なコメントアウトを見てプログラムを読み下したりして、分かったときの「ああでもこうとしか書きようがなかったよね」って共感。あなたのことを分かってしまったときのキュンキュン。でもまあよく考えるともっと他に分かりやすい書き方ない？って思ったりして、でもやっぱりなくて、みたいなね。ずっと引き継がれてるプログラムってそういう歴史が詰まってるじゃん。それを辿りながら読むの、え、えっちー。エロすぎる。凄いものを作れてしまう頭の良さ、しかし自分が賢いがゆえにそれを分かりやすく伝えられないところ、親切心と少しの遊び心を含んだコメントアウトを読むの、とっても好き。
