はじめに
22年度新卒で株式会社LIFULLに入社したYamashita-Taikiです。
最近35インチのモニターを導入して仕事の質が爆上がりです（してますよね？？？）
今回は内製OSSの自動テストフレームワークであるBucky-core、その結果レポートを担当しているBucky-managementのUIを改善したので、そこで学んだことを書いていこうと思います。
Bucky-coreやBucky-managementについては以前社員の方が詳細について投稿してくださっているのでその記事を見ていただければと思います。
今回挑戦したこと
実行されたテスト結果を表示するページのUIを改善しました。
まずbeforeとafterの画像を添付します↓
before（実際には30件並んでいます）
これでも十分使い易いのですが問題点がいくつかありました。その中でクループ内で一致した意見が
- rerun元のテストがどれか分かりづらい！！！！！
ということでした。
といいますのも、上の画像を見ていただくと大きく分けて2種類のコマンドがあります。
- bucky run hogehoge
- bucky rerun job_id hogehoge
です。
それぞれ、
runは初めて走ったテスト
rerunはfailしたテストをもう一度走らせるテスト（job_idの後ろにはrerun対象のテストのidが入ります）
です。なので画像でいうと
9397のテストがfailする→9402でrerunされるが、またfailする→9402が9405でrerunされる
という流れになりますね。
画像では3件しか表示していない＆連続しているのでわかりやすいですが、実際に運用していると
- 30件並んでいる
- runとrerunの間に別のテストが表示されて順番が連続していない
という状態で結構見ずらいんですよね。。。
それが原因で意図していないテストをrerunしてしまったりしていました（主に僕が）
after
これらの課題を解消した結果がこれです
インデントを下げる＆線を書くことによってテストがどのテストのrerunなのかがわかりやすくなっていると思います。
成果物
実際のコードも記載しようかと思いましたが、文章でうまく説明できる自信がなかったので、PRを載せておきます。
今回学んだこと
今回のこの業務では本当に色々なことを学べました。以下に記載していきますね。
1.素のRubyでの開発
今までRailsでしか開発したことがなく、「Railsはなんとなくで書けるが、Rubyは書けない」という状態でした。今回はRubyでの開発でしたが今回の経験のおかげで「言語に頼らない自力」を得られた感があります。
また今までRailsがいい感じにやってくれていたブラックボックスの部分が良くわかるようになりました。
2.公式ドキュメントの読み方＆読みに行くという習慣
最初はQiita等の2次情報に頼り切っていたのですが、上司から「できるだけ公式ドキュメントを読みに行こう」というアドバイスを頂きました。
最初は「公式ドキュメントわかりくいやん。。」となっていました。
上司に隠れて2次情報をを読んでいたこともありましたが
しかし、メソッドの仕様に詰まったことがあり、その時に公式ドキュメントに助けてもらい偉大さを実感しました。
おかげさまで今は一番最初に公式ドキュメントを見に行く癖が付きました。
例えば配列を作成する処理があったのですが、作成された配列が同じオブジェクトvalueを参照しており、一つに変更を加えたいのに全ての値が変わってしまうということがありました。
具体的なコードは以下です。（実際はこのコードは採用していない＆変数名などは適当に変えてます。）
hoge = [
{:id => 0, :commnad_and_option =>"runa"},
{:id => 1, :commnad_and_option =>"runb"},
{:id => 2, :commnad_and_option =>"rerun1"},
{:id => 3, :commnad_and_option =>"rerun2"},
]
@job_tree = Array.new(hoge.last[:id]+1,{:job_id => nil, :children => [],:is_checked => false})
fuga = @job_tree.last[:is_checked] = true
配列を作成する方法はnewメソッドのこの記法しか知らなかったのですが、これだと結果が↓になってしまいます
[{:job_id=>nil, :children=>[], :is_checked=>true},
{:job_id=>nil, :children=>[], :is_checked=>true},
{:job_id=>nil, :children=>[], :is_checked=>true},
{:job_id=>nil, :children=>[], :is_checked=>true}]
最後の要素の:is_checkedだけをtrueしたいのに！！！
と思っていた時に公式ドキュメントにはこう書かれていました。
要素毎に val が複製されるわけではないことに注意してください。全要素が同じオブジェクト val を参照します。
全部の要素が同じオブジェクトバリューを参照していたので、全部変わってしまっていたみたいです。
同じドキュメントのページ下部に、それを回避する書き方も記載があり、無事解決できました。書き換えたコードは↓です。
@job_tree = Array.new(hoge.last[:id]+1){{:job_id => nil, :children => [],:is_checked => false}}
pp fuga = @job_tree.last[:is_checked]= true
結果は↓なります。
[{:job_id=>nil, :children=>[], :is_checked=>false},
{:job_id=>nil, :children=>[], :is_checked=>false},
{:job_id=>nil, :children=>[], :is_checked=>false},
{:job_id=>nil, :children=>[], :is_checked=>true}]
もう公式ドキュメントしか愛せない
3.ロジックを考えるという難しさ
最初「こんなの作りたい！」となっても「で、何すれば良いの？？」という状態になることがよくありました。頭が真っ白になり、中学のときに数学の証明問題を解いている気分になりました。
「エンジニア向いてないかも。。。」と思うくらい悩んでました。
自分に足りなかったのはゴールから細かく分解する能力でした（今でもまだまだです）。
これに気づいたのは料理をしているときでした。
- hoge食べよー ←何食べたのか忘れた
- 材料はなんや？？
- A,B,Cがいるんか
- Aはどんな切り方したらええんや？？
- Bはどんな下味をつけたら、、、、、、あ！
気づきました。料理をするときはゴール（何を作りたいか）を決めて、材料を調べ、どんな調理をするかというのを細かく分けて考えるのに、開発するときはいきなり完成品を作ろうとしてしまっていました。
それに気づいてからは人が変わったように開発を進められました。
この経験が一番貴重だった気がします。
4.rubocopやrails_best_practice
rubocopやrails_best_practiceはお恥ずかしながら個人開発では使ったことがありませんでした。（動けばええやろと思ってました）
しかし、この仕事で過去に人が書いたコードを読むという経験をできたことで「自分以外の人が読みやすいように書こう」という意識が生まれ、これらのコードチェックの大切さを実感しました。
5.M1Mac✕Docker環境でのエラー解消
詳しく書くとそれだけで記事が作れてしまうので今回は省略しますが、かなりしんどかったです。。
「開発環境を楽にするツールになんでこんな苦しめられなあかんねん」と何度も思いました。
ハードウェア方面のエラーはしばらくお腹いっぱいです。
終わりに
今回の業務は僕が「もっとコード書きたいです」と言う希望を上司が聞いてくれて挑戦させてくださいました。 @nk-tyさんありがとうございます
お陰様でとても良い経験ができ、エンジニアとして少しはレベルアップできたかなと思ってます。
詰まったときはアドバイスをくれた同期もたくさんいて、ありがたい環境で働けているとな感じました。
今やりたい仕事としては（社内の方々への強いアピール）
- もっとコード書きたい
- RSpec書きたい
- CI,CDを構築したい
- モバイルアプリ作ってみたい
です！
これからもがんばります。
読んで頂きありがとうございました。