2021/11/01週 気づきと振り返り 嘘つくの辞めてもらっていいですか？

業務こなしての問題・気づき

ほとんど開発はしてない。。。

コードは自動生成する現場らしいのだが、メリット薄いように感じるのは、俺だけだろうか。。。？
誰でも気軽に副作用なく使えるのなら、自動生成のメリットがあると思うけど、そんな現場は稀だと思うんだよね。。。
限定的な範囲で、小規模な範囲を自動化するのなら、アリだとは思っているが、日本の開発現場って、開発全体を自動化しようとするから、色々失敗すると思う。

まずは、限定的な範囲だけ自動化して、徐々に範囲を広げていくほうが、知見ためつつ暗黙知を減らせると思うんだけど、どうだろうか？

趣味開発での問題・気づき

実装したつもりだったけど、あんまり使わない機能だったので確認が漏れていた。
速攻で対応したけど、カバレッジ１００％でも、やっぱり漏れはでるよなと思った。
そもそもロジック追加してない時点で、カバレッジじゃ気づけないしな。。。

その他雑記

ワクチン接種２回目

何も副作用が出ないのだが、本当に効いているのか？
今回は、注射がやたら痛かった。
注射するやつがド素人だったのではないかと思っている。

みんな、副作用ガーとか言っているけど、嘘つくの辞めてもらっていいですか？
仮病で会社休みたいのは分かるけど、嘘は良くないよ。

在宅勤務

在宅勤務の現場に入った。
通勤の辛さから開放されるのが嬉しすぎる。
ちょうど、人が増え始めてきたから、満員電車乗らなくて済むのは、かなり快適

2021/10/24週 気づきと振り返り 何も成果が得られませんでしたぁ！

業務こなしての問題・気づき

月末だったので、ポケモンのランクマを集中してやってた。

その他雑記

コードの自動生成

少し採用している案件の話を聞く機会があったのだが、ラーニングコストが洒落にならない状態らしい。
バージョンアップとかにも金がかかるし、自前で作成舌コードを管理する流れになったらしい。

本当にそうなのかは、金の流れを見てないのでなんともだが、自動生成に夢を見すぎた結果だろうな～と思った。

今、ローコードが話題になっているけど、どうなんだろう？
個人的には、狭い範囲で適用していると思っているが、企業が使うコードの大部分をローコードでなんとかしてたら、ラーニングコストが高そうな気がしないでもない。

まぁ、プログラミングで飯を食ってるので、コードの自動生成は敵対関係にあるから、客観的に見れて判断できているかは若干怪しいけどな。。。
自動生成は、黒魔術がいっぱい詰まる可能性が高いから、過度な適用はやめるべきだと思っている。

黒魔術を使いこなせるのは、奇抜な髪型で変なパズルを首からぶら下げてる二重人格者だけだろうなと思う。

【OCPJ】マルチキャッチは暗黙的例外

きっかけ

OCPJ11 Goldの勉強をしている際、マルチキャッチの問題を解いた際に間違えたので載せる。

テストコード

public class Ocpj3_9 {
    public static void main(String[] args) {

        try{
            throw new Ex1();
        }catch (Ex1 | RuntimeException e) {
            // eは暗黙的にfinal!!
        }
    }

    static class Ex1 extends Exception {

    }

    static class Ex2 extends Ex1 {

    }
}

varが導入されたので、再代入可能かと思ってしまったが、

参考リンク

複数の例外型のキャッチと型チェックが改善された例外再スロー

小さく注記で複数の例外型を処理する場合、catchパラメータは暗黙的にfinalになりますって書いてあるのを見て、怒りが爆発するところだった。

所感

実行時に型が決まるのだろうか？
エディタ上で見る限りは、複合型のようだったが、ここら辺の仕組みはどうなっているのだろうか？
型に厳密な言語である理解でいるのだが、ここら辺が少しあいまいになっているなぁ～と感じた。

【OCPJ】JavaのAutoclose時の例外発生時の動きの勉強

