新しいコードを読み解くことを、私たちはしばしば行いますが、それはエネルギーと時間を消費します。そこで、スラスラと新しい言語を読めるようにする方法と、進化に付いていく方法をお話しします。
大学では日本語を勉強していましたが時間が経つと、自己紹介しか話せない。
みなさんのように最近外国語を学びました、Swiftです。いい時もあればやりにくい時もある。 新しい言葉を学ぶ経験に繋がる。 どうやって流暢にコードを使うか、どのように読めるコードを書くか。
プログラミングは新しい言葉を学ぶことと共通する。
新しい外国語を学んで、クラスメイトをコヒーに誘って、断られたとしても、それは相手が理解してくれたということで良いこと。 数週間後に他のクラスメイトを誘って、Yesと言ってもらって、天気や家族、過去形の話も出来れば先週末の話もできる。会話としては退屈だが、素晴らしい、お互い分かり合えた、複数行でも理解できたとなる。
ところが発展的になると、意見が違ったりして、２回めはデートに誘わないとか。
コードでも、面接に来た人がKVO大好きと言い出すと二回目の面接には呼ばないとか。
テーマ
流暢性を言語やプログラムで考えるとニュアンスや微妙な所を考えていくことになる。
第二外国語を学ぶと第三外国語も学びやすい。 ドイツ語で男性名詞女性名詞が有るとすると、それをフランス語でも流用できる。
でも適用できない場合もある。thanksという言葉をアメリカの言葉ちょっとしたことの感謝に使うが、文化によっては、「ここまでやってくれたのか」と本当に感謝した時にしか言わないところもある。
SwiftでC Styleのループを使わないのと同じ。
みなさんはSwiftの流暢なリーダーとライターになりたいと思う。 読めるコードとは何でしょうか。
こんなことはありませんか
一人がレビューで「パターン変えてくれる？」と言ったら、もう一人が「いやこの方が読みやすいだろ？」という。こういう時、わたしたちは誰が読み手か考えずに、読みやすさについて言ってしまいます。
読み手を特定してパターンを考えていく必要がある。
蛇が自分が動く権利を交渉し、太陽が給料を受けるために登る時、トゼがバラを。。。。その時こそ素晴らしい日動物的な人間を信じる
いい意味で困惑しますね。何回読んでもわからない。何回も読んでパターンが分かり、こういうことかと分かる。１０回読んでわかりました。
このようにポエムを読むことは良いかもしれませんが、その背後にある美しさを１０回読まなければならないことは、コードではあってはなりません。
コードは、それぞれ理解度が違います。
ファクトリークラスではバインドを使うということで関係を明確化するには良い、でもチームの人達がわかっていなければ意図が伝わらない。プロなら分かって当然だと考えるのは仕事ができないと言っているようなもの。
すべてのエンジニアがすべての領域でプロフェッショナルなわけではない。
他のエンジニアが新しいコードをどんどん作っている。語彙がどんどん増える。流暢でいつづけることは不可能。解読する、それが我々の仕事。解読して、良いツールを使って、意味を読み解いていきます。
でも、解読するプロセスがどう働いているか考えたことがありますか？
作業メモリと読む力
作業メモリはどこかに注意が惹かれると消えてしまいます。何か2つ覚えておこうと思っても3つ目4つ目を見てしまうと最初の2つは忘れてしまう。
でも、7つをちゃんと一度に見れますよね？単語など。どうやって呼んでいるのでしょうか。チャンキングと呼ばれるものがあります。一つのグループに分ける
テキストから意味を読み込むのはグループとして抽象化して理解している。
きょうは、暗号的な解読できるコードの話ではなくて、最終的に、なんでも買い得は可能だが、読み取れるということと意味が違う。
これは読み取れますか？
買得は力を使います。メンタルリソースがないとコードを読み取れません。
意思決定する箇所を捨てていく必要があります。エネルギーが必要です。
コードを書く、チームメンバーが読めることが大事。自分が書いているものは読めると思いますが、あったことがない人にとってどうかは想像しにくい。
違う言語の人が聞くスピーチではスラングなどを使わない。
こんなのわからないですよね
スラングや、方言などを使うのはやめましょう。
パターンを使う
パターンを明確に作っていきましょう
何が違うのか見取りやすくなります。
目を細めて見て、構造が読み取れるようにすること。
一貫性を常に持たせて、チームメイトが直感的に読めるように、エネルギー無く読み取れるようにしましょう
共感をもって書く
なんでこれ読めないんだ？って思ってしまうことがあるかもしれません、自分が悪かったのかと思うことがあるかもしれません。でも、共感を持って、どんな情報がかけているのだろう、なぜ読み取ってもらえないのだろうと考えることで、読み取ってもらえるコードを書けるようになる。何が自分に見えていないのだろう？
最後の質問
読めるものを作るためにどれくらい時間を書けますか？ 私のコーディングガイドラインでとても好きなモノがあります。「コードに議論の余地があってはならない」
自分が読めるだけでなく、チームメンバーが皆読めるようにする。 ぜひ、エネルギー、やる気を効果的に使えるコードがどのように書けるか、パターン、共感などを利用して新しいコードを作って頂きたい
後日公開されるはずですが、今日参加されてない方は「コードリーディングについて」のセッションは資料だけではなく動画込みで見たほうが絶対良いです #tryswiftconf
— Yoshiaki NAKANISHI (@chun_ryo) 2016年3月2日
ローラさんすばらしい内容だった。これは生徒たちにも伝えよう。 #tryswiftconf
— まっす〜(＠増原大輔) (@dam0227) 2016年3月2日
「人に読まれるコードの書き方 ~Readable Code~ #tryswiftconf」をトゥギャりました。 https://t.co/jNYLGQLZLF
— トゥギャッター開発まとめ (@tg__dev) 2016年3月2日
気に入った記事は はてなブックマーク
はてなブックマークアプリiOS開発チームから来ました！ はてなブックマークにはSwift特集があります！ 良い記事を見逃さないように、ご利用ください！ http://b.hatena.ne.jp/hotentry/it/Swift
そして良いまとめ記事があったらはてなブックマークでブックマークしましょう！ try! Swift の記事で盛り上がると嬉しいです！
