プログラムセンスがある人とない人の違い 4 [無断転載禁止]©2ch.net

センスある人・・・例外をうまく使ってシンプルなコードを書くことができる
センスない人・・・例外を（俺が）使うとコードが複雑になるんじゃぁ、何が何でも処理しないと気がすまないんじゃぁ


プログラムセンスがある人とない人の違い 3 [転載禁止](c)2ch.net
http://tamae.2ch.net/test/read.cgi/prog/1423996665/

前スレではトムキャットしか使ったことのない能無しどものせいで時間を無駄にした。

いつからWebアプリケーションサーバーを使うプログラムの話になったのか？

あと例外じゃないコードの話をしてるくせに
例外だと言い張る組み込み屋（ネットワーク屋）もうざかったな。

>>3
いつからWebアプリケーションサーバーを使わないプログラムの話になったのか？

>>5
スレタイをよく見なさい。

組み込み屋の場合、例外（ではなくて本当は単なる状態処理）が
10個程度しかないんだろうね。

アプリ屋にとっては例外は標準だけで数十個
アプリやライブラリが使うものを含めるとそれ以上あるから
非対応の例外を共通の例外処理で処理して、
それ以外の対応が可能な場合だけ対応するというやり方になる。

そうするとほとんどの例外は共通処理で処理できるものになるって
いちいち処理を書いたりしないから、あとはまれにある標準以外の
対応を行う箇所だけコードだけが必要になって
故に例外を使うとコードはシンプルになる。

PHPやCGIのように、Apache配下で１リクエスト1プロセスが動くシステムを知らん奴のせいで、話が逸れたのだ。

あげく、nodeJSのように、1プロセス1スレッドで全てを捌くような
特殊なサーバーを持ち出して、例外処理をしなければ
サーバーが落ちるなどと極論を言い出した。

> PHPやCGIのように、
それっていまどきスレッドを使わない古いシステムじゃね？

例外は使う。
しかし、適切な処理を綺麗に書くために使うのだ。
アプリを落とさないためではない。

>>10
誰もアプリを落とさないために例外を書くなんて言ってないよｗ

>>9
じゃあスレッドを使うシステムが新しいのか？
ジジイを笑う中年のようだな。

PHPのシステムは世の中に溢れてるだから、現実を見ろ。

>>11
例外をログに吐けば十分＝アプリを落とさない

おまいらの認識ってこの程度だよね。

>>13
だからお前の意見をかけって
逃げるなよ

>>6
スレタイをよーく見なさい。

>>13
何度も言うように、

「殆どの場合は」例外をログに吐けば十分
それ以外の処理が必要な場合だけ、特別にコードを書けばいいから
コードはシンプルになるって話をしている。

でお前がやるべきことは、特別にコードがたくさん必要になるから
例外を使うと大変だ。その特別にコードを見せてやる（ドンッ）
っていうことなんだから、そのコードがどんなのかをいうことだよ。

>>15
>>1の内容もよーくみなさい。

センスある人・・・例外をうまく使ってシンプルなコードを書くことができる
センスない人・・・例外を（俺が）使うとコードが複雑になるんじゃぁ、何が何でも処理しないと気がすまないんじゃぁ

>>14
何度も申し上げています通り
他社のAPI等、状態が安定しない呼び先に対して
安全に処理を書くための有効な手段となるのでございます。

>>18
具体的には？

>>17
>>1をよく読んだ上で、>>3を読みなさい。

>>19
前スレで書いたろ。しつこいよ。

>>21
申し上げているのでございます

>>22
ウルセーバカ

>>21
ございます

エラー処理とか書きたくないめんどい

いくらセンスがあろうとなかろうと仕様がクソだとどうしようもないね。

おまいら異常系の処理って言うと、ありえない状況を想像するから
例外処理でやることがなくなるんだろ？

結局そこの線引きの加減が下手なんだと思うわけよ。

シングルプロセスかマルチスレッドかはあまり問題じゃないと思うけどな。

じゃあ、マルチプロセスのプログラムはどうするのか聞きたいわ。

>>28
耐障害性の観点では、多少関係がある。

>>27
まあそうなんだろうな。

このスレにいる人間のうち、サーバー(ノード)が突然、落ちることまで想定している人間がどれだけいることやら。

>>16
そもそも、俺は「例外を使うと大変だ」とは言っていない。
簡潔に書くために例外を使うのだ、と言っている。

良く解らないんですが例えばファイルの読み込みメソッドでファイルが見つからないっていう例外が発生するとして
1.呼び出し側に戻り値で失敗を知らせるべき
2.読み込みに失敗してもその後のプロセスに影響の無い設計にすべき(あるなら例外で止めちゃう)
3.そもそも例外が発生しないように呼び出し側で引数をチェックすべき

他にもありそうですが混乱しまくりです
どういうのが推奨されるんでしょうか？

>>32
3は言ってることが分からない。

ファイルが存在しなくても処理を続ける仕様ならいいが、あまりそういうシステムはないと思うけどな。

ファイルがあるかもしれないし、ないかもしれないシステムなら、例外扱いでもいいし、ただの存在チェックエラーでもいい。

それを決めるのがプログラマ。

>>32
段階的に考えるといい。

通常は処理するためには何らかの「条件」が必要
その条件が全くない場合に汎用的で一番楽な方法は落ちること。
この場合にやるべきことは何もない。

次に楽な方法は（情報をログに吐くなどして）落ちること。
これも汎用的であり、また書くのは共通部分に一箇所ですむので手間は最小限。
通常はこっちを書いておく。

この２つは「条件」が何もなくてもできる。


> 1.呼び出し側に戻り値で失敗を知らせるべき
戻り値で知らせてはいけない。戻り値で知らせるとコードが複雑になる。
例えば呼び出し側の更に呼び出し側のさらに呼び出し側に伝える場合はどうするのか？
これを例外ならば何も書かずに自動的にやってくれる。

> 2.読み込みに失敗してもその後のプロセスに影響の無い設計にすべき(あるなら例外で止めちゃう)
これは「条件」が必要。いつでもそれをやっていいわけではなく、特定の条件を満たしている場合にのみ可能なこと。

あと「例外で止める」というのは言い方がおかしい。失敗したら例外を出力するべきだからだ。
あとは止めたければ発生した例外を処理するコードを何も書かない（最初に書いたようにログに出力して落ちる）
そして「条件」を満たした場合に限り、発生した例外を無視することも可能。

