コードを読まずにバグを探すとか激しく非効率だよな

組み込みの場合、コード読むよりロジアナ使ったほうがバグ発見が早い

こういう時はどんな環境でどんなシステム作ってるか書かないと意味なくね？

例えばスマホのアプリやゲームならテストはしてもコードレビューなんてほとんどしないし

官公庁系とか銀行系のシステムなんかはレビューもテストも凄く時間かけるだろうし

作ってるものによるだろ。

マイクロソフトでエクセル作ってる人たちはまた違うだろうし

>>17
それ、キチガイだってわかるのは
コードレビューのおかげじゃんかｗ

コードレビューしなければ、ちゃんと動くから
いいでしょってなってしまう。

なぜ突然日本の業務体系の話なのか一日中問い詰めたい

いちいちコードなんて見ないし、コードレビューなんてもっての他。
あらゆるケースをテストでカバーする癖をつけないと。

それにね、レビューしてる時間があったらテスト消化してキャプチャの1つでも多く取って、客と中身を共有できるものを増やさんと。

テストの成果物納品したら、こんなに丁寧にテストしてくれた会社は初めてだよと言われ、いい関係を築いているよ。

やっぱね、プログラマーは非科学的なことは嫌いだろうけど、やっぱね、気持ちが品質の向上にも繋がるんよ。

その理屈だと少しおかしい。

Windowsアプリケーションの場合は、
ディスプレイを見なくてもバグがわかるような設計にしておきなさい。
ソフトウェアのバグを見つけるのに、ディスプレイが出てくるのはおかしい。

となってしまう。

× 組み込みの場合、コード読むよりロジアナ使ったほうがバグ発見が早い
× 組み込みの場合、切り離せない所に限定した所に限れば、コード読むよりロジアナ使ったほうがバグ発見が早い

○ 何の場合であれ、コード読むよりロジアナなど実際の出力を見たほうがバグ発見が早いこともあるし、そうでないこともある
これにて解決

>>7
書いた人も含めてソースレビューしてるよ

>>19
仕様書レビーでわかるバグは、個々の関数レベルでなく
クラス単体での矛盾を割り出せるよ
他のクラスでは、こうしてたのに
このクラスではしないのですか？
とか
開発者が多く関わる案件の場合
仕様書レビーがないと
ソースが無法地帯になるからね
知識や構成の共通化してる現場すくないから
レビーで見ないとね

また変な議論が始まった・・・

テスト手法(自動化されたE2E、ウニットテスト、モック)の是非は
1)そんな今時当たり前でしょ 2)色々あって無理なんだよ〜の
両派で永遠に分かり合えないから、どんなに話しても無駄だよ

>>35
お前の知ってる世界の話が全てだと思うな

> 例えばスマホのアプリやゲームならテストはしてもコードレビューなんてほとんどしないし
お前の会社ではな

> 官公庁系とか銀行系のシステムなんかはレビューもテストも凄く時間かけるだろうし
そうとは限らん。

レビーを数多くしてきて
基本的に
仕様書レビーで30%ぐらいバグが取れて
ソースレビーで20%ぐらいバグが取れて
単体テストで20%ぐらいバグが取れて
統合テストで10%ぐらいバグが取れる感じかな

>>55
話がズレてる
作成中にテストやデバッグが可能かどうかの話じゃなくて、
最終的にバグがあるかどうかは、機能上の出力を見ないと確かめられないでしょう。

ダイアログ等に出力するソフトウェアなら画面を見ないと確かめられないし、
バスを制御するソフトウェアならバス上の信号を見ないと厳密な意味の確認にはならない。

>>1
レアな不具合は単体テストでないと
見つからないよ

>>24
>レビューするほうが頭の程度が低いのだから

それは自己紹介？

>>16
> 仕様書レビーで30%ぐらいバグが取れて

仕様書レビューで取れるバグって
どんなやつ？

>>60
はあ・・だ〜か〜らぁ
切り離せないところに限定したところが複雑だっちゅーとんだろがぁ！

✕打ち合わせ向け
○打ち合わせなれ向け

と、ハードの経験のない素人が言っております

それだけかいｗ

セックスするならまず手マンから派やね

とても簡単な自宅で稼げる方法
参考までに書いておきます
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

A6L4J

>>62
じゃあ最初からそういえばいいのでは？

× 組み込みの場合、コード読むよりロジアナ使ったほうがバグ発見が早い
○ 組み込みの場合、切り離せない所に限定した所に限れば、コード読むよりロジアナ使ったほうがバグ発見が早い

と

組み込みでも大部分は切り離せますからね。

仕様書なんてレビューしても誤字脱字や句読点の使い方が変くらいしか
でないよな。レビューするほうが頭の程度が低いのだから、論理的な
問題が検出されることなんて極まれ。時間の無駄。
ただ検出目標があるからやるだけ。

>>6
え？ ソースコードのレビューとかしないの？
書いた人任せ？
その書いた人が問題有るコードをを仕込んだら？

2016年被爆者　　【訃報】「機動戦士ガンダムSEED」脚本家の両澤千晶さん死去　大動脈解離のため亡くなった。56歳。

