※この記事はエンジニアになる前の自分に伝えたい心構え・知識 - Qiitaの記事をエクスポートしたものです。内容が古くなっている可能性があります。

概要

コンビニ店員からエンジニアに転職して半年ほど経過しました。まだまだ技術・知識不足を実感する日々ですが、同時に独学時代に比べるとかなり成長できていることも実感できてとても楽しい毎日です。今回はそんな私が実務を通して知ったことの中で、「入社前に知っておきたかったな」と思うことを当時の自分のような方に向けて書こうと思います。

※記事の内容は全て私個人の見解であり会社を代表するものではありません。 ※モバイルアプリ開発（Flutter）に携わることが多いので知識編ではその辺りの話も書きます。

心構え編

技術以外の、自分の気持ちに関することです。

1. 質問

自分で調べても分からないことは早めに質問する

前提として、エンジニアとしてというか社会人として大事なことだと思います。しかし私は独学でプログラミングを学習していたこともあり（？）、全て自分で解決しようとするところがありました。その結果、分からないことをいつまでも調べて数時間無駄にし、「どうしても分からない」と先輩に質問したら数分で解決したなんてことがありました。

もちろん、まずは自分で調べることが大前提ですが「調べてわかる」のか「今の自分には調べても分からなさそう / 時間がかかりそう」なのかを見極めて早めに質問しましょう。将来的に回数が減っていけば良いので、新人のうちに分からないことは潰しておきましょう。

質問内容

とはいえ、先輩の時間も有限です。だらだらと何を聞きたいのか伝わらない質問をするのはよくありません。私も丁寧に質問したいあまり文章が長くなってしまうことが多々ありますが、ざっくり以下のように内容を整理してから質問しましょう。

結論
- 知りたいこと / 話の要約
状況説明
- 実現したいこと
- 再現手順
- エラー内容
試したこと
補足

【結論】

一文目に結論 / 要約を書きましょう。先輩はお忙しいので全文しっかり読む時間はありません。最初に結論を伝えることで質問の全体像と緊急度が分かります。できるだけ端的にかけると良いですね。

【状況説明】

結論の後は自分の状況を詳細に書きましょう。〇〇をしようとして △△をしたら □□になった（□□のエラーがでた）といった具合です。詳細に伝えることで先輩は状況を理解しやすくなり解決に近づきます。

【試したこと】

よくある例え話で以下のようなものがあります。 Aさん「テレビが付かへん」 Bさん「コンセントは入ってる？リモコンに電池入れた？」

何を試したのか伝えないと先輩は「どこから確認すればええんや」となってしまいます。これは箇条書きで良いので伝えましょう。

【補足】

上記の補足、参考URLやエラー画面のスクショなどがあれば親切でしょう。

2. レスポンス

基本的にSlackのメンションや自分に向けてのメッセージは確認したらすぐにレスポンスを返しましょう。新人のうちは恐らく社内で一番時間があると思うので、先輩を待たせてはいけません。中でもお客様からのバグ報告などは緊急度MAXです。すぐ先輩に確認して対応しましょう。　

知識編

GitHubについてです。

1. GitHub

GitHubは実務での使用頻度の割に学習を後回しにしがちです。私もまだまだ使いこなせているとは言えませんが、基本的な知識を書いておきます。

※ Commitの仕方などGitの操作方法については割愛します。

Issue

何を記載するかはプロジェクトに依存しますが、だいたい下記が記載されていればissueの目的は達成されると思います。

機能追加の場合
- Why
  - なぜ必要なのか
- What
  - 何が必要なのか
バグの場合
- 概要
- 発生環境
  - 前提条件を記載
  - 例）
  - MacOS Catalina v10.15.7
  - Abdroid studio v4.0.1
  - Flutter v1.22.1(stable)
  - iPhone12(実機)
  - iOS14.2
- 再現手順
  - 例）〇〇画面のボタンを押すとクラッシュする
- 期待する動作と実際の動作
  - 例）ボタンを押すと□□画面へ遷移する

