プログラマの雑談部屋 ★65

■ このスレッドは過去ログ倉庫に格納されています
2019/03/22(金) 22:42:02.62
※前スレ
プログラマの雑談部屋 ★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/
2019/03/23(土) 11:04:32.33
>>29
よく書くドキュメントはだいたい２０頁、５章ぐらいだがね。
その下に中項目１〜３、さらに小項目がある場合もある。

で、いったい何を分割しろというのか？
こうやって明確に見出しが付けられるのは、内容がきれいに分割されてるからこそなのだが。
2019/03/23(土) 11:05:09.12
unordered listで十分だけどordered listにしても構わない、自動で採番できるならいいけど、採番にわざわざ労力を使いたくはない、程度のものでしょ章番号なんてさ
ドキュメントのレビューする時だって、第3章のあれはこうしたほうがいいですね、などと言われてもわかりにくい
注文管理の章のあれはこうしたほうがいいですね、と名前だけで通じるようにすべき
2019/03/23(土) 11:06:13.01
>>30
馬鹿はファイル名に連番を振る
賢者はわかりやすい名前を付ける
結局はコード管理と同じなんだよな
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/
2019/03/23(土) 11:19:54.26
>>31
内容が綺麗に分割されてるならファイルを分割できるだろ
例えば注文管理と顧客管理を同じファイルに詰め込む意味はないし注文管理ち顧客管理に本質的は本質的に順序がないのでどっちが1章でどっちが2章などと採番するのは無意味
顧客管理のプレゼンテーション設計とドメイン設計と永続化設計を同じファイルに詰め込む意味はないし3者には本質的に順序がないのでどれがなん章だと採番するのは無意味
ドメインの各集約ルートの設計を同じファイルに詰め込む意味はないし各集約ルートに本質的に順序がないのでどれがなん章だと採番するのは無意味

こうやって物事を分析して階層化して管理していけば自然とファイルが分割されていき無意味な採番はなくなっていく

結局はコードを書く時と同じなんだよな
コードをかけない上流は1つに全てを詰め込んで無意味に順序を付けた最悪なドキュメントを書きたがる
2019/03/23(土) 11:20:00.45
>>33
100ファイルもあったらわかりやすい名前など付かないと思うがね。

人間20頁程度のドキュメント一つなら通して読めるが、
100ファイルに分割して渡されたらアホかと思うわ。
2019/03/23(土) 11:22:08.25
>>34
ユビキタス言語は英語圏の特権
ジャップランドで実現するのは難しい
敗戦時にジャップ語を禁止しとけば良かったのだがな
2019/03/23(土) 11:26:22.82
>>36
わかりやすい名前が付けれないならそもそも内容がまだよく分析されてない証拠だ
内容がぼやけてるからコレだという命名ができない
そんな状態で番号管理を始めたらどれがなんでどんな内容なのかあっという間にカオス化する

結局はコードを書くときと同じなんだよ
適切なクラス名が思いつかないので番号で分けましたなんてやって分かりやすくなることなんてまずありえない
39仕様書無しさん
垢版 |
2019/03/23(土) 11:28:00.64
結局は、出来る奴にしか出来ないってだけのことだな。
2019/03/23(土) 11:29:57.99
>>36
モダンなツールやフレームワークのドキュメントは何百と分割されてるけどな
あんなの繋げて渡されたらアホかと思うわ
2019/03/23(土) 11:33:17.16
学校じゃクラスには名詞を付けると習ってますが実務じゃクラスに番号振るのですか？
猫にニャーニャー鳴かせたいのに実装では3-1がニャーニャー鳴くとか違和感なんですけど
42仕様書無しさん
垢版 |
2019/03/23(土) 11:34:31.11
番号なんてソートやフィルターのためだけなことぐらい気づけよ。
2019/03/23(土) 11:36:32.75
ドキュメントを1ファイルに結合して番号振る人って、mainから始まる長い一本グソみたいなプログラム書きそう
2019/03/23(土) 11:38:55.53
>>42
知識スコープをなんのためにソートするんですか？
学生の自分には思い付かないのですが
エンタープライズみたいにクラスが100も200もあるとソートしたくなるのでしょうか？
2019/03/23(土) 11:39:49.75
>>35
まとめて１０ページ程度のボリュームならば見出しは５つぐらい。
一ファイルが適切でしょう。

