見出し画像

本気で働きたい会社に出会えたので未経験の自分が真剣に勉強してコードチェックに挑んでみた話

・自己紹介

こんにちは、地方で教職員をしているokaです。
年齢は33です。簡単な職歴ですが
・とあるスポーツでIH優勝の指導経験が有り
・国立教育政策研究所教育課程研究指定校事業で授業や評価方法に関する工夫改善の登壇
・キャリア教育に特化した新設コース立ち上げ〜運営まで経験
・産官学連携したものづくり事業の立案〜実施
などなど、、、
を行いつつ、日々の業務では主に業務改善を、授業では電気、電子、情報の分野をメインに行ってきました。
そんな中、この一年ちょっとの期間、真剣にSwiftを勉強をしてきました!
(もっと詳細を知りたいと言う方こちらもご覧ください※以下日付順)

・実際に業務をしたいと思った経緯

そんな自分ですが、ある日”もっとスキルを伸ばしたい”と思うようになりました!そこでこちらのサロンに入会させて頂きました!

ここではオーナーであるakioさんを中心に、様々なコードの書き方を学ばせて頂きました。今までは動くものを作れる事に喜びや楽しみを感じていましたが、いかに安全で保守性の高いコードがどうしたら書けるか、なぜそれらを意識する事が大切なのか。を中心に、より業務内容に近い分野も学ばさせて頂きました。その中で”もっとスキル伸ばしたい”という欲に駆られていきました!!

そこでこの先の人生を考えてみた時に、業務に入ってもっとリアルな技術を学んでみたい!と思い転職を意識し始めました。

・転職活動をしてみて→惨敗!!

上記のサロンでは主に学習する時に利用させて頂いています。(自分の中では大人の通信制学校的な存在)しかし転職活動は人生に関わる部分だと思い、こちらのコミュニティで記録を残すように発信しながら活動してみました。

当初
・wantedly
・Green
を中心に活動していましたが(Twitterでも少し発信してみたところ、何社かお声がけ頂いた)カジュアル面談で”未経験”と言うキーワードを出すだけで一気に顔色が変わり、お断りされてしまいました。
更にその内の数社からは年齢と未経験で転職する事はほぼ無理ですよと厳しいお言葉も頂きました。これを5,6回体験した所で自分には無理なのかと少し思い始めました。

・未経験でも技術があれば転職できる!?

そんな中、以前からよく耳にする”エンジニアは技術さえあれば転職できる”と言うワードが頭をよぎります。(アレ?つまり未経験でも技術さえあれば働けるんじゃね?)
だったら、技術磨いて、履歴書じゃなくコードチェックで受けた方がいいじゃん!と思い、以前から気になっていた企業さんで実際にコードチェックがある企業さんを受けてみる事にしました!

・実際に受けてみるーその1

まずはカジュアル面談を受けてみました!そこでは技術的な事はNGとありましたが、本当に対応して下さった方が優しい方で技術的な話からコードチェックに関する話まで沢山教えて頂きました!その中で
・Gitをプルリクベースで行うことが望ましい
・Gitの使い方は結構重要
と言うお話を聞き、”Git全然やってきてなーい笑”となりました。そんな事でGitの勉強を1週間みっちり行い(コミュニティでめちゃくちゃ親切に教えて頂いた)いざ望む事に!

学習の様子(一部抜粋)

スクリーンショット 2021-07-16 22.31.29
スクリーンショット 2021-07-16 22.32.15
スクリーンショット 2021-07-16 22.32.36

これでやっと自分を試せるぞと思った矢先、

正式にご応募をいただける場合はこのメッセージへの返信にて、履歴書・職務経歴書をお送りくださいませ。改めて書類選考を進めてまいります。

え?まず書類選考あるの?と思いました。(今考えたらそりゃあるよな笑)
ここですごく嫌な予感が頭をよぎります。(あーまた未経験だから落ちるのかもしれない)恐る恐る履歴と職歴をまとめてPDFで送りました。

結果、、、

書類選考の結果、ぜひ次のステップである
コードチェックのご対応をお願いしたくご連絡いたしました!

と言う事で無事コードチェックを受けられる事に!!(めちゃくちゃ嬉しかったのとホッとした気持ちとよし頑張るぞ!と言う気持ちが色々と入り混じった!!)

お題はGitHubにリポジトリがあり、そこからbare cloneで一旦ローカルに落としてMirror pushで自分のリポジトリにあげて行うもので、基本的にRefactoringを行うものでした。

・実際に受けてみるーその2

課題内容については3段階のレベルでお題が用意されており、どの順番から行っても良いとなっていました。しかし、経験不足な私にはすっ飛ばしてやる事は難しかったのでここは素直に順を追って課題を進めました。

課題の様子(一部抜粋)

スクリーンショット 2021-07-16 22.37.04
スクリーンショット 2021-07-16 22.37.33
スクリーンショット 2021-07-16 22.37.53
スクリーンショット 2021-07-16 22.38.20
スクリーンショット 2021-07-16 22.44.38
スクリーンショット 2021-07-16 22.42.10

・結果発表!!

そんなこんなで何とか無事終え、提出して結果を待つ事に!!

結果は、、、、、、、落ちましたーーーーー↓

以下頂いたFBです。

