個人開発で悩んだこと

どうも、ねこきち（<a href="https://mobile.twitter.com/nekokichi1_yos2">@nekokichi1_yos2</a>）です。

フリーターで地道にiOSアプリ開発をしています。

今回は、もうすぐ完成する学習アプリの**開発でつまづいた点**を反省の意味を込めて書きました。

APIやデリゲートとか難しい分野ではなく、Gitやコーディングなどの初歩的な部分の内容です。

##変数、関数の名前つけ

変数や関数って宣言することが多々あるので、宣言のたびに名前を考えるのはとても面倒でした。

格納していく値や処理をぱっと見で理解できるような名前を思いつくって、意外と難しいです。

例えば、DBのユーザーデータを扱うファイルを作る場合、
・UserData
・DataOfUser
・Data_of_Database
が浮かびます。

**関連する英単語をつなぎ合わせれば、出来上がる名前なんて無限に浮かびますし、その中から1つを選ぶのって、コードの可読性を考えたら、即決できないです。**

もしくは、次年度のデータを表示する関数だったら、
・nextYear
・display_nextYear
とか。

1番つまづいたのが、**似た名前が既に宣言されていること。**

例えば、データベースからプロフィールを読み取る関数、readUserData()、があるとします。

もしユーザーに関連するデータを読み取る関数を作るとしたら、readUserData以外の名前でないといけないのです。

そうなったら、
・readUserValue
・readDataOfUser
・readUsersData
の名前を採用することに。

対策としては、
・関数を多く作らない
・処理を明確に示す名前をつける
・変数名を生成するサービス（[codic](https://codic.jp/)）を利用する
ことで名前づけに悩む時間を減らそうかなと。

##コメントの有無、内容

後で見返した時に
・どのような処理か
・どんな処理の流れか
を示すためにコメントは逐一、加えてました。

しかし、大した処理でもないのにコメントがあるのを見ると、**本当に必要だったのか**と思い知らされます。

僕は読書する時によくメモりますが、頭に浮かんだことを忘れたくないために書き込んでいました。

プログラミングでも同じように、
**（この処理を理解している状態でコメントを書き残そう）**
の気持ちが強まり、とにかくコメントを残したのだと思います。

また、コメントが必要な複雑なコードがある場合、
・簡潔な
・分かりやすい
コメントをどう書けばいいか迷いました。

さすがに
・UILabelにテキストを代入
・UIImageに画像を代入
するような簡単な処理ではなく、
・データ取得 + データ更新
・UI部品をタップ後にデリゲート
などの処理にコメントを加えた方がいいと反省しました。

##コミットの区切り

コードに変更を加えたらコミットするのは分かりますが、**どこまで変更を加えたらコミットすればいいのか**、が曖昧です。

一口に変更と言っても、
・値を追加/変更
・ファイルを追加
・処理の順番を変えた
色々あります。

同じ変更でも人によって捉え方は違いますし、変更に値しないほど小さい変更かもしれません。

その上、変更した箇所は
・数文字
・数行
・何箇所
と多様です。

**たかが数行のためにコミットするぐらいなら、別の変更箇所とまとめてコミットした方がいい気がします。**

そして、複数の変更箇所がある場合、コミットメッセージを簡潔にまとめづらくなります。

例えば、各コミットの内容が
・AutoLayoutの変更、ライブラリの追加
・UI部品の設定を変更、コメントの追加
とバラバラな場合です。

いっそのこと、コミット内容をまとめるために、異なる変更は別のコミットするべきかもしれません。

**しかし、コミットの数が増えると、どこからどこまで変更したのかを追跡しづらくなります。**

個人で開発してるので別に気にしなくてもいいんですが、保守や管理の点ではアウトでしょう。

まとめると、
・変更箇所の概要
・変更箇所の範囲
・コミット内容の概要
に注意してコミットした方がいいですね。


##プルリクのタイミング

直近のプロジェクトでは、ブランチを
・master
・feature
・development
に分けてました。

コードレビュー 


##コードの簡略化

開発では、とにかく実装することに夢中なので、途中途中でリファクタリングをする気がないです。


もちろん、開発の途中で
（この関数、省略できないかな？）
（ネストを浅くした方がいいかな？）
と思うことは多々ありました。

**しかし、アプリの完成、コードの保守、どちらを優先させるか悩むことが何度も。**

ただし、効率の面から考えて、開発時は開発に集中した方がいいので、完成後でも良いと思います。

下記の動画を見てからは、とりあえず完成してからやってみようかと。

[リファクタリングが必要になる理由！？現役エンジニアが解説](https://www.youtube.com/embed/TzP07VXDDUM)


##フローチャートをあまり見返さない

処理の流れを明確にするためにフローチャートを最近使い始めました。
→[LucidChart](https://www.lucidchart.com/pages/ja)

すごい便利なんですが、あまり見返しません。

理由は、次々と実装したい処理や流れが思い浮かぶからです。

フローチャートのおかげで実装の手順が分かりますが、
・実は間違っていた
・コードを書くたびに追加/変更が生じる
・見返さないといけない
ことがよく起こります。

コードを書いて、見返して、コードを書いて、修正して..を何度も繰り返すのが面倒でした。

最初に理解して覚えれば見返す必要はなくなりますが、違う方法や効率的なやり方が浮かぶたびに、いちいち変更するのは手間がかかりました。

とりあえず、開発前にじっくり理解して、処理をどんな流れで実装するかの大まかに把握する程度のツールとして利用していくつもりです。


##ライブラリの選定

どのライブラリを使うかは、
**・GitHubのissueで最後の投稿が今年か**
**・使い方を解説している記事や動画があるか**
を基準にしてます。

XcodeやiOSの最新バージョンで試している人がいれば、そこで起きたエラーを質問しているはずです。

また、ライブラリには公式のドキュメントがあるので使い方に困りませんが、読んでもわからなければ、qiitaやYoutubeで解説されてると非常に助かりますね。

ただ、解説記事や動画の日時が古かったり、そのまま実行してもエラーになる場合があります。

奥の手として、外国人エンジニアの解説記事を参照する方法がありますが、解読に時間がかかるので、できれば避けたいです。

それでもダメなら、諦めます。



##終わりに

高度な技術力がなくても、時間をかければ、目的のアプリを作れてしまいます。

なので、レベルの高いことをしようとせず、無駄な時間や作業を減らす方が大切です。

初歩的なミスを無くす方が簡単ですし、ちょっとした工夫で時間のロスを減らせるなら、わざわざ身の丈以上のことをする必要はないでしょう。

##告知
数ヶ月前にアプリを初リリースしました、もし宜しければ、利用してみてください。
→[PWG-randomPassWordGenerater](https://apps.apple.com/us/app/pwg-randompasswordgenerater/id1512620729?l=ja&ls=1)