　　　　　　　　　　　　　暴走事故運転者の家族、持病は「全然なかった」心筋異常、大動脈瘤破裂？
　　　　　　　　　　　　　福島沿岸の底棲高級魚を暴力団漁師が捕獲、関西に持ち込んでるとの噂

　　　　　　　　　　　　食べて応援の雄　松方弘樹、脳腫瘍の疑い　長期療養のため公演降板・中止へ
　　　　　　　　　　　　　　　　　　　事故後も東北沖マグロを釣りまくってきた無類の魚食好き

女子プロレス界の異常。亜利弥さん、昨年北斗晶さんと同じ乳癌発症、ステージIV。「桜の咲く頃まで持たない」と告知。
長与千種さん、今年胆嚢全摘手術。そしてRAYさんの悪性脳腫瘍。。。女子プロレスは震災後福島でボランティア興行。

2015年被爆者　　盛田幸妃 横浜（現DeNA）45　　松来未祐38　　黒木奈々アナ32　　丸山夏鈴アイドル郡山市出身21

　　　　　　　　11.23「テラスハウス」今井洋介さん心筋梗塞去 31歳…母親が発見　鎌倉（今年、死亡数上昇）

　　　　　　　　　　11.15阿藤快心不全 69歳　　一押ししていたすし店『海味』の大将も、今年の9月に死去

　　　　　　　　　　　　　　　　　本質的に安全なものは、「安全」の言葉をもって身を飾りはしない。
　　　　　　　　　「原子力の安全性」や「放射能汚染食品の安全性」などというのは、それ自体が矛盾である。
　　　　　　　　　　　　　　　　　https://twitter.com/YNakagawa_bot/status/702933341478084608

　　　　　　　　　　　　　　　　　　　　　　　マイトレーヤは原発の閉鎖を助言されます。
　　　　　　　　　　　　多くの人々が核の汚染の影響で死んでいるのに、彼らは幻想の中に生きています。
　　　　　　　　　　　　マイトレーヤの唇からますます厳しい警告と重みが発せられることを覚悟しなさい

一緒に仕事したくないタイプだなw

ロジアナ使ってると仕事してる気になる

>>8
なんでそんなことしてるの？
ブラウザポチポチすればいいじゃない。

>>54
ぜんぜん違う。

組み込みでも、Windowsアプリケーションと同じように
ディスプレイだけ見てわかるようにしなさいってことだよ。

ハードの不具合を見つけるのなら仕方ないけど、
ソフトウェアのバグならば、ハードがなくてもできる。
ハードの代わりにエミュレータを使えばいいから。

別にハードウェアの完璧なエミュレータを作れって話じゃないよ。
Windowsアプリケーションのテストでも、あるモジュールができていない時や
そのモジュールが外部サービス（ウェブAPIなど）に依存している場合
代わりにモックを使って開発やテストを行う。

それと同じようにハードウェアのモックを作れば、実際のハードウェがなくても
テストやデバッグは可能。ハードウェアを直接触るのは時間が掛かる作業なので
それをしなくてもいいようにしなさいって話。

数十行ごとに2〜3人で囲んでコードレビューするだろ？うちだけなのか
マネージャー、主任、新人ぐらいの構成で1時間ぐらい時間とるぞ

受ける会社大丈夫？
下記の条件が全て当てはまる会社にご注意下さい。

・IT系 in tokyo
・「社名　労基」でググると過去の2chスレが出てくる
・転職会議で2.5点

>>53
ふっる〜いファーム屋さん乙
今の時代ＲＴＯＳを使うからタスク構成も複雑でハードとソフトを切り離せない場合もあるんだよ

>>59
だから切り離せないところだけに限定すればいいでしょう？
複雑なものをシンプルにするのが技術力の一つなのですが、
複雑だから複雑にするしか無いんだって考えてるんですかね？

>>59
だから切り離せないところだけに限定すればいいでしょう？
複雑なものをシンプルにするのが技術力の一つなのですが、
複雑だから複雑にするしか無いんだって考えてるんですかね？

なーんでこう、捨てゼリフっぽく言うんだろうね？

誤解させて悪い。断定させたつもりはないのだ

とでも言えばすむ話なのに

誤解したお前も悪い（○´ε｀○）

レビューは新人の打ち合わせ向けにやるのが大体の目的だしなあ
もちろんひどかったらやり直しさせるけど

従来のよくあるテストに加えて、Exploratory testing(探索的テスト)もやるとかなりバグが発見できる気がする
目的を持った気まぐれな意地悪ブラックテストって感じでﾎﾟｺﾎﾟｺ出てくる

過去に自分で実装したままのところを、なんでこんな実装したんだと文句言う奴多過ぎ

仕様なんて確認してたら怒られちゃうよ
まず手を動かせが社是

Rebyって新しい言語かとｵﾓﾀ

誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒　『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。

グーグル検索⇒『宮本のゴウリエセレレ』

24E15AI00P

無料じゃねえよ無理って変換しようとしたんだよ。
クソUIだなもう。

> 最終的にバグがあるかどうかは、機能上の出力を見ないと確かめられないでしょう。

