ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try

はじめに 先日、社内で「良いコードの書き方やお作法、プログラミングの原則って、どうやったら身に付くんだろうねえ？」という話になりました。 もちろん、「本を読んで勉強する」っていのも勉強法のひとつなんですが、そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは？なんて思ったりします。 強烈なモチベーションというのは、たとえば、 いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！ っていうぐらいのモチベーションです。 というか、これは単純に僕のケースですね、はい。 幸い、ソニックガーデンに入ってからは、周りのプログラマがみんなちゃんとしているので、そんな思いをすることはほぼなくなりましたが、前職、前々職ではそんな

[yukimi1977]

よいコードを書いたつもりでも数年後に見るとひどいコードになってたりするから何とも言えない。

[kart0408001]

くそコードディスりブログあるある。リーダブルコードとコードコンプリートのアフィリエイト

[imo_jo_chu]

ひどいコードをひどいコードだと気づかないままでいることがとても怖い。日本のデスマーチが常態化してた現場のコードがそんな感じだった

[ahomakotom]

良いコードが良いというトートロジー

[perl-o-pal]

cobol時代の変数名やカラム名引き継いでるってパターンはしばしば目にするけど、「変数名やロジックは引き継いだまま移殖」って提案よっぽど多かったんだろうなあ。誰が考えたんか知らんが不幸な発明だ。

[te2u]

自分の経験で読んでいて辛いコードは、何をやっているかわからない＝責務がはっきりしない、というもの。クラス名、関数名、変数名から何を意味するか推測できない、データ構造が不可解、不達なコード、など。

[haya14busa]

逆の「良いコードをメンテしてきたからこそ実感する、悪いコードや悪い設計のつらさ」もありそう．良いコード，設計は学習コストも低いことが多いのでそういう環境であれば最初からでも学びやすくて後に活かせる

[kuenishi]

時間ないしあとで捨てるかもしれない場合は、無駄に綺麗すぎるコードを書いても大変だよ…

[DiceK_U]

自動化で極めてどうでも良くなりそうね

[rjge]

“エラーが発生したら「うるさい、黙れ！」と握りつぶし” / せめて適切な箇所でログだけでも出してくれてたらって泣きながら再現調査するやつ

[ch1248]

良記事。

[mfham]

[ruby][勉強]

[hiroponz]

COBOLをVB6に焼き直したプログラムのメンテとか、今はRubyがメインとか自分と重なるところが多くて、とても共感できた

[lowpowerschottky]

“ダメダメなデータベースで開発したり運用したりするのは本当に大変”

[lbtmplz]

YMO「良いものもある…悪いものもある…」

[a_bicky]

わかる “いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！”

[harabu]

【「プログラムはコピペして作れ」と言われていて（ひどい）、ちょっとした仕様変更する場合でもコピペした部分を全部探して、一個ずつ変更、変更、変更・・・を繰り返していました。】こういう人だらけで嫌になる

[koogawa]

恥をかかないと直らない気がする。ずっと同じ場所にいると気付かない

[yanagikouta]

これは分かる "いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！"

[Kmusiclife]

まぁよくあること。コミュニケーション力の差なんてこんなものではない。生きるという標準システムの中であるからこそあまりに能力に格差があります。

[kinchiki]

COBOLやVBってそんなに古いのかね。まあ見たことも書いたこともないし、書く気なんかさらさらないけど。

[wakuteka]

“そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは？なんて思ったりします。”

[n-channel]

コードの良さにも必ず限度がある。というか良いコードも初見の人には汚く見える。大切なのはテスト可能にしておいて、試しに色々といじれるようにしておくこと。百聞は一見にしかず。

[watermaze]

今となっては著者がかつて素晴らしいと思ったStruts and HibernateのシステムもCOBOL並みの「ひどいコード」扱いの代物だと思うのですがね。昔の人は面倒なXMLやアノテーションをごりごり書いてたとか馬鹿にされそう。

[ksakae1216]

やばい、しっかり読もうこの記事！

[kyrie_leison]

強烈なモチベーション、大事だなぁ

[raimon49]

COBOLほとんど知らなくてもCOBOL流儀な設計や変数をちょくちょく見かけるのが日本IT業界の闇。

[nekonyantaro]

最初のCOBOLの名残を引き摺ってる例、早くに電算化(笑)してた大企業なんかに多いんじゃないかな。変数のスコープなんて概念無しとか名前は8文字までとか。もしかして例のメガバンク案件もそういうの関係有るのかな。

[baronhorse]

書き逃げコードの保守て渦中はハゲるけど振り返るといい経験になってたりするよね。若いうちの苦労というと老害ぽくてあれだけど。

[kkotyy]

コード例親しみある。COBOLカルチャーとVBの謎の親和性。

[tatsu_tora]

やはり皆さんも通る道なんですね。。。

[matsumoriayami]

エラーを握りつぶす！謎の力強さを感じる

[oakbow]

至極当たり前の話で肯定しかない（でも最初のORMとしてhibernate触ったときは不満の方が大きかったけど...）。

[lotasty]

これは思う。経験したからこそこだわりって出てくる。そのためにも経験の幅と量、深さ。

[nanoha3]

良いコードというか、最新のコードという感じ。