読者です 読者をやめる 読者になる 読者になる

Skyland Ventures tech ブログ

渋谷のVenture Capital Skyland Venturesのいま一番イケてる投資先、nanameue,IncとKaumoの共同技術ブログ

Swiftにおける良いコードとは何か

株式会社Nanameue iOSエンジニアのbatiです Objective -CからSwiftに乗り変えて2か月。 今は新規プロジェクトをPure Swift でやっている状況で、 そろそろ、Swift最高じゃんもうObjective-Cには戻れないわ と感じている頃です。

Swiftは超べんりです。 Objective-Cに比べてはるかにいろんな書き方ができて楽しい毎日を過ごすことができます。 しかし、デメリットとしてObjective-Cに比べてはるかに表現力が高い分、いろんな書き方があって結局どれがいいのか迷う事があります。

例えば、変数の定義の仕方にしても文字列の場合

let string: String = "a"

とも書けますし

let string = "a"

とも書けます。

Arrayの場合

let array: Array<String> = ["a"]

let array: [String] = ["a"]

let array = ["a"]

と3種類の書き方があります。

これだけ表現の仕方が多様だと、チームで開発している時など、 様々なArrayの宣言コードがいたるところに散乱しているような状態になってしまいます。

一人で開発する分にはいいのですが、チームで開発する時に、統一性のないコードになってしまうという問題が発生してしまいますね。

この問題をどう解決していけばいいのか。 僕なりの良いSwiftコードにするための3か条を発表します。

1.誰のための良いコードか考えろ

あなたが書いているコードは誰のためでしょうか?チームメンバーのためでしょうか? 自分のためでしょうか?初心者教育のためでしょうか?

多くの人は、チームメンバーのためだと思います。 チームメンバーのために良いコードを書くためには、良いコードとは何かチームの中で定義する必要があります。 一番大事なことなチームメンバーがストレスなく開発できることです。 第3者から見てイケてないコードだとしても、チームメンバーにとってストレスなく読め、最速ででき、メンテナンスがしやすいコードがチームにとっていいコードだと僕は思うのです。

コード数が少ないものがいいコードなのか? 少し長くなってもいいから可読性を意識したものが良いコードなのか?とにかくnil safe, 型safeなコードでしょうか?クロージャの書き方どうしよう?

とにかくスマートに書きたい、短くスッキリ書く事が良いコードだとしたら、 変数の宣言は簡潔に

let array = ["a"]

とすべきでしょう

またif文なども、なるべくelseが多くならないように、条件式を工夫するなども必要です。 また、なるべくオプショナルバインディングを使わない工夫も必要かもしれません。 オプショナルバインディングは便利ですが、冗長なコードを増やしてしまいます。 いたるところに

if let a = b { }

があると単純な作業なのにコードが長くなってしまいます。 本当に必要な時のみ使うべきでしょう

可読性をとにかく意識したいのであれば、 if文などもelse文が多くなったとしても丁寧でわかりやすい条件で書くべきかもしれません

どんなコードも一長一短あり、チームとしてどんなコードがいいのか、徹底的に話あう必要があります。 それはSwiftの高い表現性ゆえにです。高い表現性ゆえチームとして制約を設けないと、統一性のない、メンテナンスしにくいコードになってしまいます。

Wantedlyさんのコーディング規約などを参考にしながら、決めるというのもいいかもしれません。 (http://qiita.com/susieyy/items/f71435cc962e70d81b37)

2. チームでコーディング規約を決める際はストレスなく書ける、読めるに重きをおけ

Swiftは表現力が高いゆえに書きたいように書けます。なるべくチームメンバー全員がストレスなく書きたいように書けるにポイントを落としどころに決めたコーディング規約を作ることができるのはSwiftならでばでしょう。 書きたいように書く、エンジニアがこれほど生産性を上げられるものはないと思います。

書きたいように書く

書きたいように書く、これはもはやエンジニアの趣味の領域です。それはエンジニアの心であり情熱であり芸術性を帯びた何か得体の知れないものです。 この何か得体の知れないものを共有しましょう。 ちなみに僕はプロトコルの多様はあまり好きではありません。理由は特にないです。 感覚です。何かprotocol extensionを見かけると多少ムカつきます。 これはまさに得体の知れない何かだとしか説明がつきませんね

読める 逆説的な話になりますが、ルールはたくさん設けた方が、ストレスなく読めます。 書きたいように書くけどルールはたくさん設けるべきでしょう ルールに縛られた方が実装も迷いなくできます。

③ 感謝と思いやりの精神

誰かが良いコードを書いてくれたら最大限の敬意を持って感謝しましょう。 How great code it is!!! 君のおかげで今日も明日も爽やかで良い1日を過ごせそうだ そんな気持ちで良いコードをmergeしてあげましょう そして言葉で伝えましょう。 あなたの書いたコードを愛していますと

そして自分がコードを書くときは、チームメンバーのことを思いやりながら愛しながら書きましょう。 僕のコードはこのすばらしいチームのためにあるのです。ああなんてすばらしいチームだ と思いながら書きましょう。

その瞬間コードの神様が天から降りてきて、あなたの頭脳にささやかなヒラメキと、 コードを書く情熱を授けてくれるでしょう

その瞬間の積み重ねが人類のテクノロジーを一歩前へ、また一歩前へと進める動力源となるのです

すばらしいSwiftライフを