え？ 火星で正しく動くかは
火星で実験しなきゃわからないって話してるの？

ハードを使ったテストは時間もコストも大きいんだから
ハードを使うのは本当にハードウェアを使うことでしか
わからないことに限定して、大部分はそんな出力を見ないで
開発できるようにしないとだめだよ。

ダイアログなら別にハード使わなくてもPCの画面に出せばいいし
（出せるような仕組みにしておく）
バスを制御するのなら、想定通りの制御をしているか確認するモックを作ればいい

探索的テストは日本の業務体制と合ってないから流行らないと思う

>>51
そしてリレー焼くんですね
わかります

レビューしても、コピペしただからわかりません、説明できません、
お前が正しいか確認するためのレビューでお前の仕事だろ、って
平気でのたまうキチガイが多いから、最近はほとんど意味がないよな。

>>7
うちはソースコードレビューは、ほとんどやらない。
その前に問題を片づけるのがプロだと思ってるからね。

もちろん、作るものによって変わってくるから、
例外はいくつかあるけどね。

再現が難しいバグがあって、たまにデータが保存できない。
データが保存できると最初から入力をやり直しだから
普通にやったら時間がかかってしょうがない。
ソースコード読んだらほんの数分で原因わかったけどなｗ

レビューは使えない人間を洗い出すために必要な工数だよ！ハハッ！

age

>>37
全部知ったるとは思ってないけど、概ねそんな感じじゃない？
案件や規模によるのは当たり前でしょ。

分岐が上手くいくかなんかのテストはテスターじゃなくプログラマがやる時もあるし。

あなたこそ日本中のプロジェクト全て知ってるわけじゃないでしょう。

>>22
仕様書だよね？

「こうしていた」の内容は？
よくよく見ると、何も説明してないｗ

上が理解してくれなければ永久に導入は無料だよな。

ブラックボックスとホワイトボックスの使い分けが分からないだけ。

情報技術者の本でも読めよって感じ。

なんでこのおっさんレビューのことを頑なにレビーって言うの？？

>>12
新人も何年選手も、同じレベルのコードが書けるっていうの？
その新人は凄いなぁ。
というかむしろ何年やっていても成長してないのか？ｗ

>>65
違うだろｗ
プライベートで関わりたくないタイプ、が正解

まあ仕事のときの人間関係は我慢しないと

私も知らない。あなたも知らない。
だから断定をするなって話。

コードより路地穴の話が好きなのか
雄同士仲良く穴で盛り上げれよ

仕様が間違ってるかどうかは、コード書く前に全員でやる
それをコードに落とせる程度に曖昧さを無くす

ちゃんと仕様を複数人で揉んでいれば、
書いた後のコードのレビューも仕様視点でできる

仕様知らずにコードだけ追い始めると悲惨なことになる

>>39
断定なんてしてないつもりやけどなぁ。
まあいいや。

テストやレビューの方法は開発案件によるよね。

はい、じゃあね。

>>12
それはプロだから間違いを犯さないはずだって
言ってるようなもんだんだがｗ

ネットエージェントの問題解説ってここですか

>>23
説明が大雑把過ぎて失礼した
仕様書も要件仕様を元にクラス図を作成させ
クラス図レビュー時は、要件に見合うクラスが準備されているか
要件に不明なものが無いか確認し、あれば確認指示する
クラス図を元にシーケンス図を作成させ
シーケンス図に矛盾が無いか、イベントの発生、処理の衝突の可能性をレビューする
クラス図、シーケンス図を元に詳細設計を作成させ
クラス図シーケンス図との差異、機能に矛盾が無いか
他の詳細設計との差異、メモリ管理、例外処理、不具合の可能性と回避方法、例外発生時の確認方法を考慮した設計になっているかレビューする
まぁ、外注のサブリーダーだから部分的ではあるがこんな感じ
現場や案件、開発スケジュールやその会社の手順によってレビュー方法も変化させるから全て同じとはいかない
短期契約で現場に入って、１週間で仕様を全て理解し
現場社員リーダーのサポート役として
外注の管理、指導もやってるからね

>>1
そんなレベルのバグ除去は書いた奴のお仕事
ポチポチテストはテスターのお仕事
フェーズが違う

どんな立場から物申してるのか読み取れないよ

私の場合、大規模開発現場と新規開発案件の経験が多いから
新規の言語で進捗の悪い現場に行くことが多い
大規模開発現場でのリーダー経験と
小規模企業のシステムを一人で一から開発した経験も多いので
外注のリーダーや社員のサポートが多いな
開発作業はコアの部分を私が担当して
簡単な子機能を派遣や新人にさせるがね
年齢もそこそこいってるから、現場では最年長ってのも珍しくない
経験と知識、年齢で現場社員ですら文句いわないよ
ただ、昔社蓄時代に仕事し過ぎて体壊したから
基本短期でしか現場に入らないがね

レビーは、スキルが必要だしね
無知は、コピペ多いから
レビーする人のスキルで引っかからない事がある
設計、コーディングを同じ人がやると思い込みでデバッグ関数放置とかもあるし

>>9
そだねー
あぁ…お前をポチポチしたい