本記事は一人アドベントカレンダー企画の一つです。
30代未経験エンジニアが25日後にJavaScriptをマスターするカレンダー
JAVASCRIPT.INFOを元にJavaScriptを勉強していき、そこで学んだ知識をアウトプットしていきます。
２５日でJAVASCRIPT.INFOをやりきり、未経験エンジニアがJavaScriptをマスターする過程を投稿していきます。
3.1 コーディングスタイル
知らない単語
-
チートシートとは
- 操作や記述でよく参照される情報を、簡潔な表記でまとめて一覧できるようにしたもの
-
ネスト
- 入れ子にすること
学んだこと
構文のルール
- 波括弧
波括弧は普通、新しい行ではなく同じ行に書かれる
エジプトスタイルという
このようになる
if (hello) {
...
}
-
行の長さ
横に長いコードは読みづらいので、分割するのがベスト
バッククォート「`」を使うと文字列を複数行に分割することができる -
インデント
インデントは２つのタイプのがある
水平なインデントは 2 または 4 つのスペースがあり、タブキーで調整する
垂直のインデントはコードを論理ブロックに分割するための空行である
１つの関数でも、論理的なブロックに分割できる
例えば
function hello(a,b) {
let result = 1;
// <--
for (let j = 0; j < b; j++) {
result *= a;
}
となる
-
セミコロン
省略できるとしても文の末尾につけるようにする -
ネストレベル
コードはネストし過ぎないようにする
ループで余計なネストを避けるためにcontinueディレクティブを使ってもよい
for (let a = 0; a < 5; a++) {
if (!cond) continue;
... // <- 余分なネストレベルなし
} -
関数の配置
基本的にはコードを読んだ人が、これから何をするのかを最初に理解できるように、関数を使用するコードが先に書かれていた方がよい
感想
- 読みやすいコードを書くことで、他の人が読んでも理解しやすく、エラーの回避にも繋がると思うので、ここで学んだ事を常に意識したい。
3.2 コメント
知らない単語
-
リファクタリングとは
- 外部から見た時の挙動は変えずに、プログラムの内部構造を整理すること
-
アーキテクチャ
- 基本設計や設計思想などのこと
学んだこと
-
コメント
コメントするには 「//」や「/* ... */」で始まる1行、もしくは複数行を囲う -
悪いコメント
初心者は無駄に長いコメントを書いてしまう
例えば
// このコードはこのようなこと (...) をして、次に (...)
hello;
world;
など -
良いコメント
良いコメントは時間が経ってから見てもすぐに理解できるように書いてある -
コメントにはどのようなことを書くか？
全体的なアーキテクチャ
関数の使用方法
重要な問題がある時、その解決方法など
感想
- コメントは、どんな処理や操作をするかを後から見た人に伝えるものだと思うので、わかりやすく簡潔に必要な事を書くよう心掛けたい。
3.3 忍者コード
知らない単語
- 無し
学んだこと
-
簡潔が肝心(Brevity is the soul of wit)
簡潔に書く事で、他の人が見た時にわかりやすいので重要である -
一文字の変数
より速くコード化するための方法は、a, b や c のように1文字の変数名を使うことが良い -
略語を使用する
チームのルールで決まっていても、外部の人などが見た時にわからないので、略語ばかりではよくない -
注意力テスト
「date」や「data」のように似ている変数名などをつけてしまうと、見間違えたりする可能性もあるので、分かりづらい、紛らわしい変数名などは付けない -
スマートな同義語
例えば「display」や「render」のように意味の似ている単語を同じチーム内で使ってしまうと、後から見た時に分かりづらいので、使う単語は統一する -
名前の再利用
既存の変数名を再利用しない
例えば
let name = 'tanaka';
// 処理が加わる
name = 13;
// 処理が加わる
console.log(name);
上記のコードでは途中で変数が変わっているので、当初予定していた出力はされない
勘違いなどでエラーに繋がるので
let name = 'tanaka';
// 処理が加わる
let age = 13;
// 処理が加わる
console.log(name);
のように別々の変数名にする
-
アンダースコア
「_name」もしくは「__value」のように意味のないアンダースコアは使わない
「dog_name」など意味がある時のみにする -
意味のある変数名にする
「superItem」や「niceElement」 など、それが何を指すのか全くわからないような変数名は避ける
感想
- このサイトでは、一文字の変数を使う事について、コードを早く書けるから良いというニュアンスで書いてあるが、個人的には短すぎる変数では意味が伝わらないので良くないと思った。
皮肉的な書き方なのかもしれないが。
3.4 mocha による自動テスト
知らない単語
- 無し
学んだこと
-
なぜテストが必要か？
もしコードのどこかが間違っていたら、コードを直して再度実行、確認を期待通り動くまで繰り返す
しかし手動で直しても、何かを見逃す可能性があり、十分ではない -
ビヘイビア駆動開発(BDD)
BDDは単なるテストではない
BDDのテストフレームワークは、
アプリケーションの動作を記述するストーリーフレームワーク
オブジェクトの動作を記述するスペックフレームワーク
がある -
spec
コードを作成する前に、関数が何をすべきかを記述する、それをspecと呼ぶ
specの主要な構成要素
it("title", function() { ... })
assert.equal(value1, value2)
などがある
「assert」はmochaというフレームワークの中にある
上記のコードでは(value1, value2)が「equal」で正しいのかをテストしている
specの特徴
テストコードが正しく動作する事を保証する
実際には関数がどのように使われるのかを見る事ができる
specがあると、安全に改善、変更、関数の書き直しができる
感想
- テストが重要なのはよくわかったが、BDDやspecの使い方を深く理解できていないと思うので、さらに詳しく勉強する必要がある
3.5 Polyfill（ポリフィル）とトランスパイラ
学んだこと
-
トランスパイラ
新しいコードをソフトウェアが古い書き方で書き直して動作させる
有名なトランスパイラは「Babel」などがある -
Polyfill（ポリフィル）
簡潔にいうと、すでに実装されている機能を古いものに追加するスクリプト
感想
- コードをうまく機能させる為に、トランスパイラとpolyfillを使用すべき時に使いたい
#最後に
- コードを綺麗に書いたり、コメントなど後から他人が見てわかりやすい書き方をする事が重要だと理解できた。しかし、テストの方法やBDD、spec等の使い方は難しかったので、エンジニアの知り合いに解説してもらったり、もう少し詳しく勉強しようと思う。