まともなプログラマってどのくらいの割合でいる?
■ このスレッドは過去ログ倉庫に格納されています
おれ、今までに、
きちんと話とかして
一緒に仕事をしていて、
仕事の内容とか結果とか見ていた
人だけにすると、500人くらいいたんだけど、
この人は、ちゃんと
コンピュータをわかっていて、
開発速度もそれなりに速くて
バグもほとんどない
可読性も高い
ちゃんと交渉も話もできる
等々を兼ね備えているやつって、2人しかみたことないんだが・・・・・・・
実際、普通程度にできるプログラマって全体のどんくらいの割合なんだ? プログラムは改修繰り返して経年劣化していくのがわからん奴ってアホだと思う >>213
劣化するような回収しかできないのはお前だけだと思う・・・ 予算と納期の制約で妥協の産物ができあがるのは日常茶飯事だな 理想どおりいかなくても、多少なりともマシになっていくもんだろJK
触るたびに劣化とか、どんだけ技術力無いんだよ。 現実はどこの馬の骨ともわからん有象無象が群がって
動けばいいや的な改造っていうか改悪して金稼いでる >>212
構造化プログラミングより前の時代のプログラム修正を経験したらわかるわ。
あれだけは、触ろうとは思わない・・・・。 リファクタリングというから理解できない
改善といえばいい。
改善してトラブったらどうするんだ!
改善なんて不要、現状維持で良い。
そうおっしゃるんですね?って
聞き返せばいい。 >>216
あたりまえのことなんだけどさ。
コードというのは一行増やすだけでも
以前より複雑になってるんだよ。
既存のコードに手を付けない改修は複雑になるしかありえない。
他のコードは変えてないのに行を追加して前よりシンプルになりましたとか
絶対にありえない話なんだからさ。
もちろん行を増やす=複雑になる。なのだから現状維持ですらない。
改修して劣化しないためには、既存のコードを修正するなら
削除するしかありえないんだよ。 >>220にとってのリファクタリングってのは、複雑にすることなんだな。 >>222
横だが>>220のレス先のぞくと、>>221の言う通りだと思うんだが。
>>220は「プログラムは経年劣化するからしかたがない」って主張に対して、
常に要求が変化する中で常に完璧な状態にするのは不可能だけど、
リファクタで再設計された状態にすることで、経年劣化の年数を都度リセットできるって話だと思う。
ちなみに俺もそう思う。 ソースが経年劣化するという前提があるとしたら>>223の意見は正しいと思う
でも、>>220はそんなこと全く言ってないと思うぞ・・・・ リファクタリングの工数認めてくれる経営者なんて今の世の中いないぞ 理論上はソースコードの経年劣化はしないけど、相対的に見れば
経年劣化するも同然だよね。バグのないプログラムでない限り。 民主党みたいに想像力の欠如だな。
自分が考える「改善」をほかの誰も考えず、誰も実行しない。しなかった。
これには理由があるのでは?
そう考える能力が欠如している。
実際に見たことも触ったこともない、ものに対して論ずるのもいいが、歴史のある大企業に正社員として勤めてみろ。
そこで、ifやwhileやらの命令がなかった次代のソースに対して、同じことが言えるか。 受注系SEの非婚率は異常
低生涯収入
高稼働労働
人格障害者 >>227
それこそ、新人研修くらいだよなw
でも、あの時代のソースを新人が見たら悲鳴あげる >>227
リファクタリング=開発。
開発の工数だよ。アホ。 しかしまあ、リファクタリングできない奴等の
言い訳ってこれだけ必死に書かれると新鮮だよな あー、たしかに。
リファクタリングしないんではなく
する技術力がないんだろうな。
なにが正しいコードかもわからないんじゃ
どう直せばいいかもわからないだろうね。 リファクタリング無駄無駄ァ!って騒ぐおっさんなんとかしてくれ
文句だけいって根拠述べないし、何もしないどころか混乱だけ生む やらせてみればいいな。
無駄はいいからお前出来るのかよ?
できないから無駄って言ってるのかよ?
俺がレビューしてやっから、ほら直して見ろってw 絶対にやらない
テコでもやらない
メンテする気のないスパゲティ量産して放置して熟成する趣味にいそしんでるよ 他人の書いた数十万行のCOBOLソースをバグを出すことなく1人でリファクタ出来るなら褒めてやるわ。あ、有能な君らだから1ー2ヶ月でいいよね? >>232
お前働いたことないだろ?
上の人間には開発には見えてないぞ
実際にリファクタリングに1人月かかったとして、
外部仕様的には何も生産していないのになんで工数かかるのかっていう話になる
開発の工数に混ぜ込んでも開発自体の生産性が悪いって話になる リファクタリングでも工数は貰える
現場の信用ないと貰えないと思うけど、信用されてれば金払う。
相手の立場になって考えたらわかるでちょ。 >>239
いくらなんでも頭悪すぎ。
リファクタリングをまともに理解できないからそんな結論しかでないんだよ。 >>241
経営者に理解できるわけがないのは当たり前の話
だから予算が出ない 実際にできるできないは別にして、リファクタリングもできないようなシステムは恥だと思わないのかね。
なかには開き直るやつもいるし。 >>239
> 外部仕様的には何も生産していないのになんで工数かかるのかっていう話になる
なんでって、ソースコードが複雑だからだよ。
そういえばいいじゃん。 >>239
一人月つぎ込むことで、一人月以上のコスト削減になれば問題ない。 受注系SEは結婚困難
低生涯収入
高稼働労働
人格障害者 発想が数年遅れてる
今更リファクタリングとか覚えたてのやついないだろうが 多分だけど、リファクタリングの意味がわからなくて、勝手にバズワードと決めつけて耳塞いでる老害なんだろうな
オブジェクト指向否定してた層と同じだろう >>251
いるからこれだけ荒れてるんだろ・・・
しかも表面的な事しか知らないから無駄とか無理とかそんな話しかできないし >>253
ここまでの流れ
上が阿呆でお金出してくれない
→リファクタリングしない奴は無能www 今時リファクタリングなんて、eclipseが全部やってくれるのに何をいってるんだ?
Android Phoneでなんでもできるようになってるのに、モバイルPCと大容量バッテリーは
何がおすすめかとかいってるようなものだ。 リファクタリングできないほど複雑化したシステム触ったこと無い奴は素人。 > 今時リファクタリングなんて、eclipseが全部やってくれるのに何をいってるんだ?
全部はやってくれない。
それに人間がどうするかを決めないと
勝手にやってくれるわけじゃない。
そして人間が正しい設計を決めるには
高い技術力が必要。 なんか、リファクタリングの意味理解してないやつが時々いるな… ☆コピペ推奨☆
【犯罪者追放のお願い】
大金、知財、健康を失ってからでは、取り返しがつきません。
犯罪者に従うのも犯罪です。犯罪行為を最寄りの警察署に通報して下さい。
※通報者のプライバシーは保護されます。
刑法第246条 詐欺罪
虚偽による契約金を交付させた。
刑法第223条 強要罪
作成等の完了日を強要された。
刑法第234条 威力業務妨害罪
職権等の威力によって業務を妨害された。
刑法62条 幇助罪
犯罪行為を助長した。
職業安定法第44条 労働者供給事業の禁止
業務の時間、場所、方法等を指揮命令された。
警察官の対応に問題があった場合は、 監察局、各都道府県の警察本部監察官室、 公安委員会に苦情申出して下さい。 きちんとしたソースコードが書ければ、PGとしては何とかOKだね。
ただし、そのソースコードの構成と内容が問題。
ちゃんとした管理体系に従って、格納フォルダが命名され
内容毎にフォルダ分けされてること。
処理モジュール単位(1つのオブジェクトみたいな区切り。もっと大きな区切りでも可)で
ソースコードファイル分けされてること。
ソースコードの中に、仕様内容が詳細に記述(できれば和文と英文で)
されていて、各ルーチンのインターフェース仕様および処理についても
適度に詳細なコメントが入ってること。
担当する処理モジュールの大まかな機能と、そのインターフェース仕様を
説明する、図表を交えた仕様書を必ず作成すること。
以上の成果物を、上位設計者からの口頭説明やドラフト書類から
質問を投げかけながら、製造できること。 >>256
どんなスパゲッティも最初は絶望しか無いもんだよ
すべて解き終わったときの虚無感もな リファククタリングが出来ないコード、仕様書が無いコード。
なぜ動いているかも判らないが、業務には"まだ"支障が無いプログラム。
そんな物が蔓延している業界ならば、今すぐ参入すべき。
受託開発とか、人材派遣では無くて、事業そのものに参入するべき。
既存の競合他社は、時間と共に勝手に潰れて行ってくれる。 実際さ、大昔のCOBOLソース以外でもさ、リファクタなんてやるケースほとんどねーだろw プログラムをコピペしてちょっと修正を繰り返して全体が馬鹿でかくなるのは珍しくない >>263
おまえ、その分野がどういう分野かしらんだろw
ユーザーサイドで汎用機とかをリースや自前で持ってる世界だぞ
どうやって割り込むんだww どこのうまともわからん企業になんで基幹を任せるんだ? ぱこそん でしか考えられないプログラマって時点でまともなプログラマじゃないよね 汎用機をやって居ると、PC系のプログラムは便利なツールが
揃っているイメージがあるなあ。(充分と言えるかどうかはべつにして。)
もちろん、最近の汎用機ではプログラムのソースをPCに転送して
パソコンのツールで編集、再度転送って出来る事は出来るけど、
文字コードの問題なんかもあるし、結構大変。
そんな事考えて居たら、オープン化なんて出来るのか?
って懐疑的になるわ。 >>268
それ以前に、やっぱり永続的な稼動において動作不安定ってのはあかんよ お客さんによく、オープン化する方が良いのか聞かれるけど、
このスレタイの通りのまともなプログラマならどう答えるのか
いつも悩む。
自分が汎用機やって居るからと言うのはおいといて、
1)今の全体的な流れで言えばオープン化という方向に見える・・気がする。
2)若いSE・PGは汎用機に配属されるのを嫌がる・・・気がする。
3)安定性は汎用機の方が上。但し、サーバでも同じような安定性がある声もある。
いつも3)に関しては料金と安定性を天秤に掛けて考えるとどうなるのか
ホントよくわからん。 素朴な疑問なんだけど、汎用機の定義って何?
JCL食わせたりするのが汎用機? >>272
そうかあ・・・最近だとWindows系の奴もあるんですよね。
そう言われるとそうだなあ。ごめんよく分からないやあ。
自分は某N社の奴だけど、IとかFはどうなってんだろ。 >>274
そうそう。それもありますね。
オープン系の開発要員は数が多いから、失礼な言い方すると
比較的良いアタリの人材に当たる確率が高い気もしますね。
それも、全体的な数が多いから必然的にアタリの数も多いって
事なんでしょうけど。
これは良し悪しなのかも知れないですけど、COBOLとかJCLって
10年以上前のモノがそのまま動いているのはすごいと思う。
それがスパゲッティの原因でもありますから一概に良いとは
言えないですけど。 >>275
銀行的な基幹業務はこれからも汎用機のメリットありそうだけど、コスパは開発者の採用含めてどんどん合わなくなってきそうやね。
国内、海外含め新規案件てどれぐらいあるのかしら >>276
開発者の数が減っているのは実際の数を数えた訳では無いので
分かりませんが、減ってきている感じはしますね。
でも、現実に動いている汎用機とその中のプログラムが存在して
いるわけですから使える人材の確保は必須だと思います。
汎用機と言うと、銀行の基幹業務ばかりが言われますが、
自治体なんかも結構使っている所多いですね。
特に自治体は仕事の種類が多いから、見落とすと怖そう。
新規案件も自治体で多いかも知れないですね。 こないだの横浜銀行の件みたいなものもあるし「カイガイガーコストガー」とか言ってたらマズイのに。
現場の待遇改善しないからどんどん若手減ってんだけど、どうする気なのかね。 >>264
受託はそうだよ
リファクタリングは”自分の”コードに施すもんだ >>278
そういや自分の現場では再々委託ダメになって問答無用で切られたのが何人かいたな
なかなか優秀だったのに >>277
減ってると思うよ。新しい人がコボルとかやりたがるわけがない。
けど保守とか含めで需要はしばらく続くので今なると結構良い商売になるとか 50すぎたおっさんというと、久保田利伸?みたいなのが、いるんだね。
60すぎたおっさんだと、浜田省吾とか稲垣潤一とかだね。 そういやプログラマってどうして
歳のわりに幼かったり、くたびれた感じになるんだろうな >>284
歳のわりに幼く「且つ」たびれた感じだな リファクタリングは、やらないのか、できないのか、それが重要だ。
コボラーの場合は、できない、だろうけど、
できないなら、一生スパゲティコボルとお付き合いしとけ。
スパゲティコボルとオサラバする流れが見えるなら、できるように今から準備しとけ、
さもないと保守的コボラーが見たこともないデスマ必至よ。 できないと言ってもそれは
能力と予算的な都合の二種類あるんだけどな >>281
おっしゃる通りですね。
問題は、書いておられる「しばらく」が5年なのか10年なのかその長さによって
会社が人を出すかだと思います。自分の知っているCOBOLのソースは
30年以上前のモノがあります。基幹業務です。しかも長い。
これをCなり他の言語にバグ無く置き換えるのは至難の業だと思います。
新規で作成すれば良いと言う人も居ますが、その仕様を上げる時にその
プログラムの中で実現されている仕事がすべて上げられるか果たして
疑問です。 現行の動作と多少違ってても問題ないからやれ。俺が責任を取る。
と言える人がいないからねぇ
基幹システムなんて誰も興味持ってないし、いままでどーりに動いてればそれでいいんじゃないの??
としか思ってない。 COBOLのソースは資産なんだよ
そこらの汎用機よりよっぽど金かかってんぞ わかってないな
ソフトを作り直すより、ハードを作り直したほうが安くて合理的なんだよ >>294
そんなの早く作れる人が客にはまだですーって言いながら他のことしてた方がいいがな 遅く作る人は結局、納期に間に合わないで品質も悪く、最終的に利益を減らす >>296
☆コピペ推奨☆
【犯罪者追放のお願い】
大金、知財、健康を失ってからでは、取り返しがつきません。
犯罪者に従うのも犯罪です。犯罪行為を最寄りの警察署に通報して下さい。
※通報者のプライバシーは保護されます。
刑法第246条 詐欺罪
虚偽による契約金を交付させた。
刑法第223条 強要罪
作成等の完了日を強要された。
刑法第234条 威力業務妨害罪
職権等の威力によって業務を妨害された。
刑法62条 幇助罪
犯罪行為を助長した。
職業安定法第44条 労働者供給事業の禁止
業務の時間、場所、方法等を指揮命令された。
警察官の対応に問題があった場合は、 監察局、各都道府県の警察本部監察官室、 公安委員会に苦情申出して下さい。 >>291
COBOLソースが資産なのは、まあ認めよう。
だがコボラーはゴミ、そこを勘違いしてはいかん。 COBOLerでも業務に精通してるなら、能書き垂れてる専門卒など の10000000倍は欲しい人材 求められているのは経験30年超で業務や仕様に精通しているCOBOLerであって
おまえらみたいな最新技術に精通してるCOBOLerじゃない この間客からスキルシート出せいわれたんだけど、その項目がどの省庁のシステムやったことあるかとか汎用機どうよとかPowerBuilderどうよとか俺のスキルだとなに一つチェック出来なくて無能すぎて愕然とした(´・ω・`) うちの自社製スキルシートはVBのどんなライブラリが使えるかの項目ばかりだぜ COBOLerだらけの環境だけど、みんな、修士か博士だからほかの言語も当然余裕よw
お前らが馬鹿だから馬鹿しか集まらない会社にいるだけだろww 派遣だからまわりにいる人はそれなりに優秀だよ
バカは俺だけ >>306
博士行ってCOBOLやるとかどういう流れでそうなったのかくわすく コボル(爆)wしかやったことないのに他の言語余裕っていうのもねw
それ言語仕様知ってるだけだろw ■ このスレッドは過去ログ倉庫に格納されています