こんばんは！
ゆうです！
今回は私が読んだ本を元に
技術についてお伝えします。
また、記事の長さの都合上
読んだ本の全ては扱っていません。
では、いきましょう。
目次
１章 良いコードとは？
２章 良いコードを書くための習慣
３章 名前付け
１章
良いコードとは？
例えば宿題で書くコードを例にしたら、
課題だから答えがあって、求められているものを
クリアすることを優先しますよね？
社会人でいうと、企業に入って最初の研修なんかが
それにあたるのではないかと思います。
その場合、課題をこなせばいいので
- コメントも殆ど書かない
- 読んでもらう相手は先生だからわかるだろう
コーディングの際、良いコードを
書くために必要なことは
読む相手のことを考えることです。
大体の本を見ると難しいことが書いています。
しかし、最も重要な事は
読み手を意識してコードを書くこと
もっと身近な言い方をすれば、
一ヶ月先の自分は他人だと思って
コードを書くことです。
- コメントをしっかり書くこと
- 変数名の付け方に注意すること
重要な要素の一つが変数名になるでしょう。
「変数名は多少長くても
理解しやすいようにしたほうが絶対良い」
ということを覚えておいてください。
例を出すと
変数名が単にsizeでは
- 何のサイズ？
- 文字の個数？
- 画像の個数？
- ファイルの大きさ？
となって伝わらないんですね。
numberという変数でも同様に
int number;で宣言していたとしたら
int型は整数が入るに決まっているため
よくわからない変数名となります。
もっと計算機の表示するところの数字を
表すならResultNumberとかにするなど
もっとわかりやすくする変数名があります。
ResultNumberとnumberだと
情報量が全くと言っていいほど違います。
変数名を上手につけることができ始めると
プログラミングも上達する上に
仕事も任せてもらえるようになるでしょう。
２章
いいコードを書くための習慣
習慣その１ 読む
→ある程度できるようになってからで良い。
コードを読んで読みまくれ！！
とアドバイスされることもありますが。
これは自分で何か作れるようになってからで良いです。
そうでないと英語がわからないまま
英文を見ているのと同じです。
文字の羅列にしか見えないはずですね。
調べる時間の方が圧倒的に長いのです。
これではせっかく費やす時間ももったいないです。
なれた人向け=========================================
ここは慣れてからのことになりますが、
慣れない言語で本を見ながら調べながら書いていると、
不必要な行や、変な書き方になってしまいがちです。Githubに公開されいてる自分の作っているものに似たプロジェクトを見てコードを読みましょう。
今はもうGithubでいいと思います。
あとはGithubのTrendを毎日見とくとかでしょうか。
※時代の流れに逆らった偏屈なプログラマになってはいけません！
https://github.com/trending
==================================================
習慣その２ 書く
とにかくコードを書きましょう
自分でツールを作ったり、普段からコードを書きまくると
ということが良いということが書かれています。
実際参考書を読んでから、読んだ部分を使った
ちょっとしたツールを作ってみると良いですね。
語るよりも書くことが重要！
（自分にもこれを言いたい・・・）
習慣その３ 使うツールを常に疑う
使うツールは常にこれで良いのか疑いましょう。
メモ帳でコードを書くのとIDE(統合開発環境)
で書くのとではかなりの差があります。
メモ帳を使いこなしてそれが一番短時間で
書けるという場合はそれでも良いです。
エディタを洗練されたものを使うだけでも
作業効率が格段に上がります。
別にvimやemacsを使うことだけが答え
ではないですから、日々の作業を
どうすれば効率化できるかを
考えてみると良いです。
習慣その４ 知る
良い知識をつけましょう。
まずは原典（その技術の根幹本）と
How To本の二冊を入手することが
大切です。
つまり、使う技術の理論部分を説明した本と
どうやって使うかを説明した本を
入手しろということです。
実は、私は一番最初に読んだ本では
配列のソートのところで挫折してしまいました。
ソート？なにそれ？
わからないんだけど・・・
未経験の皆さん。
俺はこんな序盤で詰まってどうしたら・・・
と思わないでください。
それは当たり前なのです。
配列のソートという考え自体が
あなたにも私にも無かったからです。
新しい知識を噛み砕いて覚える
ということは不可能です。
できたとしても曖昧にしか覚えられません。
まずはソートとはどういう考え方、理論なのかを
知っていないといつまで経っても理解できません。
ソートのやり方が複数あると言われても
どうしたら良いのか意味分かりません。
記憶媒体の保存形式など前提となる知識を
分かっていないとダメなのです。
そのために原典は必要不可欠なのです。
苦しんで覚えたことが結局血と肉となります。
習慣その５ 聞く(教える)
アウトプットと人からのフィードバックでさらなる成長を
まずは隣の人に教えよう！！
記憶の定着度は以下のように言われている！
聞く（10%) 見る（15%） 聞く＆見る（20%） 話し合う（40%） 体験する（80%) 教える（90%）
※出典: メラビアンの法則
あなたは聞く、見るだけで終わってはいませんか？
まず話し合ったり、教え合うことから始めましょう！
まずは本に書いていることとして
教えるためには１２０%理解していなければなりません。
抽象的な概念から具体的な概念まで
一瞬で思いつくぐらいでなければなりません。
（理想としてはですが）
教える人がいないという状況もあると思いますから
そのときは相手がいると想定して考えればいいですね。
コードレビューを受ける
書籍や記事の執筆では、荒削りな段階の現行を
他人がチェックして、より良い記事にしていく、
「校正作業」というすばらしいプロセスが
用意されています。
校正作業により「自分以外の誰か」に
診てもらうことで良い原稿へと近づいていきます。
コードも同じです。公式・非公式を問わず、
自分の書いたコードを自分以外の誰かに
コードレビューしてもらうことで、
自分では気づかなかったフィードバックがもらえます。
コードレビューを通してコードが良くなるのは
もちろんですが、自分やレビュアが気づきを得て
成長できます。
コードを公開する場として最近注目を集めているのが、
ソーシャルなソースコードリポジトリのGitHubです。
GitHubで自分のコードを公開すると、
他人がコメントやフォーク（コードを引用して分岐すること）
を行うことができるので、ダイレクトな反応が得られます。
Gitについては別の機会に解説します。
３章
名前付け
実際に作者の本を読んで欲しいのですが、要点だけ書くと
１、長すぎず、短すぎず
２、意味の通じる名前に！かっこいいだけじゃダメ
３、一貫性がある
いい名前は、コード全体を通して一貫したポリシーで名前付けが行われている
・対称性を保つ
begin/end
write/read
writing/reading
right/left
open/close
on/off
onSuccess/onFailure
onSuccessとした場合はonFailedなどにしてしまうと
名詞/形容詞ということになるので対称性が保たれません。
正しくはfailedではなく、failureになります。
つまりは、名詞/名詞 または 形容詞/形容詞
というようにすることです。
大切なことをまとめると以下のようになります。
- 単語の組み合わせ方を一貫させる
- scoreAvg,scoreAverage,avgScoreなどを同時に使用しないこと
補足として
単語 ＋ 略語とした場合は一貫してそのルールで
単語 ＋ 単語にした場合は一貫してそのルールでということですね。
４、英語で付けられている
プログラミングに使われている名前は
英語がほとんどなので英語を使って
適切な名前をつけることで意図が誰にでも伝わります。
これは本当で、日本人だけならまだしも、
プロジェクトは外国人が加わることは
ごく普通にあるので万人に共通した英語で書くと
良いです。
本当はコメントも英語で書けばいいのでしょうが、
とりあえずは日本語で大丈夫です。
あとは誤訳にも注意しましょう。
英語には複数の意味を持っている単語が複数あります。
それは適切なのかどうかしっかり考えて付けましょう。
あとはプロジェクトにはイディオム（慣習）に従う。
参考
良いコードを書く技術 －読みやすく保守しやすいプログラミング作法
著者 縣俊貴
ISBN 978-4-7741-4596-9
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック
著者 Dustin Boswell
ISBN 978-4873115658
