はじめに
エンジニアになって、もう少しで一年が経ちます。実務をする上で、「エンジニアは当たり前な知識だけど、学校で習わなかったな」を度々感じています。
この記事では新卒エンジニアとして働く中で、事前に勉強しておけばよかったと思った知識とその簡単な説明をまとめてみました。
プログラミング関連知識
フレームワーク
フレームワークとは、アプリケーション開発の土台、枠組みとなるもの
- 利点
- 機能が予め用意されており、0から開発をしなくていい
- フレームワークの規約にのっとった実装になるため、コードが統一されやすい
- 欠点
- フレームワークのルールから逸脱すると、保守性を大きく欠いてしまう
- フレームワーク特有のコードがある
業務で実施したこと
私は普段の業務でRuby on Railsというフレームワークを扱っています。一般的な機能が自動で作成されるので便利な反面、理解のしずらさも感じました。 研修ではRuby on Railsチュートリアルという学習サイトを利用しました。学習時間は一か月ほどかかりますが、公式なので内容がしっかりとしています。
テストコード
テストコードとは、プログラムが仕様通りに動作するか確認するソースコード
- 利点
- 実装段階で早期にバグを発見できるため、全体的にコストを抑えることができる
- テストを繰り返し実行でき、テストコードが仕様として残るので、コードの品質を保証できる
- 欠点
- 実装に時間がかかる
業務で実施したこと
学生時代にテストコードを書いたことがなく、Ruby on Railsチュートリアルで行ったMinitestが初めてでした。テストにもフレームワークがあり、機能を簡単にテストできます。
インフラ関連知識
Linux
Linuxとは、WindowsやMacと同じOSの一種
- 狭義では、Linuxカーネルのこと
- 広義でいうと、Linuxディストリビューションのこと
- Linuxディストリビューションとは、「Linuxカーネル + その他ソフトウェア 」のセットの配布形態のこと
- Linuxカーネルだけでは、OSとして機能できない
- そのため、その他ソフトウェアとセットで配布することで、OSとして使えるようにしている
業務で実施したこと
環境構築をする上で、WSLを使用してWindowsにLinuxをインストールする機会がありました。Linuxは環境構築やサーバー上の操作をする際によく使用します。
アーキテクチャ図
アーキテクチャ図とは、システムの全体像を可視化した図
- 関係者のシステムへの理解度を高め、問題点を発見、検討しやすくなる。
- システムで利用するサービスやコンポーネント、システムの境界にはどのようなものがあるか
- 各要素がどこに配置され、どのような制限があるか
- 各要素がどのように関連しているか
以下は、AWSのアーキテクチャ図になります
参照：AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ?
- コンポーネントの解説
- Route 53：名前解決などを行う
- CloudFront：ウェブコンテンツの配信を高速化する
- Amazon S3：データを保存しておく場所
- Internet gateway：外部との通信を可能にする
- Elastic Load Balancing：受信トラフィックを分散する
- Amazon EC2：インスタンス(サーバー)
- Amazon RDS：テーブル形式のデータベース
業務で実施したこと
システムの全体を把握する為に、アーキテクチャ図を読む機会がありました。シンプルな図でも、その図に描いてある機能がなんの為に存在しているのかが理解できず、行き詰まることがありました。アーキテクチャ図の理解には、インフラの知識が必要だと思います。
ログの管理
ログとは、コンピュータやシステムの様々な履歴を記録したもの
- ログを集中的に管理することで、システムに散らばったログを時系列で確認できる
- ログを一連の流れで見ることができるので、処理の挙動を分析できる
- また、どのタイミングでエラーが発生しているか特定できる
業務で実施したこと
先輩社員から「現在動いているバッチの設定、ソースコードを元に、バッチが動いていない時間をまとめてほしい」と依頼がありました。現在動いているバッチのソースコードを読みつつ、AWSのCloudWatchを利用してログを調査しました。ログを残さないバッチや開始と終了の時間が不明瞭なバッチがあり苦労しました。
雑務
議事録
議事録とは、会議の内容や結果をまとめて、記録または周知するための文章
- 会議の内容を振り返ることができるため、認識の相違があった時に確認できる
- 会議で決定した内容の証拠になるため、トラブルを未然に防げる
業務で実施したこと
幾つかの会議に出席し、議事録を自分で書くことがありました。会議で話されるプロジェクトの理解度が低く、会話の主語を推察するのが大変でした。また、話し言葉を文章に書き起こすのに中々慣れず、簡潔な文章を書くのが難しかったです。
感想
インフラ関連は重要であるが故に求められる知識の量が多く、学習時間が多く必要でした。仮想環境やフレームワークなど便利なものが増えるに伴って、その理解が困難です。大枠の知識の有無が、一つ一つの理解の深さに大きく影響すると思います。