【フロントエンド編②】業務未経験の早大生がエンジニアとしてインターンで採用されてから約1ヶ月半で学んだことの総まとめ

こんにちは、ハシモです。前回の記事があまりに長くなったので、分割しました。多分、3000文字ぐらいに収まってくれるはず。そう祈ろう。

では、僕が未経験からエンジニアとしてインターンで働き始めるようにの、約1ヶ月半の間に得た、とっても大事なことを伝えます。この記事はフロントエンドについてですが、エンジニアとして大事なこと、という記事も書いたので、そっちも見てな!

他の記事

【フロントエンド編①】業務未経験の早大生がインターンで採用されてから約1ヶ月半で学んだことの総まとめ

【エンジニアスキル編】業務未経験の早大生がエンジニアとしてインターンで採用されてから約1ヶ月半で学んだことの総まとめ

 

htmlの構造設計が死ぬほど大事

基本的に、フロントエンドを書くときには、htmlを完成させてから、cssを書くのが基本です。まあ、htmlを各セクションごとに書いていって、それから各セクションごとにcssを完成させていくっていう方法もあるかもですが。

それで、css、まあ実務では拡張言語を使うのでscssとしますが、はクラスの継承関係が死ぬほど大事なんですね。

入れ子構造にして書くので、後々になってから、やっぱりここにdiv入れよう!!とhtmlを変更すると、scssの構造自体を変えなければならない。

この作業が死ぬほど面倒くさいです。なんか、頭がごちゃごちゃして、ワケワカラン状態になる。

画像をimgタグで出すか、backgroundで出すか

こんな発想、今までなかったです。あなたは、画像を出すとき、imgタグで出していますか、それともbackgroundで出していますか?

両者を使い分けたりしていますか?またその使い分けの基準はなんですか?

これらの質問に答えることができるでしょうか。

imgタグで出すなら、widthやheight、さらにはaltの値を指定することができます。つまり、画像に存在意義をもたせることができます。この画像がなければ、この記事の内容が上手く伝わらないなぁというとき、画像はimgタグで出力すべきです。

これに対し、backgroundのとき、表示される画像は、どこまでいっても”背景”です。あってもなくても変わらないということ。この画像の存在する意味ってなんだろうと問われたときに、特にないよなぁ…って答えられるものはbackground-imageで背景画像として出しましょう。

常識かもですが、少なくとも僕は知らなかったので、同じような全国の迷える子羊たちに伝えたいです。

imgタグのwidthとheightちゃんと書いてる?

imgタグで出力する画像には、もともとのサイズがあります。widthとheightでこれらを指定しましょう。

なぜそんなことをするかというと、サイズ指定がされていないimg要素は、読み込みが終わるまで高さと幅が確定できません。サイトを読み込むときに、画像が表示されず、レイアウトがぐちゃぐちゃになっているのを見たことがある人は多いと思います。

あれは、imgタグにwidthとheightを決めていないから起こる現象なんですよ!

だから、imgタグで画像を出すときには、ちゃんと画像サイズを指定しましょう!

altタグの中身、ちゃんと考えて書いてる?

すべての要素、タグ、属性には意味があります。このalt属性もそうです。altに値を指定すると、画像を表示できないときに、代わりに入力したテキストが表示されます。

また、音声でサイトを聞くというときには、このaltの中身の値が画像の代わりに読み上げられます。

知ってましたか?

安易に要素のwidthを決めちゃだめだぞ

画面の大きさが多岐にわたる現代のフロントエンドにおいては、安易に要素のwidthを決めることは危険です!

要素の横の長さが不変になってしまうと、ディスプレイの大きさが変わったときや、ウィンドウを小さくしたときなどに、要素が画面内に収まらない、ということが出てきます。

要素の縦の幅というのは、ディスプレイのサイズによってコロコロと変わるものではないので、確定させてもいいのです。が、要素の縦幅が決まっていると、後々テキストなどを追加するときにはみ出してしまうことがあります。

だからこそ、よーし、とりあえず楽ちんだからwidth: 760px, height: 60pxでいっちゃえ〜、なんてやっていると、後々死ぬほど面倒なことになるので、気をつけましょう!

 

railsがcssファイルを全部読み込むのがダルい

railsでアプリを作るとき(特に規模の大きい開発)、気をつけなければいけないことがあります。

assets/stylesheets/application.cssファイルの中に、デフォルトで、//= require_tree 、という記述があります。これがすべての災厄の引き金となるんです。

僕も完璧にわかっているわけではないので、ざっくりとした説明となりますが、簡単に言うと、このapplication.cssと同階層下にあるcssファイルを全部読み込むよぉ〜ってこと。

例えば、index.htmlがあったとして、cssファイルが5つぐらいあったとしましょう。このとき、index.htmlにかかるスタイルというのは、このcssファイル全てになります。

だから、この5つのcssファイルでそれぞれbodyにbackground-color: ほにゃらら、という書くと、競合が起きて、結局優先度の一番高いものが採用されるわけです。