　１．概要
　２．開発環境
　３．システム構成
　４．ソフトウェア構成
　５．機能

例えば、きみはこの１０頁のファイルを見出しごとにばらばらにして、
「概要」「開発環境」などという１〜２ページのファイルを５つ作るのかい？
受け取ったらアホかと思うわ。
2019/03/23(土) 11:42:33.23
ソートやフィルターかけるならなおさら名前だろ
独立な各章を五十音順にソートしたいのに章タイトルのプレフィックスに項番入ってたときの不快感は格別なものだ
2019/03/23(土) 11:44:14.47
首輪インターフェースを実装した猫クラスにニャーニャーと、犬クラスにワンワンと鳴かせる
これがオブジェクト指向と理解して学校卒業しましたが、実務ではクラスを3-1,3-2と管理する
実務は訳が解らないですね
ちゃんと専門学校出た人が設計しているのでしょうか
2019/03/23(土) 11:44:28.91
>>45
分けろ
なんで違うものを1まとめにするんだ
受け取ったら物事の分別がつかないアホかと思うぞ
49仕様書無しさん
垢版 |
2019/03/23(土) 11:47:06.83
ぶっちゃけ、名前がコードでも文字列でもオブジェクト指向か同どうかとは別の問題じゃね
コンパイルしてリンクして、シンボル名に実アドレス割り振ったらオブジェクト指向じゃないなら、実行可能なプログラムはオブジェクト指向じゃないことになる
2019/03/23(土) 11:48:59.94
>>45
私だったら分けます
・5つのハイパーリンクを画面左に表示
・リンクをクリックしたら内容を画面右に表示
という構成になるでしょうね
ちなみにGitbook等を使って作製します
文章の長さは意味的な分割には関係ありません
2019/03/23(土) 11:50:36.90
>>47
日本ではシステム開発とは無縁の学部出身でプログラミング経験も殆どない人が設計してます
2019/03/23(土) 11:53:10.16
>>48
アホか。
１ページずつの「概要」「用語」とかそんな名前のファイルが５つあったら。

「設計書」という名前で一つにまとめたらいいんじゃないですかと言われるわ。
2019/03/23(土) 11:55:24.75
見出し要らんと言ってるやつは
なんでWORDに見出し機能がついてるのか考えろ
2019/03/23(土) 11:57:07.32
内容を分けるのは大事だが、
内容を分ける＝ファイルを分ける　ではない
2019/03/23(土) 11:57:53.48
>>52
そいつの次のセリフは「概要シートと用語シートに分けたらどうですか？」だろうな
2019/03/23(土) 12:09:58.51
>>53
なぜって？
なんでもかんでもくっつけたクソ長いドキュメントでしかも番号管理だとどこになにがあるかわからなくなるからだろ
見出しがないとおめあてのページを見つけるのもジャングルに冒険しにいくのも大差ない労力がかかる
ファイル分割して適切な名前をつけて階層管理してれば見出しがなくてもすぐに目的の文章を見つけられる
もちろんオプションとして見出しページを生成するのは自由だ
2019/03/23(土) 12:11:45.23
>>50
> 文章の長さは意味的な分割には関係ありません

もちろんそう。
だが、意味的な分割とファイルの分割を混同してはいけない。
分割したものをファイルで分けるか、見出しで分けるかはどちらが見やすいかによるでしょう。

人間、一つのドキュメントは数〜数十ページのが見やすくそれを基準にすればよい。
2019/03/23(土) 12:21:06.15
>>57
いいえ
異なる内容が連続して続くと読みにくいです
続けて読まないと理解できない構成なのだろうか？などと単純に気が散りますし
その章の長さがパッと見てわからないと読む方としては困ります
編集する時にも困ります
編集の影響範囲がどこまで広がるのかわかりにくいので前後の章まで無駄に確認する労力がかかります
コミットログも関連性の薄いコメントが並ぶとうっとおしいでしょう
2019/03/23(土) 12:21:37.54
>>49
実務経験が無いのでそれが正しいか解りませんが、アランケイ御大がファックと呟くのは解ります
2019/03/23(土) 12:23:31.91
>>56
見つけられることと見つけやすいこととは違う。
書籍や新聞、ドキュメントには何故すべて見出しが書かれているのか。
これを見出しごとにすべて別冊にしたらどうなると思う？

