現場を知らない去年の自分へ

furiguma
·

こちらの記事はStockr開発メンバーと一緒に振り返り Advent Calendar 2023の12日目の記事です。 https://adventar.org/calendars/9612

あっという間に今年ももう終わりに近づいてきました。

今年1年を振り返ると、1番大きなイベントは初の現場での勤務がスタートしたことかなと思います。

授業や研修とはまた違うことが必要になり、たくさんのことを学びました。

そこで、現場での勤務をしたことが無い去年の自分に話したいことというテーマで振り返りをしていきます。

命名やディレクトリ構造のルールには必ず従うべき。

授業や研修で作成するようなアプリと比べファイル数が多くなり、ファイルの名前や位置、中身を記憶するのが困難になります。

そこで、命名やディレクトリ構造のルールは遵守しておくことが必要です。

細かな理由

  • 検索でファイル名や関数名を使うために、命名規則に従うべき。(ファイル数が増える分重要度が上がる)

  • 用途からファイルを探すために、ディレクトリ構造のルールを決めておき遵守する。

  • コードの用途が理解しやすいよう、ディレクトリ名やファイル名、関数名は命名規則に従い分かりやすいものにする。

ユーザーが期待することを考える。分からない時は他の人に聞く。

何かを画面に要素を追加するにしても、形・色・場所・大きさ・文言・ユーザーの操作の種類や数……考えることは沢山あります。

ユーザーはそれらの要素がどんな状態であって欲しいのかを考えながら、要素を追加していかないといけません。

どうしても分からないなら周りにいるデザイナーやユーザーに聞くこと。とにかく、自分だけが使いやすいと感じる物を作らないようにすることが必要です。

ファイルや関数の役割を小さくする。

1つのファイルが多くの役割を持っていると、可読性が下がる上に改修がしづらい原因になる。ファイル数や関数の数が増えても可読性に大きな影響は無いため、役割ごとにファイルや関数を分けた方が良い。

製品が使えない瞬間について考える。

ユーザーにとって製品が使えないのは大きなストレスです。新しく書いたコードをリリースする時、リリース直後に製品が使えない状態にならないか確認してください。「夜中にバッチ処理が走るからそれまで待てばOK」などと考えるのはやめましょう。

できるだけ、リリース直後でも製品が動くようにコードを書きましょう。どうしても不可能な場合はユーザーへ周知しましょう。

最後に去年の自分へ。

現場で仕事をすると考えることが増えたり、責任が増えたり、思いどうりに行かなかったりすることはある。でも、チームメンバーで協力して成果が上がった時は嬉しいぞ!

現場は怖くない。自信を持て!

ということで変わった形式ですが自分の今年の振り返りでした。

ここまで読んでいただきありがとうございました。