知らず知らずのうちになんだかよくわからないcssがついているとか、たしかに要素は正しく指定してあるはずなんだけど上手く効かないぁ、というときがあるので(少なくとも僕はありました)、気をつけてくださいねってことです!

cssを書く順番を統一しよう

今の自分からしたら、極めて当たり前のことですが、大事なことなので、改めて。

cssを書く順番を統一してますか?

font-sizeとかpaddingとかの順番がしっちゃかめっちゃかになっていませんでしょうか。

これの何が大事かと言うと、もちろん、コードレビューをする人にとって見やすいように書くということもあるんですが、それ以上に、自分のためでもあるんですね。

あ、ちょっとこの要素をこの要素の間を開けたいた…。よし、padding-bottomを使おう。あれ、どこいった?

みたいな感じのことが起こりうるので、というか僕の実体験なんですけど笑

ということで、cssの順番は統一しましょう。社内での統一した書き方があるところもあると思いますし、または自分の中での規則を作っておくといいでしょう。ちなみに僕の場合は、

  1. display
  2. justify-content
  3. width
  4. height
  5. color
  6. font-〇〇系
  7. text-align
  8. vertical-align
  9. background-〇〇系
  10. border-〇〇系
  11. padding
  12. margin
  13. position

だいたいこういう感じで書いています!ぜひ参考にしてみてください!!

様式を統一しよう

一個前のcssの順番を統一しよう、というのと似たようなものですが、大事なので分けて書きます。

様式というのは例えば、

body{

background-color: #FFF;

}

っていうcssがあったときに、

  • タグの後ろにはスペースをいれるのか
  • プロパティの後のコロンと、値の間にスペースを入れるのか、入れないのか
  • 波カッコが閉じた後にすぐ次の記述をするのか、それとも1行改行するのか
  • 0px, という記述と0という記述がごっちゃになっていないか
  • カラーコードについて、アルファベットのときは小文字か大文字のどちらかに統一しているか、#FFFFFFのようなときには、#FFFと省略して書いているか

 

こういうチェックリストをつくって、自分でコードを見返すといいかもです!

cssで、パソコン側とスマートフォン側で同じコードを書くことがあっても、あえて二重にするほうがよい

これも、議論が多いところだと思うんですが、僕の考えとして、スタンスを述べておきます。

レスポンシブ対応が必須の現代において、@media all and (max(min)-width: 〇〇〇px)で、PC対応、スマホ対応、場合によってはタブレット対応、ディスプレイの大きさに応じてコードを書きますよね。

そのときに、DRY(don’t repeat yourself,同じコードは書かない)にしなきゃという気持ちから、PC対応とスマホ対応で、共通のコードを抜き出そうとすることがあるかもしれません。

が、これがはたして本当にいいのでしょうか。保守性、拡張性が高まるのでしょうか。

そうとは限りません。このページのこの部分だけ抜き出したいなぁというとき、抜き出す部分が2つの場合と3つの場合、どっちが楽でしょうか。個人的には、あるファイルのコードを抜き出すのが、神経を使うので苦手です。だから、少しでも抜き出す部分が少ないほうが楽ですね!

あとは、ファイルのコード量が大きくなってくると、PC、スマホの両方にかかっているコードの存在が認識しづらくなります。

どういうことかというと、例えばスマホ版のレスポンシブデザインを作っているときに、あれ、ここの2つの要素をもう少し空けたいなぁ、とmarginを設定したとしましょう。しかし、ここではすでに共通部分でmarginがかかっていたので、あえて再びmarginで既存のコードを打ち消すことは、ムダなんですよね。

そういう意味でも、同じコードを書くとしても、PCとスマホ、あえて冗長性をもたせて二重にコードを書いたほうがいいってことっす!

 

インスペクターを制するものはフロントエンドを制す

macの人は、コマンドキー+オプションキー+i でインスペクターが開けます。で、このインスペクターがくっそ便利なんですよね、フロントエンドを書く人にとっては!

elementsから現在のページのhtml構造、かかっているcssなどがわかりますし、インスペクターを使うと、特定の要素だけにcssを追加して、その結果を見るってことが簡単にできます。

エディタにしこしこコードを書いて、ブラウザでそれをリロードして、の繰り返しはいちいちムダが多いですし、細かい調整(例えば、font-sizeを1px単位で調整するときなど)をするときなんかはものすごい面倒くさいですよね。

ですが、インスペクターを使えば、それが一発で完了します。インスペクターに追加したコードは直接サイトに反映されるので、コードの可否が一瞬でわかります。それから、これなら大丈夫ってコードをコピってきてエディタの方に貼り付ければいいんです。

だからすごい楽ちん。特に初心者の場合は、どのコードが効いて、どのコードが効かないのか、暗中模索状態のことがよくあると思います。そういうときに、暗い足元に光を照らしてくれる存在が、このインスペクターなんですね!

ってわけでぜひ使ってみてください!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です