アカウント名:
パスワード:
なんかめんどくさいな。バージョン管理システムを導入していなかったり古いjdk使ってるだけでその会社の技術レベルが低いとかなに言ってますのんって感じ。マシンスペックに異様にこだわる無能プログラマに見えてしょうがない。
動いているものが正であり、何かを変えるとその分の費用、時間、労力がかかるって事を良くわかっていない気はちょっとしますね。クライアントの了承を取ったり、すべてテストし直しになったりするのだって嫌ですし。
＞クライアントの了承を取ったり、これは馬鹿なクライアントが自分のクビを絞めているだけだから放置するとして、
＞動いているものが正であり、何かを変えるとその分の費用、時間、労力がかかるって事をだからといって事態が悪化するのを手をこまねいてみているのは、愚かなマネージャーだけがすることですよ。そんな風にレガシー化するに任せて、みずほ銀行みたいなトラブルを起こしたいですか？
あなたが何も変えなくても、周りでは技術は進歩するし開発効率もあがるのです。あなたの生産性が昔と同じということは、ライバル企業に開発効率や品質で差を付けられるということですよ。さらにあまりに古すぎる場合は、製品販売も中止されるしサポートも打ち切られるし、解説書も手に入らなくなるしその技術を使う人間もいなくなります。
「それでもあなたはCOBOLを使い続けますか？」な感じですね。そんなにCOBOLと心中したければあなた一人で死んで下さい。私だったらあなたのような人に足を引っ張られて、巻き添えを食うのは御免被ります。
> そんな風にレガシー化するに任せて、みずほ銀行みたいなトラブルを起こしたいですか？
ぶっちゃけ、みずほ銀行のトラブルの原因はJavaを持ち込んだせいなんですわ。素直に既存システムへ統合すれば良いのを、Java＆COBOLなんて訳の分からないステップ踏んだのが原因。はっきり言って動くシステムには手を加えるなってのを証明した良い例なんだよねw
この案件に参加要請をされたが、仕様を見てお引き取り願った。だってデスマ確定フラグが立っていたから。。何人か友人が参加したが、皆さん死相が出ていらっしゃいましたw一から作ればまた違った結果が出たとは思うけどね。
＞ 「
開発者＆仕様を書く奴の絶対能力に依存する体制に問題があるとは思わない？それって精神論をふりかざしてるだけに見えるなあ。それと、何もしなかった立場で、俺ならこうすると吠えてるだけに見えるなあ。
動くシステムには手を加えるなと言っても、なんだかんだで手を加える必要が出てくるわけで。でないと私らおまんまの食い上げですがな。
どうせ手を加えなきゃならないなら、できるだけ安全にしたいよね。
いや本当に痛い開発者はすぐに開発現場から退場してもらいたいですわ。
すいませんが、みずほ銀行のどのトラブルがどれくらいレガシーな体制の責任だったか解説してはもらえんでしょうか。そして例えばストーリーにある「継続的インテグレーション、単体テスト、オートメーション化された回帰テスト、業界標準の（オープンソースではない）バージョンコントロール」を採用すると、どれくらいソレが解消されるであろうか教えてもらえないでしょうか。
そう、大声で自分の無能を叫ばなくてもわかりますよ。ストーリー内の文言はちょっと曖昧なので、要点は以下。
オートメーション化されたテストバージョンコントロール以上によって実現される継続的インテグレーション
結果から言うと、以上のものがない状態から比べれば、開発に関するコストが思いっきり違います。桁が違うと言いたいけど、1/5ぐらいにはなるかな。理由は、バージョンコントロールを手作業でやると累積的に作業（工数）が膨れ上がる事テストが自動化されていればテストを実行するコストが非常に小さく、またテストを実行する回数が桁違いとなり、問題の発覚、対策のスピードが加速度的にアップする事。で、開発に関するコストが大幅に小さくなると、スケジュール、要員的に余裕ができ、品質向上などにまわす事ができ、よりよいサイクルで開発が回ると。
ああ、そんな現場見たことないというのはそうでしょうね。こういうサイクルで物をつくれる人たちは旧世代の人売り業界とは縁が切れるので、従来の現場から姿が消えたように見えると思います。
>こういうサイクルで物をつくれる人たちは旧世代の人売り業界とは縁が切れるので、
人売りの最底辺ではこのあたりの自動化は楽とかなんとかじゃなくて健康に関わりますね。今の最底辺は、異常に納期短いんで。
元コメは恵まれた労働環境にいると思われ。
いや、でかいプロジェクトじゃない、かつレガシーなものだと思えますよね。それに費用や労力を積み上げるのは状況によりけりです。
変えるとしても新規に近いプロジェクトからです。そこでもろもろの学習してから水平展開させていけばいいんです。
同意。「技術レベルが低い」というのは「ない技術が多い」ということ。実際バージョン管理の技術・技能・ノウハウが無い。#言ってるうちにトートロジーで混乱してくる
世の中、それでちゃんとお金もらってるところもあるから・・・
うちはもらえてないけどね！#1次受けメインだけど某大手から下請で仕事もらうとギャップに苦しむ。
>動いているものが正であり、何かを変えるとその分の費用、時間、労力がかかる
>継続的インテグレーション、単体テスト、オートメーション化された回帰テストの意味はわかる？費用、時間、労力がかかる事自体が低レベルだという事。えっ？品質保証するためのコスト高すぎっ？ってやつ。
jdkのバージョンはいいとして、バージョン管理システムの有無は非常に重要なファクター。ソフトウェア開発（主に製造）のプロセス上のいろいろなしきたりはバージョン管理(リリース）を手動で管理する事に起因することが多かったし、その結果、非常に非効率的だった。バージョン管理システムそのものも、運用も十分こなれてきているのに、導入されていないのは何かしらの構造的な病巣があると言い切っていい。まあ、そういう実例も知ってるんだけどね。
jdkのバージョンはいいとして、
いやいやJDKのバージョンも一概にいいとは片付けられないですよ。 いまどきこんな古いJDK使ってんの！？という会話がされるのはほぼ間違いなく1.4以前の場合です。 しかも酷いところは新規プロジェクトだったりします（Twitterのプログラマーの愚痴調べ）。
5.0での変更が大きかったので付いてこれなかったわけですが、じゃあ5.0が出たのはいつよ？というと2004年、もう7年も前になります。 この7年の間に、5で追加されたアノテーションや総称型といった機能は広く使われるようになりました。 Javaプログラムの生産性は制限の多かった時代から大きく改善しています。
・・・が、7年もかけて、それらの進化に全く追随できなかったわけです。 ついでに言うなら、とっくにサポート期間は終わっています（有償サポートはあるが）。 昔の携帯や組み込み系のように特定のバージョンしか使えない、というのなら仕方ないですが、そうでないならその会社の技術レベルは低いと言われて当然でしょう。
うちはバージョン管理システムを導しない理由はただめんどくさいからですね。複数人で同一ファイルを編集することはまずないので、皆さん勝手にsshでアクセスしてvimかemacsで編集してね！って感じです。バージョン管理といっていいのかは怪しいですが、修正前は～.java.20111012.bakの形式でコピー。これでなんとかやっていけてます。
うちはバージョン管理システムを導した理由はただめんどくさいからですね。
うちがバージョン管理システムを導入しない理由はただめんどくさいいからですね。
........orz
ありえねー！一人開発だってVCSは必須だろー。コピーを手動で管理する方がずーっとめんどくさいぞ？VCSってのはそれを簡単確実便利にやってくれるツールなんだから。
全く同感。一人で開発していても、以下のようなことは絶対に起こる。
変更したファイルは全部バックアップを取ったと思ったけど、実は漏れがあった。どこを修正したか忘れた。差分はどうなっているか覚えてない。ついうっかり最新ファイルを／バックアップを／両方とも消してしまった。PCを変更する時にどれをコピーすればいいか良く分からない。コピーしたけど漏れがあるんじゃないかと怖くなる。
そういうのを見るたびに、「バージョン管理くらい使えば良いのに」と思って見てます。
vcs？cvsのことですかね？コピー手動がめんどくさければシェルスクリプト書けばいいかなって思っているもので・・・
一般名称としての Version Control System [wikipedia.org] (参考: 英語版 [wikipedia.org]) のことでしょう。対する Concurrent Versions System [wikipedia.org] は、固有名詞。
だいぶ長いこと、ネットで使える VCS は CVS だけだったような気がする。Subversion [apache.org] が出てから、慣れたと思ったら、Bazaar [canonical.com] が出て来て、あっというまに分散型 VCS 全盛になってしまった。 （出て来た順番は個人差があると思うが）
今使ってるのは bazaar ですが、開発ツリーのトップで bzr init . するだけなので、簡単ですよ。
＃おまけを書いてるうちに「既出」になってしまったぜ。おまけに免じて許してくれ。
Version Control System を知らんのなら、とにかく使ってみるべし。私も初めて使いだしたときは、概念にもコマンドにも馴染んでなくて漠然と不安感を持っていたから、おっくうがるのは理解できます。 Subversion入門本読むとVCSの一般論から解説してるので、シェルスクリプトでコピーするよりずっと魅力的であることがわかりますよ（ウェブ上のボランティア解説よりも、書籍のほうが一般的な話から始まっててわかりやすい）。
Version Control Systemじゃないのか?
VersionControlSystemのこと。総称。シェルスクリプトなんて書く必要ないじゃん。そこにツールがあるんだから。
バージョン管理本来の目的とはそれるかもしれませんが、ソース本文以外で変更履歴などのコメントを確実に時系列に記録する目的で使ってます。自堕落で自分に甘いので、ソースコメントは端折ったり、日付変更日付加えなかったり変更理由すら記録しなかったり。当然仕様書の差分も書かないので、バージョン管理からのコメントが初版仕様書からの変更分として運用しています。ちゃんと、”変更”とか”改訂”だとかの短いコメントもrejectしてます。どれだけ自分を信用していないんだ・・・
そんなもんは規模によるんだよ。ワンライナーをVCSにつっこまねーだろ？数行のスクリプトを管理したいと思うかどうかはそれの使い方次第。要らねえ時は要らねえ＞VCS
じゃあ複数人で数行のスクリプトの集合体をメンテしてると。なんて無駄の多い開発なんだ。
めんどくさいって、なんか美徳だったっけ？いや、プログラマの美徳ではあるんだけど。なんか違うぞ。
繰り返しを面倒くさがる故に設備投資に全力を傾けるひょうきんさがプログラマの美徳であるならば、設備投資のため新しいことに頭を使おうとするのから逃げるのは、美徳の逆を行っていますね。そもそもVCのため多大なる努力が既に投入されているのに、それすら無視している…。
>修正前は～.java.20111012.bakの形式でコピー。で、まあそういうしきたりに起因するコストをどう考えるかという事で。リリースで何かしら問題が起きたときに、バージョン管理のミスを考慮に入れなきゃいかんのと、ある程度切り離せる（もしくは追跡できる）のは大きい。ある程度経験を積むと非常にありがたく思えるようになる。大体、そういうヒューマンエラーでギスギスするのっていやだし。めんどくさいって、SVNのサーバ立てるのって15分もいらんよ。立てられない事情がある場合もあるというのは分かるけど、それがまあ構造的な病巣ってやつで。
いやー、フルボッコってこういうのをいうんだな。
せめてRCSくらい使おうよと同僚の女の子にman coを見せたら引かれた覚えがある
見せたら？見せて、の間違いだろ。
タレコミ文には
>コンパイルされたファイルはそのまま本番環境に手動で移され、バージョンコントロールはされていない。
と書いてあるから、ClickOnceみたいなものが導入されてないって話だと思ったけど。バージョン管理とバージョンコントロールって同義なの？
確かにバージョン管理システムを導入していないとかはどうかと思うが使っているＯＳやフレームワーク、ここではＪＤＫが古いことに理由があるのではないだろうか組み込み業界では、実績のあるOSやチップを選択するのが最良のことがあるしインデント開発なら動作環境を変えるなんて普通しないよね
結局表面だけじゃなく、どういう理由でその開発環境になっているのか次第じゃなかろうか
いや、さすがにバージョン管理できていないのはどうかと思うが。
ふるぼっこされてるのでまとめて返信を・・・※svnとcvsしかまともに使ったことないです
機能が追加された項目見たければdiffでいいし（普通コメントにも書くと思うので）、svn立てるのは簡単だけど、クライアントPC別にローカルサーバー立てるなんてめんどくさいことしたくないし、svnに大きなファイルをコミットされたらモバイル環境から接続したときにチェックアウトに時間がかかります。サーバー側でsvn使えばいいじゃんって話になりますが、そこまでやるなら直接ステージング環境をエディットしていけばいいと思いませんか？そうですよね。思いませんよね。
>答え：複数ファイルを編集することもない。全部main()に書いてある。これちょっと面白かった
> ※svnとcvsしかまともに使ったことないです
これらは、集中型 [wikipedia.org] ですからね。私も svn までは、小さなプロジェクトにまで使おうなんて思いませんでした。分散型ならサーバ立てる必要ないし、ていうかそのまま bzr+ssh でサーバになってるし、 bazaar の軽快さに触れたらもう後戻りできないです。
機能が追加された項目見たければdiffでいいし（普通コメントにも書くと思うので）
old を残しておいて diff -burN するよりも svn di の方が楽じゃないでしょうか。
クライアントPC別にローカルサーバー立てるなんてめんどくさいことしたくないし、
Subversion だとそうでしょうね。だったら CVS や Subversion のような中央リポジトリー型を採用せず、git や Mercurial などの分散リポジトリー型も検討してみるとか。
svnに大きなファイルをコミットされたらモバイル環境から接続したときにチェックアウトに時間がかかります。
基本一度きりですし、そこまで気にする必要はないように思いますけど。 Subversion なら取得してくるディレクトリーを下層にするなどの工夫も可能ですね。
サーバー側でsvn使えばいいじゃんって話になりますが、そこまでやるなら直接ステージング環境をエディットしていけばいいと思いませんか？
単純に、同じファイルを編集したい状況が発生する可能性があるだけで嫌ですね。 一人は VIM で、一人は Emacs で編集とか言ったら、エディター固有の排他制御も役に立ちませんし。
いや、モバイル環境も混在してるならなおさらVCSは必要じゃない？肉声コミュニケーションでのコンフリクト防止ができないわけでしょ？
分散型VCSをおすすめします。
などと、意味不明の供述をしており....
まあ、色々言われてるけど、最低のコストで顧客の満足が得られて品質に問題ないなら、仕事の形態としてはアリだと思う。VCS使っててもクソなソフトは書けるしね。
会社のコストに問題が発生しているし、システム開発において属人性が高すぎるのはリスクが高い。開発者に何か有った時、どーすんのさ。
スレッド全部読んでないけど、親のコメからコストに問題が発生してるとか、属人性が高すぎるとかは 読み取れなかったんだが。
属人性を回避しようとするとそういうツールの導入をすることになるだろうから、話がずれてるってことでもないでしょう。
誰がどんな方法でVCS使ってもその辺の問題が必ず解決するの？
「誰が」「どんな方法で」「必ず」といった言葉は、難癖付けてるだけのように受け取れます。
その一言が開発者のモチベーションと、開発効率を下げていることに気づくべきです。開発者がやりたことは開発であって、システムの管理をしたいわけじゃないんだよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
こういう開発者って (スコア:1)
なんかめんどくさいな。
バージョン管理システムを導入していなかったり古いjdk使ってるだけで
その会社の技術レベルが低いとかなに言ってますのんって感じ。
マシンスペックに異様にこだわる無能プログラマに見えてしょうがない。
Re: (スコア:0)
動いているものが正であり、何かを変えるとその分の費用、時間、労力がかかるって事を良くわかっていない気はちょっとしますね。
クライアントの了承を取ったり、すべてテストし直しになったりするのだって嫌ですし。
Re:こういう開発者って (スコア:2)
＞クライアントの了承を取ったり、
これは馬鹿なクライアントが自分のクビを絞めているだけだから放置するとして、
＞動いているものが正であり、何かを変えるとその分の費用、時間、労力がかかるって事を
だからといって事態が悪化するのを手をこまねいてみているのは、愚かなマネージャーだけが
することですよ。そんな風にレガシー化するに任せて、みずほ銀行みたいなトラブルを起こしたいですか？
あなたが何も変えなくても、周りでは技術は進歩するし開発効率もあがるのです。
あなたの生産性が昔と同じということは、ライバル企業に開発効率や品質で差を付け
られるということですよ。さらにあまりに古すぎる場合は、製品販売も中止されるしサポートも
打ち切られるし、解説書も手に入らなくなるしその技術を使う人間もいなくなります。
「それでもあなたはCOBOLを使い続けますか？」な感じですね。そんなにCOBOLと心中
したければあなた一人で死んで下さい。私だったらあなたのような人に足を引っ張られて、
巻き添えを食うのは御免被ります。
Re: (スコア:0)
> そんな風にレガシー化するに任せて、みずほ銀行みたいなトラブルを起こしたいですか？
ぶっちゃけ、みずほ銀行のトラブルの原因はJavaを持ち込んだせいなんですわ。
素直に既存システムへ統合すれば良いのを、Java＆COBOLなんて訳の分からないステップ踏んだのが原因。
はっきり言って動くシステムには手を加えるなってのを証明した良い例なんだよねw
この案件に参加要請をされたが、仕様を見てお引き取り願った。
だってデスマ確定フラグが立っていたから。。
何人か友人が参加したが、皆さん死相が出ていらっしゃいましたw
一から作ればまた違った結果が出たとは思うけどね。
＞ 「
Re: (スコア:0)
開発者＆仕様を書く奴の絶対能力に依存する体制に問題があるとは思わない？
それって精神論をふりかざしてるだけに見えるなあ。
それと、何もしなかった立場で、俺ならこうすると吠えてるだけに見えるなあ。
動くシステムには手を加えるなと言っても、なんだかんだで手を加える必要が出てくるわけで。
でないと私らおまんまの食い上げですがな。
どうせ手を加えなきゃならないなら、できるだけ安全にしたいよね。
いや本当に痛い開発者はすぐに開発現場から退場してもらいたいですわ。
Re: (スコア:0)
すいませんが、みずほ銀行のどのトラブルがどれくらいレガシーな体制の責任だったか解説してはもらえんでしょうか。
そして例えばストーリーにある「継続的インテグレーション、単体テスト、オートメーション化された回帰テスト、業界標準の（オープンソースではない）バージョンコントロール」を採用すると、どれくらいソレが解消されるであろうか教えてもらえないでしょうか。
Re:こういう開発者って (スコア:1)
そう、大声で自分の無能を叫ばなくてもわかりますよ。
ストーリー内の文言はちょっと曖昧なので、要点は以下。
オートメーション化されたテスト
バージョンコントロール
以上によって実現される継続的インテグレーション
結果から言うと、以上のものがない状態から比べれば、開発に関するコストが思いっきり違います。
桁が違うと言いたいけど、1/5ぐらいにはなるかな。
理由は、バージョンコントロールを手作業でやると累積的に作業（工数）が膨れ上がる事
テストが自動化されていればテストを実行するコストが非常に小さく、またテストを実行する回数が桁違いとなり、
問題の発覚、対策のスピードが加速度的にアップする事。
で、開発に関するコストが大幅に小さくなると、スケジュール、要員的に余裕ができ、品質向上などにまわす事ができ、
よりよいサイクルで開発が回ると。
ああ、そんな現場見たことないというのはそうでしょうね。
こういうサイクルで物をつくれる人たちは旧世代の人売り業界とは縁が切れるので、
従来の現場から姿が消えたように見えると思います。
Re: (スコア:0)
>こういうサイクルで物をつくれる人たちは旧世代の人売り業界とは縁が切れるので、
人売りの最底辺ではこのあたりの自動化は楽とかなんとかじゃなくて健康に関わりますね。
今の最底辺は、異常に納期短いんで。
元コメは恵まれた労働環境にいると思われ。
Re: (スコア:0)
いや、でかいプロジェクトじゃない、かつレガシーなものだと思えますよね。
それに費用や労力を積み上げるのは状況によりけりです。
変えるとしても新規に近いプロジェクトからです。そこでもろもろの学習してから水平展開させていけばいいんです。
Re:こういう開発者って (スコア:1)
元コメの#2033550へ。
バージョン管理システムがないのは, 技術レベルが低いというには十分だ。
Re: (スコア:0)
同意。
「技術レベルが低い」というのは「ない技術が多い」ということ。
実際バージョン管理の技術・技能・ノウハウが無い。
#言ってるうちにトートロジーで混乱してくる
Re: (スコア:0)
世の中、それでちゃんとお金もらってるところもあるから・・・
うちはもらえてないけどね！
#1次受けメインだけど某大手から下請で仕事もらうとギャップに苦しむ。
Re: (スコア:0)
>動いているものが正であり、何かを変えるとその分の費用、時間、労力がかかる
>継続的インテグレーション、単体テスト、オートメーション化された回帰テスト
の意味はわかる？
費用、時間、労力がかかる事自体が低レベルだという事。えっ？品質保証するためのコスト高すぎっ？ってやつ。
Re: (スコア:0)
jdkのバージョンはいいとして、バージョン管理システムの有無は非常に重要なファクター。
ソフトウェア開発（主に製造）のプロセス上のいろいろなしきたりはバージョン管理(リリース）を手動で管理する事に起因することが多かったし、
その結果、非常に非効率的だった。
バージョン管理システムそのものも、運用も十分こなれてきているのに、導入されていないのは何かしらの構造的な病巣があると言い切っていい。
まあ、そういう実例も知ってるんだけどね。
jdk5.0が出たのは7年も昔 (スコア:1)
jdkのバージョンはいいとして、
いやいやJDKのバージョンも一概にいいとは片付けられないですよ。
いまどきこんな古いJDK使ってんの！？という会話がされるのはほぼ間違いなく1.4以前の場合です。
しかも酷いところは新規プロジェクトだったりします（Twitterのプログラマーの愚痴調べ）。
5.0での変更が大きかったので付いてこれなかったわけですが、じゃあ5.0が出たのはいつよ？というと2004年、もう7年も前になります。
この7年の間に、5で追加されたアノテーションや総称型といった機能は広く使われるようになりました。
Javaプログラムの生産性は制限の多かった時代から大きく改善しています。
・・・が、7年もかけて、それらの進化に全く追随できなかったわけです。
ついでに言うなら、とっくにサポート期間は終わっています（有償サポートはあるが）。
昔の携帯や組み込み系のように特定のバージョンしか使えない、というのなら仕方ないですが、そうでないならその会社の技術レベルは低いと言われて当然でしょう。
Re: (スコア:0)
うちはバージョン管理システムを導しない理由はただめんどくさいからですね。
複数人で同一ファイルを編集することはまずないので、
皆さん勝手にsshでアクセスしてvimかemacsで編集してね！って感じです。
バージョン管理といっていいのかは怪しいですが、修正前は～.java.20111012.bakの形式でコピー。
これでなんとかやっていけてます。
Re:こういう開発者って (スコア:2)
うちはバージョン管理システムを導した理由はただめんどくさいからですね。
Re:こういう開発者って (スコア:1)
うちがバージョン管理システムを導入しない理由はただめんどくさいいからですね。
........orz
Re:こういう開発者って (スコア:1)
ありえねー！
一人開発だってVCSは必須だろー。
コピーを手動で管理する方がずーっとめんどくさいぞ？
VCSってのはそれを簡単確実便利にやってくれるツールなんだから。
Re:こういう開発者って (スコア:2)
全く同感。一人で開発していても、以下のようなことは絶対に起こる。
変更したファイルは全部バックアップを取ったと思ったけど、実は漏れがあった。
どこを修正したか忘れた。
差分はどうなっているか覚えてない。
ついうっかり最新ファイルを／バックアップを／両方とも消してしまった。
PCを変更する時にどれをコピーすればいいか良く分からない。
コピーしたけど漏れがあるんじゃないかと怖くなる。
そういうのを見るたびに、「バージョン管理くらい使えば良いのに」と思って見てます。
Re: (スコア:0)
vcs？cvsのことですかね？
コピー手動がめんどくさければシェルスクリプト書けばいいかなって思っているもので・・・
VCS vs. CVS (スコア:2)
一般名称としての Version Control System [wikipedia.org] (参考: 英語版 [wikipedia.org]) のことでしょう。
対する Concurrent Versions System [wikipedia.org] は、固有名詞。
だいぶ長いこと、ネットで使える VCS は CVS だけだったような気がする。Subversion [apache.org] が出てから、慣れたと思ったら、Bazaar [canonical.com] が出て来て、あっというまに分散型 VCS 全盛になってしまった。 （出て来た順番は個人差があると思うが）
今使ってるのは bazaar ですが、開発ツリーのトップで bzr init . するだけなので、簡単ですよ。
＃おまけを書いてるうちに「既出」になってしまったぜ。おまけに免じて許してくれ。
Re:こういう開発者って (スコア:2)
Version Control System を知らんのなら、とにかく使ってみるべし。
私も初めて使いだしたときは、概念にもコマンドにも馴染んでなくて漠然と不安感を持っていたから、おっくうがるのは理解できます。
Subversion入門本読むとVCSの一般論から解説してるので、シェルスクリプトでコピーするよりずっと魅力的であることがわかりますよ（ウェブ上のボランティア解説よりも、書籍のほうが一般的な話から始まっててわかりやすい）。
Re:こういう開発者って (スコア:1)
Version Control Systemじゃないのか?
Re:こういう開発者って (スコア:1)
VersionControlSystemのこと。総称。
シェルスクリプトなんて書く必要ないじゃん。そこにツールがあるんだから。
Re:こういう開発者って (スコア:1)
バージョン管理本来の目的とはそれるかもしれませんが、
ソース本文以外で変更履歴などのコメントを確実に時系列に記録する目的で使ってます。
自堕落で自分に甘いので、ソースコメントは端折ったり、日付変更日付加えなかったり変更理由すら記録しなかったり。
当然仕様書の差分も書かないので、バージョン管理からのコメントが初版仕様書からの変更分として運用しています。
ちゃんと、”変更”とか”改訂”だとかの短いコメントもrejectしてます。どれだけ自分を信用していないんだ・・・
Re: (スコア:0)
そんなもんは規模によるんだよ。
ワンライナーをVCSにつっこまねーだろ？
数行のスクリプトを管理したいと思うかどうかはそれの使い方次第。
要らねえ時は要らねえ＞VCS
Re: (スコア:0)
じゃあ複数人で数行のスクリプトの集合体をメンテしてると。
なんて無駄の多い開発なんだ。
Re:こういう開発者って (スコア:1)
めんどくさいって、なんか美徳だったっけ？
いや、プログラマの美徳ではあるんだけど。なんか違うぞ。
#存在自体がホラー
Re: (スコア:0)
繰り返しを面倒くさがる故に設備投資に全力を傾けるひょうきんさがプログラマの美徳であるならば、
設備投資のため新しいことに頭を使おうとするのから逃げるのは、美徳の逆を行っていますね。
そもそもVCのため多大なる努力が既に投入されているのに、それすら無視している…。
Re:こういう開発者って (スコア:1)
なんとかやっていってるものを普通にやっていけるようにするのがVCSですよ。
# yes, fly. no, fry.
Re: (スコア:0)
>修正前は～.java.20111012.bakの形式でコピー。
で、まあそういうしきたりに起因するコストをどう考えるかという事で。
リリースで何かしら問題が起きたときに、バージョン管理のミスを考慮に入れなきゃいかんのと、ある程度切り離せる（もしくは追跡できる）のは
大きい。ある程度経験を積むと非常にありがたく思えるようになる。大体、そういうヒューマンエラーでギスギスするのっていやだし。
めんどくさいって、SVNのサーバ立てるのって15分もいらんよ。
立てられない事情がある場合もあるというのは分かるけど、それがまあ構造的な病巣ってやつで。
Re: (スコア:0)
でも一人で複数ファイルを編集することはあるよね。
機能ほにゃららを実装したときに変更したファイルはどれとどれだったかな〜ってときに日付でしか管理してなかったら即破綻するんじゃね、それ。
答え：複数ファイルを編集することもない。全部main()に書いてある。
Re: (スコア:0)
いやー、フルボッコってこういうのをいうんだな。
Re: (スコア:0)
せめてRCSくらい使おうよ
と同僚の女の子にman coを見せたら引かれた覚えがある
Re: (スコア:0)
見せたら？
見せて、の間違いだろ。
Re: (スコア:0)
タレコミ文には
>コンパイルされたファイルはそのまま本番環境に手動で移され、バージョンコントロールはされていない。
と書いてあるから、ClickOnceみたいなものが導入されてないって話だと思ったけど。
バージョン管理とバージョンコントロールって同義なの？
Re:こういう開発者って (スコア:1)
一般的には、バージョン管理と連動した、自動ビルドシステムみたいなものがあって、最終納品物になるようなものは全部、それを経由してビルドするという形が好ましいとされていますよね？？？
個人の環境でしかビルドできないものは、後々、同じものをビルドしようとしてもビルドできないことがあるわけで、それは、出荷後のメンテナンスやなんやかんやにいろいろと問題を起こす原因となってしまいます。
従って、再現性のあるビルド環境を用いてビルドするというのは、品質管理という意味でも重要ですし、それゆえにビルドシステムは、バージョン管理システムとは切って考える事が出来ないです。
Re: (スコア:0)
確かにバージョン管理システムを導入していないとかはどうかと思うが
使っているＯＳやフレームワーク、ここではＪＤＫが古いことに理由があるのではないだろうか
組み込み業界では、実績のあるOSやチップを選択するのが最良のことがあるし
インデント開発なら動作環境を変えるなんて普通しないよね
結局表面だけじゃなく、どういう理由でその開発環境になっているのか次第じゃなかろうか
Re: (スコア:0)
いや、さすがにバージョン管理できていないのはどうかと思うが。
Re: (スコア:0)
ふるぼっこされてるのでまとめて返信を・・・
※svnとcvsしかまともに使ったことないです
機能が追加された項目見たければdiffでいいし（普通コメントにも書くと思うので）、svn立てるのは簡単だけど、
クライアントPC別にローカルサーバー立てるなんてめんどくさいことしたくないし、
svnに大きなファイルをコミットされたらモバイル環境から接続したときにチェックアウトに時間がかかります。
サーバー側でsvn使えばいいじゃんって話になりますが、そこまでやるなら直接ステージング環境をエディットしていけばいいと思いませんか？
そうですよね。思いませんよね。
>答え：複数ファイルを編集することもない。全部main()に書いてある。
これちょっと面白かった
Re:こういう開発者って (スコア:2)
> ※svnとcvsしかまともに使ったことないです
これらは、集中型 [wikipedia.org] ですからね。私も svn までは、小さなプロジェクトにまで使おうなんて思いませんでした。分散型ならサーバ立てる必要ないし、ていうかそのまま bzr+ssh でサーバになってるし、 bazaar の軽快さに触れたらもう後戻りできないです。
Re:こういう開発者って (スコア:1)
機能が追加された項目見たければdiffでいいし（普通コメントにも書くと思うので）
old を残しておいて diff -burN するよりも svn di の方が楽じゃないでしょうか。
クライアントPC別にローカルサーバー立てるなんてめんどくさいことしたくないし、
Subversion だとそうでしょうね。だったら CVS や Subversion のような中央リポジトリー型を採用せず、git や Mercurial などの分散リポジトリー型も検討してみるとか。
svnに大きなファイルをコミットされたらモバイル環境から接続したときにチェックアウトに時間がかかります。
基本一度きりですし、そこまで気にする必要はないように思いますけど。
Subversion なら取得してくるディレクトリーを下層にするなどの工夫も可能ですね。
サーバー側でsvn使えばいいじゃんって話になりますが、そこまでやるなら直接ステージング環境をエディットしていけばいいと思いませんか？
単純に、同じファイルを編集したい状況が発生する可能性があるだけで嫌ですね。
一人は VIM で、一人は Emacs で編集とか言ったら、エディター固有の排他制御も役に立ちませんし。
Re: (スコア:0)
いや、モバイル環境も混在してるならなおさらVCSは必要じゃない？
肉声コミュニケーションでのコンフリクト防止ができないわけでしょ？
Re: (スコア:0)
分散型VCSをおすすめします。
Re: (スコア:0)
などと、意味不明の供述をしており....
Re: (スコア:0)
まあ、色々言われてるけど、
最低のコストで顧客の満足が得られて品質に問題ないなら、仕事の形態としてはアリだと思う。
VCS使っててもクソなソフトは書けるしね。
Re: (スコア:0)
会社のコストに問題が発生しているし、システム開発において属人性が高すぎるのはリスクが高い。
開発者に何か有った時、どーすんのさ。
Re:こういう開発者って (スコア:1)
属人性を回避しようとするとそういうツールの導入をすることになるだろうから、話がずれてるってことでもないでしょう。
「誰が」「どんな方法で」「必ず」といった言葉は、難癖付けてるだけのように受け取れます。
LIVE-GON(リベゴン)
Re: (スコア:0)
その一言が開発者のモチベーションと、開発効率を下げていることに気づくべきです。
開発者がやりたことは開発であって、システムの管理をしたいわけじゃないんだよ。