すげーや（笑）
https://www.usp-lab.com/methodology.html
開発方式の特徴： 一休さん方式
> 一休さんは、屏風に書かれた虎を見事捕まえてみよ、という難題を前に、
> 「さあ、すべて準備は整いました。私が虎を縄で縛りますから、虎を屏風から出してください。」
> という頓智で場を切り抜けた逸話がありますが、ユニケージは一休さんにならい、
> データという虎を見事捕まえるために、まずデータを全部出してもらうことを要求します。
何を言ってるのかさっぱり理解できない。俺が馬鹿なのか？
> さらに、実データを使ってプログラミングすることにより、
> 単純な動く動かないの単体テストはプログラミングの過程でクリアでき、開発効率も向上するのです。
すげーなー、実データがあれば単体テストが不要になるんだー
> ユニケージには、多くの「お作法」が存在し、ドキュメントの削減に寄与しています。
> 例えば「ワンプログラムワンフロー」の原則や、「アプリケーション固有のLEVEL4」の作法は、
> 複雑になりがちなプログラム間の相互関係の記述やテストを不要にしています。
シェルスクリプトは移植性低いからOSを変更したりバージョンアップした時に
動くかどうかわからないじゃん。テストしないとだめだよ。 セキュリティの考え方がないのかな？
個人情報盛りだくさんの実データを使ってテストするわけ無いじゃん
> ソフトの仕様を固めて、ソフトを組んでから最後にデータを流すという回りくどいことをしません。
> 実データは仕様書よりも「現実的な」情報が多いのでユニケージは
> プロジェクト当初に要件定義より先に実データをすべて準備することに拘るのです。
> 実データは仕様書よりも「現実的な」情報が多いので
意味不。なんつーか、開発手法の穴を、屁理屈でごまかしてる感じしかしないな
つーか、システム開発前に、どうやって実データを作るんだよって話
実データは別のシステムからもらえることが前提となってるのか？
そういう前提の開発手法というなら、適用できる用途が限られてることになる
実データがあったとして、じゃあ何が正しい計算結果なのか
どうやって判断するつもりだ？ロジックのテストは？
多数の実データから手計算と突き合わせて「うん、あってる！」みたいにやるのか？
実データ使って見つけられるバグは想定外のデータ形式とかで
実行時エラーが出ることぐらいなわけで
だからユニケージはバグが多くなってしまっている
こいつらテスト仕様書とかも書いたこと無いんかな？
どういうデータでテストしますとか何も決めずに
実データで動けば動くだろみたいな
甘い考えでやってるのか？
プロ意識ないな
仕様を公開していないパッケージソフトだと、こういうシステムテストだけで終わらせているところはある。
データの仕様からダミーデータ起こすよね
機械学習させる前提なら知らんけど
時代はAIなのかな
なんつーか、セミナーで
実データを使ってプログラミングすることにより、
単純な動く動かないの単体テストはプログラミングの過程で
クリアでき、開発効率も向上するのです。
とか言われたら、乾いた笑いしか出てこないわｗ
> 単純な動く動かないの単体テスト
単体テストをコンパイルエラー相当のものと勘違いしてないか？
単体テストっていうのはモジュールとか関数レベルの小さなレベルで
正しく動くことを確認するテストのことだろ？
実データには含まれてないような稀なデータでもちゃんと動くように確認してさぁ
処理が間違っていても、単純に動けばOKみたいなもんじゃないぞ
将来的に更新されないデータしか扱わないということならそれでいいかもしれない
今更一休さんがナンセンスだという動画がつべのお薦めに上がってて？だったが
こいつらの影響か
30年前の手法が今も通用するし
これからも通用するのがユニケージ
ところがユニケージは数年も持ちません
可搬性が悪く、保守性が皆無だからです
データベース、SQLのテストをしない人間は、世代に関係なくいる。データ型が間違っていても気づかない。なぜか氏名の名字は2文字という決めつけのシステムを見たことがある。
決めつけというよりは
ディスクを節約したかったのでは?
そんな節約してなんの意味があるの?
節約にならんよ
「五十嵐太郎」を例にすると姓が「五十」、名が「嵐太」となるシステムを見たことがある。
テストデータでテストしても実データで起こる問題は見つからない場合がある
実データでテストしても一見動いているように観えて問題が起こるパターンを漏らす可能性がめちゃくちゃ高い
つまり両方必要
以上おしまい
>>32
重要なのはこれなんだ
> 実データを使ってプログラミングすることにより、
> 単純な動く動かないの単体テストはプログラミングの過程でクリアでき、 実データでテストするのはむしろ当たり前だろ
それをテスト環境に本番環境からデータをコピーしてきてやるんだろ
本番環境の実データでテストしろとは誰も言ってないωωω
単体テストで動く動かないしかテストしないと思ってるのが怖い
>>34
そんな事書いてないぞ
実データでプログラミングすれば
単体テストはクリアできる
って言ってんだよ
実データでテストするとは書いていない メモリの確保サイズを確かめるには、実際に最大サイズを使わないとわからないからな。
UTF-8を使っているつもりが、SJISだったりしてもシステムテストレベルではわからないから
LFとかCRLF前提で描いてると
CRのみというアホなコードが混ざって困るのが実データ
普通の人の感想はこれだよなぁ。
https://xtech.nikkei.com/it/article/NEWS/20080906/314276/
> 最初の題材は，旧システムから新システムへのデータ変換プログラムにミスがあり，
> 新システムのシステム・テスト中に問題が見つかった事例である。
> あらかじめ実データを使ってテストされていたことを受け，
> 大西氏は「システマチックにテストされていたのか疑問だ」と指摘した。
テストデータというのは
仕様に合わせてテストすべきないようを網羅したもの。
実データでプログラミングするだけで、単体テストがクリアとか言われても
ちゃんとテストすべきものを網羅しているのかなんてわからん
はぁーーーーー、ユニケージ開発手法は、根本的に「雑」
プロの仕事じゃない 実データでテストすること自体はいい
テストデータだって完璧じゃないし見逃しはある
だが実データを使ってプログラミングしてれば
動くっしょ？という考えは大問題
シェルスクリプトで業務システム開発じゃーって息巻いて
誰かにシェルスクリプトじゃ単体テストできないよね？って
突っ込まれた時の苦し紛れの言い訳にしか見えない
「実データを使ってプログラミングすれば、単純な動く動かないの
単体テストはプログラミングの過程でクリアできる！」
いや、単体テストは、単純な動く動かないをテストするもんじゃねーから
マズい処理A
マズい処理B
が合体することで
結果として正しい結果になっている
効果を狙う匠の技
>>44
実際意図的にそんなコード書く人もいるからなぁ。
マズイ処理A
＋匠「なにぃ？まずい？そんなのこうやってああやれば修正できるだろ」
＝正しいと思えるような結果
結果だけ見ても正しくても
なんでマズイ処理やってるのに結果が正しいのかわからない
理由がわからないので、結果が正しくても責任が持てない
余計なことをした匠だけが自信満々 単体テストなんかする工数が無いのでテスト無しで普通に開発してたがそんな現場の方が多いだろ
テスト運用中に不具合潰して本番後も不具合分かったら潰す
これが俺流のアジャイル
まあ、経験上やったほうが早く済む
っていうかできるような仕組みを心掛けるって感じ？
何ならレビューすらめんどくさがられてバグがあったら俺のせい
>>46
規模が小さくて、信頼性？知ったこっちゃねーよ
っていう所しか使えないけどね
SIって作りっぱなしで保守開発は客任せにするから
だからそんな事が成り立つ
客がいくら苦労しようが知ったこっちゃないという考え
自社サービスで長期間運営するとかには使えない
自分が苦しむからね データの仕様に沿ったプログラミングして本番データで間違い無いか確認出来たら安心
データの仕様が信用出来ないかも知れんし
>>49
自社サービスではないけど保守運用は請け負っていたぞ
だから自分に返ってくるけど納期優先だから後にツケを回さずを得ない
少ないリソースでスピードが求められる現場だから理想通りには進められない 単体テストしないとスピードが落ちるじゃん
バカなの？
それともチキンレースしてるの？
テストコードを書く時間とテスト実行にかかる時間で何倍もかかる
>>54
テスト項目数何件あるの？
1000件のテストを修正のたびに手動でやってられないんだが 問題はテストコード書く時間で十回は単体テストできることだな
手動派って一回しかテストしないですむのか、うらやましいな
>>56
手動でやっていて毎日全体テストなんてできるんですか？
コード修正するたびにテストしなきゃ
責任なんて持てないでしょう？ >>59
やる必要がどこにあるんだ？
自動テストを作成する工数が高すぎるのが問題
変更コストとかそもそも元のテスト仕様がドキュメントになってなくてこれまたクソ
そんでテストの内容も仕様書のどっからこのテストができるのか？これまた謎
あとシステムもよくない
ロジックだけをテストできる仕組みを現在の自動テストは持ってない
そうなるとカバレッジいくつがという数字だけ一人歩きを始めてその数字を100%にすることに何の意味もないっていうね
このクソシステムもやりたくない理由の1つ
それと実際に時間がかかるところは結合テスト
単体に必要以上に時間をかけてる暇は今の開発にはないと思う
そんなわけで自動テストはゴミ
いつもこの話を持ってくるやつには
プロジェクトで1番でかいメソッドの自動テストを組んでもらってお引取り頂いている
まあ、だいたい2週間経っても何も出ないやつが大半よ 自分ができないからってふわっとした手動テストで悦に浸る60であった
自動テストのコストが許容できなくなるほど高いのも60が見積もれないからやろ
一番デカいメソッド ←レガシーやん、見切られてるだけやw
>>60
テスト対象の仕様を把握してないから自動テストができないだけだろ
プロジェクトで1番でかいメソッドとやらのディシジョンテーブルをまず書いてみろよ >>62
そんなもの不要。
プロジェクトで一番でかいメソッドは
いきなり本番投入！
俺はプロだからな！ コンパイル通ったらバグが無いと思ってる素人より
テスト通ったらバグが無いと思ってる管理者の方が悪質
それはテストをしない理由にはなりえない
勿論自分はプロだから、なんて戯言も
>>62
書けば？ｗ
その時間に手動の単体テスト終わりそうだけどｗ >>66
ザルテスト・ザルではないことを証明できないテストを
やったところで、テストを通過したことにはならんよ
ザルの目を通過しただけのことだからね つーかディシジョンテーブル書いてみろと言った途端に皆ビビり過ぎ
まあ、1番デカイヤツヤラせて見ろよ
これで自動テストやろうぜ厨はリアルで潰せる
そいつは何の成果もあげられない絶対だ
こういうアホの思いつきをプロジェクトから無傷で追い出すのも立派な能力
掲示板でもガチでキレたらオープンソースの自動テスト作ってもらうで
自動テストの話はそれが終わるまでさせん
1番デカイヤツが糞過ぎて、ディシジョンテーブル起こせません渡せません。まで読んだ
オワコンなプロダクトにはオワコンな人間が跋扈する、と
自動テストなんか不要！
→ほーん、じゃあそれ手動でテストしてんの？
→そもそもテストしてませんでした
この流れだからなｗ
>>69
でかいやつの、手動テスト vs 自動テストか
まず手動テストやらせてみようぜ！ 自動テスト用のテストデータを自動生成するプログラムの
テストは自動テスト?
2000年ぐらいのときの人類は自動テストを
人工知能のように考えていた人がいるんだよ
ファクトリーオートメーションのような
コンピュータを導入した自動化のことだって
分かんなかったんだよ
念のために言うけどファクトリーオートメーションは
人間が何もしなくても勝手に何かものを作ってくれる機械じゃないよ
お前らが日々セコセコと作ったジャーナルやらのデータが既にあるやろってのが彼らの理屈
それを虎とよんで提出したら作ってやるという思想
自分たちで新しいデータを作らないという前提なの？
そら使えねわｗ
もしかしてユニケージってCOBOLで開発済みのたシステムを
リプレースするための開発手法なのか？
ビッグデータ解析とかに使うのが正解ってのがここ数年で出た答えやと思うぞ
COBOLのリプレスなんか出来んぞ
インデックスもロールバックもないしな
そもそもリアルタイムに処理なんかさせたら崩壊すんぞ
シェルスクリプトでビッグデータ解析をします。
え？どうやって？
まずシェルスクリプトを実行します。
そしておもむろにそのシェルスクリプトから
Pythonプログラムを実行します
それもうビッグデータ解析に使ってるのPythonやないかーい
PythonやろがCやろがawkだとしても、シェルのパイプで連結しとって、並列処理ができて作法に準拠しとればユニケージなんやで、それがオラクルよりも速いから信者がいるわけやぞ
これがWindows系のパイプやと処理が終わりきらんと次の処理にデータを渡さんけど、Linux系なら次の処理に渡すんよね
これをたくさん繋げるから並列に大量のデータに対して効き目があるんよ
って教え込まれて育つんやぞ
オラクルよりも早くなるのはデータが少ないときだけだから、ビッグデータを扱うと普通のデータベースより遥かに遅くなるという罠
>>83
それ知らんかった
エビデンスあるん？
興味あるわぁ >>79
ビッグデータ解析にユニケージが使えるわけ無いだろ >>85
え！インデックスもねぇーし、ロールバックすら出来なくて、データをリアルタイムに更新するとぶっ壊れるんやぞ
それやから夜間バッチでデータの持ち方を変更して行くのに、ビッグデータ向けじゃないとは？ >>84
エビデンスの話をするならユニケージの方がオラクルよりも速いというエビデンスがないんだよ
ユニケージはオラクルよりも速いと主張してるだけで
エビデンスを提供してない ユニケージはファイルの書き込み量が多すぎるんだよね
なんか今のディスクは安いし大容量だから
そんなの気にしなくて良いって反論してるみたいだけど
気にしてるのは、ディスク読み書きの量が多かったら
遅くなるという所なので反論がまとはずれ
オラクルとかはメモリ内でほとんどのことを処理するので速い
>>84
例えば数十GB、数千万件ぐらいのデータをデータベースに突っ込んで
日付項目にインデックスを張った状態で
特定の日時範囲のデータを数十件を取得するのと
ユニケージコマンドで全体なめて検索するのとでは
圧倒的にデータベースのほうが速い >>89
ほう！ほう！
ええねぇ～ええねぇ～
そうすると所長は検索なんやから項目を無作為に選べないととか言い出すんやろなぁ
奴らの言う一休さん方式こそインデックスをはるポイントやなか？ >>90
何が言いたいのかわからないわ
でたらめな文章をごまかすためにエセ関西弁で書いてるの？ 皆どんぐらいユニケージさわっとるの？
おいは数年前に３年ほど
>>90
テキストファイルにインデックスはってどうするの？
そのインデックスを使うコマンドが存在しないんだが >>93
この3年でユニケージ以外のプログラミング技術
何ができるようになった？ ユニケージにかかわると、成長できない人間になっちゃうのよ
あれ、どれだけ勉強せずに仕事をこなすか（単純作業を繰り返すか）が
メインの開発手法だから
ユニケージは飲みニケーション重視の文化だからねｗ
昭和かって思う。
インデックスを、はるん違うよ
そこが何かやりたかった箇所じゃない？って意味
まぁ概ねその通りやね、リアルタイム処理が出来ない事とか認めんしね
引っ張り出した後のデータを加工する側はユニケージやなかったから色々他にも触っとったよ
ソフトウェア工学的に間違っていることに対して
「一休さん方式」とか名前をつけると
それを新しい手法とか勘違いするような間抜けが釣れるんだろうね
いやさ、常識で考えてみ
こんな弱小ベンチャーが思いつくようなこと
世界でとっくに考えられてるからさ
そして、ああこれ、だめな考え方だねってなったから名前ついてないの
プログラムを書く前に、データベース設計を先にやりましょう
でもデータベースを使わないから
一休さん方式という名前をつけたのね（苦笑）
経営者や高齢をターゲットにしたコンサルもどきの資料だね
言いくるめるにはこういうのもありなんじゃね、誠実かどうかは置いといて
ユニケージなんか使うよりそこらのDBMSのほうが早いし、商用ならカスタマーサポートもある
ユニケージの人たちってUSP、ユニバーサル・シェル・プログラミング研究所とか
名乗ってるけど、あそこの人たちが研究してるのはユニケージであって
シェルスクリプトじゃないんだね
他の会社よりも少しUNIXシェルを使ってましたってレベルで
シェルスクリプトの専門家じゃない
都合がいいから、そこにアジャイルってフィルタも被せるんやぞ
ID:qE3yIUXX
こいつは結局POSIX原理主義者だったんだろうか
それともユニケージ幻想を捨てきれなかった哀れなエンジニア崩れだろうか
