はじめに
未経験からAndroidエンジニアになって1年がたったので、ざっくりやったことを振り返っていく。
入社前
医療系の仕事をしていて、プログラミングとは無縁な環境。
趣味でAndroidアプリ開発をやってみたらドハマりして、休日は個人開発をしながらずっとコードを書いていた。
Androidアプリの仕事したいな～と思ってたら、幸運にもtwitter経由でAndroidエンジニアとして受け入れてくれる転職先が決まりました。
活動
- Android開発(6カ月)
- 個人アプリを3つ作成
- Android Jetpack等の基本的なライブラリを使える程度
- 競技プログラミング(2カ月)
- 転職前に暇だったのでやってみたがかなり面白かった
- 最初はpythonでやっていたけど、Kotlin大好きなのでKotlinで挑戦していた
- たくさんコードを書く機会を得て、論理的な考え方やコードの実装イメージが身についた
- A,B問題はスムーズに解けて、運がいいとC問題が解ける程度の実力
- Androidの実装スピードもかなり速くなったので、かなりやって良かった
この頃に読んだ本
-
- なにも分からない状態でAndroid開発の基礎を身につけた
- 最初の1カ月はこの本を読んで、後はひたすら独学でコードを書きまくった
-
- API通信を実装するうえで、そもそもサーバーとか通信方式等の知識が皆無だったので選書
- イラスト多めで、見開き完結の内容で読みやすく概観が理解できる良書
-
- コードを書き始めたころに変数の命名の正解が分からず迷っていたので選書
- 良い命名の基本原則を理解するうえで有用
-
- 初めて中規模のアプリを作ったら、しこたまバグが発生してバグを減らす特効薬になるかと思い選書
- ネット上で得られるAndroidのテストコード関連の情報は断片的で理解できなかったので、体系的に学ぶためでもある
- 未熟な状態で読んだので内容を半分くらいしか理解できず、テストコードの必要性もあまり感じられなかった
- ソフトウェア開発のバグとの向き合い方は「気合と根性」で銀の弾丸はないのか、、、と落胆した
- 後々、実務でめちゃくちゃこの本の知識が活きたので読んでよかった
-
- 競技プログラミングをやっていて、アルゴリズムとデータ構造分からなくて問題解けなかったので選書
- 内容が個人的にかなり面白く、コンピューターサイエンスを学びたい欲が高まった
入社1~3ヶ月(研修)
AndroidエンジニアとしてSESに入社。
フルリモートで最初の3カ月は研修を行いました。研修はFirebaseを利用したAndroidアプリを一人で機能要件、デザイン含めて決めて製造するという内容。
社内のAndroid歴10年以上の激つよAndroidエンジニアにコードレビューして頂ける恵まれた環境で、とにかくコードを書きまくっていた時期。
活動
- Firebaseの経験
- サーバーに近い部分は触ったことが無かったため、firebaseを触ってみてバックエンドの雰囲気が理解できた
- 公式ドキュメントを読みこむことの重要性を理解する
- 問題解決精度の向上
- それまでは、根拠なくコードの一部分を変えてみて、運よく期待した挙動になるまで闇雲に模索していた
- エラーログに重要な情報が書いてあるので、しっかりエラーログを読めばだいたい解決するという知見を得た
- Androidプラットフォームへの理解
- ライフサイクルを適切に扱うための知識を得た
- プッシュ通知への理解
- きれいなコードへの意識が強まる
- 個人開発のコードは自分だけが理解できればよかったが、コードレビューをされて他人が読みやすいコードの重要性に気づく
この頃に読んだ本
-
テスト駆動開発
- やはりバグを未然に防ぐにはテストコードが処方箋になるのでは、の思いから選書
- 実際にTDDするかはさておき、コーディングの考え方はかなり参考になった
- 「手で実行したテストは費用、コードで記述され自動化されたテストは資産」の思想が強まる
-
プリンシプル オブ プログラミング
- 激推し本。重要な原理・原則がまとまっていてすこぶる良い内容。
- 高品質なコードへの解像度が高まって、コードの質が爆上がりした
入社3~6カ月(現場配属、設計)
赤ちゃん状態でAndroidアプリの新規開発案件に入る。
赤ちゃんなのでビビり散らかしてた。
Android担当は2人で、自分は主に技術調査とか設計を担当していた。
活動
- 環境構築
- yamlで書いたAPI設計書(openApi)から、ローカルマシンで動くモックサーバーを建てたり、Koltinのコードを自動生成する環境を作った
- 本当になんも分からん状態で、Node.js使ったり、Groovyのコード書いたりしてアホみたいに大変だった
- 技術調査
- 採用するライブラリの選定するために、できること・できないこととかを調べて資料作ったりした
- この辺りから検索で日本語を使わなくなり、英語を頑張って読み始める
- 採用するライブラリの選定するために、できること・できないこととかを調べて資料作ったりした
- 設計
- Excelカキカキする作業
- アーキテクチャとかバックエンドの概要とかも学べて、Androidに限定せずバックエンドの視点も増えた
入社6~9カ月(製造)
現場にも慣れて一人で二足歩行できるようになってきた。
本格的にアプリ開発が始まり、この頃Androidチームは最盛期に7人になる。
なぜかサブリーダー的なポジションになり、戦々恐々しながらクソつよエンジニアの皆さんにお願いしたり、PMや外部の会社と交渉したり、とにかく多忙だった。
活動
- AWS SDKをAndroidに導入した
- アプリとして特殊なことをやる必要があったため、情報が少なくて動かず、クソほど大変だった
- 公式ドキュメントを見ても情報がなく、SDKのコードを読んで仕様を理解していた
- SDKのコードを読みこんだことで、結果的に良質なコードに触れてソフトウェア設計への理解が深まる
- ゴリゴリコードを書く
- 久しぶりにコードを書いたら楽しすぎて脳汁でた
- つよエンジニアの方々と実装方法について議論する機会が増えて、急激に成長した
- コードレビューを行う側になる
- 初めて多くの人のコードに直接触れる機会で、レビュー観点もこの頃よく分かっていなかった
- スケジュールがひっ迫していたのもあり、動くからヨシ！のガバガバ観点でマージボタンを押してた
- 1か月後に後悔する
入社9~12カ月(リファクタ、バグ修正)
激動の3ヶ月を終えて、ひとまずアプリが形になり落ち着く。
テストが始まりバグを修正する日々がはじまりコードを見返すと、そこには無残なクソコードが広がっていた。当初は有機的な調和を持っていたMVVMのコードが、数多のオレオレクソコードによって崩壊していたのだ。期日に追われて動けばヨシ！でマージボタンを押したのは自分なので、「クソコードが生まれてしまったのは自分に力がなかったからだ。」の自責の念に負われてクソコードを駆逐すべく強い殺意の波動に目覚めた。
活動
- 設計の目覚め
- useCase, Domainについてざっくりを理解する
- 設計思想について、つよエンジニアと議論したり、記事を読み漁ったりする
- useCase導入した流れで、メンバーを巻き込んでテストコードを導入した
- Jetpack Composeに入門する
- 宣言的UIはいいぞ
- CodeLabを英語でやっていたら、突然英語を読めるようになった
- 海外の技術記事を読み漁る
- 今まで行けなかった範囲に踏み出したら、強い武器がしこたま落ちててテンション上がる
この頃読んでいた本
-
良いコード/悪いコードで学ぶ設計入門
- 書いている内容としてはプリンシプル・オブプログラミングともやや重なるが、コードの具体性があって理解しやすい
-
Not Silver Bullet
- とても有名な論文
- 銀の弾丸はない
- 固い英語で読みにくいが、示唆に富みまくったことを書いていて良い
-
A Philosophy of Software Design
- ソフトウェアデザインの本質を突きまくっていてめちゃくちゃ面白い
- 英語が読めるなら、ぜひ読んだ方が良い
まとめ
総じて環境が良すぎた。割と裁量を任せられて自分主導で色々とやりたいことができたし、複数人の強いエンジニアと親しくなれて得るものが多すぎた。
一個人のコーディング能力があっても、チーム開発で発生するコードの崩壊は防げないというのが強烈な出来事として残った。設計等の仕組みで対応しなければいけないという思い。
バグを減らすためにコードの品質を上げることに魅力と価値を感じているので、そこを高めていきたい。
今後の展望
- 個人開発もっとやりたい
- 今年は業務で手一杯だったけど、余裕が出てきたので
- Jetpack Composeをもっと触りたい
- Wear OSも興味ある
- Android以外も触りたい
- iOS
- 本腰を入れるつもりはないが、モバイルエンジニア名乗るならやっておきたい
- KMMとかも試してみたい
- web系の技術
- LINE Bot辺りが気になっている
- iOS