ファイルで管理ではなく、見出しで管理すべき内容があるということだ。
2019/03/23(土) 12:35:23.04
>>58
「異なる内容」の単位ってなんだい？
クラス内の関数だってそれぞれ異なる内容なんだが、きみは関数ごとに一ファイル作るのかい？

例に挙げたのは、もちろん連続した内容。
続けて読まないと理解できない構成でしょう。
ファイルを分けるより一つのファイルのほうが読みやすい例であると思いますが。

章の長さは目次を見てもわかりますし、一つの見出しは１ページ程度。
むしろファイルを分けていたら開いて見なきゃわかりませんよね？
2019/03/23(土) 12:36:34.84
>>60
見出しに利便性があるからといって1つにまとめるべきであるという結論には至りません
見出しは1つの巨大な文章でも分割された文章でも機能します

書籍や新聞は媒体の制約で1つにまとめるしかなかったのでまとめられただけです
1つまとめられた文章は読みにくく探しにくく編集しにくいです
見出しはその不便性を補うために採用されました

オンラインドキュメントでは同じ文章構成でもファイル分割して管理します
その方が読みやすく探しやすく編集しやすいからです
各ファイルへのハイパーリンクを見出しとすることができます
見出しは文章の価値を高めるオプションとなります
63仕様書無しさん
垢版 |
2019/03/23(土) 12:37:24.03
>>59
オブジェクト指向の定義への適合と
ユーザビリティの評価は
まったく別の問題だぜ
オブジェクト指向なら必ず使いやすいとは限らないし、使いにくいからオブジェクト指向ではないとも限らない
2019/03/23(土) 12:43:05.10
>>61
責務を基本に考えると分割の目安が分かりやすくなります
クラスには1つの責務があるはずなので1つのファイルに書きます
概要や開発環境は明らかに異なる責務を持っています
ですのでこれらは別のファイルで管理します
65仕様書無しさん
垢版 |
2019/03/23(土) 12:47:22.12
【人類は一つです（バカウヨ除外）】　　世堺教師マｉトレーヤ　　【ユダヤから富を奪還し分ち合おう】
http://rosie.5ch.net/test/read.cgi/liveplus/1553306560/l50
2019/03/23(土) 12:51:48.75
>>62
> 見出しに利便性があるからといって1つにまとめるべきであるという結論には至りません

それはそうでしょう。そんなことは誰も主張していない。
私は、ファイルを分けるべきケースと、ファイル内で見出しを付けるべきケースが
それぞれあるということを主張している。

むしろそちらが、
見出しを付ける代わりに、なんでもかんでもファイル単位に分割せよという
妙な主張をしていると思っているのだが。
2019/03/23(土) 12:59:02.72
袋とじのテーブル仕様書
2019/03/23(土) 13:01:28.82
>>64
では「責務」の単位って何だい？

話はそれるが、
１クラス１責務というのはよく聞くが、「責務」といったところでやはり曖昧な概念だ。
システム全体でも大きな一つの「責務」を担っているし、
関数は関数で一つの小さな「責務」を担っているとも見えるのだが。
2019/03/23(土) 13:06:26.50
>>66
なんでもかんでも結合するな
分析して階層化すれば自然と分割される
と主張してます
2019/03/23(土) 13:08:47.40
>>68
抽象度に応じて責務のサイズは異なります
メソッドは互いに関連性が強くなるため同じファイルで管理してもいいでしょう
2019/03/23(土) 13:32:47.22
>>69
それなら同意見だ。
全体を分析すれば階層化された見出しが自然にできる。
階層構造の管理はフォルダでもできるが、見出であれば階層構造がわかりやすい。

もちろんドキュメントが大きくなりすぎれば可読性が落ちるので
ファイルに分けた方がよいケースも出てくる。ケースバイケースです。


>>70
> メソッドは互いに関連性が強くなるため同じファイルで管理してもいいでしょう