> 3.そもそも例外が発生しないように呼び出し側で引数をチェックすべき
それは不可能なので議論の対象にならない。

初心者は例外処理を書いて何もしていなかったり、そこで例外の情報を止めてしまうので、例外が発生していても正常終了にしてしまうからなあ。

技術は何でも初期は未熟なものだからどうしようもない話だけど、
初期の言語に「例外」というものがあれば、常識も変わっていたと思うけどね。

「エラーが発生すれば、プログラムはそこで停止するもの」というのが
初期の言語からの常識であれば、こんな議論はする必要がない。
え？エラーが発生したら止まる？それ当たり前ですよね？で終わる話。
停止させたくないときだけ、そのための処理を書く。
これを「例外」は実現している。

C言語が一番の障害だった。あれが「例外」を備えていないのに広く使われたせいで、
「エラーが発生しても、何もしなければプログラムはエラーが起きたのがわからないまま進む」
というのが初期の常識だった。そして、なにか書くのが面倒だから、
これはサンプルなのでエラー処理（エラーが発生したら停止する処理）を書いていません。
なんていうひどいサンプルが広まってしまった。本来はサンプルだからこそエラー処理を
きちんとして置かなければいけなかった。それを他の人は参考にするんだから。

だからエラー処理をまともにやるとコードが複雑になるって言ってる人は
たいていC言語しか知らない。（他の言語を使っても例外を正しく使っていない）

例外がある言語にとっては何も書かなくてもエラーが発生したら止まるというコードになってる。
これはC言語でいうエラー処理を書いた状態。そして止めずに回復できるという条件が揃ったときだけ
そのためのコードを書けば良いから楽なのだ。

>>32

> 1.呼び出し側に戻り値で失敗を知らせるべき
ファイルが見つからない例外を、戻り値に置き換えてみただけ。意味が無い。

そもそも、例外にしろ戻り値にしろ、失敗を呼び元に知らせるということは
呼び元に責任を放り投げているという事だが
それが正しい判断かどうか、という問題もある。

> 2.読み込みに失敗してもその後のプロセスに影響の無い設計にすべき(あるなら例外で止めちゃう)

例外で止めるのではなく、例外に対応するべきでは？
それが正しい設計ではなかろうか。

> 3.そもそも例外が発生しないように呼び出し側で引数をチェックすべき

結局どこかで問題に対応しないといけません。
それを適切な場所で対応するだけです。

> 呼び元に責任を放り投げているという事だが
> それが正しい判断かどうか、という問題もある。

極稀に勝手に修正してもうまくいく場合があるだけ
殆どの場合は呼び出し元の結果（エラーも含む）を返すのが正しい判断

殆どの場合は呼び出し元に結果（エラーも含む）を返すのが正しい判断

例えばファイルを開く関数があったとして
ファイルがなければ空ファイルがあることにして開いたら
空のファイルがあるのか、ファイルがないかの区別がつかない。

例えばファイルを開く関数があったとして
設定ファイルがなければデフォルトの値を返す関数があったとしたら、
それは「ファイルを開く」関数ではなく、「設定ファイルを開く」という
専用の関数になってしまう。

これは「極稀に勝手に修正してもうまくいく場合」の一例であり
汎用的な処理としては使えない。

このまま上に上に返していくと
最終的にユーザーに「ファイルがありません」とメッセージが表示される。
それが正しいのか、何か復帰処理を試みるのか。

>>41
ファイルを開く関数で、勝手にファイルを作ったら問題だ。
しかし、一つ上の呼び元では
そういったロジックが必要になるかもしれないだろ？

各メソッドがそれぞれの責任を果たすよう
適切な例外処理を書きましょうねって事だよ。

更に言うならば「設定ファイルを開く」という関数であったとしても
設定ファイルが複数種類あったらどうなるだろうか？

勝手に直すならば「ユーザー情報設定ファイルを開く」
「GUI設定情報ファイルを開く」などというファイルごとに関数を
作らなくてはいけなくなってしまう。

そうすることなく汎用的な関数にしたいならば「設定ファイルを開く」関数に
ファイルがなければデフォルトを渡すための引数を追加することで実現は可能だが
それだけ結局「呼び元に（デフォルト値をわたすという）責任を放り投げている」ことになり、
呼び出し元がやるのが正しいということになる。

>>42
> そういったロジックが必要になるかもしれないだろ？

「必要になるかもしれない」で作るのはYAGNI違反。
必要になったときだけやればいい。
つまりそれは「極稀に」うまくいく場合の一例でしか無い。

>>42
> 最終的にユーザーに「ファイルがありません」とメッセージが表示される。
> それが正しいのか、何か復帰処理を試みるのか。

デフォルトの動作を安全側に倒すかどうかの話でしか無い。
安全側はその場で終了。「例外」ならば何も書かなくてそれを実現している。

それが正しくない場合にのみ、コードを書けばいい。

>>45
よく読んで欲しい。
多層に重なった呼び元のどこかで、処理をするのだ。
一つのメソッドで完結せよ、という話ではない。

> 多層に重なった呼び元のどこかで、処理をするのだ。

俺の言い方↓に変えろやｗ

多層に重なった呼び元のどこかで（やる意味がある場合のみ）処理をするのだ。
やる意味がなければ処理する必要はない。
何も書かなくてもエラー処理（途中でプログラム中断）してくれるのが
例外であり、C言語などの例外がない言語との大きな違いなのだ。

だいたい「設定ファイルを開く」関数でも
中では設定ファイルの種類に応じて
それぞれの設定用関数を呼び出すだろ。

そうしないなら、「設定ファイルを開く」関数に何でもかんでも詰め込むという事？
それは筋が悪いな。適切な粒度ではない。

粒度って言ってみたかっただけかｗ

>>48
今してるのは、責任の分担の話だろ？
例外か、戻り値かに関わらないよね。

>>51
例外か戻り値かの話を俺がどこでしてると思ってるんだ？

>>52
どうでもいいけど>>44はおかしくね？
汎用的な関数って言ってるけど
何でもかんでも出来るのが汎用的なんじゃないよね？
決められた仕事だけやるのが汎用的だよね？

>>53
いろんなことに使えるのが「汎用的」という言葉の意味だ。

何でもかんでもできるのは「機能詰め込みすぎ」で
決められた仕事しかできないのは「専用的」というんだよ。