きっかけ

OCPJ11 Goldの勉強をしている際、Autocloseの問題を解いた際に躓いたので、勉強がてら実際にコードを書いて試したので載せる。
ここら辺は、機能追加されたときにしっかり勉強したので大丈夫かと思ったが、間違えたので、結構ショックだった。。。

テストコード

※問題集のコードをそのまま載せると問題だと思ったので、ちょくちょく変えてる。

public class Ocjp3_4 {

    public static void main(String[] args) {

        try(Foo foo = new Foo(); Bar bar = new Bar()) {
            System.out.println("1");
        } catch (Exception e) {
            System.out.println("4");
        }finally {
            System.out.println("5");
        }

    }

    public static class Foo implements AutoCloseable{

        @Override
        public void close() throws Exception {
            System.out.println("3");
        }
    }

    public static class Bar implements AutoCloseable {

        @Override
        public void close() throws Exception {
            System.out.println("2");
            throw new RuntimeException();
        }
    }
}

実行結果

1
2
3
4
5

躓いたところ

Autoclose時に例外が発生した場合、close処理が終了するかと思っていた。。。
なので、自分の期待値としては、1245だった。
回答を見て、よくよく考えたら、Autocloseしない方が問題だから、12345で動かないとダメだと思ったので、実行結果には納得できた。
例外が発生しても、Autocloseが完了するまで例外を一時的にストックしているのだという理解でいる。

close順は、定義順の逆順だったのは知っていたので、そこには引っかからなかった。

2021/10/11週 気づきと振り返り アーキテクチャの検証ってどうやってるんだ？

業務こなしての問題・気づき

闇を見ているのかもしれない

今、参画しているプロジェクトで、アーキテクチャレベルの問題を抱えていることが分かった。
単体テストがやりにくく、テストを通すためのテストデータを作ってしまうので、テストにならない場合が多いように感じた。
そんでもって、新規参画者がキャッチアップするのに時間がかかり、責任批判が参画者に飛んでくる状況だった。。。
問題は参画者ではなく、アーキテクチャにあるはずなんだが、おそらく、「新規参画者が～」を理由に、真因に迫れてない気がする。
たぶん、問題を上げる場合に政治問題が絡んできて、問題意識が現場と管理者で違っていると思われる。
だから、いつまでたっても改善はされないし、参画した人は毎回責任を追及される状況になっている気がする。
管理者がちゃんと現場知っているかが重要だと思う。

まぁ、複数ベンダーで開発しているので、政治問題が否応なし絡んでくるのだろうなと思う。
その政治問題がいろんなものを歪めている気がする。

だから、内製化したがる方向が潮流になり始めているのだと思った。
たぶん、初期開発時の問題が、最近になって顕著になってきた or 表面化しだしたのだと思う。
アーキテクチャの問題だから、問題が表面化するのに時間がかかったのだろうと推測しているが、実際はどうなんだろうか？
アーキテクチャの正否って、実際に使われてみないと分からない気がする。
そもそも、アーキテクチャのテストってできないからな。。。

汎用化の弊害

汎用化しようとして全部定義ファイルに追いやった結果、ロジックが定義ファイルに入って、新規の言語を使っているような感じになっている現場であることが分かった。
内容見る限り、BASICベースのxmlで記述可能なプログラミング言語みたいだった。。。
開発者の神経をすり減らしそうな内容だったので、チラ見してファイルは閉じた。

趣味開発での問題・気づき

自動テストについて

品質の維持はできるけど、高めることはできない認識をした。
最近、ユニットテストを作成して実際に導入したけど、品質維持には貢献するが、向上には、あまり関与しないなと感じた。

今は、初期開発が終わったら、実際に動かして動作確認したあと、テストケース自動生成ツールで簡単に高いカバレッジを維持できるテストケースを作成している。

その他雑記

ワクチン接種

１回目の接種をしたが、打たれたのか？ってくらい痛みがなかった。
筋肉注射だからだろうか？
むしろ、健康診断で血を抜かれるときのほうが痛い。

