サイトの画像ディレクトリってどうしてますか？
① /images/ のフォルダに全部ぶちこむ
② /images/hoge/ として、画像ディレクトリ内で階層分けする
③ /hoge/images/ として、ディレクトリごとに完全に分ける
④ その他
自分は今②でやっていて、
メリット：ある程度ファイルの見通しがよい。
デメリット：ディレクトリ名の変更があったら面倒。複数ページで使うものは /images/common/ に纏めているが、変更に弱い。
と感じています。
よろしければご意見お聞かせください。
49 件の回答
基本的には③かな。
共通画像はトップディレクトリに/common/をつくって入れている。
色々試した中で、これが一番わかりやすく汎用的かなと感じています。
> 複数ページで使うものは /images/common/ に纏めているが、変更に弱い。
どゆこと？
想像力弱くてすまん。
３。
/hoge/配下にindex.html、cssディレクトリ、jsディレクトリ、imgディレクトリとした方が個人的にわかりやすいし、グループ作業がしやすいように感じた。
/assets/img/ ←トップページとサイト共通で使うやつ
/assets/img/about/ ←下層ページで使うやつ
Re:3
要するにディレクトリ名を変更したらソースコードにあるやつ全部ディレクトリ名変更しなきゃいけないってことでしょ。
/img/hoge/a.pngでhogeをhoge2にしたらソースのやつ全部hoge2にしなきゃいけない的な。
/img // サイト全体で使う
/js // 同じ
/css // 同じ
/about/img // about 下でのみ使う
/about/js // 同じ
/about/css // 同じ
て感じ。主の言う③かな
/images/ サイトで使う画像。固定。
/uploads/ アップロードした画像（たまにfilesにする場合もあり）
/uploads/blogs/ ブログで使用した画像
サブドメインに隔離してハッシュ管理。
Re:3
すみません。分かりづらかったですね。
例えば /hoge/ で使っているのと全く同じ画像を、 後から /fuga/ で使うことになった場合、
commonに移さないといけない（気持ち悪い）という意味でした。
これは②だけに限らないですが。。
Re:7
一度同じ運用をしたことがあるのですが、
画像が100枚をこえた辺りから見通しがすごく悪くなって、自分にはちょっと厳しかったです。
何か特別に気をつけておられることとかあるのでしょうか？
みなさんありがとうございます。
③が多い感じなんですかね。
確かに要らなくなったらディレクトリごと消せばいいし、整理しやすそうです。
③の方は作業環境ってどうしてますか？
例えばpugを使っていたら、
src/pug/hoge/index.pug
└ /images/…
src/pug/fuga/index.pug
└ /images/…
という風に分けているのでしょうか？
Re:11
うーん。ファイルパスなり、命名規則なりで解決するしかないと思うが、個人的には、共有していなかったものを、あとから共有で使うことになった時点で、ファイルパスが共有用のパスに変化するのは、逆に、至極自然な流れだと思うよ。それはディレクトリの話ではなくて、仮に1の運用でもファイル名で対応しないといけいないから結局同じだと思う。
「共有ファイルの扱いが気持ち悪い・後からの変更に弱い」という問題は、どちらかと言うと、「(なるべく)後から変更されないように設計する」ことの方がプライオリティが高いだろうし、そうなってしまう状況は最初の設計(ページング・デザイン)が悪いと見るね。俺の場合。
Re:10
メリットは？
サブドメインを異なるサーバーで運用して負荷分散とかしてるってこと？
ページごとにcssやjsも分けてる人たちって、連結してないってことなの？
常にHTTP/2環境だから連結する必要ないって恵まれた人たちなの？
①だな
/img/の中に全部ぶっこんでる
画像名には必ずページのファイル名を頭につけることで分けてる
logo.svg
aboutImg01.jpg
aboutImg02.jpg
companyBtn01.jpg
とか
①も②も③もやったけど、結局①が一番早く組める。
場所が1か所だから迷わない。
100ページ超えるようなサイトも作ってるけど、今のところ困ったことはないな。
Re:14
> ファイルパスが共有用のパスに変化するのは、逆に、至極自然な流れだと思うよ
やはりその作業は当たり前に行なわないといけないものなんですね。
面倒がらずに徹底しようと思います。
> 最初の設計(ページング・デザイン)が悪い
ですよね。
全体像が見えない、顧客との合意が取れていない状況で作り始めることが殆どなので、
できるだけ変更に強い方法で運用したいなぁと思い、質問をしました。
Re:15
同一サーバー内に置くのはデメリットばかりじゃない？スケールしないし。コスト問題も起きる。SEOの為のレスポンスや負荷分散は大きいよね。何より画像はミドルウェアで色々処理したり、ログのために仕込んだり出来るよ。
Re:16
そこを考えないといけない程のアクセス数がない。
Re:18
というより、変更がそこまで患わらしいと思ったことが一度もない。
殆どの場合、置換とかで一発だと思うんだけど？
なんか時代遅れなレスばかりで驚愕してるんだが、こんなものなの？
Re:19
まぁ、わからんでもない発想だけど、そのメリットを受けられるケースは、とても限定的とだけは言っておこう。
Re:20
連結することによほどコストが必要なら理解できる意見ではあるけれど、全面的にメリットしかないものに対して、それほどコストがかからないのに採用しない理由が見当たらない。強いて言えば、職務怠慢ぐらいしか思い浮かばない。
Re:24
解像度を意識しないでいいし、権限わけも出来るのに？初心者には分かりづらいか。
Re:22
じゃあ2018年最新の方法を頼む。
Re:21
おっしゃる通り置換で一発なんですが、構築中に2回も3回も変わることあるんで面倒なんですよね。
ただの面倒くさがりなだけなんですが。。
Re:10
初心者過ぎてわからなかったので反応が遅れたのですが、そういう方法もあるんですね。
権限分け、ログの仕込み、画像の処理等できるとのことですが、自分の仕事の規模では少しオーバースペックそうです。
必要に駆られたらそういうこともできるのだと思い出すようにします。ありがとうございます。
Re:16
20と26にまとめてレスするけどさ、
いやいや、連結していれば、初回のロードで全ページ分のCSSがブラウザキャッシュされるやん。
ある意味プリロードやん。違う？ リクエストも常に1回だけだしさ。
>強いて言えば、職務怠慢ぐらいしか思い浮かばない。
これを職務怠慢って言う？ むしろ、連結すること前提にしておいたほうが、リンクの貼り間違えとか無くなるよね？ ミスが起こるリスクを潰すことにもなるけど？
Re:27
ポータルサイトでもやってんの？
みんながみんなポータルサイトやってるわけとちゃうからな。
最近こういうサービス見つけて、今度実案件に使おうかどうか検討中
https://cloudinary.com/
Re:26
メンテ性だよ。タスクランナーとか使えない層向けの。
Re:31
業務によって変わるから、正直どちらが正しいとかないと思うけどなあ。
自社開発系だったら連結にしろ圧縮にしろメリットしかないからやらない手はないと思うし、それを前提にするなら16の意見には全面的に同意。
ただ、Webサイトの場合は納品後の更新作業をクライアントがする場合がある。中小の場合は更新まで外注するとコストがかかりすぎるからな。そうした時にクライアントはタスクランナーどころかSassも使えない場合が圧倒的に多く、クライアントが更新をしやすくするためにあえて連結・圧縮をしないことが結構ある。連結・圧縮をせずにわかりやすいファイル管理をしようとするとディレクトリ毎の小分けをした方が事故率は下がる。
実際に中小や大手の一部を見てみるとそうなってる。ソース見ればわかるはず。
Re:27
大は小を兼ねる的な発想ね。
ただ、大には大なりのコストがかかるわけで、まぁ、わかりやすく言えば、多くの場合、その発想は無駄だね。
Re:35
この業界の人じゃないでしょ？
今日びディレクトリで管理とか不便すぎでしょ
Re:36
君が知らない業界もあるんだよ。
世間って、思っているよりも広いんだよねぇ～
Re:36
あのさ、反論してくれるのはいっこうに構わないんだけど、もっと論的につっこんでくれるかな。君のやってる行為、ﾏｻﾞｰﾌｧｯｶｰ連呼してるのと変わんないぜ？ それとも反射的に感情を出さずにはいられない寂しい生物なの？
Re:28
1つのフォルダに全てぶち込む
Re:34
うちはクラ直のサイト制作が主なんだけど、顧客のパターンとして
１）納品後、顧客自身では触らない。
２）納品後、顧客自身はCMSの管理画面側だけ触る。
３）CMSもソースも触る。
の3パターンに分かれていて、多い順に、２＞１＞３ なのよ。内訳は7:2:1ぐらいかな。
なので、連結しても困らないし、3の人たちはPugとかSassとかガンガンやってる人たちなんだよね…
なので、連結してる。
どうしてもソースコード直接触って更新したい、って人には、オーバーライド用のuser.cssってのを作って、そこに追記するようお願いしている。jQueryプラグイン追加したい時は、（jQueryを先頭にしている）app.min.jsの後に追加してくれ、っていうお願いもしている。
まあ、それが出来ないって人のためには、34さんの言うような運用にするかなあ。
Re:17
やだよ一覧表示した時さ…。
Re:42
そもそも一覧で表示しないんちゃう？
Re:5
これ
Re:39
非論理的すぎだろ。上に書いてるじゃん
Re:45
話が通じないな。
上に書いたものに関しては、「小規模なものに対してコストをかけるメリットがない(大は小を兼ねない)」と反論が終わってるのわかんねえかな。それに対して、「この業界の人じゃないでしょ？」はいくらなんでも論理がゼロじゃないか。説明すべきは、なぜその結論になったのかという部分だ(多くの人はこんなに分かりやすく噛砕なくても察する)。それにしても、逆に君の言う非論理ってどこの部分のこと言ってるんだよ。
Re:46
非論理的すぎｗ
会社でもこういう輩に説明しても無駄だとわかるけど、何でわからないのか。
Re:47
だから何を非論理的だといっているか説明しないことには前に進まないぜ？
説明なしで「非論理的」を連呼することほど非論理的なことはないと思うけどな。
自分で非論理を実践しちゃってるじゃん。分かってんのかな。
それともそれで論理武装してるつもりなんかな。お前の持ってるの竹槍だぞ、
Re:22
あー、君（ID:Fk0EOf ）って上で叩かれてるひとでしょ？
色々なやり方があるのは当然だと思うけど、人を納得させられる提示案も出来ないくせに見下すような書き込みするのはやめたほうが良いよ。
もーえーよお前ら。他所でやれヨソで。