Show newer

ソースコード+コメント・アノテーションでドキュメント作成と単体テストケースをある程度自動化できるようになれば楽なんだけどなぁ…

なんかできそうな気もするんだが🤔

私の作る「~のメソッドを作成せよ」系の設問だと,Main()に単体テストが書いてある.メソッドの在非を調べるところからテストしている.

バックエンド側というか内部プログラムの単体のみJUnit書いたりするけど、画面系も自動化するならロボットツールに操作を覚えさせてやる、とかかなぁ🤔

テストを書くというがどうテストを書いていいかよく分かってない。NUnitはやったことあるけど、あんな感じでいいのかな?でも、画面系とかどうするのって感じ。🤔

「この村では10年火事おきてないから消防署はいらない」っていうのと一緒だと言うと気付いてくれるケースは「多い」けど稀にそれでも「消防署と違って人死にが出るわけじゃない」と押し切られるケースもある

JUnitみたいなテスト自動化の運用保守を開発者に割り当てない仕組みにならないかなぁ

別途担当者を割り当ててメンテしたほうが良いと思うの
あとドキュメントも

リファクタリングしたいけどそうするとテスト工数が跳ね上がる問題がなぁ
テストの自動化なぁ
自動化したテストのメンテになにもかも吸われるのがなぁ

本物の土建屋さんに置いて行かれてしまう

日本のシステム業が土木建築業の系譜にグループされてしまってるからなぁ…

稼働したものに対して手を加える敷居が高くなってるんじゃないかと思う

ただ土建業自体は現在、新技術の導入やメンテのコストを理解して計画しているみたい…

余裕がなさ過ぎるのよね今のシステム屋さんは

日本のシステム屋は「動いているものは触るな」とウン十年前から言い張り,一方,米国のシステム屋は「リファクタリング」という概念を作った.

日本のソフトウェア工学の限界を見るようだ.

個人的にはTEXTJOINがテストデータ用CSVファイル作成とかに便利なのでExcel2016を何卒…

Excel2016から複数セルの文字列結合便利になったよね(CONCAT関数)

だから2016入れたいんですよね(2010使用)。。

あーーコンカートネートあったな

docker-compose.ymlはたまに修正入るので、Docker勢はアプデ前に確認したほうが良いかも

基本的にそのまま利用してるのなら、
修正を取り消し→最新版をチェックアウト→ファイル修正
ってやったほうが安全(自分がその運用)

自分なんて最近はミニ四駆インスタンスでガンプラの話しかしてないんじゃないかと思うよ

あとSSSS.GRIDMAN

そうそう
マストドンという仕組みについて技術面だったり(コミュニティー)サービス面だったりでしっかり考えられる人すげぇなぁって思う

マストドンの仕様について語る人と、マストドン上でのコミュニティについて語る人で、大きく分かれてる。
その両者ともハイブリッドに把握してる人って、すげーと思う。
おいらはどっちも浅いもんで。

Show older
ミニ四駆DON

ミニ四駆好きが集まる雑談中心のインスタンスです