  |
はてなキーワード: Guiとは
テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
GでもCでもUIはまた別
結論としては書かないほうがいいと思った。
そういうこともある
全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
まあそれはないだろう
それはデバッグの一環のような
一番よくあるやつ
そこのバランス考えないと
バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる
悪いね
テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね
上にも書いたけどパーツがでかいのでは？って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど
バックエンドのビジネスロジックなど書いた方が絶対にいいものもある
ネット上ではテストコードを書かないのは低レベルな開発者という風潮だ。
10年以上、テストコードを書く開発と書かない開発の両方を経験してきた。
■前提
・テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
結論としては書かないほうがいいと思った。
・テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
・100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。
・テストコードを書くと実装の見落としが見つかってありがたいことはあった。
・git pushするたびに毎回走っても全くの無意味だった。
・テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。
・その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。
・GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。
・テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
そうそう。
GUIのシステムって、どのボタンが押されてどのテキストボックスにどういう入力がされたかって記録されないから厄介。
CUIなら、ユーザーの入力内容を逐一記録してログに残すのがとっても簡単。
だから、トラブルや作業ミスがあったときには、ユーザーがどんな操作をしたのか確認できるから便利だしね。
もちろん、過去に打ち込んだコマンドを再実行できるのもいいメリットだね。
現在、個人が運用できる生成AIはStableDiffusionが主流であり、多くの便利なプラグインもそれように開発されている。
しかし本家本元のStableDiffusionnはコマンドラインでしか動かず、極めて不便である為、それを元に開発されたGUI版である、
Stable Diffusion web UIが事実上の標準となっている。そしてStable Diffusion web UIや多くのプラグインは基本的に個人開発である。
つまり、適当な罪状をでっち上げて開発者を逮捕、勾留し、証拠隠滅を阻止すると言う名分で開発環境を取り上げればいい。
Winnyは裁判の結果、開発者は無罪となったが、Winnyの更新は停止し、代替となるようなファイル交換ソフトの開発に一定の歯止めをかけた。
そうして、稼いだ時間でファイル交換ソフトの監視体制を作り上げて、各プラットフォームが合法な配信環境を整えるまで権利を守ることができた。
生成AIは技術的に合法であっても、もたらしている被害はWinnyに匹敵するか、それ以上であり、Winnyの開発に歯止めをかけたのと同じように、超法規的な手段で開発を止める必要がある。
最終的に裁判で開発者が無罪となっても、一時的にでも開発者を萎縮させ、無規制な生成AIの氾濫を止めることができれば、開発者個人を法に基づかず逮捕することは正当化される。
