※前スレ
プログラマの雑談部屋 ★62
https://medaka.5ch.net/test/read.cgi/prog/1551007254/
プログラマの雑談部屋 ★63
https://medaka.5ch.net/test/read.cgi/prog/1551744733/
プログラマの雑談部屋 ★64
https://medaka.5ch.net/test/read.cgi/prog/1552655641/
探検
プログラマの雑談部屋 ★65
■ このスレッドは過去ログ倉庫に格納されています
2019/03/22(金) 22:42:02.62
2019/03/22(金) 22:49:27.61
新元号は;DROP DATABASE *
2019/03/22(金) 22:56:11.83
vipのスレ貼れ
2019/03/22(金) 23:10:03.48
6仕様書無しさん
2019/03/22(金) 23:58:59.84 大手ってプログラムは外注するもんちゃうの。
7仕様書無しさん
2019/03/23(土) 01:17:42.37 人生飽きた。
自殺するか迷う。
自殺するか迷う。
2019/03/23(土) 02:30:52.95
労働者に祖国はない
ネトウヨは働いてないから人間失格
シベリアで強制労働してこい
ネトウヨは働いてないから人間失格
シベリアで強制労働してこい
10仕様書無しさん
2019/03/23(土) 03:10:47.25||‖|||⊥⊥、||‖‖
||‖|/JAP:ヽ|‖‖ アベノミクスで景気が回復している
||‖/::_ノ八\_::\|‖
|| /::((・))::((・))::ヘ ‖ 韓国・中国は日本に嫉妬している
|||:::⌒(_人_)⌒::: |
|| ::::|トェェイ|::::|| イチローは優秀な日本人
||ヘ | | /‖
||‖>ヘ ヒェェイ ノ < ‖ でも在日は日本人じゃない
||r' `ー-´ ヽ
イチロー凄い、日本凄い、俺凄い、安倍総理万歳!!
11仕様書無しさん
2019/03/23(土) 05:17:38.73 4連休なのにやることがない
12仕様書無しさん
2019/03/23(土) 07:46:22.82 前スレで処理を3-5-2とか数値で管理するとか議論してましたけど、オブジェクト指向使わない開発ってまだあるのでしょうか?
20万人月のエンタープライズ開発とか関わった事無いので、そういう開発はまだまだ現役なのかなと気になって
20万人月のエンタープライズ開発とか関わった事無いので、そういう開発はまだまだ現役なのかなと気になって
13仕様書無しさん
2019/03/23(土) 07:49:19.41 オブジェクト指向言語で開発してたけどクラスとメソッドに連番ついてたよ
14仕様書無しさん
2019/03/23(土) 07:49:23.68 F22の制御システムはエントリポイントから一直線に関数使わず処理を書いてるらしいから区切り毎に数字で管理してそう
16仕様書無しさん
2019/03/23(土) 07:51:38.68 ぜいたくだな
17仕様書無しさん
2019/03/23(土) 07:54:01.87 単語管理だと少々の綴り間違いとか読み間違いで場所間違えたりするじゃん
番号ついてたら資料との対応付けが正確
オブジェクト指向とどう関係するとおもったのか
番号ついてたら資料との対応付けが正確
オブジェクト指向とどう関係するとおもったのか
18仕様書無しさん
2019/03/23(土) 07:54:58.49 【偽装請負多重派遣搾取犯罪者追放のお願い】
犯罪者個人に対して告訴状を偽装請負・偽装出向・多重派遣の被害者が作成(刑事告訴は無料) or 司法書士が代筆(料金は5万円ぐらい)
↓
告訴状を【検察の直告班】に郵便局の内容証明付で送付(疎明資料・証拠にはICレコーダー、スマホによる録音が適しています)
↓
審査 → 不受理 → 告訴状再提出または刑法 第193条で訴えを起こす
↓
受理 → 告訴事実を認め示談交渉(↓) →示談成立 →法廷相場50〜100万円の示談金 ※示談拒否が良い
↓ ↓
事案化 ←←←←←← 示談不成立(↓) →示談外交渉 →犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓ ↓
↓ 起訴 →公判 →罰金刑=前科(起訴事実を認めてるため)→追討ち民事訴訟
↓
審査 → 起訴(強制捜査・留置場)→ 公判 → 懲役刑などの厳罰(反省が認められないため)→追討ち民事訴訟
↓
不起訴、起訴猶予
↓
検察審査会法第30条(検察審査会へ申し立て)→ 起訴 → 起訴後は同上
刑法 第193条(公務員職権濫用)で検察事務官を刑事告訴 → 同上
◎告訴→告訴受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約(公正証書・即決和解で秘密保持契約)
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者に告訴できます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事告発(刑事訴訟法239条1項)も可能です。
加害者本人、管理間接部門の社員が刑事告発に踏み切る場合も和解金による解決が妥当です。
注意:告訴が受理されない理由
●3年間(※)の時効が過ぎたもの ※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの ※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。
犯罪者個人に対して告訴状を偽装請負・偽装出向・多重派遣の被害者が作成(刑事告訴は無料) or 司法書士が代筆(料金は5万円ぐらい)
↓
告訴状を【検察の直告班】に郵便局の内容証明付で送付(疎明資料・証拠にはICレコーダー、スマホによる録音が適しています)
↓
審査 → 不受理 → 告訴状再提出または刑法 第193条で訴えを起こす
↓
受理 → 告訴事実を認め示談交渉(↓) →示談成立 →法廷相場50〜100万円の示談金 ※示談拒否が良い
↓ ↓
事案化 ←←←←←← 示談不成立(↓) →示談外交渉 →犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓ ↓
↓ 起訴 →公判 →罰金刑=前科(起訴事実を認めてるため)→追討ち民事訴訟
↓
審査 → 起訴(強制捜査・留置場)→ 公判 → 懲役刑などの厳罰(反省が認められないため)→追討ち民事訴訟
↓
不起訴、起訴猶予
↓
検察審査会法第30条(検察審査会へ申し立て)→ 起訴 → 起訴後は同上
刑法 第193条(公務員職権濫用)で検察事務官を刑事告訴 → 同上
◎告訴→告訴受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約(公正証書・即決和解で秘密保持契約)
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者に告訴できます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事告発(刑事訴訟法239条1項)も可能です。
加害者本人、管理間接部門の社員が刑事告発に踏み切る場合も和解金による解決が妥当です。
注意:告訴が受理されない理由
●3年間(※)の時効が過ぎたもの ※違法派遣
●同一事実について過去に告訴取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの ※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事告訴は有効です。
19仕様書無しさん
2019/03/23(土) 08:39:32.73 >>11
エンジニアのくせに何いうとるねん、やることはいっぱいあるだろ、死ね。
エンジニアのくせに何いうとるねん、やることはいっぱいあるだろ、死ね。
23仕様書無しさん
2019/03/23(土) 09:33:38.07 >>12
オブジェクト指向を使わない開発は今でもあるが、それはあまり関係ない。
前スレはオブジェクト指向関係なくドキュメントの話だ。
ワードやエクセルの資料には必ず章番号、項番号がある。
ただ処理フローレベルで書かれていて、
項番をガチガチに参照しなくちゃならないドキュメントは前時代的であまり見かけない。
オブジェクト指向を使わない開発は今でもあるが、それはあまり関係ない。
前スレはオブジェクト指向関係なくドキュメントの話だ。
ワードやエクセルの資料には必ず章番号、項番号がある。
ただ処理フローレベルで書かれていて、
項番をガチガチに参照しなくちゃならないドキュメントは前時代的であまり見かけない。
24仕様書無しさん
2019/03/23(土) 09:45:07.71 前時代もクソも
機能一覧が完璧であれば
それの処理一覧=メソッド一覧を出せば
設計は完璧なんだよ
オブジェクト指向なんてどこで必要になるのか?
やるにしても処理一覧出してからやってくれ
機能一覧が完璧であれば
それの処理一覧=メソッド一覧を出せば
設計は完璧なんだよ
オブジェクト指向なんてどこで必要になるのか?
やるにしても処理一覧出してからやってくれ
25仕様書無しさん
2019/03/23(土) 09:46:08.80 なのでドキュメントの項番とメソッド名が結びついてさえいればドキュメントとしては完璧
26仕様書無しさん
2019/03/23(土) 10:00:39.0128仕様書無しさん
2019/03/23(土) 10:25:43.6329仕様書無しさん
2019/03/23(土) 10:46:43.16 >>28
分割しろや
なんでもかんでも詰め込んだくっそ長いゴッド設計書を書いてるから番号付けたくなるんだよ
1ファイルに100章あるならそりゃ番号付けたくもなるだろうがな
適切に分割すればそんなもんは必要ない
分割しろや
なんでもかんでも詰め込んだくっそ長いゴッド設計書を書いてるから番号付けたくなるんだよ
1ファイルに100章あるならそりゃ番号付けたくもなるだろうがな
適切に分割すればそんなもんは必要ない
31仕様書無しさん
2019/03/23(土) 11:04:32.33 >>29
よく書くドキュメントはだいたい20頁、5章ぐらいだがね。
その下に中項目1〜3、さらに小項目がある場合もある。
で、いったい何を分割しろというのか?
こうやって明確に見出しが付けられるのは、内容がきれいに分割されてるからこそなのだが。
よく書くドキュメントはだいたい20頁、5章ぐらいだがね。
その下に中項目1〜3、さらに小項目がある場合もある。
で、いったい何を分割しろというのか?
こうやって明確に見出しが付けられるのは、内容がきれいに分割されてるからこそなのだが。
32仕様書無しさん
2019/03/23(土) 11:05:09.12 unordered listで十分だけどordered listにしても構わない、自動で採番できるならいいけど、採番にわざわざ労力を使いたくはない、程度のものでしょ章番号なんてさ
ドキュメントのレビューする時だって、第3章のあれはこうしたほうがいいですね、などと言われてもわかりにくい
注文管理の章のあれはこうしたほうがいいですね、と名前だけで通じるようにすべき
ドキュメントのレビューする時だって、第3章のあれはこうしたほうがいいですね、などと言われてもわかりにくい
注文管理の章のあれはこうしたほうがいいですね、と名前だけで通じるようにすべき
34仕様書無しさん
2019/03/23(土) 11:12:19.88 うちのシステム、システム上では同じ物を指してても
人によって呼び方がバラバラなんだが
DDDのユビキタス言語とやらを取り入れたら解決できる?
プログラマーと顧客でシステム内の用語の呼び方が違うと
伝言ゲーム化して認識にズレが生じてしまう
予めプログラマーと顧客の間で共通言語を定義しておいてそのズレを防ごうと言うのがDDDにおけるユビキタス言語らしい
http://www.slideshare.net/AtsuoAoki/ddd-201811
静的解析ツールのNDependは予め辞書で定義した用語しかコード内で使えないようにする機能がある
ユビキタス言語の使用を徹底させるための物だ
確かにここまでしてしまえば勝手に同じ物を別な呼び方をするのは出来なくなりそうだが、どうなんだ?
Checking DDD Ubiquitous Language with NDepend - NDepend
https://blog.ndepend.com/checking-ddd-ubiquitous-language-with-ndepend/
人によって呼び方がバラバラなんだが
DDDのユビキタス言語とやらを取り入れたら解決できる?
プログラマーと顧客でシステム内の用語の呼び方が違うと
伝言ゲーム化して認識にズレが生じてしまう
予めプログラマーと顧客の間で共通言語を定義しておいてそのズレを防ごうと言うのがDDDにおけるユビキタス言語らしい
http://www.slideshare.net/AtsuoAoki/ddd-201811
静的解析ツールのNDependは予め辞書で定義した用語しかコード内で使えないようにする機能がある
ユビキタス言語の使用を徹底させるための物だ
確かにここまでしてしまえば勝手に同じ物を別な呼び方をするのは出来なくなりそうだが、どうなんだ?
Checking DDD Ubiquitous Language with NDepend - NDepend
https://blog.ndepend.com/checking-ddd-ubiquitous-language-with-ndepend/
35仕様書無しさん
2019/03/23(土) 11:19:54.26 >>31
内容が綺麗に分割されてるならファイルを分割できるだろ
例えば注文管理と顧客管理を同じファイルに詰め込む意味はないし注文管理ち顧客管理に本質的は本質的に順序がないのでどっちが1章でどっちが2章などと採番するのは無意味
顧客管理のプレゼンテーション設計とドメイン設計と永続化設計を同じファイルに詰め込む意味はないし3者には本質的に順序がないのでどれがなん章だと採番するのは無意味
ドメインの各集約ルートの設計を同じファイルに詰め込む意味はないし各集約ルートに本質的に順序がないのでどれがなん章だと採番するのは無意味
こうやって物事を分析して階層化して管理していけば自然とファイルが分割されていき無意味な採番はなくなっていく
結局はコードを書く時と同じなんだよな
コードをかけない上流は1つに全てを詰め込んで無意味に順序を付けた最悪なドキュメントを書きたがる
内容が綺麗に分割されてるならファイルを分割できるだろ
例えば注文管理と顧客管理を同じファイルに詰め込む意味はないし注文管理ち顧客管理に本質的は本質的に順序がないのでどっちが1章でどっちが2章などと採番するのは無意味
顧客管理のプレゼンテーション設計とドメイン設計と永続化設計を同じファイルに詰め込む意味はないし3者には本質的に順序がないのでどれがなん章だと採番するのは無意味
ドメインの各集約ルートの設計を同じファイルに詰め込む意味はないし各集約ルートに本質的に順序がないのでどれがなん章だと採番するのは無意味
こうやって物事を分析して階層化して管理していけば自然とファイルが分割されていき無意味な採番はなくなっていく
結局はコードを書く時と同じなんだよな
コードをかけない上流は1つに全てを詰め込んで無意味に順序を付けた最悪なドキュメントを書きたがる
36仕様書無しさん
2019/03/23(土) 11:20:00.4538仕様書無しさん
2019/03/23(土) 11:26:22.82 >>36
わかりやすい名前が付けれないならそもそも内容がまだよく分析されてない証拠だ
内容がぼやけてるからコレだという命名ができない
そんな状態で番号管理を始めたらどれがなんでどんな内容なのかあっという間にカオス化する
結局はコードを書くときと同じなんだよ
適切なクラス名が思いつかないので番号で分けましたなんてやって分かりやすくなることなんてまずありえない
わかりやすい名前が付けれないならそもそも内容がまだよく分析されてない証拠だ
内容がぼやけてるからコレだという命名ができない
そんな状態で番号管理を始めたらどれがなんでどんな内容なのかあっという間にカオス化する
結局はコードを書くときと同じなんだよ
適切なクラス名が思いつかないので番号で分けましたなんてやって分かりやすくなることなんてまずありえない
39仕様書無しさん
2019/03/23(土) 11:28:00.64 結局は、出来る奴にしか出来ないってだけのことだな。
41仕様書無しさん
2019/03/23(土) 11:33:17.16 学校じゃクラスには名詞を付けると習ってますが実務じゃクラスに番号振るのですか?
猫にニャーニャー鳴かせたいのに実装では3-1がニャーニャー鳴くとか違和感なんですけど
猫にニャーニャー鳴かせたいのに実装では3-1がニャーニャー鳴くとか違和感なんですけど
42仕様書無しさん
2019/03/23(土) 11:34:31.11 番号なんてソートやフィルターのためだけなことぐらい気づけよ。
43仕様書無しさん
2019/03/23(土) 11:36:32.75 ドキュメントを1ファイルに結合して番号振る人って、mainから始まる長い一本グソみたいなプログラム書きそう
44仕様書無しさん
2019/03/23(土) 11:38:55.5345仕様書無しさん
2019/03/23(土) 11:39:49.75 >>35
まとめて10ページ程度のボリュームならば見出しは5つぐらい。
一ファイルが適切でしょう。
1.概要
2.開発環境
3.システム構成
4.ソフトウェア構成
5.機能
例えば、きみはこの10頁のファイルを見出しごとにばらばらにして、
「概要」「開発環境」などという1〜2ページのファイルを5つ作るのかい?
受け取ったらアホかと思うわ。
まとめて10ページ程度のボリュームならば見出しは5つぐらい。
一ファイルが適切でしょう。
1.概要
2.開発環境
3.システム構成
4.ソフトウェア構成
5.機能
例えば、きみはこの10頁のファイルを見出しごとにばらばらにして、
「概要」「開発環境」などという1〜2ページのファイルを5つ作るのかい?
受け取ったらアホかと思うわ。
46仕様書無しさん
2019/03/23(土) 11:42:33.23 ソートやフィルターかけるならなおさら名前だろ
独立な各章を五十音順にソートしたいのに章タイトルのプレフィックスに項番入ってたときの不快感は格別なものだ
独立な各章を五十音順にソートしたいのに章タイトルのプレフィックスに項番入ってたときの不快感は格別なものだ
47仕様書無しさん
2019/03/23(土) 11:44:14.47 首輪インターフェースを実装した猫クラスにニャーニャーと、犬クラスにワンワンと鳴かせる
これがオブジェクト指向と理解して学校卒業しましたが、実務ではクラスを3-1,3-2と管理する
実務は訳が解らないですね
ちゃんと専門学校出た人が設計しているのでしょうか
これがオブジェクト指向と理解して学校卒業しましたが、実務ではクラスを3-1,3-2と管理する
実務は訳が解らないですね
ちゃんと専門学校出た人が設計しているのでしょうか
49仕様書無しさん
2019/03/23(土) 11:47:06.83 ぶっちゃけ、名前がコードでも文字列でもオブジェクト指向か同どうかとは別の問題じゃね
コンパイルしてリンクして、シンボル名に実アドレス割り振ったらオブジェクト指向じゃないなら、実行可能なプログラムはオブジェクト指向じゃないことになる
コンパイルしてリンクして、シンボル名に実アドレス割り振ったらオブジェクト指向じゃないなら、実行可能なプログラムはオブジェクト指向じゃないことになる
50仕様書無しさん
2019/03/23(土) 11:48:59.94 >>45
私だったら分けます
・5つのハイパーリンクを画面左に表示
・リンクをクリックしたら内容を画面右に表示
という構成になるでしょうね
ちなみにGitbook等を使って作製します
文章の長さは意味的な分割には関係ありません
私だったら分けます
・5つのハイパーリンクを画面左に表示
・リンクをクリックしたら内容を画面右に表示
という構成になるでしょうね
ちなみにGitbook等を使って作製します
文章の長さは意味的な分割には関係ありません
52仕様書無しさん
2019/03/23(土) 11:53:10.1653仕様書無しさん
2019/03/23(土) 11:55:24.75 見出し要らんと言ってるやつは
なんでWORDに見出し機能がついてるのか考えろ
なんでWORDに見出し機能がついてるのか考えろ
54仕様書無しさん
2019/03/23(土) 11:57:07.32 内容を分けるのは大事だが、
内容を分ける=ファイルを分ける ではない
内容を分ける=ファイルを分ける ではない
56仕様書無しさん
2019/03/23(土) 12:09:58.51 >>53
なぜって?
なんでもかんでもくっつけたクソ長いドキュメントでしかも番号管理だとどこになにがあるかわからなくなるからだろ
見出しがないとおめあてのページを見つけるのもジャングルに冒険しにいくのも大差ない労力がかかる
ファイル分割して適切な名前をつけて階層管理してれば見出しがなくてもすぐに目的の文章を見つけられる
もちろんオプションとして見出しページを生成するのは自由だ
なぜって?
なんでもかんでもくっつけたクソ長いドキュメントでしかも番号管理だとどこになにがあるかわからなくなるからだろ
見出しがないとおめあてのページを見つけるのもジャングルに冒険しにいくのも大差ない労力がかかる
ファイル分割して適切な名前をつけて階層管理してれば見出しがなくてもすぐに目的の文章を見つけられる
もちろんオプションとして見出しページを生成するのは自由だ
57仕様書無しさん
2019/03/23(土) 12:11:45.23 >>50
> 文章の長さは意味的な分割には関係ありません
もちろんそう。
だが、意味的な分割とファイルの分割を混同してはいけない。
分割したものをファイルで分けるか、見出しで分けるかはどちらが見やすいかによるでしょう。
人間、一つのドキュメントは数〜数十ページのが見やすくそれを基準にすればよい。
> 文章の長さは意味的な分割には関係ありません
もちろんそう。
だが、意味的な分割とファイルの分割を混同してはいけない。
分割したものをファイルで分けるか、見出しで分けるかはどちらが見やすいかによるでしょう。
人間、一つのドキュメントは数〜数十ページのが見やすくそれを基準にすればよい。
58仕様書無しさん
2019/03/23(土) 12:21:06.15 >>57
いいえ
異なる内容が連続して続くと読みにくいです
続けて読まないと理解できない構成なのだろうか?などと単純に気が散りますし
その章の長さがパッと見てわからないと読む方としては困ります
編集する時にも困ります
編集の影響範囲がどこまで広がるのかわかりにくいので前後の章まで無駄に確認する労力がかかります
コミットログも関連性の薄いコメントが並ぶとうっとおしいでしょう
いいえ
異なる内容が連続して続くと読みにくいです
続けて読まないと理解できない構成なのだろうか?などと単純に気が散りますし
その章の長さがパッと見てわからないと読む方としては困ります
編集する時にも困ります
編集の影響範囲がどこまで広がるのかわかりにくいので前後の章まで無駄に確認する労力がかかります
コミットログも関連性の薄いコメントが並ぶとうっとおしいでしょう
60仕様書無しさん
2019/03/23(土) 12:23:31.91 >>56
見つけられることと見つけやすいこととは違う。
書籍や新聞、ドキュメントには何故すべて見出しが書かれているのか。
これを見出しごとにすべて別冊にしたらどうなると思う?
ファイルで管理ではなく、見出しで管理すべき内容があるということだ。
見つけられることと見つけやすいこととは違う。
書籍や新聞、ドキュメントには何故すべて見出しが書かれているのか。
これを見出しごとにすべて別冊にしたらどうなると思う?
ファイルで管理ではなく、見出しで管理すべき内容があるということだ。
61仕様書無しさん
2019/03/23(土) 12:35:23.04 >>58
「異なる内容」の単位ってなんだい?
クラス内の関数だってそれぞれ異なる内容なんだが、きみは関数ごとに一ファイル作るのかい?
例に挙げたのは、もちろん連続した内容。
続けて読まないと理解できない構成でしょう。
ファイルを分けるより一つのファイルのほうが読みやすい例であると思いますが。
章の長さは目次を見てもわかりますし、一つの見出しは1ページ程度。
むしろファイルを分けていたら開いて見なきゃわかりませんよね?
「異なる内容」の単位ってなんだい?
クラス内の関数だってそれぞれ異なる内容なんだが、きみは関数ごとに一ファイル作るのかい?
例に挙げたのは、もちろん連続した内容。
続けて読まないと理解できない構成でしょう。
ファイルを分けるより一つのファイルのほうが読みやすい例であると思いますが。
章の長さは目次を見てもわかりますし、一つの見出しは1ページ程度。
むしろファイルを分けていたら開いて見なきゃわかりませんよね?
62仕様書無しさん
2019/03/23(土) 12:36:34.84 >>60
見出しに利便性があるからといって1つにまとめるべきであるという結論には至りません
見出しは1つの巨大な文章でも分割された文章でも機能します
書籍や新聞は媒体の制約で1つにまとめるしかなかったのでまとめられただけです
1つまとめられた文章は読みにくく探しにくく編集しにくいです
見出しはその不便性を補うために採用されました
オンラインドキュメントでは同じ文章構成でもファイル分割して管理します
その方が読みやすく探しやすく編集しやすいからです
各ファイルへのハイパーリンクを見出しとすることができます
見出しは文章の価値を高めるオプションとなります
見出しに利便性があるからといって1つにまとめるべきであるという結論には至りません
見出しは1つの巨大な文章でも分割された文章でも機能します
書籍や新聞は媒体の制約で1つにまとめるしかなかったのでまとめられただけです
1つまとめられた文章は読みにくく探しにくく編集しにくいです
見出しはその不便性を補うために採用されました
オンラインドキュメントでは同じ文章構成でもファイル分割して管理します
その方が読みやすく探しやすく編集しやすいからです
各ファイルへのハイパーリンクを見出しとすることができます
見出しは文章の価値を高めるオプションとなります
63仕様書無しさん
2019/03/23(土) 12:37:24.0364仕様書無しさん
2019/03/23(土) 12:43:05.10 >>61
責務を基本に考えると分割の目安が分かりやすくなります
クラスには1つの責務があるはずなので1つのファイルに書きます
概要や開発環境は明らかに異なる責務を持っています
ですのでこれらは別のファイルで管理します
責務を基本に考えると分割の目安が分かりやすくなります
クラスには1つの責務があるはずなので1つのファイルに書きます
概要や開発環境は明らかに異なる責務を持っています
ですのでこれらは別のファイルで管理します
65仕様書無しさん
2019/03/23(土) 12:47:22.12 【人類は一つです(バカウヨ除外)】 世堺教師マiトレーヤ 【ユダヤから富を奪還し分ち合おう】
http://rosie.5ch.net/test/read.cgi/liveplus/1553306560/l50
http://rosie.5ch.net/test/read.cgi/liveplus/1553306560/l50
66仕様書無しさん
2019/03/23(土) 12:51:48.75 >>62
> 見出しに利便性があるからといって1つにまとめるべきであるという結論には至りません
それはそうでしょう。そんなことは誰も主張していない。
私は、ファイルを分けるべきケースと、ファイル内で見出しを付けるべきケースが
それぞれあるということを主張している。
むしろそちらが、
見出しを付ける代わりに、なんでもかんでもファイル単位に分割せよという
妙な主張をしていると思っているのだが。
> 見出しに利便性があるからといって1つにまとめるべきであるという結論には至りません
それはそうでしょう。そんなことは誰も主張していない。
私は、ファイルを分けるべきケースと、ファイル内で見出しを付けるべきケースが
それぞれあるということを主張している。
むしろそちらが、
見出しを付ける代わりに、なんでもかんでもファイル単位に分割せよという
妙な主張をしていると思っているのだが。
67仕様書無しさん
2019/03/23(土) 12:59:02.72 袋とじのテーブル仕様書
68仕様書無しさん
2019/03/23(土) 13:01:28.82 >>64
では「責務」の単位って何だい?
話はそれるが、
1クラス1責務というのはよく聞くが、「責務」といったところでやはり曖昧な概念だ。
システム全体でも大きな一つの「責務」を担っているし、
関数は関数で一つの小さな「責務」を担っているとも見えるのだが。
では「責務」の単位って何だい?
話はそれるが、
1クラス1責務というのはよく聞くが、「責務」といったところでやはり曖昧な概念だ。
システム全体でも大きな一つの「責務」を担っているし、
関数は関数で一つの小さな「責務」を担っているとも見えるのだが。
71仕様書無しさん
2019/03/23(土) 13:32:47.2272仕様書無しさん
2019/03/23(土) 13:34:54.83 【言論弾圧】【言葉狩】ツイッター、「ジャップ」はBAN対象に
73仕様書無しさん
2019/03/23(土) 13:41:10.57 ジャップでBANされるだけでなくチョッパリでもBANされたという噂もある
これでますますネトウヨがつけあがる
これでますますネトウヨがつけあがる
75仕様書無しさん
2019/03/23(土) 13:47:31.19 こいつら国外追放してほしいわ
76仕様書無しさん
2019/03/23(土) 13:52:41.08 >>74
デフォルトというなら、見出しのないドキュメントの方が多いということですか?
新聞、雑誌、書籍、技術ドキュメント、だいたい何見ても
一つのドキュメント内にいくつもの見出しがついてると思いますがね。
「全部ファイルに分割すれば、見出しは必要ない」 などというのが
いかに非常識な主張かをわかっていただければ幸いです。
デフォルトというなら、見出しのないドキュメントの方が多いということですか?
新聞、雑誌、書籍、技術ドキュメント、だいたい何見ても
一つのドキュメント内にいくつもの見出しがついてると思いますがね。
「全部ファイルに分割すれば、見出しは必要ない」 などというのが
いかに非常識な主張かをわかっていただければ幸いです。
77仕様書無しさん
2019/03/23(土) 14:01:03.82 >>76
見出しとファイル分けるわけないは別の話だと何度もレスしてる
単一ファイルでも分割ファイルでも見出しは付けれる
単一ファイルは見出しがないと使い物にならないけどね
新聞雑誌書籍等は製造、輸送、販売の都合でまとめられてるだけ
Web無償提供の技術ドキュメントはそういったやむをえない事情がないから合理的に分割するほうが増えてきてる
見出しとファイル分けるわけないは別の話だと何度もレスしてる
単一ファイルでも分割ファイルでも見出しは付けれる
単一ファイルは見出しがないと使い物にならないけどね
新聞雑誌書籍等は製造、輸送、販売の都合でまとめられてるだけ
Web無償提供の技術ドキュメントはそういったやむをえない事情がないから合理的に分割するほうが増えてきてる
78仕様書無しさん
2019/03/23(土) 14:05:21.65 さらに言うとユーザーの手元にまとまって届く書籍等でもライターの手元では分割管理されているものだよ
79仕様書無しさん
2019/03/23(土) 14:07:42.46 ん?この話の論点は何なの?
80仕様書無しさん
2019/03/23(土) 14:22:14.40 >>77
そちらは見出し単位でファイル分けるという主張ですよね?
つまりその主張だと1ファイルに見出しは一つ。
Webドキュメントなら一ページ一見出しも多いが、それはデザインの関係だ。
閲覧者から見れば、ファイルの概念ではなくあくまでページとして見えるからね。
ではWORDやExcelのドキュメントはどうだ?
まともなドキュメントには、だいたい見出しと目次がついてる。
いくつものファイルでバラバラに提供されるより、
一文書として見出しにより構造化されていた方がわかりやすいからね。
そちらは見出し単位でファイル分けるという主張ですよね?
つまりその主張だと1ファイルに見出しは一つ。
Webドキュメントなら一ページ一見出しも多いが、それはデザインの関係だ。
閲覧者から見れば、ファイルの概念ではなくあくまでページとして見えるからね。
ではWORDやExcelのドキュメントはどうだ?
まともなドキュメントには、だいたい見出しと目次がついてる。
いくつものファイルでバラバラに提供されるより、
一文書として見出しにより構造化されていた方がわかりやすいからね。
81仕様書無しさん
2019/03/23(土) 14:32:01.39 >>77
> 新聞雑誌書籍等は製造、輸送、販売の都合でまとめられているだけ
そういう売る側の手間もあるでしょうね。
しかしもっと根本的に考えてくれ。
書籍が見出しごとにバラバラにされ、クリアファイルに入れられてたら買うかい?
> 新聞雑誌書籍等は製造、輸送、販売の都合でまとめられているだけ
そういう売る側の手間もあるでしょうね。
しかしもっと根本的に考えてくれ。
書籍が見出しごとにバラバラにされ、クリアファイルに入れられてたら買うかい?
82仕様書無しさん
2019/03/23(土) 15:00:10.19 >>80
良い文章は論理構造がわかりやすいだけであって1つにまとまってたり見出しや目次があるからわかりやすいのではないよ
>>81
紙の書籍だと媒体の制約のせいでバラ売りされると管理が面倒だから買わないかな
でも同じ内容の電子書籍だったら媒体の制約がないから欲しいセクションだけ買うかな
適切な名前で必要なセクションにすぐアクセスできるならそっちのほうがいい
いちいち巨大な書籍をロードして目次までスクロールして目次ページをめくってめくってリンク押してそこから目的のページまでオフセット分ページ捲ってようやっとたどり着くのって面倒だよね?
紙の書籍だと分厚い重い本を本棚から取り出して目次ペラペラめくってページ番号覚えて適当にページ開いて番号比較して違ってたらまたシークしてセクションの先頭から目的のページまでまた微調整でページめくってってなるんだろうけど酷い手間だ
良い文章は論理構造がわかりやすいだけであって1つにまとまってたり見出しや目次があるからわかりやすいのではないよ
>>81
紙の書籍だと媒体の制約のせいでバラ売りされると管理が面倒だから買わないかな
でも同じ内容の電子書籍だったら媒体の制約がないから欲しいセクションだけ買うかな
適切な名前で必要なセクションにすぐアクセスできるならそっちのほうがいい
いちいち巨大な書籍をロードして目次までスクロールして目次ページをめくってめくってリンク押してそこから目的のページまでオフセット分ページ捲ってようやっとたどり着くのって面倒だよね?
紙の書籍だと分厚い重い本を本棚から取り出して目次ペラペラめくってページ番号覚えて適当にページ開いて番号比較して違ってたらまたシークしてセクションの先頭から目的のページまでまた微調整でページめくってってなるんだろうけど酷い手間だ
83仕様書無しさん
2019/03/23(土) 15:32:59.28 >>82
そうじゃない。
わかりやすい論理構造を表現するために、見出しや目次をつけるんだ。
> 適切な名前で必要なセクションにすぐアクセスできるならそっちのほうがいい
なるほど、きみがイメージしているのは、
辞書のように、項目が独立している「論理階層のない」ドキュメントだ。
それならば自分が使う部分だけを引っ張ってこれれば事足りる。
しかし納品物には論理階層があるからね。
だからWORDドキュメントには見出しが付いている。
そうじゃない。
わかりやすい論理構造を表現するために、見出しや目次をつけるんだ。
> 適切な名前で必要なセクションにすぐアクセスできるならそっちのほうがいい
なるほど、きみがイメージしているのは、
辞書のように、項目が独立している「論理階層のない」ドキュメントだ。
それならば自分が使う部分だけを引っ張ってこれれば事足りる。
しかし納品物には論理階層があるからね。
だからWORDドキュメントには見出しが付いている。
84仕様書無しさん
2019/03/23(土) 15:53:33.45 >>83
目次は文字通りインデックスでしかない
目的のページを検索するための道具であって論理構造には影響しない
論理構造が目次に影響することはあるがね
論理階層構造をディレクトリで表現するんだよ
君なんも理解してないね
注文管理のドメイン層の注文エンティティについて記述した文書だったらordering/domain/entities/order.xxxを見ればいいってすぐにわかるのは論理階層構造が明確化されてるからだろ?
目次形式だと目次ページを開いてシーケンシャルに目次を追わなきゃorderの項目までたどり着けん
論理階層構造とは無関係の連番で管理されてるからだ
エクセルやワードに執着してるとわからんのかなぁ?
テキストからコンパイルするタイプのドキュメントかマークアップ・ダウン系統のドキュメントを何度か書いてみたら?
目次は文字通りインデックスでしかない
目的のページを検索するための道具であって論理構造には影響しない
論理構造が目次に影響することはあるがね
論理階層構造をディレクトリで表現するんだよ
君なんも理解してないね
注文管理のドメイン層の注文エンティティについて記述した文書だったらordering/domain/entities/order.xxxを見ればいいってすぐにわかるのは論理階層構造が明確化されてるからだろ?
目次形式だと目次ページを開いてシーケンシャルに目次を追わなきゃorderの項目までたどり着けん
論理階層構造とは無関係の連番で管理されてるからだ
エクセルやワードに執着してるとわからんのかなぁ?
テキストからコンパイルするタイプのドキュメントかマークアップ・ダウン系統のドキュメントを何度か書いてみたら?
85仕様書無しさん
2019/03/23(土) 15:56:30.52 ちょこっとコードを書かないといけなくなった
家じゃ全然やる気しないからカフェで
コーヒー飲みながらやってくるわ
家じゃ全然やる気しないからカフェで
コーヒー飲みながらやってくるわ
86仕様書無しさん
2019/03/23(土) 16:03:07.67 要するに1ファイル君はツリーで表現されるべきデータ構造をベクターで表現しようとしてるんだよ
でもベクターじゃ読むのしんどいし検索もキッツイし編集は最悪にやりにくい
せめて検索だけでも楽にしようってんで見出しをつけてインデクシングしたの
んでなにを血迷ったのかせっかく用意したインデックスにも番号振っちゃったせいでシーケンシャルアクセスしないと情報を見つけられないようにしちゃった
でもベクターじゃ読むのしんどいし検索もキッツイし編集は最悪にやりにくい
せめて検索だけでも楽にしようってんで見出しをつけてインデクシングしたの
んでなにを血迷ったのかせっかく用意したインデックスにも番号振っちゃったせいでシーケンシャルアクセスしないと情報を見つけられないようにしちゃった
87仕様書無しさん
2019/03/23(土) 16:04:48.3888仕様書無しさん
2019/03/23(土) 16:09:33.10 >>84
ドキュメントは読むためのものだ。
論理構造があるかないかではなく、それを表現するための道具として見出しは使われる。
数ページ程度のドキュメントに対して、見出し単位で分解してバラバラにした挙句
ディレクトリに振り分けて論理構造を表現しましたと言われたら
そいつはきっと正気ではないと思う。
要するにきみらはドキュメントの一部が必要なだけなので、
そこだけ小さなファイルに分けて渡してもらった方がよいという話に過ぎない。
ドキュメントは読むためのものだ。
論理構造があるかないかではなく、それを表現するための道具として見出しは使われる。
数ページ程度のドキュメントに対して、見出し単位で分解してバラバラにした挙句
ディレクトリに振り分けて論理構造を表現しましたと言われたら
そいつはきっと正気ではないと思う。
要するにきみらはドキュメントの一部が必要なだけなので、
そこだけ小さなファイルに分けて渡してもらった方がよいという話に過ぎない。
89仕様書無しさん
2019/03/23(土) 16:18:09.42 >>88
なるほど君はエンジニアじゃなくてエンドユーザーだったんだな
エンジニアにとってドキュメントは書くものでも読むものでもある
なので編集性には最大限の気を配ってファイルを分割する
もちろんそれで検索性や可読性が悪化するということはなく逆に向上するのだけどね
なるほど君はエンジニアじゃなくてエンドユーザーだったんだな
エンジニアにとってドキュメントは書くものでも読むものでもある
なので編集性には最大限の気を配ってファイルを分割する
もちろんそれで検索性や可読性が悪化するということはなく逆に向上するのだけどね
90仕様書無しさん
2019/03/23(土) 16:33:11.61 >>89
「読むもの」というのはエンドユーザーへの成果物として捉えているかどうかだ。
そりゃ開発中の参考資料や途中段階だったら、編集が被らないようにバラバラの方が都合がいいわ。
納品の際には結合するんだがね。
「自分らにとって都合がいい」に無理やり理屈をつけてるに過ぎない。
自分らの効率はそれで正当な理由だがまずそれを認識しろ。
成果物としてのドキュメントには、常識的に一つのファイル内に目次やいくつもの見出しが必要になる。
大きすぎるファイルは可読性が悪いので分けるのは賛成だがね。
ただ見出しの項目ごとにファイルを分けるというのは、あまりにも馬鹿げた主張。
数10ページ単位で一つの見出しを付けてる奴の発想だ。
「読むもの」というのはエンドユーザーへの成果物として捉えているかどうかだ。
そりゃ開発中の参考資料や途中段階だったら、編集が被らないようにバラバラの方が都合がいいわ。
納品の際には結合するんだがね。
「自分らにとって都合がいい」に無理やり理屈をつけてるに過ぎない。
自分らの効率はそれで正当な理由だがまずそれを認識しろ。
成果物としてのドキュメントには、常識的に一つのファイル内に目次やいくつもの見出しが必要になる。
大きすぎるファイルは可読性が悪いので分けるのは賛成だがね。
ただ見出しの項目ごとにファイルを分けるというのは、あまりにも馬鹿げた主張。
数10ページ単位で一つの見出しを付けてる奴の発想だ。
91仕様書無しさん
2019/03/23(土) 16:49:07.3492仕様書無しさん
2019/03/23(土) 16:55:55.82 家でやる気が出ない時点でカフェに行ってやる気が出るはずもなし
93仕様書無しさん
2019/03/23(土) 17:08:30.05 >>90
ビルドして静的なウェブサイトを構築するツールなどがありますよ
PDFなどにコンパイルする選択肢もあるっちゃありますが今はウェブサイトの方が圧倒的に使いやすいですね
使いやすいと言ったのは読みやすいだけじゃなく検索や前後上のリンク、パン屑リスト、JS等ウェブサイトのポテンシャルを活かしたドキュメントを構築できるからです
エクセルやワードでも機能付きドキュメントは作れますが管理が困難の極致にあり動作が遅すぎるため実用には届きません
あなたもエンジニアなのですから(ですよね?)言語やフレームワークのオンラインドキュメントを読んだことがあるはずです
あなたの常識(成果物は1ファイル内に見出しがうんぬん)は少々古く歪んだ常識ではないでしょうか
あなたの目の前にあるパソコン(あるいはスマホ)でぜひ視野を広げてみてください
ビルドして静的なウェブサイトを構築するツールなどがありますよ
PDFなどにコンパイルする選択肢もあるっちゃありますが今はウェブサイトの方が圧倒的に使いやすいですね
使いやすいと言ったのは読みやすいだけじゃなく検索や前後上のリンク、パン屑リスト、JS等ウェブサイトのポテンシャルを活かしたドキュメントを構築できるからです
エクセルやワードでも機能付きドキュメントは作れますが管理が困難の極致にあり動作が遅すぎるため実用には届きません
あなたもエンジニアなのですから(ですよね?)言語やフレームワークのオンラインドキュメントを読んだことがあるはずです
あなたの常識(成果物は1ファイル内に見出しがうんぬん)は少々古く歪んだ常識ではないでしょうか
あなたの目の前にあるパソコン(あるいはスマホ)でぜひ視野を広げてみてください
95仕様書無しさん
2019/03/23(土) 17:30:25.82 >>93
俺はWeb系じゃないし、ウェブサイトの仕様書など成果物として認められんのだわ。
見出しは必要だが、ファイルは数十ページぐらいで分割が適切といっておろうが。
なんで1ファイルにすり替えられてるんだ
見出しが要らないという君は、文書といったらWebサイトでググったページばかりで、
WORDのドキュメントを見たことないのかい。
俺はWeb系じゃないし、ウェブサイトの仕様書など成果物として認められんのだわ。
見出しは必要だが、ファイルは数十ページぐらいで分割が適切といっておろうが。
なんで1ファイルにすり替えられてるんだ
見出しが要らないという君は、文書といったらWebサイトでググったページばかりで、
WORDのドキュメントを見たことないのかい。
96仕様書無しさん
2019/03/23(土) 17:48:16.9497仕様書無しさん
2019/03/23(土) 17:54:18.30 >>95
1ファイルじゃなくても数十ページは大きすぎだな
ワードのドキュメントは何度も見てるが見やすいと感じたことはないね
せいぜいエクセルよりマシかなって程度だ
もちろん君の大好きな見出しと連番のついたドキュメントだよ?
1ファイルじゃなくても数十ページは大きすぎだな
ワードのドキュメントは何度も見てるが見やすいと感じたことはないね
せいぜいエクセルよりマシかなって程度だ
もちろん君の大好きな見出しと連番のついたドキュメントだよ?
98仕様書無しさん
2019/03/23(土) 18:06:38.42 >>97
そら不特定多数に見せるために金かけてデザインされたWebサイトよりは見にくいわ。
Webサイトより簡単に作れるがね。
WORDの文書はだいたい数十ページだと思うが?
体裁が最低限整えられたWORDファイルで
10ページ未満も100ページ以上もあまり見かけない。
そら不特定多数に見せるために金かけてデザインされたWebサイトよりは見にくいわ。
Webサイトより簡単に作れるがね。
WORDの文書はだいたい数十ページだと思うが?
体裁が最低限整えられたWORDファイルで
10ページ未満も100ページ以上もあまり見かけない。
99仕様書無しさん
2019/03/23(土) 18:25:06.52 誰もが頭が良くなる、プログラムが書けるようになる方法が発見される 71578
https://you-can-program.hatenablog.jp
https://you-can-program.hatenablog.jp
100仕様書無しさん
2019/03/23(土) 18:28:17.60 これ無料なんだけど
有料サービスの中身ってこんなもんだっていう皮肉?
有料サービスの中身ってこんなもんだっていう皮肉?
101仕様書無しさん
2019/03/23(土) 18:38:47.14 GoogleMapの性能がクソ過ぎて死んだw
102仕様書無しさん
2019/03/23(土) 20:10:48.83 Yahoo地図つかえ
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【窪田順生氏】「高市政権人気の裏には多数の“弱者感を抱えた男”の存在がある」弱者感を抱えた男は人知れずマイルド右翼に… [おっさん友の会★]
- 【サッカー】カズ・三浦知良 来季も現役続行を明言! 来年2月に59歳 「12月から来季に向けての自主トレを予定してます」 [冬月記者★]
- 【調査】クレジットカード、1人何枚持つのが「平均的」?★3 [ひぃぃ★]
- 【テレビ】池上彰氏 報道の自由度が高い国の特徴「どんどん政府を批判する。政治家は受け入れる」 一方独裁国家は… [冬月記者★]
- 「ヘイトスピーチをやめろ」 各地の「移民反対デモ」に抗議活動 [蚤の市★]
- 【国防】防空ミサイル(中SAM) 輸出検討へ 政府、フィリピンと非公式協議 [シャチ★]
- 【U-NEXT】プレミアリーグ総合 ★39
- 【DAZN】フォーミュラGP【F1 2 3 SF P】Lap1814
- とらせん IP
- 巨専】
- 【フジテレビ】2025 FORMULA 1【NEXT】Lap607
- こいせん 全レス転載禁止
- 高市早苗さん、超人気アニメキャラターにそっくりと話題に⇦なぜかネトウヨイライラw [271912485]
- まったり進行おじゃる丸待機ハウス🏡
- フィフィ「「歌唱強制中断」騒動、この時期に中国でライブ公演しようとするアーティストの方にも問題があるのでは?」 [377482965]
- 日本国民が減反インフレ裏金カルト円安インフラ崩壊人口減少日中戦争を支持している理由、学者にも解けない謎 [819729701]
- 無観客フル公演の浜崎あゆみさん、中国でとんでもない尊敬を集めてしまう… これもうこの国の外交官だろ… [452836546]
- 【高市速報】自民党広報「質問した岡田のせいで国益を損ねた」 [931948549]