つまり、互いに関連性が強い（と思う）からファイルは分けない方がよい（と思う）
という感覚的な基準ですよね？
72仕様書無しさん
垢版 |
2019/03/23(土) 13:34:54.83
【言論弾圧】【言葉狩】ツイッター、「ジャップ」はBAN対象に
2019/03/23(土) 13:41:10.57
ジャップでBANされるだけでなくチョッパリでもBANされたという噂もある
これでますますネトウヨがつけあがる
2019/03/23(土) 13:45:09.01
>>71
分けた方が良いケースもあるというよりは分けた方が良いケースがデフォルト
2019/03/23(土) 13:47:31.19
こいつら国外追放してほしいわ
2019/03/23(土) 13:52:41.08
>>74
デフォルトというなら、見出しのないドキュメントの方が多いということですか？
新聞、雑誌、書籍、技術ドキュメント、だいたい何見ても
一つのドキュメント内にいくつもの見出しがついてると思いますがね。

「全部ファイルに分割すれば、見出しは必要ない」　などというのが
いかに非常識な主張かをわかっていただければ幸いです。
2019/03/23(土) 14:01:03.82
>>76
見出しとファイル分けるわけないは別の話だと何度もレスしてる
単一ファイルでも分割ファイルでも見出しは付けれる
単一ファイルは見出しがないと使い物にならないけどね

新聞雑誌書籍等は製造、輸送、販売の都合でまとめられてるだけ
Web無償提供の技術ドキュメントはそういったやむをえない事情がないから合理的に分割するほうが増えてきてる
2019/03/23(土) 14:05:21.65
さらに言うとユーザーの手元にまとまって届く書籍等でもライターの手元では分割管理されているものだよ
2019/03/23(土) 14:07:42.46
ん？この話の論点は何なの？
2019/03/23(土) 14:22:14.40
>>77
そちらは見出し単位でファイル分けるという主張ですよね？
つまりその主張だと１ファイルに見出しは一つ。

Webドキュメントなら一ページ一見出しも多いが、それはデザインの関係だ。
閲覧者から見れば、ファイルの概念ではなくあくまでページとして見えるからね。

ではWORDやExcelのドキュメントはどうだ？
まともなドキュメントには、だいたい見出しと目次がついてる。
いくつものファイルでバラバラに提供されるより、
一文書として見出しにより構造化されていた方がわかりやすいからね。
2019/03/23(土) 14:32:01.39
>>77
> 新聞雑誌書籍等は製造、輸送、販売の都合でまとめられているだけ
そういう売る側の手間もあるでしょうね。

しかしもっと根本的に考えてくれ。
書籍が見出しごとにバラバラにされ、クリアファイルに入れられてたら買うかい？
2019/03/23(土) 15:00:10.19
>>80
良い文章は論理構造がわかりやすいだけであって1つにまとまってたり見出しや目次があるからわかりやすいのではないよ

>>81
紙の書籍だと媒体の制約のせいでバラ売りされると管理が面倒だから買わないかな
でも同じ内容の電子書籍だったら媒体の制約がないから欲しいセクションだけ買うかな
適切な名前で必要なセクションにすぐアクセスできるならそっちのほうがいい
いちいち巨大な書籍をロードして目次までスクロールして目次ページをめくってめくってリンク押してそこから目的のページまでオフセット分ページ捲ってようやっとたどり着くのって面倒だよね？
紙の書籍だと分厚い重い本を本棚から取り出して目次ペラペラめくってページ番号覚えて適当にページ開いて番号比較して違ってたらまたシークしてセクションの先頭から目的のページまでまた微調整でページめくってってなるんだろうけど酷い手間だ
2019/03/23(土) 15:32:59.28
>>82
そうじゃない。
わかりやすい論理構造を表現するために、見出しや目次をつけるんだ。

> 適切な名前で必要なセクションにすぐアクセスできるならそっちのほうがいい
なるほど、きみがイメージしているのは、
辞書のように、項目が独立している「論理階層のない」ドキュメントだ。
それならば自分が使う部分だけを引っ張ってこれれば事足りる。

しかし納品物には論理階層があるからね。
だからWORDドキュメントには見出しが付いている。
2019/03/23(土) 15:53:33.45
>>83
目次は文字通りインデックスでしかない
目的のページを検索するための道具であって論理構造には影響しない
論理構造が目次に影響することはあるがね