ーーーーーーーーーーーーーーーーーーーー
## 課題完成度
- [ ]:未達成
- [/]:一部達成
- [x]:達成
### 初級
- [x]  可読性の向上
- [x]  安全性の向上
- [x]  バグの修正
- [x]  Fat VCの回避
### 中級
- [x]  構造のリファクタリング
- [x]  アーキテクチャの適用
- [/]  テストの追加
### ボーナス
- [/]  UIのブラッシュアップ
- [x]  機能の追加
## 良かった点
- SwiftLint を導入している
- GitHub の Issue/PR ベースで開発を進めている
- コミットメッセージに prefix をつけていてわかりやすい
- 画面回転、ダークモードもケアされている
- コード変更時にコメントで変更内容を整理するのは良い習慣だと感じました
- SwiftUI での実装に挑戦している
- README を更新し、自分の成果に対して客観的に整理できている
- 追加してもらった Drag して 3D 効果は面白く好きです!
- スペルチェックを機械的に行った点も素晴らしい取り組みです
## 改善点
- iOS App の UI を考える上で Human Interface Guidelines が参考になるのと、 Store での配信では遵守することが必須となってくるので、一読をお勧めします。
https://developer.apple.com/design/human-interface-guidelines/
- SwiftLint に Carthage も除外対象にしていましたが、 Carthage は使っていないようなので、除外対象としては不要です
- 特別な理由でキャッシュとして共有したい場合以外では、リポジトリに Pods を含めないようにして、管理しなくて済むものは管理しないようにしたいです
- 詳細画面で前の画像が一瞬表示されていました
- コードの変更と Xcode アップデートのコミット/PR は分けた方が良いです
- コード変更内容を整理するコメントには TODO/FIXME などのマーキングをつけておくと処理漏れが防げます
- 1つのコミットに複数の変更が混ざってしまうことがありました
- 命名に違和感があり Fetch は動詞なので func 向けで protocol には不自然でした
- テストコードを SwiftLint で除外するのは、良いとして、 product コードは SwiftLint に含めた方が良いです。自動生成のまま触らないのであれば、除外しても良いですが、今回は変更しているため。
- 画像取得前に noImage の画像が見えてしまうことがあるので、取得前は placeholder として plane な画像を用意し、取得に失敗してから noImage を表示するとユーザの驚きを小さくできると思います。
- MockRepository はテストでしか利用しないので、 Tests にあると良いです。
- UnitTest はパスしていますが、スレッドを利用してテスト実行時にこの処理を待っていないため、Assert の結果が反映されていません。試しに Assert で失敗するコードを書いても成功すると思います。
- また UnitTest の方は MockRepository を活用してロジックのテストを行うと良いです。こうすることでスレッドを必要としないテストを書くことが可能になります。
## その他
- 改善点を多く挙げさせてもらいましたが、それだけ多くのことにチャレンジした証拠だと思います。
- iOS App Developer として HIG は避けて通れないので、この部分が性に合うかどうか一度じっくり向き合ってみると良いと思いました。
- 段階的に変更されているので、課題の順序的にも UI ブラッシュアップの前にテストを書いておくとその後の変更でロジックが破壊されないことを確認しながら進めることができるのでおすすめです。
- テストが成功したことだけを確認すると、テスト自体が誤っていることに気づけないので、わざとテストが失敗する状態から始めて、テストを成功させるように変更するというステップを踏むと、そういったミスに早い段階で気づくことができるようになります。
- 全体としてはほぼ A だと感じていましたが、テストが機能していないので B とさせて頂きました。
ーーーーーーーーーーーーーーーーーーーー

結果を見た時は愕然としました↓
しかし、少し冷静になってきた時に、悔しいや、後悔(例えばあそこをもう少しこうしておけば良かった↓など)の様なものは無く、純粋に”あー力がなかったんだ、、、”と思いました。(自分で言うのも何ですがそれ程集中して取り組んだんだなと改めて感じました)
また課題をする中で自分の課題を見つける事や成長が感じれた事、非常に勉強になった事に加え、これだけFBをもらえた事はとても自分にはありがたい事でした!!まだまだ改善点がある=成長できるという風に捉え、しっかり改善していき、引き続き勉強してコードチェックを受けていきたいと思いました!!

・その後〜

なんと奇遇な事に、以前からお声がけ頂いていた企業様の基で9月から働く予定に!!

と言うことで一旦教員を退職する事になりましたー!!笑

ものすごくやりがいのある仕事で、すごく楽しかったんですが、色んな事に興味ある(チャレンジしたい)自分にとっては時に足枷となる部分もあったので今までよりも一層チャレンジできる状態になったと思います!!(ちなみに今年度いっぱいは授業は引き続き行う事にしました)

とにかく今は業務経験を積みたいと思っているので引き続きコードチェックを行なっている会社を中心に企業研究を行い、チャレンジしていこうと思っています!!(この記事を見られた方でもしiOSの採用枠でコードチェックを行っている企業様を知っていたら是非教えて下さい!!)また週20時間程度は時間を作れますので、もしiOSエンジニアが足りていない企業様ございましたらお仕事ください!!笑

また勉強会などにも積極的に参加してみたいと思います。

と言う事で最後まで読んで頂きありがとうございます!
引き続きiOSエンジニアを目指して奮闘していきますので応援して頂けると嬉しいです!!

ps.本当に色んな方に支えられ、またご指導頂き今日に至ります。特にコミュニティやサロンのメンバーの方々にはいつもお世話になっていますので改めて感謝申し上げたいと思います。本当にいつもありがとうございます。また今回コードチェックを受ける前から直接ご指導して頂きましたかっくんさん本当にありがとうございました!!

いいねと思えたらよろしくお願いします😋