既存のコードの質を依頼を受ける前に確かめる方法は？ 117
ストーリー by headless
難題 部門より
難題 部門より
danceman 曰く、
「Ask Slashdot: How To Avoid Working With Awful Legacy Codeより
私は10年ほどソフトウェアエンジニアとして仕事をしているが、新しいソフトウェアを一から作る仕事を依頼されることはほとんどないため、仕事の満足度は既存のコードの質に左右される傾向がある。既存のコードの中には出来のいいものもあるが、出来のよくないものがほとんどだ。そのため、面接時に「最新の技術が使われているか」「コードレビューを実施しているか」「テスト駆動開発を実施しているか」といった質問でコードの質を確認するのだが、それでも最悪な出来のコードに出会うことがある。最悪なコードを避けるため、/.erならどのような質問をするだろうか。コードの質を事前に確認するよい方法が他にもあればお教えいただきたい。
例外もかなり多いけど (スコア:5, 興味深い)
ドキュメントのまとめ方である程度傾向は判断出来る
詳細仕様・テスト仕様の改版履歴とレビュー結果報告だけでも見ればずいぶん傾向は見える。
更にchangelogを見せてもらえれば言う事無し。
Re:例外もかなり多いけど (スコア:1)
最近思うのだが、その現場のレベルって情報伝達に対する意識である程度測れるような気がしてきた。
レベルマイナスたくさん 話せばわかる、会話は神聖にして侵されざるものと思っている。
とりあえず、その場で話しながら考える。話しながら考えるから物事がとかく整理されないしまとまらない。
アジェンダなどは作らない。補助的に事後に記録を残すこともあるが、あくまで記録であってその記録が後のアクションにつながるわけではないし、事後なので不確かな記憶に基づく事になる。
音声による会話は参加人数がどれだけいても、ミクロ的には１対１の行為なのでその間、他のメンバーの待ちが発生する。つまり非同期で動作できない。
レベルけっこうマイナス メールを使用し始める。メーリングリストなども使っているかもしれない。でも、いろいろな意味で整理されていないため、低いレベルで簡単に飽和する。
レベルよくあるマイナス 生産されるドキュメントは納品するための作業の目的でしかなく、次の工程のインプットという意識がない。工程のためのドキュメントを作るために工数をかける必要を認められない。
（めんどうなのでとばす）
レベルプラスいくつか wikiなどを使用し始める。打合せはあるにせよ、ドキュメントドリブンで行う。
各自の作業はできる限り非同期で行えるようにする。プロジェクト管理ツールを適切に使用しているとベター。
#つーか、普通そうするだろJK
ひどかった例として。
テスト工程でバグ判明→修正→確認のサイクルの情報伝達に使っていた手段が、
バグ管理システム３系統＋エクセルの表＋メール＋チャット＋口頭だった時はあきれ果てた。
今は遠方の客先とのコミュニケーション手段が少しのメールと電話会議という、現代に早く帰りたい...という現場なので
とりあえず、独立したネットワークはつながってるんだから、チャットぐらいつかわんかねと提案してみようかなあ。
なんか、意味なく抵抗されるような気がして面倒なんだけどなあ。
なあ、信じられないだろ、これでも not P not U な会社の仕事なんだぜ。
#ID で書こうとしたけど上の一行書いてしまったのでAC
Re:例外もかなり多いけど (スコア:1)
>以前参加してたところだと、「機密上見せられない」で押し切られそうな気がする。中小じゃないからなおさら。
ああ、「ウチは情報漏えいとかに注意してます」なんて所ほど、そういうことになりがち（苦笑）
一度、ファイルをインポートする部分の改修を請け負った時、仕様知りたいから、ファイル見せて？と言い出したら、それは「機密がなんちゃら」と言い出したな。
結局、あちこちマスキングされた状態で出て来たけど、カンマやダブルクォーテーションとかが欠落した代物で、使いものにならず。
文句言ったら、やったのが一般のユーザーなんで諦めろと来たもんだ。アホか？と思ったね。
（まぁ、実物じゃなくても、どうにかなる手段は幾つかあんだけど、そのユーザーさんが協力してくれないんで実行不可ｗｗｗ）
#結局、その部分は納品後にもバグ頻発して、責任は全部俺の所に来ました。つーか、CSVなのに列数が可変とか意味不明の設計してんじゃねーよｗｗｗ
Re:例外もかなり多いけど (スコア:1)
Q「ドキュメントに書いてある内容と挙動が違うんだけど?」
A１「そのドキュメントは旧版です。最新版はコードを参照して下さい。」
A2「ドキュメントは設計書ですが、実装にはバグがあって、その通りには実装されていません。」
A3「その機能はまだ実装されていません。次のフェーズ３以降で実装する予定です。」
＃なれるSEでもそんなネタがあったなあ。
前任者はコードもドキュメントもほぼ完璧だったけど、不況のあおりで前任者がクビにされて、
現在の担当は一切コメントもドキュメントも書かずに、バグフィックスや機能追加、リファクタリングと
称してスパゲッティプログラムを大量生産。
……という可能性も無いとは言えない。
＃ユニットテストも無しでCのスパゲッティプログラムを書き換えるのを「リファクタリング」と
＃称してる奴がいたなあ。死ねば良いのに。
特に中小企業だと、作ってるのが実質一人だったりするからなあ。
その担当がクビにされた後を引き継ぐのが未経験の新人だったりすると、
こういうことは十分起こりえる。
確かめるまでもない。 (スコア:5, すばらしい洞察)
どこかの誰かが手に負えなくなったからこそそういう仕事が発生したんだ。
最初に作った奴の手に負えるならそいつに発注されてるさ。
そして手に負えなくなった原因は...あとはわかるな？
既存コードの修正依頼なんてのにマトモなコードはないと思ったほうがいい。
# 少なくとも最初の会社で請けてたのは100%そうだった。
発想が、ちょっと駄目かな (スコア:2)
のでは無く、最悪なコードを見かけたらそれを最高に書き換えるのがプロの仕事。
既に動いてる部分は触ってくれるなというクライアントも居るが、
保守性の向上とか潜在バグの回避とか幾らでも説得材料はあるし。
Re:発想が、ちょっと駄目かな (スコア:5, すばらしい洞察)
糞な業務を蹴るのも、プロの仕事の一つ。
Re:発想が、ちょっと駄目かな (スコア:1)
どうい。
素直に見積もればいいんだけどね。お断り価格になるから。
Re:発想が、ちょっと駄目かな (スコア:4, 興味深い)
>のでは無く、最悪なコードを見かけたらそれを最高に書き換えるのがプロの仕事。
うーん、リファクタリングもやりすぎると、ただの「アーティスト気取りの困ったチャン」だと思うんだけど？
最近関わったプロジェクトで、何個かアプリ納品したけど、一個飛び抜けて「異質な実装」してあるものがあって、かえって叩かれました。
設計を説明してる最中の引き継ぎ先の目線がマジに痛かった。俺が実装したんじゃねえのにな（怒）
保守性の向上の中には既存のアプリと同等であるという部分も無いと無意味だと思うの？ｗｗｗ
Re:発想が、ちょっと駄目かな (スコア:1)
>火種は消しとけ
確かにねｗｗｗ
思わず、実装段階で俺がチェック出来る立場に居たらって思ったよ。
俺も大勢いる要員の一人で、リーダーが自社要件とか言い出して逃亡したから、俺が説明に回ったんだよ。
内容チェックしたのが当日の朝だったから、もう死刑囚の気分だった（苦笑）
#俺も相手に同意して一緒に怒りたかったけど、俺は納品する側の人間だからねｗｗｗ
Re:発想が、ちょっと駄目かな (スコア:2, すばらしい洞察)
＞保守性の向上とか潜在バグの回避とか幾らでも説得材料はあるし。
それで説得できるケースってあるの？
客にとって大事なのは、動いてる部分の維持保障とコストの増大を防ぐことだよ。
その辺の説得材料をどう数値化してる？
Re:発想が、ちょっと駄目かな (スコア:1)
同意。作り直すというモチベーションだけではビジネスにならないですね。直近の開発コストもそうですが、ソフトウェアのユーザにとってのメリットが提示できないと改修は難しい印象です。
再設計を主眼に置いた案件を獲得したことは何度かありますが、そのときは追加したい機能を建て増しするコストと、再設計した上で機能を追加するコストを天秤にかけて、後者をお客さんに選んでもらいました。コストの中に保守性や潜在バグに関する話も入りますが、商談の中心ではなかったですね。
Re:発想が、ちょっと駄目かな (スコア:1)
最悪なコードにぶつかった事が無い人かしら、羨ましい。
●500行の関数が短く見える
●コメントに嘘が混ざっている
●入出力パラメータの意図がはっきりしない
●コピペされたコードが散在し、コピペのうちの数行が異なっている、異なっている意味が分からない
●ポリシーがわからない、あるのかないのかわからない、書いた奴がどの程度馬鹿なのか馬鹿じゃないのか分からない
●一見バグに見えるコードが本当にバグの状態にあるのか信じられない
●その状態で多くの人がメンテしてきて、もう誰が何をどういう意図で書いてるのかわけがわからない
まあ、全てを兼ね備えたプロジェクトがあったわけじゃないけど、1件だけパーフェクトに近いのがあったなあ。。。
Re:発想が、ちょっと駄目かな (スコア:2, おもしろおかしい)
●コメントの90%はコメントアウトされた修正前の古いコードか、コーディング規約で決められたテンプレート(中身はない)
●モジュール間のデータのやりとりは基本的にグローバル変数なので入力パラメータも出力パラメータもない
●コピペされたコードが散在し、完全に一致している。指摘しても修正工数がないのでそのまま、さらにもう一つコピペが作られる
●最初に書いた設計者は天才だったようだ。明確なポリシーにもとづく教科書に載せたいくらい鮮やかな実装がそこにあった。ただし、外注だった彼はもういない。それを修正した何人ものプロパーはみんなアホ。完全に元のコードを破壊している
●どう見てもバグに見えるコードは本当にバグっているが、それが仕様で正しい
●だから誰もが自分の責任範囲を極小化することだけにキュウキュウとしている。個別部分の意図は痛いくらい分かるが、全体としては意味をなしていない。
Re:発想が、ちょっと駄目かな (スコア:1)
なんだ，うちの会社のコードの品質って最底辺かと思ってたけど，世間でよくあるレベルの「最悪なコード」だったのか．
こりゃ駄目と思った実例 (スコア:1)
某Linuxデバイスドライバーを開発してもらった時のエピソード。ソースコードを納入してもらったんだけど、怪しげな書き方をしているところがありました。でもテストするとちゃんと動く。
一晩くらい悩んだら、どうして動くのか理解できました。少しロジックを変えれば意図がはっきりするという問題はあるにせよ、納入コードにちょっとコメントを追加してcheck inすればいいの話。後で同僚に解説したら「そんなの読み解けない」と言われた書き方でしたけど。(笑)
正式納品前に、そのコード担当者と打ち合わせがありました。もっとやさしく書けるのに、どうしてそんなに難しいコードを書くのですか?答えが「言われてみると、どうしてちゃんと動くか分かりません」だって。で、客側のこっちが「あなたのコードはこんな風に動いています」と説明する羽目になりました。(苦笑)
なお、この取引先って日本を代表する企業の名前を冠に戴いた企業。N○Cホゲホゲや東○ホゲホゲみたいな会社です。
vyama 「バグ取れワンワン」
Re:こりゃ駄目と思った実例 (スコア:1)
ごめんなさい。「そんなの、私の解説なりコメントがなければ、読み解けない」に訂正です。
# 書き散らしよくない、よく校正するよろし。_ _;;
vyama 「バグ取れワンワン」
Re:発想が、ちょっと駄目かな (スコア:1)
> のでは無く、最悪なコードを見かけたらそれを最高に書き換えるのがプロの仕事。
では無いなあ。趣味の世界なら結構なんだが、営利の世界の話ではそれ無いわな。志向としては大変結構だけど、現実的ではない、って話ね。
この話でもリファクタリングマンセーな人がいる様だけと、リファクタリングでカバー出来る範囲って、アルゴリズムかコーディングのレベルまでじゃない？糞プログラムって、要件とかアーキテクチャ段階から腐っているのも多くて、そういうのにはリファクタリングは有効とは言えないと思うよ。プログラムの外部I/Fを変更するとか、外部I/Fを変更は変更しないけどスクラップ＆ビルドとかまで、リファクタリングに含めるなら話は別だけどね。
> 保守性の向上とか潜在バグの回避とか幾らでも説得材料はあるし。
そういう理由でメンテをオーダーしてくるお客が居れば、そこのプログラムは糞プログラムで無い可能性があるよね。普通お客が気にするのは外部品質であって、良好な保守性とか潜在バグの少なさの様な内部品質なんか気にしていない。個人的には内部品質軽視には反対なんだが、世の中そうなっているから仕方がない。
まあ今みたいに「お客が怒り出さない程度の最低の（内部）品質」なんて方針でソフト屋が商売してると、そのうちしっぺ返しを食うだろうけどね。
Re: (スコア:0)
判りやすくリフォームで例えると
「木造二階建てのボロ家を三階建てにしてくれ、ただし増築分の資材と最低限の工賃しか出さない」
みたいなクライアントが多いから避けてるんだろ。
大黒柱が腐ってるからって安易に取り替えて崩壊したら誰が責任取るんだよ・・・
Re:発想が、ちょっと駄目かな (スコア:1)
似たようなことを思った。
汚いコードを汚いまま放置しているクライアントは、コードの品質に金を出さないからこそ
汚くなった。そういったクライアントが今更コード品質に金を出すようになるとは考えにくい。
その仕事に見合う金さえ出せばやってもいいよ。
だけど彼等の提示する金額は桁が３～４桁以上少ないんだよ。
バージョン管理システム使ってますか？ (スコア:1)
何を使ってるか、どれくらい前から使ってるか、どんな風に使っているかも聞いておく…
McCabeのサイクロマチック数 (スコア:1)
我慢しなさい (スコア:0, オフトピック)
> 新しいソフトウェアを一から作る仕事を依頼されることはほとんどないため
その程度の人と見なされてるんじゃないの？
Re:我慢しなさい (スコア:5, 参考になる)
逆だよ、出来ない奴に最悪のコード渡したら、よりひどくなって収拾がつかない。
低レベルの奴に難易度の高い仕事回すほうがどうかしてるだろ。しがらみがない分、修正より一から作るほうが簡単だもの。
だから、出来る人と見なされている彼に出来の悪いコードの修正が集まってくるんだよ。
そう思わんと人生やっとれんわ・・・
Re:我慢しなさい (スコア:3, 興味深い)
同感。いわゆる業務アプリ系メインでやってると、改修案件が大半を占める。
でもって、既存の出来の悪さがそのまま成果物の質を左右してくれるんで、やる度に気分が悪くなるのも確か。
「それは元からある仕様です」この台詞を素直に受け取ってくれる人はほとんどいません。
で、勝手に直したら、それはそれで問題になるし、事前に指摘して、直さない方針になっても、お客さんは怒るしｗｗｗ
Re: (スコア:0)
既存システムの変更なのに、ソースがカオスで、
社内ではどうにも手の施しようがない案件の依頼とかあります。
#外注にまわってくるのはそんなのばかり。火消しや人身御供も。
百聞は一見に (スコア:0)
確実な方法は、
ソースの一部を見せてもらうこと。
一目瞭然です。
#部分的には勉強になるときもあるが、
#元ソースの出来がよかったためしがない。
Re:百聞は一見に (スコア:1)
ある程度の規模のシステムならソースなんて全部読んでいられない。
ごく一部のダメコードが広範囲に影響する事もあるし。
それより、開発ツールを聞いて、コード解析レポートを提出させて、「テストの」デモをさせた方がいい。
アプリのデモだけでは駄目。
ちゃんと動く部分しか見せないから。
xUnitを使っていれば、コードカバレッジがわかる。
静的コード解析ツール(Code Sniffer, Mess Detector等)を使っていれば、コード規約違反やダメコードの有無がわかる。
CIツール（Jenkins等）を使っていれば、テストが自動化されているかどうかがわかる。
あと質問者はコードについてだけ聞いてるけど、実際にはミドルウェアも気にしないと駄目。
とっくに開発が終わってたりコミュニティが小さいフレームワークやストレージエンジンを使ってると、保守ができない。
Re: (スコア:0)
契約する前に見られることはまずない。
契約するかどうか決めるのに質を見たいというのだから採用できない案かと。
Re: (スコア:0)
逆に自分のサンプルソースを見せて相手の反応を試してみては
先方のエンジニアも呼んで
案外自分の方がひどかったりしてw
テスト駆動って (スコア:0)
「動くこと」だけは保証するけど、コードの質を保証するもんじゃないでしょ。
コードレビューだって、自分の仕事とかかわってこない部分の他人のコードは、さほど真剣に読まないよな。
書いた本人が取り組んでいる問題の深さのレベルに、そう簡単に到達できるとは思えないし。
そんな暇あったら自分の仕事を進める。
Re:テスト駆動って (スコア:3, 参考になる)
テスト駆動は、
仕様をテストという形でコードに起こす。
テストは自動化されているのでいつでも繰り返しテストができる。
テストがいつでもできるので、リファクタリングというコード品質改善プロセスを安心して行える。
リファクタリングが済んだら次の仕様をテストに起こす。
次の仕様をクリアする段階で既にあるコードに手が入り、問題が発生しても（既にあるコード向けの）テストを実行すればクリアできる。
です。
コード書いてて、これちゃんとうごくんだっけと別窓で簡単な確認コード書いた経験があるなら、それをもっと体系的に製造プロセスに盛りこまれたような感じです。
そしてその確認コードが動く限りメソッドの抽出などのリファクタリングを行っても、自分の欲しい部品であり続けてる（壊れてない）。壊れてないことが確認できる方法があるんだからリファクタリングに取り掛かりやすい。リファクタリングしているからメンテナンス性が向上される。ここまで含めなければテスト駆動開発とは言えません（習熟中で不完全な場合は仕方ないですけどね）。
あと、テスト駆動用に書いたテストですべてがテストされるわけではないので、普通のテストもしますね。（『そこを指して「動くこと」だけは保証するけど』なんでしょうが。）
誤解を恐れず言えば、アプリケーションが動くことまではカバーしません（どこまでのテストコードを書くかはチームによるでしょう、最近はメソッド単体ではなく、併せて一連の動作のテストも書くといいという話も出てますし）。
もちろん理想と現実はありますが、それでもテストコードが少しでもあると全くないとでは全然違うと最近よく思います。
# 中途半端だと全部グリーンじゃない状態で放置されてたりすることもあったり。
# yes, fly. no, fry.
Re:テスト駆動って (スコア:1)
それが「コードの品質」ってことなんだよね。ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。
テスト自体が仕様なのであれば、テスト駆動で「品質」を保証できるってことになる。
一方、仕様自体にバグがあれば、コードの「品質」はクリアしてるのに動かないってこともありうる。
もっとも、テストに書ききれない仕様やコーディング規約ってのはあるかも知れないので、テスト駆動だけで「品質」をすべてカバーできるわけじゃないだろうね。
Re:テスト駆動って (スコア:1)
＞ソフトウェア開発における「品質」ってのは、一般に理解されている品質とはちょっと意味が違っていて、
＞仕様通りに実装されているかどうか、を指す。達人的に超絶コーディングされている、という意味ではない。
むしろ逆じゃね？
仕様書通りに作ってさえいれば、どんなに糞コードでも｢高品質｣であるなんて行ってる奴の方が珍しいと思う。
あなたがSI的オレオレ品質定義に染まってるだけではないかと。
普通はもっと広義で品質という単語を使ってると思いますよっと。
Re:テスト駆動って (スコア:1)
あなたがSI的オレオレ品質定義に染まってるだけではないかと。
普通はもっと広義で品質という単語を使ってると思いますよっと。
はい。私も最初からその様に言ってますね。「普通は」「達人的に超絶コーディングされている」ようなものを品質が高いと評する、と。
しかしながら、SI業界をはじめとするISO 9000 [atmarkit.co.jp]が通用するような業界では、「品質」と言えば、仕様通りにモノが作られていることを指します。敢えて言うなら、「SI的オレオレ品質定義」ではなく、ISO 9000的定義でしょうか。
なお、ISO 9000的定義では、場合によっては、仕様よりも精度が高すぎることすら高「品質」ではない、と判断されます。精度は費用に返ってきますし、費用も含めて設計されているからです。
仕様書通りに作ってさえいれば、どんなに糞コードでも｢高品質｣であるなんて行ってる奴の方が珍しいと思う。
それならば、どう書けば「糞コード」でないかを明示すべきですね。普通は、コーディング規約とかでやるんじゃないですか。
職人みたいに「見て盗め」じゃダメです。個人的にはそうしてほしいですが。
Re:テスト駆動って (スコア:1)
もうちょっとちゃんと読んだらどうかな、ISO9000とかをさ。そういう半可通がソフト業界をダメにしてるんだと思うよ。
原典は読みはしませんが(笑)、それなりに学習しましたよ。で、何がどう問題だと言っているんですか?
出来上がりのプログラムが機能要件を満たしている、なんてのは当たり前の話。
そうですね。その当たり前のことを当たり前に実行する。それが「品質」ってものです。
だけど、機能要件を満たしている、なんかじゃTCOとかを制御出来ないんだね。
TCOのは、「コードの品質」とは別次元の話です。それはそれで別に保証されるべきです。コーディング段階で勝手にTCOを妄想されて実装されたのでは、それこそTCOを制御できません。
まあ、現場レベルからTCO改善策を提案することはあってしかるべきです。
これは言うのは簡単。信頼性、効率性、保守性、移植性の品質特性が高い事。だがね、こういうのは有効なメトリックスが無い場合もあるんだね。だから、機能性品質特性みたいには簡単に行かない。
そう言うものは当然ありますね。
有効なメトリックスが無い⇒主観的でも何でも良いからともかく基準を作ろう、なのか、有効なメトリックスが無い⇒メトリックスが無いものは無視無視、なのかで、出来るもんがずいぶんと違うわね。
「ともかく基準は作る」んですよね。つまり仕様化するってことです。だったら、私の言っていることと大差ありませんね。何が気に食わないんでしょうか?
ロイ君は多数派の無視無視の方だろうけど、そういう考えでやってると未来は無いと思うよ。
誰ですか、「ロイ君」って。
＃私の名前をそんな風に間違うなんて、新人さんでしょうか(笑)。
コーディング規約で制御出来るのはコーディングだわな。コーディング規約で、アルゴリズムとかアーキテクチャを制御出来るって、もしかして考えてる？
いいえ。
アルゴリズムやアーキテクチャは、当然明示的に仕様化されているものだと思いますが、あなたの職場では違うんですか?
テストをコード単体の仕様を完全に反映したもの、と考えると、内部の実装はどうでもいい、ってことになるわけですが、私は最初から、「テスト駆動だけで「品質」をすべてカバーできるわけじゃない [srad.jp]」と言っていますね。
全体として、特に意見の相違が見つからないんですが、何が気に入らないんでしょうか?
Re:テスト駆動って (スコア:1)
現状でテストの確認をするためのテストを、それを確認するためのテスト…をしているならテストコード導入してもそれが求められるかもしれませんね。
> 「10の27乗ぐらいかな。1秒に100万ケースチェックするとしてぇ・・・」
「するとしてぇ・・・」どうなったかは知りませんが、
1秒に100万ケースチェックできるっていいですよね。
もちろんテストコードじゃなくても同じ数を手でテストしようとしてたんですよね？
# どうせなら現実的な問題のテストコードのメンテナンスとか突いて来ればいいのにね。
# yes, fly. no, fry.
Re:テスト駆動って (スコア:1)
レッドになっても何が原因か即座にわからなかったり。コードにすると割に合わないテストコードも存在します。なんでもかんでもテストコードにすればいいというわけではないです。
ただそれがテストケースであっても結局人が作るので、その品質もありますよねケース不良とか。
「人が介在するのだから」という部分はテストコードにしたところで変わりません。仕様を誤解していればテストコードだって誤解されたものができるでしょうし。
いつでも繰り返しテストできるとかそういうところがメリットです。
まずは特定のフィールドのチェックメソッドとか、書式変換メソッドとか、いつ呼んでも期待値が変わらない軽量のメソッドに対してだけテストコード書いてみるといいですよ。
ごく単純なテストメソッドでは
var target = new MyStringValidator();
Assert.AreEquals(true, target.HasDotCharacter("Ubuntu 12.04"));
Assert.AreEquals(false, target.HasDotCharacter("Windows 8"));
のようにインスタンス化含めて 10行以内になることも多いですので、品質がどうのこうのなることはあまりありません。
テストコードもテスト駆動も道具ですから、うまく使えるところに使えばいいんです。
# yes, fly. no, fry.
Re:テスト駆動って (スコア:1)
「この層はテスト駆動開発でやりました」でもいいでしょう。
どんな手法でも、怖いのはなんでもかんでも「それだけでやれ」という考え方ですよ。
古い言い方なら銀の弾丸などないです。
# yes, fly. no, fry.
Re: (スコア:0)
結局、コードの品質を保つために実施している施策はありますか？程度だよね。
＃プロジェクトの途中で、面接して人を集めだしている案件なんて、地雷臭しかしない。
Re:テスト駆動って (スコア:1)
結局、コードの品質を保つために実施している施策はありますか？程度だよね。
＃プロジェクトの途中で、面接して人を集めだしている案件なんて、地雷臭しかしない。
なるほど。
「御社の有給休暇消化率の時間変化をグラフで示してください」
「一人当たりの残業時間数を示してください。え？ 『書類上は』残業ゼロ？」
「御社社員一人が同時に抱えている案件数はいかほどでしょうか？」
「御社営業担当は、御社の事業内容をしっかりと理解して案件を契約して来ていますか？」
「御社社長は、どの畑からの出身でしょうか」
「一人当たり、どれだけのワークスペースが割り当てられてますでしょうか。
島型オフィスで、隣とひじがぶつかるような環境ですか？スペーサで一人ずつ個別の環境になってますか？」
「コンパイル環境が一人ひとつ以下とか、順番待ちで作業がとまるようなライセンス契約とかはないですよね。」
これらにまともな回答が戻ってくる企業なら受けても大丈夫、って
そんな企業から外部に発注するわけない
Re:テスト駆動って (スコア:2)
>「御社営業担当は、御社の事業内容をしっかりと理解して案件を契約して来ていますか？」
さすがに事業内容は知っているさ。自社、つまり、技術者それぞれの専門や能力、スケジュールを把握しているかでしょうね。
典型的な無能な営業は、安請け合いするか、何も出来ないというか、どちらかだから。
もちろん、外注に廻すにしても、社内の技術者に中身を把握してもらって、打ち合わせにも出席してもらわないと、営業だけでは価格や納期も設定できないし。できれば外注管理も担当して欲しいし。
>「一人当たり、どれだけのワークスペースが割り当てられてますでしょうか。
> 島型オフィスで、隣とひじがぶつかるような環境ですか？スペーサで一人ずつ個別の環境になってますか？」
島型だと、レイアウト変更が自由なので便利だよ。機材が必要な時は机を二つ使ったり。仕事をし出せばどうせ周りは目に入らないし。
>そんな企業から外部に発注するわけない
ん？ 社内だけでこなせる量の仕事しか取ってこれない営業なら、それは問題では？
受注量に山谷があるのは自然なことだし、社内の技術者にもそれぞれの専門(得意)分野もあるのだから、年間を通せば、外注に出す仕事が一定量ないと遊びが出来ることになる。
Re: (スコア:0)
何の話をしてるんですかね？
テスト駆動って細かい修正を繰り替えし加えていくものなので (スコア:0)
"メンテのしやすさを考えたコードになってる可能性が高い"
と予測するのはあながち的外れではないんちゃうかと
市井の中小企業でコードレビューなんてやってるところなんて存在しない (スコア:0)
グーグルやfacebookに憧れてるようなボーズがCEO（笑）をしているような自称WEBクリエイター会社だけ
Re:市井の中小企業でコードレビューなんてやってるところなんて存在しない (スコア:1)
Web系のプログラマって、プログラマーやソフトウエアエンジニアというとすぐにWeb系に限定して考える癖があるよね。
それだけ世界が狭いってことなのかなあ。
Re:市井の中小企業でコードレビューなんてやってるところなんて存在しない (スコア:1)
顧客の要求でやってるところもあるんだよ。
# 一番ダメなのはそんな小手先の部分じゃなくて顧客側の開発体制だと思うがな！
Re:コードの質云々ってより (スコア:1)
究極の選択だね。
職場環境は理想的だが、生産物が限りなく糞
職場環境は限りなく糞だが、生産物は理想的
でも、生産物が糞というのは結局それに起因して後が壊滅的な状況になるので、環境も糞になるのだよ。
Re:意外と簡単です。 (スコア:1)
> 何時、誰が、書いたと、ソースに明記されていますか？
その問いだと、適切にバージョン管理システムを運用している、
天国のようなプロジェクトににたどりつけない場合があります。
Re:質問者がおかしい (スコア:1)
なんか訳がおかしいような…。
その技術の新旧とコードは関係無い、ってほうのリンクは
(そのコメント主の経験的に)新しいものが良い事であったことはあんまない。
どっちかというとヤベェ。って書いてるように見えるけど…。
# 俺なら「今までコレやってた奴はなんで逃げた? 」と聞く、とも書いてある
それに対する反論ってほうは、古かろうと新しかろうとクソはクソだ、
だが同じクソでも新しいクソは新しい道具が処理に使えるから大分マシだ、
と書いてあるように見える。ある意味こっちのほうが技術の新旧とコードの
質は関係ない、って言ってるかも。
# あと、後者のほうは Bonjour は消毒だぁ! ヒャッハー! みたいなの書いてあって
# Interesting がついてるっぽいなwww
# 悪意ある意訳だけど ID