アーキテクチャの検証

アーキテクチャの検証って、どうやっているのだろうか？
今まで触れてきてなかったところだから、どうやっているのだろうかと疑問を感じた。

サンプル実装しただけだと、本当の問題とか分からないと思うんだよね。

リリースしたあとだと、アーキテクチャ変えるのは難しいだろうし、リリース後に変えたいとかになったらどうするのか気になった。

2021/10/04週 気づきと振り返り covarageで悩まされた

業務こなしての問題・気づき

なし。テストするだけなので、新規の発見をするのは、かなり難しい。

趣味開発での問題・気づき

sonarcloud

covarage計測

プルリクを何度か出して解析していたら、とうとうcovarageに引っかかることに。。。
今までは行数自体が少なかったから引っかからなかったけど、大型機能の追加したら、引っかかってしまった。。。

回避方法を考えたが、どうせ後々対応するのなら、今のうちに入れてしまおうと思い、ユニットテストを追加した。
ユニットテスト追加すれば突破できると思っていたが、テスト結果のレポートを取り込まないとcovarage計測がsonarに連携されないことに気づき、結構悩んだ。

対応としては、jacocoのレポート出力機能を利用して、sonarにカバレッジ情報を連携するようにした。

jacocoとsonarcloudの連携方法

自分は、下記の方法で連携するようにした。

plugins {
// 省略
    id 'jacoco'
}

// 省略

sonarqube {
    properties {

// 省略

        // jacocoのレポート出力先
        property "sonar.coverage.jacoco.xmlReportPaths", "build/reports/jacoco/test/jacocoTestReport.xml"
    }
}

// 省略

test {
    finalizedBy jacocoTestReport // report is always generated after tests run
}

jacoco {
    toolVersion = "0.8.7" // これはコピペしてきただけなので、検討の必要性あり
}

jacocoTestReport {
    dependsOn test // tests are required to run before generating the report
    reports {
        xml.required = true
        csv.required = false
        html.outputLocation = layout.buildDirectory.dir('jacocoHtml')
    }
}

大事なのは、xml.required = trueの設定をすること。
これが有効になってないと、連携用のxmlが出力されない。
上記設定でgradle testを実行すると、build/reports/jacoco/test/ に jacocoTestReport.xml が出力される。

ユニットテスト

TestMeを使ったテストケースの自動生成

sonarcloudのカバレッジ計測で少しでも楽しようと思い、ユニットテストの自動生成について調べていた。
100%自動生成するのは無理だと分かったときは、絶望した！

IntelliJプラグインで、TestMeがよさげだったので、利用することに決定。
開発はIntelliJでやっていたので、敷居が低そうだったってのもある。

Mockitoは、以前利用していたので、難なく利用できた。
JUnit5+Mockitoでユニットテストを生成した。

生成されたテストケースは、カバレッジが高くなるようなケースが自動生成されるようだった。
追加で必要だったのは、期待値の記述だけ。
あと、モックの設定くらい。

使っていて思ったのは、DIを利用するとテストが楽になるなと思った。
後は、Mockitoが便利すぎてヤバイ。
Mockito、マジやばくね？

参考サイト