>>54
なんか腑に落ちんが、まあいい。

もはや誰が何を主張したいのか分からんw

>>55
腑に落ちないのは、お前が変なことを言ってるからだ。

「なんでもできる万能ロボット」と
「なんにでも使える汎用的なネジ」を
ごっちゃにしているからなだけだ。

無理やり共通処理化する初心者はあとをたたない。

>>57
いやいや、おまいの言い方で言えば
上手い切り口で「専用的」に作られたものが、「汎用的」に使えるんだろ。
万能ロボットが実際にはポンコツなのは判ってるよ。

単純化するためのモジュール分割だったのに、いろんなことができるモジュールにしてしまう事例はよくある。

逆にJavaプログラマでさえ、なんのクラス分けもないものを平然と作っていたりもする。

>>59
> 上手い切り口で「専用的」に作られたものが、「汎用的」に使えるんだろ。
どこにも書いてないどころか、それと正反対の事を言ってるんだが？

汎用的なのは「ファイルを開く」関数であって
専用的に作られた「設定ファイルを開く」関数ではない。

>>60
頭が柔らかい義務教育時代に
プログラミングの勉強をしないからそうなる。

>>61
おまいが上に責任を投げる事が正しいかについて
長大なレスを付けるから話がややこしくなったんだよ。

俺は業務ロジックの話をしてたんだ。

>>63
おや？自分の読解力のなさに気づいて
他人のせいにするのですかな？ｗ

>>64
しね
あと>>44は例えが適切ではない。

>>65
具体的に何が問題かを言えない時点で話にならないですなｗ

>>42までは「ファイルを開く」関数の話じゃねーか

>>67
>>41も読もうか？

一気にレス増えてるわ新スレ立ってるわで吹いたんだが。
ここで熱中する人はセンスも知識も最低部類の疑いが強い
まぁ読んでないから知らんけど

プログラミングを知らない人がプログラミング教育をする危険性
https://wirelesswire.jp/2016/06/54228/

>>70
この人、2chに自分で書いてるやつだな。

文章が同じだもんw

>>71
どれと文章が同じなの？

>>72
頭の中でプログラミング

迷惑電話 FJネクスト ウンコ注意9評判 口コミ 悪徳･2ch.net

http://hayabusa6.2ch.net/test/read.cgi/estate/1465394964/

>>73
それはどの話？

>>75
この板でスレッドのタイトルに設計書とかが入っているスレッド

>>76
つまり具体的に言えないってことかな？ｗ

きっとアンカし忘れただけだろうと思って優しく聞いてみたが
なんかわざとアンカするのを拒否しているようだな。
こりゃ具体的に言うまでは、こいつは答えられないと認識したほうが良さそうだｗ

自分で調べろよ。

そいつがいるスレッドはつまんないからいまは見てないんだよ。

>>79
その「そいつ」はここにもいるんだがｗ

横ですまんが、ここはソース貼るべきだ
でなければ逃げてるようにしか見えない

客から要件を聞くとプログラムが浮かぶとか言ってるやつだが、いま探したがまだ見つからない。

http://itest.2ch.net/test/read.cgi/prog/1448622471/

>>83
いやね、特定の人物の話なんだから
レス番号まで書かないと意味ないでしょ。

DAT落ちしてるわ。

スレッドタイトル
「いきなりコードを書くな。設計してから書け。」

トンファーキックで笑える人

無能実態派遣残業して時間報酬相場下げるな！
【知的財産と契約料金の搾取促進者ばかり】
［SI生涯損害助長SEを追放すべき］
偽装請負従犯SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病早死7

>>7
> アプリ屋にとっては例外は標準だけで数十個
わざわざ複雑にして自慢するとかバカじゃね？

例外出たから工場止めるよ。

が許されたなら幸せだったのにな。

センスある人は競技プログラミングでも良い成績になる

>>89
> 例外出たから工場止めるよ。

それは例外をキャッチしなかったら
そうなるって話？

例外をキャッチするから工場は止まらないよね。
これは例外の利点の一つ。


例外を使わないと、エラーが起きても工場は止まらないとか
なって挙句の果てに爆発起こしたりしそうだねｗ

>>88
例外じゃなくてもエラーの数はこれぐらいあるだろ？
エラーコード表見てみ。

>>92
ないよ。

だいたい、なんでアプリがシステムレベルのエラーを意識しないといけないんだ。

成功したかどうかがわかればいい。

>>93
可哀想にｗ

>>96
あなたが一番可哀想な感じがします
自分が知る範囲だけで、他のシステムも同様と決めつけてるところがね

>>97
自分が知る範囲で無いよって言ってるわけかｗ

Oracleのエラーコード表見てみ？

SQLエラーのことか？
インジェクションされるようなアプリ作るなよ

>>100
流石にそれは無知すぎｗ

つか、エラーと例外は別モンだよな

違い？ こんなんでどうかね？
例外のほうが幅広い。

http://mameratta.tumblr.com/post/6282752670/%E4%BE%8B%E5%A4%96%E3%81%A8%E3%82%A8%E3%83%A9%E3%83%BC%E3%81%AE%E9%81%95%E3%81%84

例外：

「対応しない/できない/許容しない/責任範囲外」等の意思を実装で表明するもの。
例外を投げるのは、自分が対応しない/できない処理や、許容しない処理、実行環境や別モジュールなどの責任範囲外で失敗した通知など。
通常発生しない/発生してはいけない処理。例えばstd::logic_errorとか。そこが呼ばれること自体がおかしいなど。
対策をとらない/とる気がない処理。正しい前提で処理をし、異常系を処理しないなど(std::invalid_argumentとか)
必ずしもエラーとは限らない(が、現実的には大半がエラー)。割り込みや中断、タイムアウトなどは、エラーでなくても例外的と言えることも。

エラー：

想定しうる処理失敗/異常系処理で、対応の用意/意図/可能性があったもの。
逆に言うと、自分が受け付けて処理を試みた上で完了できなかったもの。

>>103
Javaだと逆なんだよな。

言葉の定義は難しいよ。

【主な偽装請負従犯SEの作業】
[技術不要の使い捨てスキル]
コマンド
データ > ロジック
簡単ロジック
大量データ
SE適性不要
IT資格不要
大卒資格不要
文科系対象
体育系対象
商業系業種
業務系処理

