-
1:ID:asnwIO · 1週間前

サイトの画像ディレクトリってどうしてますか?
① /images/ のフォルダに全部ぶちこむ
② /images/hoge/ として、画像ディレクトリ内で階層分けする
③ /hoge/images/ として、ディレクトリごとに完全に分ける
④ その他

自分は今②でやっていて、
メリット:ある程度ファイルの見通しがよい。
デメリット:ディレクトリ名の変更があったら面倒。複数ページで使うものは /images/common/ に纏めているが、変更に弱い。
と感じています。

よろしければご意見お聞かせください。

49 件の回答

2:ID:B0ZNZl · 1週間前

基本的には③かな。
共通画像はトップディレクトリに/common/をつくって入れている。
色々試した中で、これが一番わかりやすく汎用的かなと感じています。

3:ID:9qGdhI · 1週間前

> 複数ページで使うものは /images/common/ に纏めているが、変更に弱い。

どゆこと?
想像力弱くてすまん。

4:ID:grzyQN · 1週間前

3。
/hoge/配下にindex.html、cssディレクトリ、jsディレクトリ、imgディレクトリとした方が個人的にわかりやすいし、グループ作業がしやすいように感じた。

5:ID:2SVdMJ · 1週間前

/assets/img/ ←トップページとサイト共通で使うやつ
/assets/img/about/ ←下層ページで使うやつ

6:ID:grzyQN · 1週間前

Re:3
要するにディレクトリ名を変更したらソースコードにあるやつ全部ディレクトリ名変更しなきゃいけないってことでしょ。
/img/hoge/a.pngでhogeをhoge2にしたらソースのやつ全部hoge2にしなきゃいけない的な。

7:ID:v7IilS · 1週間前

1
で、ファイル名のプレフィックスにページ名を入れてる

/images/hoge_a.jpg
/images/hoge_b.jpg
/images/common_a.jpg

8:ID:vGCB6w · 1週間前

/img // サイト全体で使う
/js // 同じ
/css // 同じ
/about/img // about 下でのみ使う
/about/js // 同じ
/about/css // 同じ
て感じ。主の言う③かな

9:ID:L4nLnY · 1週間前

/images/ サイトで使う画像。固定。
/uploads/ アップロードした画像(たまにfilesにする場合もあり)
/uploads/blogs/ ブログで使用した画像

10:ID:3xPXEr · 1週間前

サブドメインに隔離してハッシュ管理。

11:ID: · 1週間前

Re:3
すみません。分かりづらかったですね。
例えば /hoge/ で使っているのと全く同じ画像を、 後から /fuga/ で使うことになった場合、
commonに移さないといけない(気持ち悪い)という意味でした。
これは②だけに限らないですが。。

12:ID: · 1週間前

Re:7
一度同じ運用をしたことがあるのですが、
画像が100枚をこえた辺りから見通しがすごく悪くなって、自分にはちょっと厳しかったです。
何か特別に気をつけておられることとかあるのでしょうか?

13:ID: · 1週間前

みなさんありがとうございます。
③が多い感じなんですかね。
確かに要らなくなったらディレクトリごと消せばいいし、整理しやすそうです。
③の方は作業環境ってどうしてますか?
例えばpugを使っていたら、
src/pug/hoge/index.pug
      └ /images/…
src/pug/fuga/index.pug
      └ /images/…
という風に分けているのでしょうか?

14:ID:9qGdhI · 1週間前

Re:11
うーん。ファイルパスなり、命名規則なりで解決するしかないと思うが、個人的には、共有していなかったものを、あとから共有で使うことになった時点で、ファイルパスが共有用のパスに変化するのは、逆に、至極自然な流れだと思うよ。それはディレクトリの話ではなくて、仮に1の運用でもファイル名で対応しないといけいないから結局同じだと思う。
「共有ファイルの扱いが気持ち悪い・後からの変更に弱い」という問題は、どちらかと言うと、「(なるべく)後から変更されないように設計する」ことの方がプライオリティが高いだろうし、そうなってしまう状況は最初の設計(ページング・デザイン)が悪いと見るね。俺の場合。

15:ID:9qGdhI · 1週間前

Re:10
メリットは?
サブドメインを異なるサーバーで運用して負荷分散とかしてるってこと?

16:ID:2SVdMJ · 1週間前

