More than 5 years have passed since last update.

初心者プログラマーがコードをモリモリ読めるようになる方法

Posted at 2019-01-04

免責

ポエムです。

ワーキングメモリとプログラミング

実務にぶちこまれると、他人の書いた洗練されていない謎コードを読む機会があると思います。
今回はワーキングメモリの観点から謎コードを読めるようになる方法について書きたいと思います。

ワーキングメモリとは

参考: ワーキングメモリ - Wikipedia
脳内に一時的に記憶しておくための仮想的な領域やその概念のこと。
ワーキングメモリの多寡は(動作性の)IQに関連するとされています。
また、ワーキングメモリが大きい方が複雑なコードを読めると言われています[要出典]。

ワーキングメモリフレンドリーでないプログラム

ワーキングメモリがいかにコードリーディングに関わるかの例として、
ワーキングメモリを浪費するコードを適当に考えました。
コードを読んで何が出力されるか考えてみてください。
Rubyです。

$output = '';
$do_something = -> (s) {
  $output = 'hello'.then do |a|
    a << s
    a.upcase
  end 
}

def main
  $do_something === 'world' && puts($output)
end

main

正解

HELLOWORLDが出力されます。

このコードのよくないところ

変数がたくさん登場する
不適切なスコープ
中身がわからない適当な命名
一般的でないシンタックス
ロジカルじゃないロジック

名前で中身が説明されない変数が多いとそれだけその変数を脳内に留めておかなければなりませんし、
またアノテーションもないと覚えておくことが増えますし、
グローバルスコープの変数がカジュアルに変更されまくったり、
パッと見て処理内容がわからないようなシンタックス（ Proc#===等）を濫用されたり、
不必要にブロックやプロックが乱用されることで、
コードを読んで処理内容を追う毎にどんどんワーキングメモリが圧迫されるのが体感できるかなと思います。

洗練されていないコードを読めるようになる方法

↑の例ほどでないにしろ辛いコードはこの世に大量に存在します。
そういうコードを読めるようになる方法が２つだけあります。

その1. 知識をつけて経験を積む

よりワーキングメモリを消費しないようになる、という解決法です。

ワーキングメモリの容量限界については諸説あるようですが、自身がより精通しているもののほうが記憶しやすいことが知られています。

**「りんご・みかん・さくらんぼ」の方が「カリン・グアバ・マンゴスチン」**より覚えやすい・思い出しやすいですよね。
これは、後者に馴染みがないからです。
「カリン・グアバ・マンゴスチン」を覚えやすくなるためには、あなたが「カリン・グアバ・マンゴスチン」を毎日食べればいいんです。

これをプログラミングの話に戻すと、すなわち、
プログラミングの知識をモリモリつけて、脊髄反射で Object#thenや Proc#===の挙動を引き出せるようになったり、
コードリーディングをしまくって脳内にREPLを備えることで、
複雑なコードは読めるようになる、ということです。

その２． nBackTrainerでワーキングメモリを鍛える

ワーキングメモリの総量自体を増やす、という解決法です。

***さて、***ここからが本題です。
ここから下が本当に書きたかったことで、上に書いたものはあとから考えたものです。科学的な正しさも保証しません。

こんなものつくりました

nBackTrainer - App Store

Nバック課題(n-back task)という、課題?試験?をプレイすることができるiPhoneアプリです。
プレイする毎に多面体が育っていくという大変ユニークなコンセプトになっています。
（無料です。広告もありません。）

Nバック課題は、継続的にプレイすることで大人でもワーキングメモリの容量を増やすことができるとされています。

Nバック課題とは

Wikipediaの説明を引用します

実験参加者は一連の刺激を順番に呈示され、現在呈示されている刺激がN回前の刺激と同じかどうかを答える。この負荷因子Nによって課題の難易度を調節する。

例えば、聴覚の3バック課題では、実験者が以下のようなアルファベットを実験参加者に向かって読む。

T L H C H S C C Q L C K L H C Q T R R K C H R
実験参加者は上のアルファベットの内の太字で示したものが読まれた際に応答しなくてはならない。なぜならこれらは3回前に読まれたアルファベットと同一だからである。

引用元: Nバック課題 - Wikipedia

####　🤔🤔🤔
より深く知りたい方は「Nバック課題」でググるなり、アプリをプレイするなり、HPを見ていただくなりすると良いかと思います
nBackTrainerにはアルファベットではない２つのゲームモードがあります。

こんな画面のアプリです。

開発の話

Qiitaなのでこのアプリをつくった際の開発的な話をします。

開発の動機

Three.jsすごい、使ってみたい　→　Swiftでなにか作ってみたい　→ このライブラリ使ってみたいあのライブラリ使ってみたい
という発想の流れで（エンジニアとしてよくない気がしますが）ライブラリ駆動開発をしました。
~~人々のワーキングメモリを改善して生活を豊かにしたいみたいな大目的とかないです~~

仕事での開発ではメンテナンスされていないライブラリを使うことは将来的なリスクになりますし、大きな目的やデザインが先にあることが多いので制約が多く、
一方で個人だと開発的にやってみたいこと駆動で物が作れるというのは利点かなあと

使用技術等

iOSネイティブアプリ

Swift 4.2

iOS関連のライブラリ

cocoapods パッケージ管理
RxSwift/RxCocoa 言わずと知れた。（大して使ってない）
Realm DB
Crashlytics クラッシュレポート
Surge 対数の自力実装面倒だったので
lottie-ios AdobeAEで作ったアニメーション再生
Material マテリアルデザイン支援
paper-onboarding 初回のチュートリアル的な
SVGKit SVGをUIImageに変換する
LTMorphingLabel 動く文字
NumPad ソフトウェアテンキーっぽいもの
SideMenu サイドメニューを簡単に実装
IBAnimatable 画面遷移をカッコよく
CDAlertView いい感じのAlertView
fluid-slider シャレオツなスライダー
BetterSegmentedControl シャレオツなセグメントコントロール

アプリ内WebViewで使ったライブラリ

Three.js スゲーやつ
cal-HeatMap Githubの草みたいなもの

iOSアプリ作ってて躓いた点

Swift4.2

（特に個人開発のライブラリで）「おっこれよさそう」と思ったライブラリがまだSwift4.2に対応していないという事案がそこそこ発生しました。
3 -> 4.2 や 4 -> 4.2の移行はそこまで辛くなさそうなのでどうしても使いたければForkして自力で変換するという手がないわけではないと思いますが、僕にはそこまでのパッションはありませんでした。
なのでライブラリの選択肢を増やすという観点では、現時点ではまだSwift4で作るのが攻守最強かなという感じがします。

CocoaPods

CocoaPodsはパッケージ管理を色々よしなにやってくれて、
Podfileさえ更新してしまえばライブラリが追加できるというのはお手軽ではあるんですが、
キャッシュが効かなくなるのか、Podfileを変更してアプリをビルドすると毎回ライブラリのビルドも１からし直すため、ビルド時間がかかるという事案に苛まれました。

そこらの軽いライブラリならビルド時間にあまり影響しないのですが、~~Realm、おめーのことだぞ~~
動作確認のために頻繁にビルドする僕みたいな初心者は、ビルド済み（というかビルドして）ライブラリを追加するCarthageの方が時間的コストが節約できるのかな〜と思いました。
ホットリロードできるFlutterやReactNativeだったらこの辺ストレスフリーなのかな〜と妄想しました。