[業務ソフト作り捨てソフト]
ノンプログラミングツール
フレームワーク
COBOL
VＢ
.net
Java
Web
DB
ERP
SAP1

>>103
エラーを例外でぶん投げてくるのが間違いの元。

日本語の文章がうまい人はプログラムのセンスも高い。

それはプログラムじゃなくてコメントな

>>108
はあ？

言葉で説明できないロジックなんて特殊なアルゴリズム以外にないだろ。

プログラムセンスあんまり関係ないかもだけど、ログの開始位置はどっちがいいと思う？
自分的には一連の処理が始まるタイミングで
開始ログ〜チェック処理〜実処理〜リソースの破棄〜終了ログ
なんだが、先輩はチェック処理が全部終わって実処理が始まったタイミングと終わったタイミングでログを吐くべきって言ってて、
とりあえず言うとおりにしたけどしっくりこなくて。
処理のくくりが違うんだろうか。

>>109
日本語がうまくてセンスがよいのはコメント
プログラムコードは関係無い
コードとコメント両方が上手い人は
コーディングセンスと日本語のセンスの両方を持ってる

>>112
前後で矛盾してないか？

>>111
それはたぶんコボラー

なんとか処理部とか言い出すのはコボラー

処理の最初と最後が分からなければ、意味がない。

>>111
場合によるけど、無意味なログが出まくるのは鬱陶しい
後でログを確認したときに、中身の無い開始終了が延々と続いてるとか

なんとか処理部なんて誰も言ってない。
処理という文字を見ただけで処理部に
見えてしまう人はコボラーｗ

>>111
チェックの内容による。

例えばユーザーが入力したデータに対するチェックは基本的にログに取らない。
例えば「名前は必須入力です」みたいなエラーを出すためのチェック

それに対して関数の引数としてありえないものを渡した（要するにバグ）を
検出するためのチェックであれば、ログに取る。
この場合は、チェックしてありえない引数であることを検出したら
例外として送出する。あとは例外の共通処理部分でログに記録される。

構成の良い綺麗な文章を書ける人はプログラムもセンスあるよね

普通の文章で、英数字やスペース、括弧などを全角半角入り混じって書いちゃう人のコードは信用しないことにしている。

>>115
なるほど、そういう用語はコボラー寄りなんだね
知らんかったわ

>>121
普通の文章って何さ

>>119
ユーザーの入力だからかもしれません。
納得しました。
自分のタイミングだとファイルがないときとかフォルダがないときかアクセスできないときとかでログが出るから適切ではないかもしれません。
例外処理は共通じゃなく出たとこでキャッチしてログに吐いて終わる感じです。

>>121
ドキュメントの半角カッコをリーダーに全角カッコに書き換えられていましたがこの場合はどうなりますか

>>116
そう思ったのですが認識が違ったみたいです。

>>111みたいなSIer的で原始的な事ってまだやってるんだね(驚き)

AOPやそれに似た感じの手法でログ吐くことに慣れちゃうと
もう、そんな事やれって言われたら、辞めますわｗ

> AOPやそれに似た感じの手法でログ吐くことに慣れちゃうと
具体的にどの言語でどのライブラリ（フレームワーク？）の
ログを吐く方法使ってるの？

ぶっちゃけAOPは流行ることなく消えた技術の一つだと
考えているのでね。

>>113
どこ？

>>126
COBOLだとソースコードに処理の分類がある。

コボラーにプログラムを書かせるとあまり意味のないコメントを書き出す。

そうだよなあ
AOPと大層な名前付けても、ログ吐く以外に使い道がなあ。。

>>129
後者に前者が含まれているだろ？

>>130
処理の分類とは起承転結で分かれてるみたいな感じですか？？

>>132
はあ？

>>133
COBOLはそういう区分がある。

COBOLプログラムの基本構造

COBOLのプログラムは、次の4つのDIVISIONをこの順番で記述するのが基本となっている。

IDENTIFICATION DIVISION……見出し部ENVIRONMENT DIVISION……環境部DATA DIVISION……データ部PROCEDURE DIVISION……手続き部

>>134
コメントがうまい人の一部の集合は、コメントもコードもうまい人の集合と重なってるよね？

ログは出しすぎかなと思っても、何かあったときに原因を突き止めるのに
必要だから出しておいた方がいい。ログの出力が少なすぎるとログの
埋め込みからやらないとならないからになって対応が遅れるから。

中にはログを出すのが恥だとでも思ってるのか、頑なにログ出力する
コードを書かない奴がいるけど、そういうやつは邪魔だから早いうちに
矯正しておいた方がいい。

あとはオレオレロガーを使うのではなく、有名どころのログフレームワークを
使うこと。

ログの出力しすぎかなと思っても今だとfluentdみたいので、集約したり
ファイル分けたりなんかは簡単だから。 ログがなくて困ることはあっても
ログがあって困るのはログの生存期間を悩むくらいだからね。

>>135
レビュー後の直しがそんな感じだったのでコボラーなのかもしれません
とりあえずは言うとおりにしておきます
今更ですが、言語はc#でした

>>137
ログで必要な情報って、運用に携わってないと中々わかんないんだよね
プログラムの動作を追えるのも必要だけど
誰が何をやったかというのも聞かれる事あるからね

>>137
そう思って共通部品でスタックトレース含めて出力できるようにしたんですがダメらしくて、ため息をつかれました。
各メソッドで発生時点で例外ごとにキャッチして、その時点で書き出すように指示されたので今はそのように実装してます。
例外ごとになにがだめだったか画面にメッセージボックスで出すようにしたのでエビデンスで発生した例外のあたりはつく感じになってます。

fluentdはログの集約ばかり注目されるけど
本当に良い所は、ディスクIOとの間に挟まるバッファになる所だと思う。

一旦メモリに吐き出すので、IOにプログラムが引っ掛かることが無い。
マルチスレッドで直接ファイルに吐くとありがちな、競合、ログの消失も無い。

ちなみにlog4系は嫌いだ
マルチスレッドに対応してなかったりするから

A応P？

ログファイルはプロセス、スレッド単位でかぶらないように、また時間をファイル名に入れておく。

ログファイルなんてただのテキストだから大量に出てもたいしたことない。

無駄にループ内で同じメッセージを出すのはアホだから、エラーメッセージとエラー発生時のデータ、操作、時間が分かれば十分。