ページごとにcssやjsも分けてる人たちって、連結してないってことなの?
常にHTTP/2環境だから連結する必要ないって恵まれた人たちなの?

17:ID:KE6GMw · 1週間前

①だな
/img/の中に全部ぶっこんでる

画像名には必ずページのファイル名を頭につけることで分けてる
logo.svg
aboutImg01.jpg
aboutImg02.jpg
companyBtn01.jpg
とか

①も②も③もやったけど、結局①が一番早く組める。
場所が1か所だから迷わない。

100ページ超えるようなサイトも作ってるけど、今のところ困ったことはないな。

18:ID: · 1週間前

Re:14
> ファイルパスが共有用のパスに変化するのは、逆に、至極自然な流れだと思うよ
やはりその作業は当たり前に行なわないといけないものなんですね。
面倒がらずに徹底しようと思います。

> 最初の設計(ページング・デザイン)が悪い
ですよね。
全体像が見えない、顧客との合意が取れていない状況で作り始めることが殆どなので、
できるだけ変更に強い方法で運用したいなぁと思い、質問をしました。

19:ID:3xPXEr · 1週間前

Re:15
同一サーバー内に置くのはデメリットばかりじゃない?スケールしないし。コスト問題も起きる。SEOの為のレスポンスや負荷分散は大きいよね。何より画像はミドルウェアで色々処理したり、ログのために仕込んだり出来るよ。

20:ID:vGCB6w · 1週間前

Re:16
そこを考えないといけない程のアクセス数がない。

21:ID:9qGdhI · 1週間前

Re:18
というより、変更がそこまで患わらしいと思ったことが一度もない。
殆どの場合、置換とかで一発だと思うんだけど?

22:ID:Fk0EOf · 1週間前

なんか時代遅れなレスばかりで驚愕してるんだが、こんなものなの?

24:ID:9qGdhI · 1週間前

Re:19
まぁ、わからんでもない発想だけど、そのメリットを受けられるケースは、とても限定的とだけは言っておこう。

26:ID:Twb/oL · 1週間前

Re:20
連結することによほどコストが必要なら理解できる意見ではあるけれど、全面的にメリットしかないものに対して、それほどコストがかからないのに採用しない理由が見当たらない。強いて言えば、職務怠慢ぐらいしか思い浮かばない。

27:ID:3xPXEr · 1週間前

Re:24
解像度を意識しないでいいし、権限わけも出来るのに?初心者には分かりづらいか。

28:ID:2B6/Xo · 1週間前

Re:22
じゃあ2018年最新の方法を頼む。

29:ID: · 1週間前

Re:21
おっしゃる通り置換で一発なんですが、構築中に2回も3回も変わることあるんで面倒なんですよね。
ただの面倒くさがりなだけなんですが。。

30:ID: · 1週間前

Re:10
初心者過ぎてわからなかったので反応が遅れたのですが、そういう方法もあるんですね。
権限分け、ログの仕込み、画像の処理等できるとのことですが、自分の仕事の規模では少しオーバースペックそうです。
必要に駆られたらそういうこともできるのだと思い出すようにします。ありがとうございます。

31:ID:2SVdMJ · 1週間前

Re:16
20と26にまとめてレスするけどさ、
いやいや、連結していれば、初回のロードで全ページ分のCSSがブラウザキャッシュされるやん。
ある意味プリロードやん。違う? リクエストも常に1回だけだしさ。

>強いて言えば、職務怠慢ぐらいしか思い浮かばない。

これを職務怠慢って言う? むしろ、連結すること前提にしておいたほうが、リンクの貼り間違えとか無くなるよね? ミスが起こるリスクを潰すことにもなるけど?

32:ID:2SVdMJ · 1週間前

Re:27
ポータルサイトでもやってんの?
みんながみんなポータルサイトやってるわけとちゃうからな。
最近こういうサービス見つけて、今度実案件に使おうかどうか検討中
https://cloudinary.com/

33:ID:vGCB6w · 1週間前

Re:26
メンテ性だよ。タスクランナーとか使えない層向けの。

34:ID:grzyQN · 1週間前