ユニットテストの自動作成ツールを調べてみた(2019年末版） - Qiita

TestMe - IntelliJ IDEs Plugin | Marketplace

その他雑記

国際フォーラムの解放

そういえば、10/1で国際フォーラムの通行止めが解除されたので、京葉線から品川方面への乗り換えに利用することに。
今まで京葉線ホームから東京駅ホームへ移動するという苦行からやっと解放された。
京葉線から有楽町までの距離と変わらないが、京葉線から東京駅ホームまでの道のりは殺風景だから、心理的に長く歩いてる感じがするんだよね。
今は、京葉線から有楽町までは、人が少なくてかなり快適。

料理

野菜炒めのあんかけ

あまった野菜を適当に炒めて、甘酢餡を作ってかければ、それなりにうまいものが作れることが分かった。
野菜の消費が簡単にできるのがいいと感じた。

2021/09/27週 気づきと振り返り 静的コード解析はボッチの強い味方

業務こなしての問題・気づき

開発後の工程によるドキュメントの理解

書いてあることで100%理解できるドキュメントって、かなり難しいのではないかと感じている。
挙動と合わせて読みすすめないと厳しいと正しく読み込めているか、怪しいと思った。

かなり信頼できるところでは無い限り、ドキュメントの記述と挙動が一致しているか確認する必要があると感じる。
製品として出されたものは、ある程度信頼できるが、開発してテスト前とかテスト中だと、ドキュメントに100%の信頼を寄せるのは危険だと思う。
信じないわけではないが、挙動とセットで信頼にたるものか判断する対応が必要だとは思った。 ※修正対象範囲外についての話

見つけた役立ちそうなサイト

gitのMerge済みローカルブランチを削除

gitのMerge済みローカルブランチを削除する - andooown's blog

gitの不要なブランチが溜まってきたので、簡単かつ安全にブランチ削除する手段はないものかと探したときに遭遇。

確認というステップがあるので、誤削除少なそうだと思いました。

趣味での開発の雑記

sonarcloud

sonarqubeを導入しようと思ったが、環境構築が面倒だな～と思って調べていたら、sonarcloudなるものを見つけた。 パブリックリポジトリなら、無料だったので利用するように対応した。
自分は、githubから連携して利用するようにした。
プルリクエスト作成時にGithubActionsで、修正箇所についてコード解析するようにしてある。
あと、ローカルでも確認できるように、sonarcloudに解析依頼するgradleのタスクを作った。

解析した結果、ほとんどbugがなくて、さすが俺と思った。
普通に開発するよりは、自信がつくので、開発能力が疑心暗鬼な人、能力に自信がない人は、導入を検討したほうがいいと感じた。
あと、レビューしてくれる人がいないぼっちには、最適なツールだと思う。

使っていて思ったのは、解析結果の対応をどうやってやっていくか、いい案が思いつかなかった。
現状は、手動でissueを作って対応のブランチ作って、マージしている。

プルリクエスト作成時のsonarの解析は、少し時間がかかるので、もう少し短縮できないか、検討の余地はありそう。
なんか、余計なものが実行されている気がする。。。
githubActions不慣れなのが、要因としてありそう。。。

おかしな実装の発見

sonarcloudで解析した結果を見ていたら、何をしているのか意味不明なコードがあった。

具体的に言うと s.indexOf(s) < 0みたいなコード。
俺も、何をしたいのかよく分からんかった。。。
自分が作ったはずなんだが、記憶にない。
たぶん、何かのタイプミスだと思うのだが。。。

変な実装でも、ちゃんと抽出してくれるのは、使っていてありがたかった。

overviewでの表示

なんか、ランク付けされるんだな。
"A"とか"E"とかあるから、パワプロみたいだなって感じた。
"S"があると狙ってしまうのだが、表示の切り替えってできるのだろうか？

今後していきたいこと

１リポジトリに複数言語のソースがあるのだが、解析できるのだろうか？
現状、Javaしか解析してないけど、HTML/Typescriptあたりも解析できるようにしたい。

その他雑記

料理

最近、在宅勤務が終わったので、あんまりできていない。。。
会社が弁当配達のサービスを契約してるので、昼はそれを利用して、食が偏らないようにしている。
たぶん、コンビニ弁当食べるようにしたら、油ものに偏る気がするんだよね。。。
コンビニ弁当って、油もの多すぎだろって思う。

在宅勤務

在宅勤務が終わって１ヶ月たったが、超辛い。。。
出勤って、何も対価がないのっておかしくない？って思い始めた。
メリット何も無いよな～って感じるのだが、何かある？
美人を眺めるくらいしかメリットがない。
しかし、美人がいるのは極稀なので、ほとんどデメリットだな。