ログファイルは定期的に自動で削除すればいい。

たかがログファイルくらいで変なもの使う必要ないよ。

外国人が出すようなログファイルは見づらいでしょ？

日本人と違って不親切なんだよな。

たかがログファイルなんて言えちゃうような人がセンス無い人なんだろうな。

スレッド間通信とかログファイルに出すと数秒で50Mとかなって困る

年収1,000万円以下の低レベルSEへ

SEの低生涯収入と短勤続年数の対策を考えろよ！
相場下がって迷惑だから交渉するか作業減らせ！
生産下がって迷惑だから技術は報酬で評価しろ！

[推定平均生涯収入]
100万/月 3億5,000万円以上(大卒サラリーマン上位レベル)
90万/月 3億円以上(大卒サラリーマン平均レベル)
80万/月 2億5,000万円以上(大卒サラリーマン下位レベル・高卒サラリーマン上位レベル)
70万/月 2億円以上(高卒サラリーマン平均レベル)
60万/月 1億5,000万円以上(高卒サラリーマン下位レベル)
50万/月 1億円以上(フリーターレベル)
40万/月 5,000万円以上(パートレベル)

>>146
キミの経験がないからそう思うのかもよ。

>>147
他のチームから殴られないかそれw

50Mはないけど、初期化処理だけでトレースがあふれてて、
一個前の実行時点のログが全く影も形もない、そんなのばっか。
関数の出入りを全部取る！とかバカだろおまえ...

取るのはいいんだけど、後で簡単に検索出来ないとな

>>150
一応、ログを種類分けして任意で表示させれるようにした
デバッグ中はそれでいいけど、予測不能のバグの場合はしっかりログが残ってないぜ

>>153
おまいの理屈だと、インサーキットエミュレータでCPU動作の全ステップを記録してないとバグは取れないと言う事になるが、そんな事しないだろ？

ログ出力できないような異常時は直前の処理がわかれば問題ない。

発生条件さえ判明すれば何とかなる。
再現性のないバグが発生すると死ぬ。

スタックトレース見りゃだいたい判るだろ

センスがないヤツはログの見方も分かってない

それJavaの話？

111のログについて質問したものです。
もう一つ質問いいでしょうか？
今日インスタンス生成のタイミングについても修正がありました。
1メソッド内でしか使用しない変数で、特に何度も初期化をしなくてもいいクラスを実体化するのにコンストラクタ内で初期化を行いました。
そのタイミングを、メソッド内で、変数の定義も初期化も行ってほしいと指示されました。
何度も呼ばれる処理ですし、一度実体化すればそれを使い回しておけると思いそうしたのですが、メソッド間で使用しない変数はフィールドにしてほしくないらしいです。
スコープを考えるのであればその方がよいのでしょうか？

何度も呼ばなくていいのか何度も呼ばれるのかどっちよ。

>>159
オブジェクトのライフタイムは出来るだけ狭いスコープでってのは、割と常識。

画面操作に伴う処理なのですが、ボタン押下の度にメソッドは呼ばれます。
変数は特に引数もないので初期化自体は一度で大丈夫です。
ほかのインスタンスはメソッド内で定義してます。
それだけは頻繁に呼ばれるので一度実体化しておいた方が実行効率としてはいいのかなと思っていました。
if文で囲んでnullの場合だけ生成するようにするのだといかがでしょうか。
一応メソッドの最後でdisposeはします。

>>159
それは先輩が正しい。

メソッド内での話です。
すみません。

>>159
素直に先輩の言うこと聞いとけ
そして疑問に思う事はここで聞かずにその先輩に聞いた方が良い

>>165
聞いたんですが答えてもらえなくて言うとおりにすればいいとのことだったので、すみません。

>>166
プログラマの「〜の方が効率が良いと思った」程、信用できないものはないってのも、割と常識。

シンプルな構成に保つのが第一。
実際に何か問題が起きたら、まず実測。
思い込みで作ったものは、後でみんなに迷惑かけるからね。

>>162
スレ前後しちゃうけど、そういうのを早期の非最適化って言うらしいぞ。
実際には何の問題もないのに、思い込みで無駄に変な作りにして、後で当時の意図がわからず困るという、アンチパターン。

>>159
これはグローバル変数の問題と同義。
自分で書いている通り、スコープを考えるのであれば、その方が良い。

>>169
自分でもあまりよくないのはわかっていたんですが、一度しか実体化しなくていいものを何回も実体化するのには抵抗があってこのような形にしてました。
スコープも考慮したやり方を調べてみます。
ありがとうございました。

初期化が重くなければローカルスコープで構わないけど
重いとかプロパティ保持が前提なら１メソッドだろうがクラスメンバ化
少しでも処理速度を稼ぎたい組込やゲームなんかは、見た目以上に効率化だな

>>142
log4j系ってlogbackも含むの？

int等の組込型なら初期化のコストは無視できるレベルだし、その変数が特定
メソッドでしか使われないなら、メソッド内のローカル変数にすべきだろう。

ローカル変数であれば、x86系CPUなら1命令でイミディエイト値をPUSHできる
し、スタック上の変数は、SP+固定オフセットでアクセスできる。ENTER/LEAVE
命令を使えば、複数のローカル変数領域の確保と開放を一気にできる。

クラスメンバの場合、CXレジスタなどにthisポインタを保持しての相対アク
セスになるが、そのメンバ関数はマルチスレッドでは呼べない。

複数のメソッドから更新・参照されていれば、排他処理を追加していないと、
それらメンバ関数同士もマルチスレッドでは呼べない。

但し、同じクラスオブジェクトの全てのインスタンスに対して共通の定数など
であれば、const型のstatic メンバとして宣言すべき。コンストラクタで
初期化する必要もない。

すみません、ただのprocessクラスです。
プロパティは設定しますがメソッド内で定義します。

>>173
そういうのは断定できないことだから、ある程度までにしてやめた方がいい。

いまのOS、CPU、その他ハードウェアでは本当にそうかどうかを証明できない。

年収1,000万円以下の低レベルSEへ

SEの低生涯収入と短勤続年数の対策を考えろよ！
相場下がって迷惑だから交渉するか作業減らせ！
生産下がって迷惑だから技術は報酬で評価しろ！

