標準的なソフトウェア開発環境って？ 110
ストーリー by hylom
あなたの標準は私の非標準 部門より
あなたの標準は私の非標準 部門より
あるAnonymous Coward 曰く、
本家/.「Ask Slashdot: Standard Software Development Environments?」より。
自分はソフトウェア開発に携わってまだ5年であり、今までずっと同じ会社に務めてきた。最近転職したのだが、転職先の開発プロセスの技術の低さに驚いている。
今までの会社では継続的インテグレーション、単体テスト、オートメーション化された回帰テスト、業界標準の（オープンソースではない）バージョンコントロールが採用されていた。また自分もJavaのリリースなど最新のツールを身につけるよう努力していた。しかし現在の会社ではこれらは全て無く、コンパイルされたファイルはそのまま本番環境に手動で移され、バージョンコントロールはされていない。使用しているツールはもうサポートが切れて5～7年になる上、Java自体も古い。
このような開発環境はよく見受けられるようなものなのだろうか？最新技術に遅れないようにする環境の方が多いのか、それとも何とかやっていけるならそれで良いという方が多いのだろうか？現在の仕事は業界に入ってまだ2社目であるので皆さんの経験談をお聞かせ願えないだろうか。
前職の環境が整いすぎていたという見方や、タレコミ人は「幅広い」開発環境の端から端に身を置いたのだという意見、また「バージョンコントロール無し？継続テストなし？開発規律に欠けるやばい会社だ、逃げろ」といったアドバイスなど、本家/.には多くの意見や経験談が寄せられている。
/.J諸兄方がみてきた開発環境の「ピン」と「キリ」はどんなものだっただろうか？
むしろ (スコア:3)
むしろ品質報告とか進捗報告とかどうやってやっているのか知りたいです。
---- ばくさん！＠一応IT土方
Re:むしろ (スコア:3, 興味深い)
そりゃーKKDさねw
今俺は、LinuxカーネルのバリアントをSubversionで管理しているという奇妙なプロジェクトにいる。
本家がgit使ってるのにパッチ当てて追加されたファイルや削除されたファイルを手動でリポジトリへ反映とか、複数ソースの変化を一つのブランチにごたまぜにしておいて後でログ見てチェリーピックとか(藁
当然チケットドリブン開発とかみたいな開発管理は一切やってない。
ユーザの要望も伝言ゲームで...このくらいにしておく
Re: (スコア:0)
あー・・・その会社のそのプロジェクトって・・・
他人事とは思えない
Re:むしろ (スコア:2)
そんな会社に仕事を出す会社がある事にびっくりですわ……。
客先でカスタマイズしたソースをそのまま自社に持ち帰って、他の客へ渡すマスターにデータごと複製してたMDISに多くの図書館が仕事を出してたわけで。
Re:むしろ (スコア:1)
品質報告とか進捗報告をまともに検証するには、発注する側にも相応の技術と体制が必要です。
・・・が、日本においては大企業であってもCIOを置いていない事は珍しくありません。能力が無いなら、第三者的な企業に進捗管理や品質管理を頼めば良いのですが、その手の事もしませんからね。
技術的な面ではいかようにでも嘘の付きようがあるのが現実です。
どんなモノが業界標準かは置いといて…… (スコア:2)
本家のタレコミ人が転職先を間違えたのは確かだと思う。
両方のパターンを経験したけど (スコア:2)
人間VCS (スコア:2)
5年くらい前だけど、面接でどうしてそんな質問したのか忘れたけど、バージョン管理どうやってるか聞いたら
専門の人が居てその人にファイル渡してバージョン管理するって若干恥ずかしそうに答えてくれた人が居た。
お金のある所は雇用が生まれていいですね。
正しいことをしたければ (スコア:1)
オールドタイプなプロジェクトリーダーに継続的インテグレーションだの、単体テストだの、オートメーション化された回帰テストだの、業界標準のバージョンコントロールだのを教え込むくらいなら、そういうの使いこなせるお前が開発リーダーになった方が100倍早い。
Re:正しいことをしたければ (スコア:2)
ただ、元ネタは本家なので、おそらく米国
その会社にいたままでプログラマがマネージャはおろか、プロマネやアーキテクトに昇格する事は難しいと思う。ましてや、プログラマの分際で開発プロセスを改革するのも難しいかと。
効率が悪い、品質が悪い、会社に勤めていたという負の実績が積み上がる前に、さっさと再転職すべき
Re: (スコア:0)
Re: (スコア:0)
転職したのがヘッドハントなら投稿者の培ってきた物を導入したいってことだと思うんだ。
そうでなく給与に引かれて転職したのであれば人生の罠にはまったとか下り坂の運をひろったって事だろう。
#良くあることだと思うんだがなぁ
あきらめろ (スコア:1)
今までの会社では継続的インテグレーション、単体テスト、オートメーション化された回帰テスト、業界標準の（オープンソースではない）バージョンコントロールが採用されていた。また自分もJavaのリリースなど最新のツールを身につけるよう努力していた。しかし現在の会社ではこれらは全て無く、コンパイルされたファイルはそのまま本番環境に手動で移され、バージョンコントロールはされていない。使用しているツールはもうサポートが切れて5～7年になる上、Java自体も古い。
「俺のいた環境に合わせて、転職先の環境を変えたい」なんて要望はまず通らない。
何が「ピン」で、何が「キリ」か、なんて、環境依存（その企業の生い立ち依存）だし。
いままで、社内がsvnで管理していたところに居たので、それにあわせてログとバージョン管理をとっていたなら、
以下の状況に合わせて、転職先の状況に合わせられる人が勝ちじゃね？
1．転職したら、RCSで管理していた。
2．転職したら、gitで管理していた。
3.転職したら、バージョン管理なんてしていなかた
ってときにシームレスで移行できたら勝ち組でしょ。
そして、そういうパッケージを提供できたらより勝ち組でしょ・
Re:あきらめろ (スコア:1)
そういう奴はね、ダメな会社ごと沈むんだよ。
こういう開発者って (スコア:1)
なんかめんどくさいな。
バージョン管理システムを導入していなかったり古いjdk使ってるだけで
その会社の技術レベルが低いとかなに言ってますのんって感じ。
マシンスペックに異様にこだわる無能プログラマに見えてしょうがない。
Re: (スコア:0)
動いているものが正であり、何かを変えるとその分の費用、時間、労力がかかるって事を良くわかっていない気はちょっとしますね。
クライアントの了承を取ったり、すべてテストし直しになったりするのだって嫌ですし。
Re:こういう開発者って (スコア:2)
＞クライアントの了承を取ったり、
これは馬鹿なクライアントが自分のクビを絞めているだけだから放置するとして、
＞動いているものが正であり、何かを変えるとその分の費用、時間、労力がかかるって事を
だからといって事態が悪化するのを手をこまねいてみているのは、愚かなマネージャーだけが
することですよ。そんな風にレガシー化するに任せて、みずほ銀行みたいなトラブルを起こしたいですか？
あなたが何も変えなくても、周りでは技術は進歩するし開発効率もあがるのです。
あなたの生産性が昔と同じということは、ライバル企業に開発効率や品質で差を付け
られるということですよ。さらにあまりに古すぎる場合は、製品販売も中止されるしサポートも
打ち切られるし、解説書も手に入らなくなるしその技術を使う人間もいなくなります。
「それでもあなたはCOBOLを使い続けますか？」な感じですね。そんなにCOBOLと心中
したければあなた一人で死んで下さい。私だったらあなたのような人に足を引っ張られて、
巻き添えを食うのは御免被ります。
Re:こういう開発者って (スコア:1)
そう、大声で自分の無能を叫ばなくてもわかりますよ。
ストーリー内の文言はちょっと曖昧なので、要点は以下。
オートメーション化されたテスト
バージョンコントロール
以上によって実現される継続的インテグレーション
結果から言うと、以上のものがない状態から比べれば、開発に関するコストが思いっきり違います。
桁が違うと言いたいけど、1/5ぐらいにはなるかな。
理由は、バージョンコントロールを手作業でやると累積的に作業（工数）が膨れ上がる事
テストが自動化されていればテストを実行するコストが非常に小さく、またテストを実行する回数が桁違いとなり、
問題の発覚、対策のスピードが加速度的にアップする事。
で、開発に関するコストが大幅に小さくなると、スケジュール、要員的に余裕ができ、品質向上などにまわす事ができ、
よりよいサイクルで開発が回ると。
ああ、そんな現場見たことないというのはそうでしょうね。
こういうサイクルで物をつくれる人たちは旧世代の人売り業界とは縁が切れるので、
従来の現場から姿が消えたように見えると思います。
Re:こういう開発者って (スコア:1)
元コメの#2033550へ。
バージョン管理システムがないのは, 技術レベルが低いというには十分だ。
Re: (スコア:0)
世の中、それでちゃんとお金もらってるところもあるから・・・
うちはもらえてないけどね！
#1次受けメインだけど某大手から下請で仕事もらうとギャップに苦しむ。
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:こういう開発者って (スコア:1)
めんどくさいって、なんか美徳だったっけ？
いや、プログラマの美徳ではあるんだけど。なんか違うぞ。
#存在自体がホラー
Re:こういう開発者って (スコア:1)
なんとかやっていってるものを普通にやっていけるようにするのがVCSですよ。
# yes, fly. no, fry.
Re: (スコア:0)
>修正前は～.java.20111012.bakの形式でコピー。
で、まあそういうしきたりに起因するコストをどう考えるかという事で。
リリースで何かしら問題が起きたときに、バージョン管理のミスを考慮に入れなきゃいかんのと、ある程度切り離せる（もしくは追跡できる）のは
大きい。ある程度経験を積むと非常にありがたく思えるようになる。大体、そういうヒューマンエラーでギスギスするのっていやだし。
めんどくさいって、SVNのサーバ立てるのって15分もいらんよ。
立てられない事情がある場合もあるというのは分かるけど、それがまあ構造的な病巣ってやつで。
Re: (スコア:0)
でも一人で複数ファイルを編集することはあるよね。
機能ほにゃららを実装したときに変更したファイルはどれとどれだったかな〜ってときに日付でしか管理してなかったら即破綻するんじゃね、それ。
答え：複数ファイルを編集することもない。全部main()に書いてある。
Re:こういう開発者って (スコア:1)
一般的には、バージョン管理と連動した、自動ビルドシステムみたいなものがあって、最終納品物になるようなものは全部、それを経由してビルドするという形が好ましいとされていますよね？？？
個人の環境でしかビルドできないものは、後々、同じものをビルドしようとしてもビルドできないことがあるわけで、それは、出荷後のメンテナンスやなんやかんやにいろいろと問題を起こす原因となってしまいます。
従って、再現性のあるビルド環境を用いてビルドするというのは、品質管理という意味でも重要ですし、それゆえにビルドシステムは、バージョン管理システムとは切って考える事が出来ないです。
Re: (スコア:0)
確かにバージョン管理システムを導入していないとかはどうかと思うが
使っているＯＳやフレームワーク、ここではＪＤＫが古いことに理由があるのではないだろうか
組み込み業界では、実績のあるOSやチップを選択するのが最良のことがあるし
インデント開発なら動作環境を変えるなんて普通しないよね
結局表面だけじゃなく、どういう理由でその開発環境になっているのか次第じゃなかろうか
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:こういう開発者って (スコア:1)
属人性を回避しようとするとそういうツールの導入をすることになるだろうから、話がずれてるってことでもないでしょう。
「誰が」「どんな方法で」「必ず」といった言葉は、難癖付けてるだけのように受け取れます。
LIVE-GON(リベゴン)
推して知るべし (スコア:1)
何をもって標準とするか・・・ (スコア:0)
バイナリエディタとか・・・
標準環境 (スコア:0)
１台のPCと充分なハードディスク容量
エディタとビルドに必要なコマンドラインツール
実行（テスト）環境
ビジュアルデバッガとか有れば小躍りして喜べ！
Re:標準環境 (スコア:1)
今いるところ
ブラウザ：IE6以外をたとえサブでも導入する権利はありません、IEは早く死んでください。
エディタ：秀丸以外を選択する権利はありません、慣れてないと使い辛いです。
統合開発環境：どこかの会社がEclipseを改悪したツールしか選択する権利はありません、アホ重いです。
ネット：使えません、たぶん発展途上国にいるのだと思われます。
HDD：40GBです、アホ重いツールでほぼ埋まっています。
ここは生産性を重視している職場だと説明を受けました。
七年ぐらい前にタイムスリップしている可能性が高いので、早く現代に帰りたいです。
ナイト・ビルド (スコア:0)
という言葉を初めて聞いた時は、ちょっとワクワクしたな。
Re:ナイト・ビルド (スコア:1)
LIVE-GON(リベゴン)
Re:規模によるものでは (スコア:2)
ええ、数日でおわるはずのプロジェクトだったんですよ。
それがあんなことになるとは…。
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
Re:規模によるものでは (スコア:1)
さらに後任者が過去の修正や変更を知る必要もなくて、それでも問題なく保守できると言うなら。