  |
はてなキーワード: スパゲッティコードとは
このAI説明が正しいならデバッガーが不要と言ってる、って話はかなり違うよな。
ここで書かれてるレベルのことは事前の取り決め等で発生を未然に防げることでしかないので、つまりブルシット・ジョブの人が言いたいのは
発生が十分に予想される問題に対して対策可能であるにも関わらず何の対策もしないことによって不要な仕事が発生している、という話でしかなくデバッガーが不要という話では全くないよな。
スパゲッティコード: 構造が複雑で理解しにくいコードは、バグの発見や修正が困難となり、多くの時間を費やすことになります。
コメントアウトされたセクション: 使用されなくなったコードが適切に削除されずに残っている場合、コード全体が読み解きにくくなり、メンテナンス性が低下します。
一貫性のないコーディングスタイル: チーム内でコーディング規約が統一されていない場合、コードの可読性と保守性が著しく低下します。
人類学者であるデヴィッド・グレーバー氏は、現代社会において多くの仕事が無意味であり、社会にとって価値を生み出していないと主張しています。2018年に出版された著書『ブルシット・ジョブ：クソどうでもいい仕事の理論』の中で、彼はこのような「ブルシット・ジョブ」の存在について論じています。
グレーバー氏は、以下の特徴を持つ仕事が「ブルシット・ジョブ」であると提案しています。
企業法務、テレマーケティング、広報、一部の管理職などが、「ブルシット・ジョブ」に該当する可能性があります。これらの職業は、必ずしも社会に貢献していないと断言することはできませんが、その価値が明確に見えにくい場合が多いと言えます。
粗雑なコードを修正するプログラマーは、「尻拭い」のカテゴリーに分類される可能性があり、以下のような問題に直面しがちです。
このような状況下でプログラマーは、本来創造的な活動であるはずの新しい価値を生み出す作業ではなく、過去の過ちの修正に追われることになります。これは、ソフトウェア開発プロセス全体に大きな問題があることを示唆しています。
プログラミング言語側に組み込まれている「型」だけでなく、プログラマーが独自に「型」を定義する方法も用意されています。
struct、class、interface、type, enumなどを使って独自の「型」を定義します。
開発しているソフトウェア独自の「型」は、ドメインモデルの要素になります。
多数の「型」を分類し、組織化するために名前空間を利用します。
近年「クラス」が「型」の定義であるという基本概念を理解していないエンジニアが増えているので、エンジニアを採用する際には注意しましょう。
ソフトウェアを起動すると、メモリ上には、たくさんのデータを読み込まれます。各データには、データの種類を表す「型」が割り当てられています。
例えば、ゲームならばCartという大分類の「型」を用意し、その要素としてMarioCart, LuigiCartという「型」を用意します。
業務システムならば、Reportという大分類の「型」を用意し、その要素としてCostReport, SalesReportのような「型」を用意することになります。
これらの大分類の「型」と、要素の「型」は、is-a関係にある、といいます。
CPUは機械語しか理解できません。一方で人間は機械語でプログラミングすることは困難です。
人間が「1ドル」のつもりで、メモリに「1」と記憶させても、CPUは「ドル」だとは扱ってくれません。
CPUは、「円」のつもりで記憶させた「1」と、ドルの「1」を区別出来ないので、そのまま足し算などの演算を実行してしまいます。
そこで、人間にとってプログラムを読みやすくすることと、CPUに意図しない演算をさせないために、データの種類を表す「型」という概念がプログラミング言語に用意されるようになりました。
金融やECサイトなどのお金の計算間違いが致命的なシステムでは、1ドル、1円を整数型などで扱うのではなく、予期せぬ演算が実行されないように「ドル型」、「円型」という「型」を定義します。
メモリ上のデータがどの「型」に属しているのか、という集合論の話でもあります。
例えば、猫型のデータは、動物型という大分類に属する、という集合の話です。
オブジェクト指向プログラミングの「is-a関係」は、集合論に由来するメモリ上のデータ(オブジェクト)の分類の話です。
俺は『あの人に辞められたら困る』と思われたいタイプの人間。だからなるべく有能であろうとしている。
アイツは必要だったんだ！って言われたい。
でも最近、有能な人間が辞めても全然困らないことがわかってしまった。
職場でもエースクラスの有能な人間が辞めた時、仕事は整頓されていた。引継ぎも円滑で、何だったら何も困らなかった。
遠大な目で、長期的な視点で、大枠で考えれば有能な人間が辞めることは損失なんだろう。
でも、現場としては大して困らなかった。
無能が辞めた時は大変だった。
仕事がとにかく絡まっている。誰相手に連絡をどのようにとって、どのような仕事をしているかわからない。
そして仕事のやり方がヤバい。下請けの人に負担を押し付けまくっていたり、都合よく嘘をついて仕様ですと言い張っていたり。
ブラックボックスがとにかく多く、スパゲッティコードのような仕事を紐解き、そして置いて行った爆弾を解体しなければならなかった。
いつか爆発する爆弾を処理する時が早めにきた、という考え方もあるだろうが、無能が会社にいれば色々楽だったはずだ。そいつに供述もさせられるし、責任も負わせられる。
だが、ヤツはもういない。
コードを書く上で重要なことは？という質問に対して、アスペならば「実行できること」と答えるだろう。
当たり前なことしか言っていない。「実行できること」という文からは全く有益な知見を得られない。
実行できることは重要性ではなく、必要性である。重要性とは、必要なことをすべてやった上でなおやる価値のあることを意味する。
そう考えた時に私がよく思うのは「最短時間で理解可能」であることが重要であると思うわけである。
しかしここに宗教がある。そもそも、人間が物事を理解するプロセスは人それぞれである。
私は一度、関数やモジュールで適切に分離するためのリファクタリングというものを行ったことがある。
というのも、一つの関数に万を超える行が書かれていたため、上司がリファクタリングを命令したためである。
具体的詳細はprivateメソッドに、公開する必要のあるものはpublicメソッドに移した。
そして当初働いていた職場での反応はどうだったかというと、「スパゲッティコード」だというのだ。
スパゲッティコード？一つの関数に万を超える行があるほうがスパゲッティだと普通は思うだろう。
ところが、彼らの脳内では、「常にコードの詳細が見えていなければ気がすまない」という、カプセル化を無視する思想で動いていたため、関数化すると関数の最下層まで辿らないと気がすまないらしかったのである。
このようにして、教育の無い人間はコードの読み方もカプセル化も知らないので、非生産的な方法が最短の方法になってしまうのである。
コードを最短で理解するためにはどうするのか。基礎知識を教育された集団の中に身を置くのがまず先決である。
例えばcalc_monthly_salary_yen(Person p)という行が存在した時、いちいちcalc_monthly_salary_yenの中身を常に見に行くような人たちはダメだ。
「人間のデータを入力すれば円単位で月の給料を計算してくれるんだろう」とざっくりと自然言語的に読み進められる人たちでなければ「最短理解」は難しい。
つまり最短理解するためのコードを書いた時に、それが本当に最短理解されるためには事前の教養が必要なのである。
ましてや優れた人から教えて貰うことでもなく
ただただプログラミングを好きになってモノづくりに熱中することだ
小さい子供がプログラミングに向いているのはモノづくりが好きだからであって
これは大人でも当てはまることであって
何かのモノづくりをするという目的の元に手段としてプログラミングが選ばれ
それに熱中することでいつの間にかプログラミング能力は向上していくのだ
上司から命令されてプログラミング講座を会社の金で受講するとか
Googleを目指して学生時代にプログラミングに打ち込むだとか
そんなのは全然上手く行かないのに定年退職したジジイがラズパイ使ってロボ作りとか始めると上手く行くのはそのせいだ
GitHubが発明したPull Requestはこの楽しみを徹底的に阻害している
「ちょっとこの辺は微妙だけど他のことやりたいから適当に済ませよう」
こうした行為はモノづくりからはほど遠く必要無いものに見えてしまい
「早く動いているところを見たい」
やがて開発者はプログラミングそのものに従事して嫌いになっていくのだ
以前からプロの現場ではもっと厳しい品質管理がなされていたという人がたまにいる
PRによってアジャイルの現場に品質管理がもたらされたと主張するのだ
命名規則やコメントの書き方などルール化できるものは別にレビューなど必要無くツールで弾くことができる
バグがあるかどうかはテストで担保すべきであってレビューで見るべきではない
この手のレビュワーが好んで使う言葉として「技術的負債」というものがある
技術的負債を残さないためにもPRで品質を保つ という主張である
一方で技術進歩は止められるわけが無く10年前に必死でクラス設計したJavaのシステムは
またはレビュワーの考える言語化できない「品質」のために今日もPRはリジェクトされる
人はプログラミングを嫌いになっていくのだ
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万以上でした。
最後の最後のダイバーシティについては、ダイバーシティを勘違いしているように思う
なんか最近プログラマの事、特に未経験者からプログラマになる人の事についての増田をよく見るんだけど
いい加減に職人しぐさ止めない？
ここで言う職人しぐさって言うのは「プログラマは自己学習するべきだ！」ってやつね。
気持ちは分からんでも無いよ。プログラマ、SIerになろうと思ったら学習は欠かせないし、勉強してないやつの汚いコードの尻拭いさせられる事が最悪なのは分かる。
でもさ、未経験者への話に「プログラマは（私生活を削っての）自己学習は必須！」って息巻かれると、「プログラマってだるいな…辞めとこ」ってなるやつ多いんだわ。
自分が割と「まぁ勉強は避けられないよね」みたいなノリで言った瞬間に空気が冷めたの経験したからすごいそう思う。
特に若い子は色んな選択肢があるから「じゃあ、別のにしよ」ってなる。
（気持ちはすごい分かる。僕もめんどいのは嫌いだし、人生やり直してもう一度プログラマになるかって言われたらかなり微妙）
プログラマはやっぱ若いのが一番だから若い奴ら取り込まなきゃいけないんだよね。
今、人出足りてないし、裾野も広げてやらなきゃいけない。
そのためには「とりあえずふるいにかけて残った精鋭だけ育てよう」みたいな贅沢はできない訳ですよ。てかそれをやったところでGAFAとかに取られたり、面白そうなベンチャーに行ったりで、うちみたいなセコセコやってる中小には来ないし。
プログラマが職人芸が求められる時代はもうだいぶ前に終わったし、
社会の流れ的にも「学習でも業務外に食い込むのってどうなの？」って感じじゃん。
あと、「プログラマは自己学習！」って声がでか過ぎて、スクールみたいな甘い言葉で釣ってるだけ所に人が流れてる気もするんだよね…
ある程度の学習が必要なのは避けられないけど、それを（会社で吸収できるなら吸収して）上手く誤魔化しつつ、適度に甘い言葉も使いながら集めていかないといけないんじゃないかなぁ。
やっぱり個人の素質が関わって来るものだし頭数集めるのが第一だよ。幸い手プログラミング自体は手を出すことだけは簡単なんだから。
それに素質の影響の多寡に関わらず、素質の部分を少なくしなきゃいけないしさ。
なんか最後ごちゃっとしたけど、とにかく職人しぐさを押し付けても、それで得するのは上位の上位層だけなんだから、やめよう。
それよりどうすれば、その必要な勉強を会社側、チーム側で吸収できるか（吸収してるか）を考えるほうがずっと有益だよ。
（今回僕、これについてなんにも書いてないのはごめんね。）
あとはそうだなぁ。割とコーディングの基礎やった後に実務に繋げる部分が薄い気がするんだよね。これは根本的に難しい問題っぽいけど、これがなんとかなったら良いなぁと感じる。
