ID:43610さん

# この案件の参画から終わりまで ## ECサイトの概要 ある海外ブランドを、自社パッケージを利用し構築。 ## 配属直後 2017年9月に入社し、初めて配属された案件。 初のRubyとRailsでの開発であったが、ドットインストールや、RailsチュートリアルなどでRubyとRailsを学び、案件の足を引っ張らないよう学習時間も設け仕事をした。 ## 課題 ### Railsの思想に沿っていなかった闇のコード達や、バグ達 RailsのメインであるDRYのコーディングに沿っておらず似たようなコードが乱立し 定数もcontrollerやmodelなどに変数として記述されいてた ### 担当社員が音信不通 ある日お昼にでかけてからそのまま帰ってこなかった そのせいもあり引継ぎ等も正確に行われなかった ### 影響範囲がわかりにくい。 本来定数で定義されていたほうがよい値が各ファイルごとに定義されているため修正漏れが起こりやすくなっていた。 ### 修正範囲が広くなりすぎるため工数が嵩む、バグが増える 本来共通化されていると思われていた箇所であっても別々のファイルで管理されているため 影響範囲調査に時間がかかったり、単体テストにも時間がかかっていた ### その問題は今までなぜ解決できなかったのか？ 元々担当していた社員や、当時はまだエンジニア育成などのカリキュラムもなく 割と無理やり業務をこなしていた部分があった また人数も少なくレビュー体制もしっかりと整っておらず１名でフロント、バック両方担当している案件であると 誰もレビューに入らずそのまま検証環境にアップしてテスターが確認するという手段が多かった なので画面上の動作に問題がなければＯＫという状態が続いていた ### 解決のために レビュー体制や、１名体制の部分は会社の規模などでどうしようもなかったので... 自分の当時持っていた知見を最大限生かしてリファクタをさせてくださいと志願した。 以下がその対応 ・複数の箇所で使い回せるコード(金額計算や金額の整形(消費税など))はHelperに書き出し ・controlleで行われていたDB操作はModelへ移す ・各ページで似たようなコードがviewファイル毎にコピペで散りばめられていたのでコードの共通化としてテンプレートとして書き出し。同様のパラメーターで検索出来るように。 ・controllerなどにファイル名をベタ書きしている所があったのをyamlファイルなどに書き出し定数として管理。 ### 結果 ・修正漏れでのバグの数が圧倒的に減った。 ・コードの共通化のおかげで影響範囲調査委、修正範囲が少なく工数削減