なぜあの時あんなにもswiftが分からなかったのか（原因編）
今は昔、社会人2~3年目あたりでswiftを使ったスマホアプリのプロジェクトにわりあてられ、全く分からなかったときのことをまとめました。
一意見として、初心者は何が苦手なのか、誰かに伝わると嬉しいです。
当時の自分の背景
工学系（非情報系）からソフトウェアエンジニアとして新卒で就職。
学生時代は、授業でC言語の基本をやった程度。
研究では解析ソフト内製の独自言語でマクロを組む程度。当然手続き型で書いています。
入社直後はpython等を使用。トライしながら学んでいこう、というスタイルの職場でした。
同期と一緒に（勉強もかねて）協力して構築、という感じでした。信頼のなさもあって、一人でコードを書くということが少なく、半ばペアプロのようになっていました。
学生時代に培ったググり力に、あの時ほど感謝したことはなかったでしょう。
インターネットの情報をかき集める
↓
プログラム作る
↓
問題にぶつかる
↓
（上に戻る）
を繰り返してプロダクトコードをつくっていました。
余談ですが、aws lambdaのサンプルコードをネットでみていて、
input_data = event['data']
の意味が分からない中、ふと突然「dataというキーに紐づく値をとっているんだ！」と自力で気づいた時の衝撃は忘れられません。
辞書型が何かも、これが初歩の話かも分かっていない時代でした。入門書ぐらいは業務内でやってもよかったんじゃないの？と今では思います。
帰納的な学習は発見時に感動が大きいのですが、時間かかりすぎますね。
swit 襲来
3年たつか経たないかでiOSアプリのプロジェクトに追加人員としてアサインされました。先行していた先輩に教えられながら、やはりなかばペアプロのような状態でスタート。
これが本当に全く「わからなかった」。
「今週はこれを進めましょう」となっても、どのファイルをいじったらいいのか、何を書いたらいいのかすらわからない状況。思い返してもおぞましい。
わからないことやそれが改善しないことを過剰に責められるような状況でもなかったので、病むことはなかったのですが、「今日も仕事嫌だな」とは思っていました。
結局、大して理解が進まないまま、一年後にはプロジェクトから外されてしまいました。
以下ではあのときに立ち返り、なにがなぜわからなかったのか、当時何をしたのかが続きます。
わからなかったこと vs 当時やったこと
- 文法
型を明示する言語をまじめに書いたのが初めてで、しょっぱなから躓いてしまいました。
半年ぐらいたってからようやく、
let arr: [Int]
が整数の「配列」の宣言であることを知りました。遅すぎない？
→ 当時の対策 : 当時は文法について具体的な対策をしていませんでした。日々の業務をこなすだけでした。正直なところ本などを読んで勉強するものだとは思っていませんでした。
- XCodeの操作
「サイドパネルが表示できない」「ＵＩの長さ設定がみつからない」など、初歩的な操作がおぼつかず、ほかのことに神経を集中させる余裕がなかったです。いろいろできすぎて混乱しました。
ペアプロしてくれていた先輩の操作がよどみなく、見ていても咀嚼する余裕がなかったです。
ストーリーボードなどもつかっていたので、UI作りに関しては一人では戦力になりませんでしたね。
→ 当時の対策 : ショートカットをメモしたり、反復練習をしたりしました。でも足りなかったんでしょうね。思い出す前に先輩の突っ込みが入ることも多々。ごめんなさい。
ストーリーボードについては、苦手な操作を家で再現してみたこともあります。が、うまくいかない or 見かけ上はできているが手順がよくない、のどちらかでした。
- ソースコードの構成
はじめてプロジェクト構成を見るときはたいていそうだと思うのですが、どこがmainで、何が設定されているのか、わからなかったです。
そもそもそれまでは、せいぜい数ファイルしか書かないような開発スタイルでした。複数ファイルで構築したのは、プログラミング言語以外のインフラ構築言語ぐらいのものです。
ソースコードを追う「手がかり」的なものが乏しかったように思います。
アプリ起動時に動くのはどのファイルのどれ？
この画面に遷移したら最初に動くのはどの関数？（たとえばViewDidLoadとか。）
→ 当時の対策 : これはもうその時はどう調べたらいいのかもわかりませんでした。先輩方に聞いても、基本理解が足りな過ぎて得るものが少なかったです。せめてライフサイクルでもしっかり押さえておけばよかったものを。
- プロダクトのソフト的な構成
IoT系のプロダクトだったので、デバイスと通信したり、クラウドのAPIをたたいたりと、一通りのことはやってました。これはシンプルに把握しきれませんでした。
→当時の対策 : シーケンス図をとかは見ました。面倒なことに、逆に抽象度が高く、頭が受け入れられませんでした。
- 関数の処理内容
上ともかぶりますが、一番悩まされたのがこれでした。
自分の頭のメモリが足りないような感覚で、「この関数の中では、処理A, B, Cが呼ばれていて、処理Aの関数はここに定義してあって、その中では関数DとEをよび、さらにそのなかでは...」 という風に深く中をみていくにつれ、呼び元が記憶からうすれていきます。そのため、何の処理をみていてこの関数にたどりついたのか、どういう目的でこの処理をやっているのか、があいまいになってしまい、ソースコードを呼んでも頭に入らない状態でした。なれない時の英語のリスニングのような感覚でしょうか。
さらに言うとそれまでクラスをまともに書いたこともなかったため、当然のようにクラスを使っていた当時はコードを読むのがきつかったです。
→これも当時は対策が分からず。途方にくれました。
- 何が分からないのか
上記5つは今だからこそ分けて定義できているものもあります。実際はそれぞれが癒着しているような状態でした。もっと具体的にわからないことを伝えられていたら、とも思います。
解決したのか
当時はしなかったです。見守ってもらえただけましでしょうか。
外された後、ほかのプロジェクトでVueを扱い、似たような壁にぶつかりました。
ただその壁が存外低かったため半年ほどかけて超えることに成功。その後別件でswiftを使うプロジェクトにアサインされましたが、その時はなんとなくコードが分かる状態、追える状態になっていました。
慣れ＋メンタル的な問題も大きかったのかもしれません。考える余裕ができるって大事ですよね。
また、正直言って今ほどハードワークでもなかったので、伸びる理屈もなかったでしょうか。
（考察編）に続く
Discussion