その他

自分が担当なら自分をAssign
ログを残す（後で見返せます）
SSIA
- "Subject Says It All”の略。「タイトルが全てを表している」という意味。

Pull request（PR）

issue同様、何を記載するかはプロジェクトに依存しますがだいたい下記を記載しています。レビュワーがビルドしなくても状況が伝わるように意識して書きたいですね。

概要
できるようになること
- スクショ画像等（<img width="300" src="アップロードURL">のようにすると見やすいです）
していないこと

粒度を小さくする

　1つの機能に対して1つのPRが理想的です。粒度が大きいとレビューが大変なので後回しにされてしまいます（自戒）。1個の大きいPRより10個の小さいPRを。

その他

LGTM
- "Looks Good To Me”の略。「私は良いと思う」という意味。

テンプレート

IssueやPull Requestはプロジェクト毎にテンプレートを作成することができます。プロジェクト全体で記載項目を統一できますし、何より作成時の手間が減ります。こちらの記事が分かりやすいです。

Project機能

GitHubプロジェクトでカンバンを表現できる機能です。視覚的にタスクを確認できるので便利です。

カンバンとは

カンバンは視覚的に仕事の管理や処理をする方法です。アジャイル開発手法をリードするアトラシアンは、「カンバンは仕事の可視化、WIP（進行中の作業）の制限、仕事の効率や流れを最大限に引き上げる方法であり、カンバンチームは、プロジェクトまたはユーザーストーリーの開始から完了までにかかる時間の削減に重点を置く」と説明しています。

引用：カンバン方式の基礎: チームがより素早く効率的に働く方法（トヨタ工場発のフレームワークみたいです。さすが世界のトヨタ…！）

私は過去のプロジェクトでは下記のような分類でタスク管理をしていました。

Sprint Backlog（着手していないタスク）
Todo（次に着手するタスク）
In Progress（作業中）
Review In Progress（レビュー中）
Reviewer Approved（レビュー完了）
Done（完了したタスク）

引用：5分で理解するリーンな「かんばん」

2. ソースコード

リーダブルコードおすすめです。

Flutter編

Flutterに関するTipsです。

1. デバッグ

simple_logger

ログ出力に呼び出し元の情報を含むことができ、クリックで飛べるようになります。これを知る前はprint()を使用していたのですが、開発効率が段違いに上がります。

使い方

こちらの記事を見ることを推奨します。simple_logger開発者のmonoさんが書かれたので一番分かりやすいと思います。

// logger.dart
final logger = SimpleLogger()
  ..setLevel(
    Level.FINEST, // 適当なレベルを設定
    includeCallerInfo: true, // リリースビルドではfalseにする
  )..onLogged = (log, info) {
    if (info.level >= Level.SEVERE) { // 適当なレベルを設定
      // Crashlyticsにエラーを送る。
    }
  };

// main.dart
import 'package:simple_logger/simple_logger.dart';

logger.finest('Hello!');
logger.finer('Hello!');
logger.fine('Hello!');
logger.config('Hello!');
logger.info('Hello!');
logger.warning('Hello!');
logger.severe('Hello!');
logger.shout('Hello!');

ログ

ビジュアルデバッグ機能

https://qiita.com/tatsu/items/68cf1125bfb167e2f6e8

Widgetのレイアウトを視覚的にデバッグできます。

2. 環境変数

.env + flutter_dotenv Gitで管理したくない秘匿情報や環境変数を扱えます。

使い方

プロジェクトルートに.envファイルを作成。

SAMPLE_VALUE=this is dot env value.

main関数で初期化。一度初期化したらどこでも呼び出せます。

// main.dart
void main() async {
  await DotEnv().load('.env');
  runApp(DotenvApp());
}

次のように呼び出します。

final sample_value = DotEnv().env["SAMPLE_VALUE"]

以上。

Jot Down the Tech

ソフトウェアエンジニアのメモ書き

エンジニアになる前の自分に伝えたい心構え・知識

概要