[推定平均生涯収入]
100万/月 3億5,000万円以上(大卒サラリーマン上位レベル)
90万/月 3億円以上(大卒サラリーマン平均レベル)
80万/月 2億5,000万円以上(大卒サラリーマン下位レベル・高卒サラリーマン上位レベル)
70万/月 2億円以上(高卒サラリーマン平均レベル)
60万/月 1億5,000万円以上(高卒サラリーマン下位レベル)
50万/月 1億円以上(フリーターレベル)
40万/月 5,000万円以上(パートレベル)

dispose必要なのに？

>>144
> ログファイルなんてただのテキストだから大量に出てもたいしたことない。
テキストだからこそ、実行性能に影響出ること結構あるぞ

テキストって最も容量効率悪いはずなんだが・・・

>>144
> 無駄にループ内で同じメッセージを出すのはアホだから、エラーメッセージとエラー発生時のデータ、操作、時間が分かれば十分。

本当にそうかね？ それがマルチスレッドで動いていれば
スレッド番号もわかったほうがいいだろう？
forkとかを考えればプロセスIDもほしいだろう？
複数のユーザーがログインするサーバーならば
ユーザー名がわかったほうがトラブル解決に役に立つぞ

catとgrepで確認できるから実用的だよ。

スレッド番号やプロセスIDが判っても、ログを開いた時点でそのスレッドや
プロセスは既に存在していないと思うが？　それらに依存する再現性がある
というなら話は別だが、本質的に無駄な情報だろう。

あんなこといいなできたらいいな vs 実用的

>>181
cat必要？

>>182
それらが無ければ一連の動作が繋がらんだろ。

運用した事ない人はログの活用法のイメージが湧かないんだよね。
だからただスタックトレース出す話に終始する。

さすがトラブル対策ばかりやってる人の言うことは違うな。

プロセスIDはあった方がいいぞ。
同じ通過ログが、複数あった時とか至極便利
つか、無いと追えない。

そんな障害を起こすプログラムを作る方がおかしいけどな。

問題箇所の特定ができないシステムの仕様もおかしい。

つまり設計がおかしい。

「アップルにアイデア盗まれた」 １兆円超の賠償求め米国男性が提訴
http://headlines.yahoo.co.jp/hl?a=20160701-00000012-jij_afp-int

>>189
障害がテスト環境で再現出来るんなら、別にログは必要ないんよ。
ただ、報告者の報告通りやっても再現しないとか、報告者の
勘違いだったなんて割とよくあるし。本場環境だと起きて、テスト
環境だと起きないなんてのもざらだし。報告が無いからと言って
放置してたら、使われなくなるなんてのもあるし。
ログがあれば直せてなくても、既知の問題として対処したりも
できるし、開発だけして、はいさようならな人には理解出来ない
だろうけどね。

>>191
それはプログラムの問題ではないだろ。

プログラムの問題ではないことを証明するためにログファイルは存在する。

なんか問題の切り分けがおかしい人がいるけど、最近の現場ってこんなのばかりだな。

経験者が去っていくからレベルがなかなかあがらない。

問題がないのに問題の切り分けだけがあるという不思議ｗ

>>194
ここでいってるやつらは自分のプログラムのことを言ってたり、環境のことを言ってたりと、初心者すぎるんだよ。

環境のログファイルを見なきゃいけない状況を作り出している方が悪い。

まあ外国人に作らせたり、環境自体が外国製だから変な問題が発生するんだが。

>>182
個々のスレッドがどう動いたかがわからないと何が起きたのかすらわからないだろ

>>196
プログラミングしかやったことない人らしい発言ですね。

>>198
すさまじい誤解w

よほどひどいシステムしか見たことがないんだろうな。

>>198
おまえ、まえも同じレスしてるよな？

それしかないのか？

>>197
スレッド番号やプロセスIDが判ったら、スレッドがどんな動きをしたか
判るんだ。　現場の血文字で真犯人が判っちゃうコナン君でちゅか？

そんな下らん情報より、エラー出したソースのファイル名とソース行番号
くらいレガシー言語のCでもマクロで一発で出せるだろ。

運用とか構築やってる連中(特にインフラ系)って、意識だけ高くて表面的な
知識だけでレベルが低い印象。

>>201
エラーになるような簡単な問題ならいいですねー

インフラ屋って理由のあまりない設計、構成が多いからな。

理屈がないやつが多い。

そうしてみたかっただけとか多くてびっくりする。

>>202
だから、それは作ったプログラムの問題ではないだろうか？

>>204
自分が作ったプログラムに一切不具合はないと言い切れるんだ。
おじさん、そんな自信はないから万が一の時に原因をトレースできるように
ログ出しちゃうなぁ。

自分で作ったプログラムで発生した事象で原因わからんとか
センスないから職を変えた方が世のためだな
他人のモジュール呼ぶにしても想定外の返却値が戻された箇所くらいはわかるはず

迷惑電話 FJネクスト ウンコ注意9評判 口コミ 悪徳･2ch.net

http://hayabusa6.2ch.net/test/read.cgi/estate/1465394964/

>>205
自分が作った範囲ではすべてのことを想定して作るのが普通だろうが？

>>208
へー

あたりまえだが、初心者はこれができない。

それは誰でも最初からできたわけではないからね。

なんかログ出力派なのに逆のことを言われてるけどなんなんだこの流れ。

>>208
電源引っこ抜かれたことも想定して設計するよな

>>211
当然だろ。

サーバー(ノード)が突然、落ちることはあるからな。

初心者は再起動のことも考えてなかったりするからやっかい。

>>201
もしかして落ちた瞬間しかログ出さない前提で話してる?

>>210
＞それは誰でも最初からできたわけではないからね。

最初から完璧には無理かも知れんが
基本的に最初できないヤツは、ずっとできない

自分で作ったものが理解できてないのは
責任感とか論理的思考力が足りてないだけなので、経験ではなく資質の問題だ

そろそろセンスある人求む

Windowsで育った人はログ出さない印象

>>216
暑いから扇子はいつも持ち歩いてる

>>216
む求人

>>217
たぶんね、画面まわりしか作ったことしかないと出さないかもしれない。

そういうやつがバッチ処理を作るとなんのログもないものを作ってトラブルに対処できない。

何ヶ月か前に話した20代後半のやつがそうだった。

どれもセンスねえレスだなw

>>221
どれもセンスねえレスだなw

>>217
お前さんかわいそうな世界で生きてるな

イベントビューアーとか見たこと無いんだろうな

