フロントエンド開発３カ条

2020-08-10

フロントエンド開発を行うにあたって、自分なりの３カ条があるので書いていこうと思います。

1 つずつ解説をば。

シンプル・イズ・ベスト

フロントエンド開発を行うにあたって、complicated な状態、つまり複雑な状態を作るべきではありません。

フォルダ構成や画面仕様、api 仕様など、すべてにおいてシンプルであるべきだというのが持論です。

シンプルかつ理路整然とされた状態を作るには、しっかりとしたルールの整備が絶対に必要だと思っていて。

海外の大手 tech 企業が採用しているルールを導入するとともに、シンプルな設計や開発フローを取り入れることが、まず何よりも優先すべきことです。

プロジェクトに関わるメンバー全員がシンプル・イズ・ベストの理念のもとに、業務に当たることが大切だよなーと思います。

日本人の特徴として、長いものには巻かれがちなくせして、長いものに巻かれることを嫌うという風潮があると思っています。

で、個々人が独立した状態になったとたんにユニーク性を訴えるという、でもすごく気持ちはわかる、わかります。

長いものに巻かれる精神というのは、個人的にはケースバイケースだと思っていて。

単純に必要なときと不必要なときがあって、その判断を見誤ってはいけないよね、と思っています。

で、ことフロントエンド開発においては、長いものに巻かれる精神ってすごく大切です、10 割長いものに巻かれて大丈夫です。

特に技術選択においては、モダンでかつデファクトスタンダードに沿えば、きちんとしたものが作れます、これは断言できます。

にも関わらず、使ったこともないマイナーなものを選択したり、誰も理解していない難易度の高い思想を導入したりする現場が跡を絶たないのは、間違いなく日本人の人間性に依るところが大きいよなーと。

無難に冒険をしないチョイスって、時としてはすごく強い選択肢なわけです。

フロントエンド開発においては、保守的な思想こそ崇高であると、個人的には強く思います。

上の 2 つと比べると少し劣りますが、それでももちろん重要な考え方です。

未だに手動でフォーマットをかけたりリンターをかけたりビルドからデプロイをかけるような現場がめちゃくちゃ多いですが、昭和じゃないんだからといつも心のなかで突っ込んでいます。

可能な範囲で手動でのアプローチを省くこと、これは業務の効率化に他ならないわけで。

ちょっとしたスクリプトを組むこと、ちょっと調べることすら面倒臭がるのは、エンジニアとして最低な姿だとすら思っています。

業務の効率化を行うことで、コーディングなどの業務に集中すること、これこそあるべき現場の姿かなーと思います。

自分としては至極当たり前のことを書いているつもりですし、現場もこういう姿であるべきだと思っています。

前にも書きましたが、こういったことをきちんと遂行するには、スタートダッシュでおかしな選択をしなければ良いだけの話であって、途中で直すのはなかなか骨が折れます。

ということで、個人的なフロントエンド開発３カ条でした。