Re:31
業務によって変わるから、正直どちらが正しいとかないと思うけどなあ。
自社開発系だったら連結にしろ圧縮にしろメリットしかないからやらない手はないと思うし、それを前提にするなら16の意見には全面的に同意。
ただ、Webサイトの場合は納品後の更新作業をクライアントがする場合がある。中小の場合は更新まで外注するとコストがかかりすぎるからな。そうした時にクライアントはタスクランナーどころかSassも使えない場合が圧倒的に多く、クライアントが更新をしやすくするためにあえて連結・圧縮をしないことが結構ある。連結・圧縮をせずにわかりやすいファイル管理をしようとするとディレクトリ毎の小分けをした方が事故率は下がる。
実際に中小や大手の一部を見てみるとそうなってる。ソース見ればわかるはず。

35:ID:9qGdhI · 1週間前

Re:27
大は小を兼ねる的な発想ね。
ただ、大には大なりのコストがかかるわけで、まぁ、わかりやすく言えば、多くの場合、その発想は無駄だね。

36:ID:8Qkony · 1週間前

Re:35
この業界の人じゃないでしょ?
今日びディレクトリで管理とか不便すぎでしょ

37:ID:2SVdMJ · 1週間前

Re:36
君が知らない業界もあるんだよ。
世間って、思っているよりも広いんだよねぇ~

39:ID:9qGdhI · 1週間前

Re:36
あのさ、反論してくれるのはいっこうに構わないんだけど、もっと論的につっこんでくれるかな。君のやってる行為、マザーファッカー連呼してるのと変わんないぜ? それとも反射的に感情を出さずにはいられない寂しい生物なの?

40:ID:FLcAmD · 1週間前

Re:28
1つのフォルダに全てぶち込む

41:ID:2SVdMJ · 1週間前

Re:34
うちはクラ直のサイト制作が主なんだけど、顧客のパターンとして

1)納品後、顧客自身では触らない。
2)納品後、顧客自身はCMSの管理画面側だけ触る。
3)CMSもソースも触る。

の3パターンに分かれていて、多い順に、2>1>3 なのよ。内訳は7:2:1ぐらいかな。
なので、連結しても困らないし、3の人たちはPugとかSassとかガンガンやってる人たちなんだよね…

なので、連結してる。

どうしてもソースコード直接触って更新したい、って人には、オーバーライド用のuser.cssってのを作って、そこに追記するようお願いしている。jQueryプラグイン追加したい時は、(jQueryを先頭にしている)app.min.jsの後に追加してくれ、っていうお願いもしている。

まあ、それが出来ないって人のためには、34さんの言うような運用にするかなあ。

42:ID:vGCB6w · 1週間前

Re:17
やだよ一覧表示した時さ…。

43:ID:2SVdMJ · 1週間前

Re:42
そもそも一覧で表示しないんちゃう?

44:ID:UEJZOt · 1週間前

Re:5
これ

45:ID:Fk0EOf · 1週間前

Re:39
非論理的すぎだろ。上に書いてるじゃん

46:ID:9qGdhI · 1週間前

Re:45
話が通じないな。
上に書いたものに関しては、「小規模なものに対してコストをかけるメリットがない(大は小を兼ねない)」と反論が終わってるのわかんねえかな。それに対して、「この業界の人じゃないでしょ?」はいくらなんでも論理がゼロじゃないか。説明すべきは、なぜその結論になったのかという部分だ(多くの人はこんなに分かりやすく噛砕なくても察する)。それにしても、逆に君の言う非論理ってどこの部分のこと言ってるんだよ。

47:ID:Fk0EOf · 1週間前

Re:46
非論理的すぎw
会社でもこういう輩に説明しても無駄だとわかるけど、何でわからないのか。

48:ID:9qGdhI · 6日前

Re:47
だから何を非論理的だといっているか説明しないことには前に進まないぜ?
説明なしで「非論理的」を連呼することほど非論理的なことはないと思うけどな。
自分で非論理を実践しちゃってるじゃん。分かってんのかな。
それともそれで論理武装してるつもりなんかな。お前の持ってるの竹槍だぞ、

49:ID:J8OWyg · 6日前

Re:22
あー、君(ID:Fk0EOf )って上で叩かれてるひとでしょ?
色々なやり方があるのは当然だと思うけど、人を納得させられる提示案も出来ないくせに見下すような書き込みするのはやめたほうが良いよ。

50:ID:vGCB6w · 5日前

もーえーよお前ら。他所でやれヨソで。

3 件の回答が除外されました。[詳細]
コメントの受付は終了しました。

一緒に読まれている質問

ページ上部に戻る