【学習38日】エンジニアに必要な《検索力》《可読性のあるコード》とは？【応用1日】
基礎カリキュラムを一旦終えたので、ブログを開始してみました！！
ブログを書こう！
Q 効率的にブログを書くために（15分以上時間をかけない）
最終的なアウトプットの時間の15分をブログに記述する。
→内容が頭に入っていないとアウトプットができない
→25分ー5分のスパンの休憩後に前のブロックで学んだ内容をこまめに思い出す
これを持っていないエンジニアは死活問題？！”検索力”とは？
エンジニアとして働き出したとしてもわからない問題にはその都度出会う
→自ら検索して答えを導き出す力は必須
→Google検索のプロになろう！！
ポイントは2つ
❶適切なキーワードを検索BOXに入れる
❷検索結果の中から適切な記事を選ぶこと
❶適切なキーワードを検索BOXに入れるのポイントは4つ
ー複数キーワードで検索
ー「検索ツール」から日時で絞り込む（新しい情報を表示）
ー英語で検索する
ーGoogle検索テクニックを使う（マイナス検索、フレーズ検索）
❷検索結果の中から適切な記事を選ぶこと のポイントは4つ
ー必ず1頁目から選ぶ（3ページ目とかもう信憑性がない）
ーQiitaとStack Overflowは信頼の置けるナレッジブログ
（Qiitaはストック数、Stack Overflowは票数が多い情報が
正確である可能性が高い）
ー一次ソースを確認する（公式サイトかGithubあたりに載っている）
ー怪しいブログは切り捨てる
（ほぼ更新させていないサイト、知恵袋・個人ブログ等の専門性の低いサイト等）
英語で検索することもあるから以下の単語は押さえておけ！！
| 英単語 | 意味 |
|---|---|
| change | 変える |
| save | 保存する |
| default | デフォルトの |
| compare | 比較する |
| configure | 設定する |
| override | 上書きする |
| install | 導入する |
良いコードとはなんぞ？？
A 読みやすいコードのこと。
複数人が集まって開発をするから周りの読みやすさを考慮すべし！
②コードのレイアウト（コードのレイアウトがぐちゃぐちゃになっていないか）
③コメント（他の人が1から解読しなくていいようにコメントを残しているか）
①命名規則
・汎用的な単語を用いていないか
・具体的でわかりやすい単語になっているか
・誤解を与えないか、2つの意味に取れたりしないか
| 英単語 | 説明 | 具体例 |
|---|---|---|
| set | 主にクラスのプロパティに値を代入する場合に用いる。 | set_projects |
| add | 追加。配列・リストにデータ、オブジェクトを加えるケースが多い。数値の加算もこちらを用いる。 | add_user_nickname |
| render | 画像などを編集した結果を表示したり、項目を HTML などに変換した上で返す。 | render_html |
| import | ファイルを対応形式に変換して読み込む。 | import_projects_show_file |
| fetch | （別の場所から）情報を取ってくる。CPU がメモリから命令コードを取ってくることを指す場合もあるが、データベースから情報を取得することを指すことが多い。 | fetch_account |
| modify | 部分的に修正する。edit より用途が広く、データのメインとなる箇所の変更はもちろん、それ以外の小さな変更であっても modify と表せる。 | modify_indentation |
| apply | 適用する。当てはめる。 | apply_projects_css |
| remove | データをリストや閲覧・アクセス可能な場所から取り除く。アクセス権のない領域への移動。取り除かれたデータが消滅するとは限らず、元に戻せる可能性がある。 | remove_user_data |
| is～ | オブジェクトが特定の型、状態であるか調べて true/false を返す。 | is isChecked |
②コードのレイアウト
・整列しているか（＝の位置を合わせるだけでもスッキリ）
・一貫性があるか（｛｝で改行するかどうかとか統一する）
・ブロック化（変数やメソッドを定義する際にある程度カテゴリでまとめておく等）
③コメント
・いちいち他のエンジニアに解読させない
・「なぜ」このようなコードを書いたのか
・TODO（いつかやる） メモ残す
・FIXME（直せる人直して）伝言を残す
・言葉で説明できない時は、具体例（どんな挙動になるのか）を残す
予想通り15分では書ききらず…！！
