一定のバグが潜んでいる
それはわかるが、言語によってコーディング量もバグの量も変わる
これについては統計データを見た事がない
それなのに、一定の係数でバグがあると仮定して
テスト量を増やして見つけたバグの量を捏造しなければならない事が多々ある
これは特に大手様で顕著で、どうやら大手様のお偉い方が書いた論文が元になっているのだ
テストもH社はマトリクスになっている
N社は大中小項目で文章記述
どちらもやっていることは変わらない
テストによりバグがなくなり品質が上がると思っているようだが、この根底にはプログラムなんて誰が書いても同じものが出来上がると言う幻想空想都市伝説があるようだ
誰が書いても同じになるなんて、、、
それなんて言うPython？
人によって書き方が大幅に変わるのがプログラムだ
わたしは各言語によってこう書けば今後のメンテナンス性が上がると言う書き方を知っているが、コーディング規約にまで落とした事がない
そのうち作るべきかもしれない
コーディング規約といえば
ローマ字禁止って書かないとダメか？
特にH社はローマ字でテーブル名もカラム名も書かれていて、まぢかと思った
ローマ字禁止なんて常識だろ？
書かないとわからないか？
まぁ、テストは必要だ
大抵バグがある
使っているライブラリの使い方を間違ってメモリー消費が増え続け、3日位連続で稼働させたら絶対に落ちるバグとかもある
だが、自分で作ったプログラムを自分でテストケース作ってテストしても、大抵簡単には見つからない
ベアプログラミングをしてペアでテストするのが良い
それと、少し組んでみて、動き出してからもっといい手を考えつく事がある
この場合、たとえ動いていても変えた方が良い
少しバックするが、その後の進み方が変わる
このやり方はゲーム業界ではよく行われてきた
いわゆるアジャイルでも動いていたところを全部作り直すなんてことはあまりやらない
試して動きを確かめて、ディレクターを呼んでテストプレイしてもらって、これでいいね？これで行こう？と言うアジャイルなやり方は、ゲーム業界では昭和からやってきた
アジャイルを聞いた時に何を今更？と思ったものだ
ゲーム業界では、みんな自分の役割を果たして開発を進め有機的に進んでいた
だからクソみたいなコードが残りづらかったのだ
今の業務アプリを見ろ
クソコードのメンテしかない
ディレクターやマネージャーのやる事は、
単に線表を引いてスケジュール通りか確かめるだけだ
そんな人必要か？
マネジメントを行うのであれば、
スケジュールの遅れや問題点を朝会で確かめるのではなく、すでにその場で全体を知っているべきなのだ
そうなるには仕事中に顔突っ込んで話し込む事だ
それをやらない人間はリモート作業でもオフィスに居ても仕事をしていないのと同じ
クソ役立たずだ
マインドセットが足りてない
あるチームに問題点があったので、こうして解決しました似たような問題を抱えるチームがあれば参考にしてくださいと言う朝会ならやる意味がある
確認作業なんて昨日のうちにやっておけ
アジャイルとか名前つけて
わざわざ勉強しないと理解できないなんて
マヂで馬鹿すぎだ
知っとけ
未来を作る気ならマインドセットしとけ
0 件のコメント:
コメントを投稿