>>220
画面周りこそログだろ。
デバッガ使うと挙動が変わるし。

>>201
コナンはさ、死体があるから仕事できるんだよ。
血文字でも遺書でも大差ない。基本的に状況は変化しないから。

>>225
デバッガ？

プロはデバッガはあまり使わない。

>>227
メモ帳一択ｗｗｗ

>>228
笑うところじゃないよ。

>>224
Windows界隈の人って見ないよね

イベントログは証拠隠滅のためにも使える。

>>224
スレッド単位のログみたいな雰囲気で出してたら
ロストしまくるだろ。

>>232
ものによるだろ。

どんなの想定してんだよ。

>>230
お前の世界ではな

>>220
むしろエンド側しかやったことなかったからフロントの仕事したときに価値観が合わなくて疑問に思ってました。
そういうことだったんですね。

バックエンドとフロントエンドね。

SEX用語かと思ってた。

フロントエンドがバックエンドを、乱暴に扱うのはよくないよな
同性の場合は特に、色々と問題が出てくる

>>236
素で間違えました。
ありがとうございます。

Windowsで育ってフロントエンドメインだったけど
確かにバックエンド担当にしたときログ残そうとしないな
もちろん残すんだが何残すべきか考えるの面倒っていうか

プログラマーとしてだましだまし5年以上やってきたけど
体系的に学んだことがないから
新しい職場では全く通用せず残業のオンパレード
このままじゃやべーな

まず全員と仲良くするべし
たとえ性格が合わなかったり真剣に仕事をやらない人とでも。
仲良くなったぶんだけ質問が許される。
質問攻めしても対応してくれるなら大親友だ

仲良くなれば、今後仕事を紹介されるかもしれないしな。

仲良くなれないと、どんなに技術があろうが仕事は振ってこない。

アホな質問が許されるのは、相手もアホな場合のみ
俺なら、あいつやべぇぞ、ってリーダーにチクるわ

あ、もちろんアホじゃない質問なら真面目に回答する
むしろ人に教えるのは好き

今技術が低くても前向きに勉強する人は応援する。
技術を軽く見てなめてる奴は潰す。

>>246
お前潰されんぞ

技術屋の家族かわいそう

技術ない方が寿命と収入高い

技術下げるか収入上げろ！

放送・商社・銀行・公務 > 製造・化学・通信・情報

2014年度有価証券報告書より
伊藤忠商事　1,395万円(41.5歳)
三菱商事　　1,376万円(42.6歳)
三井物産　　1,361万円(42.4歳)
丸紅　　　　1,306万円(41.5歳)
住友商事　　1,301万円(42.8歳)

http://m.finance.yahoo.co.jp/stock/fundamental?code=4676.T
3

>>248
コピペにレスつけるのもあれだが、
確か商社マンって退職後の寿命が短いんじゃなかったかな？

>>249
SE寿命は退職前

>>243
きもい

幾多の難関をくぐり抜け仕事を勝ち取ってきた歴戦のアナル

【主な偽装請負従犯SEの作業】
[技術不要の使い捨てスキル]
コマンド
データ > ロジック
簡単ロジック
大量データ
SE適性不要
IT資格不要
大卒資格不要
文科系対象
体育系対象
商業系業種
業務系処理

[業務ソフト作り捨てソフト]
ノンプログラミングツール
フレームワーク
COBOL
VＢ
.net
Java
Web
DB
ERP
SAP5

東大卒の新人には勝てないと思った

何に勝てないって？

新人のアナルには勝てない

http://hayabusa6.2ch.net/test/read.cgi/pc2nanmin/1439353617/216
　　　　　　　 ↑　　↑　　↑　

無能実態派遣残業して時間報酬相場下げるな！
【知的財産と契約料金の搾取促進者ばかり】
［SI生涯損害助長SEを追放すべき］
偽装請負従犯SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死7

ほんとにできる奴って凄い事を普通にやって凄い事の様に見せないと思う

別に凄い事じゃなくたって
普通の事を普通にこなせてるだけでも凄い事ですよ

>>259
は？凄いことをやってりゃできる奴じゃん

出来もしないのに口弁慶は山ほどいるけどな

できる奴は、初めからできる。
理屈じゃない、そういう世界。
努力は無駄だよ。

プログラム構造のイメージを作りながらコードを読む事なんて
訓練してもできるようにならないからね。

小説を読めば情景が広がる。それと同じくらいの読解力くらい持てよ。

小説を読んで見える情景は千差万別だけどな

無能ITドカタへ

契約外の作業期日は断れ！
時間外労働違反はするな！
生産技術低すぎなんだよ！

無能残業者は優秀なSEに迷惑
無能残業者は共働きSEに迷惑
無能残業者排除を政府が対策

残業代ゼロ法案
http://lite.blogos.com/article/109636/
1

プログラム読んで思い描くイメージも千差万別なんだぞ。
おまいが思い描くポインタと俺が描くポインタのイメージは違うからな。

そこで共感覚(シナスタジア)が一定に共有されやすい物が集団生活では好まれるのです。

共通解釈はあり得るよ。
じゃなきゃ、国語と言う教科は有り得ないからね。

まぁ、時々、おまいらのような千差万別理論で、国語を否定する輩もいるけどな。

何読んでもエロしか思う浮かばんのだが

そこで肛門快楽(アヌスアクメ)が一定の集団では好まれるのです。

>>262
＞ プログラム構造のイメージを作りながらコードを読む事
え、そんなん、レベルの違いはあっても、誰でもできるんじゃないの？

プログラミングが全然できない人に出会った事がないから、
よう分からんのです

やたらとアナルが好きな奴がいるな

俺もだけど

プログラミング言語で仕事選んでる奴はセンスない

コボラーかな？
俺はアナルで仕事を選ぶけど

>>273
特定の言語を指定してくる仕事は断ってるぜ
センスを活かすには熟知したMy道具は付き物だからな
職人に自分の道具を使うなとかふざけたことは常識的に言わないもんだけどな

スマホとPCで主要言語違うけど、勿体無い。

何が勿体ないの？

いつの間にかアナルスレになっててワロタ

いまどき言語の違いなんてそんなに変わらないでしょう

>>275みたいな釣りがぜんぜん面白くない

>>279
VCとperlで同じ成果物がつくれるのか？

>>280
釣りじゃねえよ
何でも引き受けるとかバカのする事だろ

