4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

bosyuAdvent Calendar 2019

Day 3

意識が低い雰囲気エンジニアのやり方

Last updated at Posted at 2019-12-03
Advent Calnder.png

自己紹介

bosyuで意識低い系雰囲気エンジニアをしています。
なので難しい理屈とかそういうのは分からないでエンジニアやっています。
守備範囲も適当です。iOSだったり、バックエンドだったり、フロントやったり……

そんな適当でどんな感じでやってんのっていう話をします。

Webviewアプリからフルネイティブへの移行

まったくiOSエンジニアがいない所からの依頼です。今年一番大きいお仕事でした。
最初はコンサル的な感じでお願いをされていたのですが、せっかくなのでコードも書きたいなと思い開発もさせて頂くことに。

メンバーは全員業務委託で、週1〜2日の稼働、自分を含めて2人でやる事になりました。
もう1人の方はAndroid開発者でiOS開発未経験です。

まずやったこと

アーキテクチャを決め、ベースになるコードや画面の作り方を一通り作ってしまうことです。

アーキテクチャ

これは本当に沢山あります。
MVC, MVP, MVVM, VIPER, CleanArchitectureなどなど……
エンジニアの好みや慣れ親しんだものがそれぞれあると思います。

ウチは雰囲気でエンジニアをやっているので難しいことは何一つ分かりません。
なので正直どれでもいいです。どれでも作れますしどれ選んでもある程度は汚くなるし、どれでやってもメリデメあります。
設計とかに完璧は存在しないのです(betterとかはあると思う)

ウチが今までの経験上、iOS開発で大事にしていることは雑に言うと

  • ViewControllerをデブにしない
  • データの流れを複雑にしない
  • レイヤー作ったらあちこち参照しない

ということです。
これ守れれば大体なんとかなるかなぁと。

んでこれを突き詰めていったのがCleanArchitectureかなぁと感じてはいるので、これをベースにしました。

しかしCleanArchitectureのデメリットととして多くの人がご存知かと思いますが、コストがかかりすぎるということです。
あと分からない人がとっつきにくいとか色々ありますね。

ましてやスピード重視の初期の段階でこれを採用するのはどうかと思います(思います)

でもCleanArchitectureって世の中の記事とか見ると結構皆さんそれぞれで自由にやってるんですね、個人的な見解ですが。
だからガチガチに抽象化して固める必要なんかなくて、適当に緩くしちゃえばいいのかなぁって思うわけです。
メンバー少人数だし、エンジニア間で認識が取れてれば問題はないはず(勿論後々人が沢山来たときのことはある程度考える)

というわけでゆるふわCleanArchitectureにしました。

なにがゆるふわなのか

  • Data層でDIしなかったり
  • Domain層のモデル作ったり作らなかったり
  • ViewにRouterっぽいの持たせなかったり
  • DIも自前で簡単なもので済ませたり(作ったのはウチではない)

まぁその時その時で必要になればやればいいのかなぁと。
ってか上のやつそんなにCleanArchitecture関係なかった……

なんとなく守るべきルールを決める

iOSの開発独特の雰囲気ルールを決めました。

  • 1画面1Storyboard
    • もちろんこれも厳しくではなく、ContainerViewやChildViewController使う時は別に良い
  • さっきのアーキテクチャで下のレイヤーが上のレイヤーを参照したらダメ
  • ColorAssets利用しましょう → New
    • 初めて使ったけどこれは便利でした
  • CocoaPodsは禁止でCarthageオンリー
    • 意地
  • RxをViewでは闇雲に利用しない様にする
    • 今までやってて人による理解度の差があったり、逆にコード長くなってない?というところがあったりして、無秩序になりやすいなぁと感じていたので。便利なんですけどね

どんな感じだったか

初期

Alamofire使ったAPI Clientとか、view/presenter/usecase/repository/datastore 作って簡単な画面作ってゆるふわアーキテクチャの認識合わせを行います。

もう1人のエンジニアの方はウチよりかなり若くて凄く頭が良いので、バンバン意見をくれて本当に助かりました。
またこのゆるふわで適当なウチに凄く理解を示してくれて感謝です。

流石にView周りで知らないと無理、という様なところだけは指摘しましたが、それ以外は自走してくれました。

また中盤に入る前に知り合いの優秀なiOSエンジニアをさらに召喚しました。
この方もこの雰囲気エンジニアに理解ある方で本当に助けられました。

中期

この時にはすでに手法は固まっていたので、みんなでバリバリ開発する感じです。
API Client作って、Repository作って、Usecase作って、ViewController+StoryboardとPresenter作って、最後つなげる。

まがりなりにもCleanArchitectureなのでレイヤーはある程度分かれて、メンバーのコードがぶつかり合う事もなく平和に進みます。

デザイナーさんがiOS経験がほぼなく、色々紆余曲折ありましたが、段々と形になってきます。

後期

今ここです。
利用する外部サービスの変更などヤバいっていうのがちらほらありましたが、最小限の形でリリースまで行けそうです。

アドベントカレンダーが終わる頃にはリリース出来てるといいなぁ、という感じです。

まとめ

  • ちゃんとしている人に怒られそうなエンジニアなのに、なんとかやっていけてます
  • 優秀な人はこんな適当なエンジニアにも合わせられるので凄い
  • 優秀なメンバー最高
  • つまりは運良く良いメンバーに恵まれているだけで生きていけてる!?
  • こんなエンジニアがいたっていいじゃない
4
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?