アカウント名:
パスワード:
これでいいのか?何かを別環境にポーティングする作業なんかで、ビルドが通るようにするだけで何日もかかるなんてのはざらだが。
平行して行った別の作業や、帰宅しての生活時間、このへんを排除して記録できるのが一番だったんでしょうが、それが出来なかったんでしょうね。それに比較的短時間で終わる作業についての知見ってことではアリでしょう。
Javaの奴はこんなのばかりですね。ビルド環境作った人に何のライブラリ入れたか聞いても「分からない」「覚えてない」とかtry-with-resource文あるのにJava6でコンパイルすることになってたりとか。
Maven、Ivy、Gradleのどれでも良いけど、ライブラリ依存性解決ツール使わない人にビルド環境を作らせてはいけない。
最近までネット禁止だったらしいし、コボラーな世界だからかツールは悪みたいなとこです。
なんでここオーバーロード関数じゃないのって聞いたら、なにそれ?で切れられましたw
エラー範囲の規模を把握するために、ビルドを試し打ちしたりすることがあるね。
コンパイラにエラーや警告を吐き出させながらコーディングするスタイルの場合、とっても頻繁にビルドするし、エラーもでるし、出させる。
コンソールで作業している場合、パラメタを変えながらテスト→ビルド→テスト→ビルド→テスト→ビルド→テスト→ビルド→OKみたいなことを私はする。こういうときは、ビルド頻度はとても高くなるだろうけど、実はコンパイルしているのは一部だけだから、それぞれ1秒以内で終わっている。
コンソールで作業していない場合、もう少し丁寧にテスト用のUIを用意しないといけなくなるから、ビルドごとのコーディング実量が増えるし、そうなると一発でしあげようとするから、コンパイル回数は減る、
重要なのはビルドの回数ではなく、プログラマがコーディングする時間と、ビルドしている時間とその合計、、
そしてどっちがくたびれるかだ。ビルド時間が効率の良い休憩になっている場合もあるからね。
たしかに。最近はもうバックグラウンドで常にコンパイラやインタプリタが走っていて、エラーを逐次報告する環境もありますね。
書いてみてもらえませんか。なぜだめと思っているか興味あります
横レスですが、せっかくのエラーの重みをやたらに薄めて運用してると意味的エラーを構文で逃げるような字面指向プログラマになりますよ。
たいていキャストすれば文句言われない。void*キャスト最強。未初期化変数がどうとか言われたら0を入れとけば黙る。突き詰めればそういうベクトルです。
それはビルドエラーをなくすのを目的にして間違った方向に努力するのが駄目というだけの話で、「コンパイラにエラーや警告を吐き出させながらコーディングするスタイル」が良いか悪いかとは関係がないと思う。
論文はまだ読んでいないので、じつはこの二つに関係があるという話が書かれているなら失礼。
それは逆かなぁ。IDEの構文チェックに頼り過ぎると、構文チェックで検出できなかったエラーが、コンパイル時に一気に噴出するので、エラーを軽視しがちになる。
解析にかけられる時間の問題で、リアルタイムな構文チェックはコンパイラのエラー出力より正確性も厳密性も低い。一つのファイル内で完結する終端記号と括弧以外、あまり当てにしないほうがいい。
それは、ビルド回数を減らすことでどう解決するの?
「エラーありき」の姿勢が無くなれば、本来の重要なエラーが埋没しないでしょ。
この場合は最終的にエラーゼロを目指すもんでしょ。コンパイラを書式チェックに使っているようなもの。機械的なチェックで済ませられるようなものを人間が目でチェックするのはプログラマーの三大美徳に反する。一発で通すことを目指すあまり0代入が癖になったり、お約束としてエラー抑制を書き込んだりそっちの方がヤバい。
# エラーはみんなアウト。重要もクソもない。
家に帰ってから再び職場に行くまで12時間も空かないだろ?空かないよな?
論文をざっと見ると、対象がC++とJavaだけ?結果も、この二つに違いがあるような、ないような…微妙というしか…
他のコンパイラ言語の使用率がこれらに比べて極端に少ないからでしょ。
比較できないほど少ないとは思えないが…
Googleの環境だとコンパイラ系はほぼこの二つになるのでは?
Go...
make て入力するたびに、失敗確実ジャンってね
コマンドラインが返す、足りないパッケージ名と、実際のパッケージ名が違う事が少々あって、数日ハマる事が多いっす。そういうのに限って make uninstall が用意されてなかったりで、自分で make ファイルに追加したり、散々みたいな。
多分かみあってない
kate でエディットして make でビルド。ほこたて状態
Googleの開発者がIDE使わないのは生産効率の上でかなりの損失なのではないのかなあ
undeclared_var_use, undeclared_var_use_suggest, no_member なんていう打ち間違えみたいなのでエラーの四割を占めているから、IDEを使えば一気に減らせるとは思う。
補完 [llvm.org]も静的コード解析 [llvm.org]もコード整形 [llvm.org]もclangが提供しているので、テキストエディターでもIDEでも機能的に差はない。
それはギャグで言っているのか
優れたウィザードにとっては出来合いのツールに縛られるほうが効率落ちそう
「弘法は筆を選ばず」って考え方もあると思う。まぁ、箸にも棒にもかからないようなひどい筆は別にして、昨今の開発ツールはそれほどひどい筆であることは少ないですからね。どんなツールにでもあわせろとは言わないまでも、普通のツールなら何でも使いこなせるよ、という人のほうがスゴイと思う。
# 私の周囲で言えば、道具を選びに選び、俺様カスタマイズに時間を掛けるヤツは、言うほど凄いコードは書かない(ことが多い)。# そして、カリカリチューンして自分好みを追求するが故に、環境の変化に弱い(客先や現場に行かせると時間が掛かる)。# ま、エリートだけで構成されるgoogleのようなところとは事情が違うのかもしれませんが。
IDE使うとエラー時の解決にたどり着くまでの時間が増える
エラー数×解決までの時間でどっちが長いかの比較がほしいところ
IDEを使っていると、単純ミスでのエラーがIDEによってビルド以前に指摘されるので、ビルド後のエラー修正については、C++の場合より複雑な問題の比率が高くなる。よって、修正に掛かる時間の中央値が高くなる。という結果だと思う。
C++で使えるまともなIDEってあったっけ?念のため言っておくとGoogleの開発者はWindowsアプリの開発だけしていればいいわけではないからな。
つ QtCreator
emacs とか vim とか、いくらでもあるけど?
ねぇねぇ、他には他には?
geditでも使ってろ!!
#悪くはないよ実際。
JetBrainsがC++のIDE作ってるからしばらく待て
マジ?
GNU cgicc$ touch doc/html/index.html↑ソースツリーのトップでこれを実行しないと make all が通らないというパターンがあった
#ビルド違い
敵が空気を読まずに攻撃してきた。
https://www.youtube.com/watch?v=cqfl-QRYJSU [youtube.com]あのモニターの位置って絶対狙ってるよね。
不慮の事故で括弧が合わなくなったときのエラーメッセージの意味不明さが厄介。エラー行も適当だし、メッセージも的外れなのが多い。VSのIDEってなんか追跡遅かったりしばらく前のやつが表示され続けたりするから補完以外は信用できないし。
と、リンクされた論文も読まずにバカが言う
暇ですなぁ。
ビルドエラーの話をバグ全般にまで発散させて「クソもミソも一緒くた」にしたらそりゃあ大抵のことは意味を失ってクソレベルの話にしかならないでしょう。
出るエラー(のリファレンスに載ってる一般的な発生原因)とそのエラーが出た本当の原因は違うことが多い気はする
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
解決までに12時間以上かかったビルドは除外している? (スコア:1)
これでいいのか?
何かを別環境にポーティングする作業なんかで、ビルドが通るようにするだけで何日もかかるなんてのはざらだが。
Re: (スコア:0)
平行して行った別の作業や、帰宅しての生活時間、このへんを排除して記録できるのが一番だったんでしょうが、それが出来なかったんでしょうね。
それに比較的短時間で終わる作業についての知見ってことではアリでしょう。
Re: (スコア:0)
Javaの奴はこんなのばかりですね。
ビルド環境作った人に何のライブラリ入れたか聞いても「分からない」「覚えてない」とか
try-with-resource文あるのにJava6でコンパイルすることになってたりとか。
Re: (スコア:0)
Maven、Ivy、Gradleのどれでも良いけど、ライブラリ依存性解決ツール使わない人にビルド環境を作らせてはいけない。
Re: (スコア:0)
最近までネット禁止だったらしいし、コボラーな世界だからかツールは悪みたいなとこです。
なんでここオーバーロード関数じゃないのって聞いたら、なにそれ?で切れられましたw
Re: (スコア:0)
エラー範囲の規模を把握するために、ビルドを試し打ちしたりすることがあるね。
ビルド失敗回数って意味あるのかな (スコア:1)
コンパイラにエラーや警告を吐き出させながらコーディングするスタイルの場合、
とっても頻繁にビルドするし、エラーもでるし、出させる。
コンソールで作業している場合、パラメタを変えながら
テスト→ビルド→テスト→ビルド→テスト→ビルド→テスト→ビルド→OK
みたいなことを私はする。こういうときは、ビルド頻度はとても高く
なるだろうけど、実はコンパイルしているのは一部だけだから、
それぞれ1秒以内で終わっている。
コンソールで作業していない場合、もう少し丁寧にテスト用のUIを用意しないといけ
なくなるから、ビルドごとのコーディング実量が増えるし、そうなると一発でしあげようと
するから、コンパイル回数は減る、
重要なのはビルドの回数ではなく、プログラマがコーディングする時間と、ビルドしている時間と
その合計、、
そしてどっちがくたびれるかだ。ビルド時間が効率の良い休憩になっている場合もあるからね。
Re:ビルド失敗回数って意味あるのかな (スコア:1)
たしかに。最近はもうバックグラウンドで常にコンパイラやインタプリタが走っていて、エラーを逐次報告する環境もありますね。
Re: (スコア:0)
書いてみてもらえませんか。
なぜだめと思っているか興味あります
Re:ビルド失敗回数って意味あるのかな (スコア:1)
横レスですが、せっかくのエラーの重みをやたらに薄めて運用してると
意味的エラーを構文で逃げるような字面指向プログラマになりますよ。
たいていキャストすれば文句言われない。void*キャスト最強。
未初期化変数がどうとか言われたら0を入れとけば黙る。
突き詰めればそういうベクトルです。
Re:ビルド失敗回数って意味あるのかな (スコア:2)
それはビルドエラーをなくすのを目的にして間違った方向に努力するのが駄目というだけの話で、「コンパイラにエラーや警告を吐き出させながらコーディングするスタイル」が良いか悪いかとは関係がないと思う。
論文はまだ読んでいないので、じつはこの二つに関係があるという話が書かれているなら失礼。
Re:ビルド失敗回数って意味あるのかな (スコア:1)
それは逆かなぁ。IDEの構文チェックに頼り過ぎると、
構文チェックで検出できなかったエラーが、コンパイル時に一気に噴出するので、エラーを軽視しがちになる。
解析にかけられる時間の問題で、リアルタイムな構文チェックはコンパイラのエラー出力より正確性も厳密性も低い。
一つのファイル内で完結する終端記号と括弧以外、あまり当てにしないほうがいい。
Re: (スコア:0)
それは、ビルド回数を減らすことでどう解決するの?
Re: (スコア:0)
「エラーありき」の姿勢が無くなれば、本来の重要なエラーが埋没しないでしょ。
Re:ビルド失敗回数って意味あるのかな (スコア:1)
この場合は最終的にエラーゼロを目指すもんでしょ。コンパイラを書式チェックに使っているようなもの。
機械的なチェックで済ませられるようなものを人間が目でチェックするのはプログラマーの三大美徳に反する。
一発で通すことを目指すあまり0代入が癖になったり、お約束としてエラー抑制を書き込んだりそっちの方がヤバい。
# エラーはみんなアウト。重要もクソもない。
一発完動教を思い出しました (スコア:1)
除外する項目がおかしい (スコア:1)
家に帰ってから再び職場に行くまで12時間も空かないだろ?空かないよな?
C++とJavaだけ? (スコア:0)
論文をざっと見ると、対象がC++とJavaだけ?
結果も、この二つに違いがあるような、ないような…微妙というしか…
Re: (スコア:0)
他のコンパイラ言語の使用率がこれらに比べて極端に少ないからでしょ。
Re:C++とJavaだけ? (スコア:1)
比較できないほど少ないとは思えないが…
Re: (スコア:0)
Googleの環境だとコンパイラ系はほぼこの二つになるのでは?
Re: (スコア:0)
Go...
だいたいコマンドが負けはないよな (スコア:0)
make て入力するたびに、失敗確実ジャンってね
Re: (スコア:0)
コマンドラインが返す、足りないパッケージ名と、実際のパッケージ名が違う事が少々あって、数日ハマる事が多いっす。
そういうのに限って make uninstall が用意されてなかったりで、自分で make ファイルに追加したり、散々みたいな。
Re: (スコア:0)
多分かみあってない
Re: (スコア:0)
kate でエディットして make でビルド。ほこたて状態
IDE使って下さい (スコア:0)
Googleの開発者がIDE使わないのは生産効率の上でかなりの損失なのではないのかなあ
Re:IDE使って下さい (スコア:2)
undeclared_var_use, undeclared_var_use_suggest, no_member なんていう打ち間違えみたいなのでエラーの四割を占めているから、IDEを使えば一気に減らせるとは思う。
Re:IDE使って下さい (スコア:1)
補完 [llvm.org]も静的コード解析 [llvm.org]もコード整形 [llvm.org]もclangが提供しているので、テキストエディターでもIDEでも機能的に差はない。
Re: (スコア:0)
Re: (スコア:0)
それはギャグで言っているのか
Re: (スコア:0)
優れたウィザードにとっては
出来合いのツールに縛られるほうが効率落ちそう
Re: (スコア:0)
「弘法は筆を選ばず」って考え方もあると思う。
まぁ、箸にも棒にもかからないようなひどい筆は別にして、昨今の開発ツールはそれほどひどい筆であることは少ないですからね。
どんなツールにでもあわせろとは言わないまでも、普通のツールなら何でも使いこなせるよ、という人のほうがスゴイと思う。
# 私の周囲で言えば、道具を選びに選び、俺様カスタマイズに時間を掛けるヤツは、言うほど凄いコードは書かない(ことが多い)。
# そして、カリカリチューンして自分好みを追求するが故に、環境の変化に弱い(客先や現場に行かせると時間が掛かる)。
# ま、エリートだけで構成されるgoogleのようなところとは事情が違うのかもしれませんが。
Re: (スコア:0)
IDE使うとエラー時の解決にたどり着くまでの時間が増える
エラー数×解決までの時間でどっちが長いかの比較がほしいところ
Re:IDE使って下さい (スコア:1)
IDEを使っていると、単純ミスでのエラーがIDEによってビルド以前に指摘されるので、
ビルド後のエラー修正については、C++の場合より複雑な問題の比率が高くなる。
よって、修正に掛かる時間の中央値が高くなる。
という結果だと思う。
Re: (スコア:0)
C++で使えるまともなIDEってあったっけ?
念のため言っておくとGoogleの開発者はWindowsアプリの開発だけしていればいいわけではないからな。
Re: (スコア:0)
つ QtCreator
Re: (スコア:0)
emacs とか vim とか、いくらでもあるけど?
Re: (スコア:0)
ねぇねぇ、他には他には?
Re:IDE使って下さい (スコア:1)
geditでも使ってろ!!
#悪くはないよ実際。
Re: (スコア:0)
JetBrainsがC++のIDE作ってるからしばらく待て
Re: (スコア:0)
マジ?
こんなケースもある (スコア:0)
GNU cgicc
$ touch doc/html/index.html
↑ソースツリーのトップでこれを実行しないと make all が通らないというパターンがあった
そりゃあ手抜きのせいでしょう (スコア:0)
#ビルド違い
Re: (スコア:0)
敵が空気を読まずに攻撃してきた。
https://www.youtube.com/watch?v=cqfl-QRYJSU [youtube.com]
あのモニターの位置って絶対狙ってるよね。
括弧 (スコア:0)
不慮の事故で括弧が合わなくなったときのエラーメッセージの意味不明さが厄介。
エラー行も適当だし、メッセージも的外れなのが多い。
VSのIDEってなんか追跡遅かったりしばらく前のやつが表示され続けたりするから補完以外は信用できないし。
Re: (スコア:0)
と、リンクされた論文も読まずにバカが言う
Re: (スコア:0)
暇ですなぁ。
Re: (スコア:0)
ビルドエラーの話をバグ全般にまで発散させて「クソもミソも一緒くた」にしたら
そりゃあ大抵のことは意味を失ってクソレベルの話にしかならないでしょう。
Re: (スコア:0)
出るエラー(のリファレンスに載ってる一般的な発生原因)とそのエラーが出た本当の原因は違うことが多い気はする