アナルは十人十色

違うのは色だけじゃねえけどな

アナル好きはプログラミングのセンスがある

プログラマはアナル好き
一理あるわ

アナリストですね

センスのある男には女がいない。

これ真理。

8日ぶりに風呂に入った。

>>281
それは片方スクリプトだしね

SEの不健康と低知能の時間外労働違反対策

貧困と訴訟が増えて迷惑だから残業は辞めろ！
優秀なSEや共働きに迷惑だから残業は辞めろ！

時間外労働違反となる
将来削減の業界である
多数が嫌う職種である
共働き結婚妨害である
契約に作業期限はない
契約終了が早期化する
定年退職が早期化する
健康障害をもたらす
対人障害をもたらす
生産評価が低下する
生産能力が低下する
能力評価が低下する
時間報酬が低下する
情報技術が低下する
生涯収入が低下する
学習時間が減少する
副業時間が減少する
訴訟が増加する
失業が増加する
貧困が増加する
独身が増加する
早死が増加する5

この執念深さは気違いならではなんだろうね

>>290
だからなに？

外部仕様ならいけるんじゃね

>>290
vcでWindows版perlのコンパイル出来なかったっけ？

SEの報酬対効果と知的財産搾取の対策

相場下がって迷惑だから不利益開発するな！

報酬80万/月以下で設計するのは辞めろ！
報酬80万/月以下で実装するのは辞めろ！
10

Perl/Tk 使えばいいじゃない

SEの知的財産と契約料金の搾取対策

早死に貧困の助長だから偽装請負の従犯は辞めろ！
相場下がって迷惑だから報酬増やすか作業減らせ！

・IT社長に贅沢資金を搾取させるな
・平均年齢40歳未満の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時間以下の契約は辞めろ
・6時間/日以上のPC使用は辞めろ
・100万円/月以下のプログラムは作るな
・偽装請負の開発は辞めろ
・多重派遣の開発は辞めろ
・多重契約は止めろ
・残業見積りは止めろ
・不要作業は止めろ
・時間外労働違反は止めろ
・契約外作業期日は守るな
・客先指示に従うな
・不利益な依頼は断れ
・知的財産を渡するな
・生産効率を上げろ
・残業しないで学習しろ
・残業しないで副業しろ
・損害は訴えろ

【非婚】SI受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1451213054/
6

それよりも批判ばかりして
同僚と知識交換しない奴はいらん

知識交換って何？
教えてクレーってこと？

女子社員と体液交換ならしてもいい

たぶんダメダメばっか言ってどこがどうダメでどうしたらいいかって言うのをいいたいんじゃないかな

問題提起の難しさとか重要性わかってるか？

ダメダメ言うだけなのは、まだ期待されてるんだ
おまいらに解決策まで教えたら頭使わないだろ

教えたがりのくせにw

そうだよ
そこをあえて指摘までで抑えてるんだ
わかってんなら文句言わず頑張れ

教えたがりの独断に満ちた指摘()はいらんわ

独断が満ちてるってどういう状態か知らんが

指摘が間違ってると判断できるなら従わなくて構わんよ

なんで従うやねんwそれがお前の独断やw
指摘はacceptかrejectするのが先やでw

んじゃそのacceptやrejectする担当に文句言え

問題点がどこにあるか分からんバカ

>>309
この流れでは問題点はお前以外にないのだがw

そうね
バカにエサあげた俺が悪いね

そして独断により他人をバカ認定する事で心の平穏を保つ>311であった
めでたしめでたしw

こんなんばっか

マジレスしたら無関係な話をおっ始められた…

>>303
でたでた

日本のプログラマ業界の病気だわ

プログラマに限らず大体こんなもんやと思うで
周りは皆バカでなぜか自分だけ賢いねんw

SEの知的財産と契約料金の搾取対策

早死に貧困の助長だから偽装請負の従犯は辞めろ！
相場下がって迷惑だから報酬増やすか作業減らせ！

・IT社長に贅沢資金を搾取させるな
・平均年齢40歳未満の会社は辞めろ
・1,000万円/年以下の会社は辞めろ
・100万円/月以下の契約は辞めろ
・5,000円/時間以下の契約は辞めろ
・6時間/日以上のPC使用は辞めろ
・100万円/月以下のプログラムは作るな
・偽装請負の開発は辞めろ
・多重派遣の開発は辞めろ
・多重契約は止めろ
・残業見積りは止めろ
・不要作業は止めろ
・時間外労働違反は止めろ
・契約外作業期日は守るな
・客先指示に従うな
・不利益な依頼は断れ
・知的財産を渡するな
・生産効率を上げろ
・残業しないで学習しろ
・残業しないで副業しろ
・損害は訴えろ

【非婚】SI受注SEは3億円以下の低生涯収入【離婚】
http://hanabi.2ch.net/test/read.cgi/infosys/1451213054/
1

無能実態派遣残業して時間報酬相場下げるな！
【知的財産と契約料金の搾取促進者ばかり】
［SI生涯損害助長SEを追放すべき］
偽装請負従犯SEの動機
コミュニケーション障害
コンピュータ趣味
人格障害
文系大卒
低偏差値大卒
情報処理資格非保有者

偽装請負従犯SEの迷惑
無償プログラム提供
事前面接
契約外期限遵守
客先指示遵守
知的財産譲渡
中間搾取促進
時間外労働違反
低予備工数見積
残業見積
無料追加
学習不足
裁判苦手
対人障害
健康障害
孤独死

偽装請負従犯SEの代償
低収入低技術
非婚離婚
鬱病早死11

年収1,000万円以下の低レベルSEへ

SEの低生涯収入と短勤続年数の損害対策考えろ！
相場下がって迷惑だから交渉するか作業減らせ！
生産下がって迷惑だから技術は報酬で評価しろ！

[推定平均生涯収入]
100万/月 3億5,000万円以上(大卒サラリーマン上位レベル)
90万/月 3億円以上(大卒サラリーマン平均レベル)
80万/月 2億5,000万円以上(大卒サラリーマン下位レベル・高卒サラリーマン上位レベル)
70万/月 2億円以上(高卒サラリーマン平均レベル)
60万/月 1億5,000万円以上(高卒サラリーマン下位レベル)
50万/月 1億円以上(フリーターレベル)
40万/月 5,000万円以上(パートレベル)9