アカウント名:
パスワード:
・人件費の安い素人が適当に書いたコードを誰も理解できなくなった・低予算なのでコードを理解できるレベルの技術者がいなくなった・素人が適当に頑張ってますます誰も理解できなくなった・頑張って技術者を採用してみたが、納期の問題で当人が認めるクソース作られた
だいたいこんなとこ。予算は少々譲るが、最悪でも「素人」をプロジェクトに参加させるのやめてくれ。最近では絵画修復の話題もあるが、「素人が頑張りました」が最も始末が悪い。「誰でも最初は素人だ」「○○さんならできるのに君はできないのか」とか抜かす奴は×ね
数年たったら捨てると、最初から割り切っている世界じゃないかなあ。
代表的なのが PHPに代表される、動的Webサイトの業界。みんな作り捨て。チラシのDTPと一緒で、作った瞬間から古くなっていくと割り切ってる。
この手の話で問題になるのはだいたい社内システムだと思う。発端は使い捨てるつもりで書くんだけど軌道に乗ってしまうと「変える理由がない」で使い続けられ、いよいよヤバくなって改修しようと提案したら「売り上げに直結しないものに割ける予算はない」で。
あと使い捨てシステムの場合も、コアになる部分やDB周りはコピペして別システムで使われるってことも多くて、どういう原理で動いてるのか誰も分かる奴がいないとか冗談みたいな話もよくある。
発端は使い捨てるつもりで書くんだけど軌道に乗ってしまうと「変える理由がない」で使い続けられ、
いやいや。当時としては非常にマジメに作られたけど、今から見ると全然ダメなコードが、改善されず使い続けられる、なんてこともあるぞ。# ソースは弊社。
フレームワークも揃ってなかった時代の古いコードでもまともな奴が書いたコードは読みやすいのでメンテできるもんだぞ。最低限でもモジュールの入出力はしっかりしてるし見なきゃいけないスコープも短くなるように工夫されてる。
フレームワークのお陰で、「安く早く、簡易に作り捨て」できるようになったんじゃないかな。PHPなんてまさに。スクリプト言語やフレームワークが無ければ、高コストのままで、「IT化を諦めて未だ手作業のまま」という現場も多いような。
弊社じゃなくて自分だろ。つまらん見栄は不要。
従業員 1,2名の会社の社長かもよ
作り捨てなんで、そもそも「改修」という概念があってはいけないわな。スクラップ&ビルドしないと。データーさえエクスポートできる仕様になってればいい。
WEB屋って作ったもの1,2年もすると古い古い捨てて最新技術で作り直さなきゃって大騒ぎして営業かけてくるよね
それは「フレッシュ感の演出」なのでは。リアル店舗だってSKUは変わらないのに、2年ごとに棚の配置を大移動しているじゃないですか。
後々付けの仕様変更でソースがねじ曲がった。色んな理由で不便なライブラリに対応するため理解しづらいソースに変貌。とかも。普段の1日の作業時間が実質3時間なら書き換えも考えるけどね。
「技術的負債」の話をするとき、最初はリリース優先のコードでも仕方ないみたいに捉えられがちだけど、今回の話だと
多くのブロガーが負債のメタファーのことを、後できれいに書き直すつもりなら雑なコードを書いてもいいという考え方と混同し
そのソフトウェアに現時点での理解を可能な限り反映させることが重要です
むしろコードを書くときには常にそのときのベストを尽くせと言っています
だから、リリース優先の汚いコードでも仕方ないなんて言ってないって事だよね…。最初から出来得る限りのベストを尽くしたうえで、どうしても生産性が落ちてくるのが負債?「リリース優先の技術的負債」って考え方はそもそも誤解でNGなのか。
綺麗、汚い以前にまともに動かなかったり、リリースが遅れたりして、日の目を見ないコードの方が圧倒的に多いよ。むしろ、ビジネス的にうまくいったから、コードの汚さが問題になるんだけどね。問題になって愚痴の対象になれたということは、ある意味では成功とも言えるんだよ。
最近では絵画修復の話題もあるが、「素人が頑張りました」が最も始末が悪い。
最近の話題ならとあるOSSじゃないの。誠心誠意善意で作られたものと鼻歌まじりに適当に作られたもの、どっちが素晴らしいかといえば、どうしたって結果が全てだよなぁ。
発端は善意かもしれないが、派遣会社でかき集めた糞も味噌も一緒くたのチームに開発させた時点で悪意が混入しただろ笑
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
むしろ「安物買いの銭失い」 (スコア:2, 興味深い)
・人件費の安い素人が適当に書いたコードを誰も理解できなくなった
・低予算なのでコードを理解できるレベルの技術者がいなくなった
・素人が適当に頑張ってますます誰も理解できなくなった
・頑張って技術者を採用してみたが、納期の問題で当人が認めるクソース作られた
だいたいこんなとこ。
予算は少々譲るが、最悪でも「素人」をプロジェクトに参加させるのやめてくれ。
最近では絵画修復の話題もあるが、「素人が頑張りました」が最も始末が悪い。
「誰でも最初は素人だ」「○○さんならできるのに君はできないのか」とか抜かす奴は×ね
Re: (スコア:0)
数年たったら捨てると、最初から割り切っている世界じゃないかなあ。
代表的なのが PHPに代表される、動的Webサイトの業界。みんな作り捨て。
チラシのDTPと一緒で、作った瞬間から古くなっていくと割り切ってる。
Re:むしろ「安物買いの銭失い」 (スコア:3, 参考になる)
この手の話で問題になるのはだいたい社内システムだと思う。
発端は使い捨てるつもりで書くんだけど軌道に乗ってしまうと「変える理由がない」で使い続けられ、
いよいよヤバくなって改修しようと提案したら「売り上げに直結しないものに割ける予算はない」で。
あと使い捨てシステムの場合も、コアになる部分やDB周りはコピペして別システムで
使われるってことも多くて、どういう原理で動いてるのか誰も分かる奴がいないとか
冗談みたいな話もよくある。
Re:むしろ「安物買いの銭失い」 (スコア:1)
発端は使い捨てるつもりで書くんだけど軌道に乗ってしまうと「変える理由がない」で使い続けられ、
いやいや。
当時としては非常にマジメに作られたけど、今から見ると全然ダメなコードが、改善されず使い続けられる、なんてこともあるぞ。
# ソースは弊社。
Re:むしろ「安物買いの銭失い」 (スコア:1)
フレームワークも揃ってなかった時代の古いコードでもまともな奴が書いたコードは読みやすいのでメンテできるもんだぞ。
最低限でもモジュールの入出力はしっかりしてるし見なきゃいけないスコープも短くなるように工夫されてる。
Re: (スコア:0)
フレームワークのお陰で、「安く早く、簡易に作り捨て」できるようになったんじゃないかな。
PHPなんてまさに。
スクリプト言語やフレームワークが無ければ、高コストのままで、「IT化を諦めて未だ手作業のまま」という現場も多いような。
Re: (スコア:0)
弊社じゃなくて自分だろ。つまらん見栄は不要。
Re: (スコア:0)
従業員 1,2名の会社の社長かもよ
Re: (スコア:0)
作り捨てなんで、そもそも「改修」という概念があってはいけないわな。スクラップ&ビルドしないと。
データーさえエクスポートできる仕様になってればいい。
Re: (スコア:0)
WEB屋って作ったもの1,2年もすると
古い古い捨てて最新技術で作り直さなきゃって
大騒ぎして営業かけてくるよね
Re: (スコア:0)
それは「フレッシュ感の演出」なのでは。
リアル店舗だってSKUは変わらないのに、2年ごとに棚の配置を大移動しているじゃないですか。
Re: (スコア:0)
後々付けの仕様変更でソースがねじ曲がった。
色んな理由で不便なライブラリに対応するため理解しづらいソースに変貌。
とかも。
普段の1日の作業時間が実質3時間なら書き換えも考えるけどね。
Re: (スコア:0)
「技術的負債」の話をするとき、最初はリリース優先のコードでも仕方ないみたいに捉えられがちだけど、今回の話だと
だから、リリース優先の汚いコードでも仕方ないなんて言ってないって事だよね…。
最初から出来得る限りのベストを尽くしたうえで、どうしても生産性が落ちてくるのが負債?
「リリース優先の技術的負債」って考え方はそもそも誤解でNGなのか。
Re: (スコア:0)
綺麗、汚い以前にまともに動かなかったり、リリースが遅れたりして、日の目を見ないコードの方が圧倒的に多いよ。
むしろ、ビジネス的にうまくいったから、コードの汚さが問題になるんだけどね。
問題になって愚痴の対象になれたということは、ある意味では成功とも言えるんだよ。
Re: (スコア:0)
最近では絵画修復の話題もあるが、「素人が頑張りました」が最も始末が悪い。
最近の話題ならとあるOSSじゃないの。
誠心誠意善意で作られたものと鼻歌まじりに適当に作られたもの、どっちが素晴らしいかといえば、どうしたって結果が全てだよなぁ。
Re: (スコア:0)
発端は善意かもしれないが、派遣会社でかき集めた糞も味噌も一緒くたのチームに開発させた時点で悪意が混入しただろ笑