論理階層構造をディレクトリで表現するんだよ
君なんも理解してないね
注文管理のドメイン層の注文エンティティについて記述した文書だったらordering/domain/entities/order.xxxを見ればいいってすぐにわかるのは論理階層構造が明確化されてるからだろ？
目次形式だと目次ページを開いてシーケンシャルに目次を追わなきゃorderの項目までたどり着けん
論理階層構造とは無関係の連番で管理されてるからだ

エクセルやワードに執着してるとわからんのかなぁ？
テキストからコンパイルするタイプのドキュメントかマークアップ・ダウン系統のドキュメントを何度か書いてみたら？
2019/03/23(土) 15:56:30.52
ちょこっとコードを書かないといけなくなった
家じゃ全然やる気しないからカフェで
コーヒー飲みながらやってくるわ
2019/03/23(土) 16:03:07.67
要するに1ファイル君はツリーで表現されるべきデータ構造をベクターで表現しようとしてるんだよ
でもベクターじゃ読むのしんどいし検索もキッツイし編集は最悪にやりにくい
せめて検索だけでも楽にしようってんで見出しをつけてインデクシングしたの
んでなにを血迷ったのかせっかく用意したインデックスにも番号振っちゃったせいでシーケンシャルアクセスしないと情報を見つけられないようにしちゃった
87仕様書無しさん
垢版 |
2019/03/23(土) 16:04:48.38
>>85
自分もそれたまにやろうとするけど意外とはかどらないんだよね
WiFiに接続するだけでコーヒー一杯飲んじゃってたり
2019/03/23(土) 16:09:33.10
>>84
ドキュメントは読むためのものだ。
論理構造があるかないかではなく、それを表現するための道具として見出しは使われる。

数ページ程度のドキュメントに対して、見出し単位で分解してバラバラにした挙句
ディレクトリに振り分けて論理構造を表現しましたと言われたら
そいつはきっと正気ではないと思う。

要するにきみらはドキュメントの一部が必要なだけなので、
そこだけ小さなファイルに分けて渡してもらった方がよいという話に過ぎない。
2019/03/23(土) 16:18:09.42
>>88
なるほど君はエンジニアじゃなくてエンドユーザーだったんだな
エンジニアにとってドキュメントは書くものでも読むものでもある
なので編集性には最大限の気を配ってファイルを分割する
もちろんそれで検索性や可読性が悪化するということはなく逆に向上するのだけどね
2019/03/23(土) 16:33:11.61
>>89
「読むもの」というのはエンドユーザーへの成果物として捉えているかどうかだ。
そりゃ開発中の参考資料や途中段階だったら、編集が被らないようにバラバラの方が都合がいいわ。
納品の際には結合するんだがね。

「自分らにとって都合がいい」に無理やり理屈をつけてるに過ぎない。
自分らの効率はそれで正当な理由だがまずそれを認識しろ。
成果物としてのドキュメントには、常識的に一つのファイル内に目次やいくつもの見出しが必要になる。

大きすぎるファイルは可読性が悪いので分けるのは賛成だがね。
ただ見出しの項目ごとにファイルを分けるというのは、あまりにも馬鹿げた主張。
数１０ページ単位で一つの見出しを付けてる奴の発想だ。
91仕様書無しさん
垢版 |
2019/03/23(土) 16:49:07.34
>>85
>>87
おれも休日は喫茶店に行って
仕事をやろうとすることはあるんだが、
思ったようにはかどらない。

どうしてなんだろうね？
2019/03/23(土) 16:55:55.82
家でやる気が出ない時点でカフェに行ってやる気が出るはずもなし
2019/03/23(土) 17:08:30.05
>>90
ビルドして静的なウェブサイトを構築するツールなどがありますよ
PDFなどにコンパイルする選択肢もあるっちゃありますが今はウェブサイトの方が圧倒的に使いやすいですね
使いやすいと言ったのは読みやすいだけじゃなく検索や前後上のリンク、パン屑リスト、JS等ウェブサイトのポテンシャルを活かしたドキュメントを構築できるからです
エクセルやワードでも機能付きドキュメントは作れますが管理が困難の極致にあり動作が遅すぎるため実用には届きません
あなたもエンジニアなのですから(ですよね？)言語やフレームワークのオンラインドキュメントを読んだことがあるはずです
あなたの常識(成果物は1ファイル内に見出しがうんぬん)は少々古く歪んだ常識ではないでしょうか
あなたの目の前にあるパソコン(あるいはスマホ)でぜひ視野を広げてみてください
2019/03/23(土) 17:11:24.13
>>92
それが違うんだなぁ不思議だけど
2019/03/23(土) 17:30:25.82
>>93
俺はWeb系じゃないし、ウェブサイトの仕様書など成果物として認められんのだわ。

