1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

苦労しないコーディング方法

Last updated at Posted at 2023-08-08

皆さんこんばんは。
毎日個人制作をするために残業をやめようと決意したまちゅです。

昨日は1日目にしてインプットしている時間が取れず、
3時頃まで夜更かししてしまいました。
無茶をすると取り組みが継続できないのでやり方を考えねば・・と悩んでます。
良いやり方を見つけたいです。

本題

結論から言いますと、
苦労しないコーディング方法は分割をしっかりとすることです。

どういうことか。

エンジニアリングは出力という明確な回答があるのに対して、
デザインやUX/UIには答えがありません。
一般的にマテリアルデザインと言われるものも理想のUX近似値にすぎません。

ではその不毛な思考、消耗をやめるために必要なことは何か。
それが領域毎の作業の分割です。
具体的な行動は

  • CSS上でデザインを弄繰り回さない。
  • 見た目の実装と機能の実装を行ったり来たりしない。
  • デザインと実装の間で共通の規則を決める。

です。
上から解説します。

1. CSS上でデザインを弄繰り回さない。

最悪手です。
必ず、デザイン→実装の順番を守るようにします。
デザインボードに起こさない状態で実装に走ると、デザイン変更→吟味→デザイン変更→・・・といった、デザインのレビューサイクル速度が著しく低下し消耗します。
figmaはドラッグ1つで見た目を変えられますが、それをコード上でしようとすると、ホットリロードを活用したとしてもたった1pxの変更でさえ毎回文字を入力する→保存する→反映をまつという時間が発生します。

それに加え、ゴールが見えない状態で走ることになるので、しっくりこない点があると掛け算で作業時間が肥大化してかなりしんどいです。
デザインボードを再現することをとりあえずのゴールにしましょう。

2. 見た目の実装と機能の実装を行ったり来たりしない。

機能の実装をしている時に見た目の変更をするのをやめましょう。
あっちこっちいくのは、考えないといけないジャンルが雑多になって消耗し、成果物の質が落ちます。
しっかりと見た目実装と機能実装の作業フェーズを分割しましょう。

補足ですが、
実装で最も効果的な方法は、
見た目は雑で機能だけ作る→デザインに沿って見た目を整える
です。
なぜ機能が先かというと、
サイトは世の中を便利にする機能があって、その先に見た目がある、が本質だからです。

例えば、

  • 見た目が汚くても機能に不備が無く使いやすいサイト
  • 機能はバグだらけだが見た目が良いサイト

の2つを比較した場合には、前者が圧倒的に評価されます。
世の中の大半の人は、製作者が思っているよりもサイトのデザインを気にしていません。
サイトのメイン価値はそこではないからです。

なので、先に機能を仕上げておいてあげるとサイトはサイトとしての最低限の職能を全うでき、なおかつ不具合などに極力意識を割かずにデザインに没頭できるというメリットが発生します。

よって、しっかりと見た目と機能別で分けて実装に取り組んだ方が成果物の質が高くなります。

3. デザインと実装の間で共通の規則を決める。

デザインとエンジニアリングを薪のように分割した後は、
それを蝶番で繋がなければいけません。
両者のインターフェースとして、独自のコーディング規則を作ります。

例ですが、

  • marginは8の倍数にする
  • フォントサイズのバリエーションは5個まで
  • ブレークポイントは768pxと1080pxの2点

など、ここは独自ルールで構いません。
広く使われているTailwindCSSなどでは、ml-4のようなクラスがあり、これはmargin-left: 1remと同義です。figmaではgrid layoutを活用しましょう。

フォントサイズではtext-xsなどがあります。これは、figmaでもTypograpyとしてフォントサイズの定数化ができるので上手く使いたいですね。

端末のブレークポイントは、$xs: 375px;のような定数化をしてsassのメディアクエリで使用します。
figmaではレイアウト制約やオートレイアウト、コンポーネントを活用して管理コストを下げましょう。

コーディング規則のメリットは、管理コストが下がることもありますが
具体的な数値に悩むことが無くなることが良いです。
「規則で決まっているのだから、ここはこれでいいんだ」という割り切りができ悩む時間が減ります。

さいごに

個人開発だと特に、メンテナンスにかける時間は極力少なくしてモチベ高く施策に注力をしていきたいですよね。

上記の3つを守って運用してあげると気持ちよく制作活動ができるかもしれません。

明日はグリッドレイアウトの活用について書きます。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?