見出しは必要だが、ファイルは数十ページぐらいで分割が適切といっておろうが。
なんで１ファイルにすり替えられてるんだ
見出しが要らないという君は、文書といったらWebサイトでググったページばかりで、
WORDのドキュメントを見たことないのかい。
2019/03/23(土) 17:48:16.94
>>92
オシャレ私服と良い椅子とうまいコーヒーとMacBook Pro
やる気を出すのにこれ以上のシチュエーションがあるっていうのかい？
2019/03/23(土) 17:54:18.30
>>95
1ファイルじゃなくても数十ページは大きすぎだな
ワードのドキュメントは何度も見てるが見やすいと感じたことはないね
せいぜいエクセルよりマシかなって程度だ
もちろん君の大好きな見出しと連番のついたドキュメントだよ？
2019/03/23(土) 18:06:38.42
>>97
そら不特定多数に見せるために金かけてデザインされたWebサイトよりは見にくいわ。
Webサイトより簡単に作れるがね。

WORDの文書はだいたい数十ページだと思うが？
体裁が最低限整えられたWORDファイルで
１０ページ未満も１００ページ以上もあまり見かけない。
2019/03/23(土) 18:25:06.52
誰もが頭が良くなる、プログラムが書けるようになる方法が発見される 71578
https://you-can-program.hatenablog.jp
2019/03/23(土) 18:28:17.60
これ無料なんだけど
有料サービスの中身ってこんなもんだっていう皮肉？
2019/03/23(土) 18:38:47.14
GoogleMapの性能がクソ過ぎて死んだｗ
102仕様書無しさん
垢版 |
2019/03/23(土) 20:10:48.83
Yahoo地図つかえ
2019/03/23(土) 20:24:21.71
ジャップランドの会社が切られてザマァ見ろ
2019/03/23(土) 20:55:49.24
観光バス大炎上こわいわ〜
安全には投資したほうがええんやな
105仕様書無しさん
垢版 |
2019/03/23(土) 21:30:33.57
俗名　”福島瑞穂さんですね？！
ちがいます　”大沼（大池沼）みずほ”です
そうでしたか？
野党さん　ころころ党名改廃がはげしいもんで
認識困難です”
　|￣￣￣￣￣￣￣￣|
　| 　 　訂正云々　 　 |
　|＿＿＿＿＿＿＿＿|
　　　 ∧∧ ||
　　　 ( ﾟдﾟ)||　＜カンペ読むだけの仕事だから落ち着いて！
　　　 /　づΦ

　　　　　 三晋晋晋晋晋ﾐ
　　　　 晋三　晋晋晋晋三
　　　　晋晋　　　三晋晋晋
　　　　I晋 ◆／）||（＼◆晋
　　　丶,I◆∠●Ｉ　Ｉ ●ゝ◆ｿ
　　　　I│　　.　││´　 .│I　　＿＿＿＿＿＿＿
　　　　｀.|　　 ノ（_＿）ヽ　 .|´　／
　　　　　I　　　 │　 I　　 .I　＜　で…でんでん
　　　　 　i　　 .├─┤　./ 　　＼＿＿＿＿＿＿＿
　　　　　　＼　/ ￣ ヽ,ノ　　
毎年５兆円　盗電バカ社長廣瀬が払えだって　下痢三
2019/03/23(土) 22:02:18.64
日本人は文書構造という概念を知らない奴ばっかなのでWordがまともに使えないの
2019/03/23(土) 22:07:04.80
>>102
サンキュー行けた
まさかZENRINと手を切るとは
Googleが負けることもあるのな
2019/03/23(土) 22:16:24.50
プログラマーはコンプレックスとトラウマの塊でキモいわ
2019/03/23(土) 22:35:11.25
子供部屋から俺が思う最強の・・を書き込んでるのかと思うと胸熱だわ
2019/03/23(土) 22:38:30.11
>>106
本来はQuarkやInDesingを使うべき場面でもWordのスキルで乗り切ろうとするよな
なんで日本人って最強のソフト1本で何でも乗り越えようとするんだ
適材適所って言葉を知らんのかな
2019/03/23(土) 22:47:35.57
>>110
容量が足りないから1つしかおぼえられないのでは？昔のパソコンみたいに
なので最強かどうかはともかく最初に覚えた1つで乗り切ろうとする
2019/03/23(土) 23:07:22.30
まあ、だいたいメリケンのアプリは日本語対応弱いからな
少なくとも2019年まではoffice以外のソフトは見なくても問題なかった
2019/03/23(土) 23:29:07.60
Publisherとかいうアレ
2019/03/23(土) 23:36:33.88
毛唐自体が別に技術力が格段に高いってわけじゃないからね
ここ数日のぐぐるまっぷの騒ぎやパチンコガンダム駅とか直接関係ない
ようなものには全然気を配らないし。
シングルバイト文字しか使ってこなかったからマルチバイト文字でアホ
みたいなこと平気でやるし。
115仕様書無しさん
垢版 |
2019/03/24(日) 00:41:51.34
社員同士のソースレビューはLGTMばっかりなのに俺のソースは30コメントとかつくんだが。というかソースコメントで聞いてない機能が「入ってないんですけど」とか言われる。
116仕様書無しさん
垢版 |
2019/03/24(日) 00:43:25.38
日本語で尾k
117仕様書無しさん
垢版 |
2019/03/24(日) 00:44:48.29
コーディング規約がないのに変数名が変だとか言われても困るし。
118仕様書無しさん
垢版 |
2019/03/24(日) 00:47:57.81
昔のソースからコピーした処理が書式NGってどういうことだよ
119仕様書無しさん
垢版 |
2019/03/24(日) 00:54:38.18
「ソースレビューはレビュアーとレビューイの間で観点の共有が必要」らしいけどそんなこと全くしてないんだが

古参や社員はすぐLGTM出てるのにな。
120仕様書無しさん
垢版 |
2019/03/24(日) 00:59:11.19
そんだけソースレビューしてコード書き直しさせられまくったプログラムでバグ出たし。ソースレビューの意味ないじゃん
2019/03/24(日) 01:04:40.97
安全策を施してたら
事故ったのを安全策のせいにするあるある
122仕様書無しさん
垢版 |
2019/03/24(日) 01:05:53.88
まあ時給でやってる上にスケジュールが延びてもリスケされるだけだから俺個人の金銭や契約的にはダメージはないんだが

これじゃ会社が儲からないしフリーランス雇ってる意味ないよ。もっと若くて安い奴を社員で雇ってイチから鍛えればいいのに。
123仕様書無しさん
垢版 |
2019/03/24(日) 01:08:02.03
会社組織がイヤになって会社員を辞めたのに前より組織の都合に振り回されてるよ
124仕様書無しさん
垢版 |
2019/03/24(日) 01:13:59.65
結局コードレビューなんて言っても社内の立場しか見てないとしか思えない。根拠としてはリーダークラスのレビューで差し戻しを見たことがない。
2019/03/24(日) 01:15:30.41
>「ソースレビューはレビュアーとレビューイの間で観点の共有が必要」らしいけどそんなこと全くしてないんだが
理由書いてるじゃねーか
126仕様書無しさん
垢版 |
2019/03/24(日) 01:17:39.28
他人がレビューして質問も問題もないコードが一発で書けるわけがない。どんなプロが書いた文章でも校正で1つの赤入れもされないなんてあり得ない。
127仕様書無しさん
垢版 |
2019/03/24(日) 01:26:48.98
今の開発ってマッチポンプよな。

「自分たちはこんなに大変なことをしてるんだ。だから高給も高待遇も当然だ」ってか。

その人件費が負担になってたらそれもう商売じゃねーよ
128仕様書無しさん
垢版 |
2019/03/24(日) 01:30:50.29
結局開発なんて虚業でしかないな
2019/03/24(日) 01:31:25.99
もちろんもっと安価にちゃっちゃっと済ませることもできる
でもなぜか大企業もそうしないし国も望んでない

それが豊かさというものだ
130仕様書無しさん
垢版 |
2019/03/24(日) 01:33:07.27
高度な知識を要求されても本質的にパチスロの店員と変わらん。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況