プログラマの雑談部屋 ★17
■ このスレッドは過去ログ倉庫に格納されています
後輩が実装で詰まってるみたいで、朝から何度も質問とか相談とかされてるんだけどまだ解決出来てないみたい
この後輩に限らず、今までの経験上、詰まってる奴が苦悩しながら組んだ実装って十中八九バグを内包してるんだよな
詰まってる部分を俺がやってやった方が話が早い訳だが今後の事を考えると安易に手伝うのもどうかと思う
お前らならどうする？ >>4
設計書は発注元が書いてるから書き直すのは無理なんだよね
出来る事と言えば後輩に仕様を細かく噛み砕いて説明してやるくらいなんだけど、軽く混乱状態に入ってるみたいで、普段ならわかるであろう内容まで？？？って状態
みんな通る道だとは思うけど時間かけてゴミソース作ってこられるくらいなら俺がやったほうがマシかなって >>5
一緒にやってやれよ
お前が指示出してその通りやらせるんだよ 指示は細かくな
もう脳みそが回ってねぇんだから
これしかねぇ どうせ口頭だけで全部説明してるんだろ
メモ書いて渡してやれよ 彼にはもうそれを理解する余力は無さそう
もう
「visualstudio開いて」
「ここにｘｘｘコピー」
「その変数で参照飛んで」
「ここにｘｘｘ貼って」
みたいな感じで指示出せ
その横でお前は自分の仕事進めろ
管理職必須の技術だ 助言はなんぼしてもいいけど
成果物をかわりにアウトプットするのはNG >>11
え？ありだろ
だって個人事業主じゃねーんだから
渡せるタスクあるならタスク引き取ってやれよ チームで動いている以上は組織として成果を出すのは大切
その上であまり引き取りすぎると成長を阻害したり有識者が偏りすぎたりして結果的に組織として牛歩となったりもする
難しいところ ただ、他のメンバーより大幅に残業してるのであれば
それはなんか違うな
下手するとただのイジメ 残念だけど四苦八苦して書き上げた汚いバグだらけコードはいくら書いても成長しない
スマートな正解を見せて解説してやったほうがそいつのためになるよ 山本五十六
「やってみせ 言って聞かせて させてみて ほめてやらねば 人は動かじ」
「話し合い、耳を傾け、承認し、任せてやらねば、人は育たず」
「やっている、姿を感謝で見守って、信頼せねば、人は実らず」
「苦しいこともあるだろう 言い度いこともあるだろう 不満なこともあるだろう 腹の立つこともあるだろう 泣き度いこともあるだろう これらをじっとこらえてゆくのが 男の修行である」
男の修行であって
プログラミングの修行ではないな
では後は頼んだぞ! >>15
デザインパターンの概念だな
個人的にはまずは手を動かしてバグだらけコードを書いた後にスマートなものを見せる方がいいと思ってるけどね >>17
無駄だな
統計的に頭のいい親から出ないと
頭のいいやつは生まれない
だとすると日常的に正解が近くにあったほうが
上手く育つということだ >>18
それは遺伝子学の話
正解を知るだけでいいのであれば同じ本を使って同じ時間勉強した人だとしても差がでるのは何故なのか
人は成功失敗問わず体験を通した方が学ぶもんだよ ほっとくと変な方向に進化してしまう
OOP全くできてないけど1000行の手続きでも迷わずコーディングできる奴とか
まさに職人技って感じ 同じ本、同じ時間
以外は差しかないじゃないか。
青空を見て、他の条件を考慮しなければ
誰もが同じことを感じると思うか？ あおいそら
君が思い浮かべたものを当ててみようか？ >>12
いったん振ったならしょうがない
次からタスク配分調整すりゃいいが ジャップは最低の社会
実力主義だったら俺エリートなんだが
なんで俺がこんな目に
コネ＞実力
新卒＞実力
コミュ力＞実力
顔（女）＞実力
仕事で要領がいいだけ＞実力
プログラミングが早いだけ＞実力
プログラミングで細かいだけ＞実力
ジャップランドは全然実力主義じゃないんだよなぁ 個人で開発して公開できる業界時代で何言ってんだチョンは ずいぶんと前だが大阪のシステム開発会社の試験で
こんなのがあってよ
これの答えは何なん
( )に入る値を答えよ
void main(void){
_floattoint() = 10;
single + signum >> 3;
return num;
if(num < function(a,b)){
( ) + (intnum / num2);
・・・・(以降カット)
「は？？」って思わず口から出てしまった
・変数の宣言もされてねえ
・そもそもどっから来たんだこの数字と関数
・この関数の中身がどこにも書いていない
・Cってreturnの後にも続いていいんだっけ？
「解なし」って言わせたいにしては文章問題じゃないし
50問あるうちの45問くらいが同じようなものなので、ほとんどが解なしになってしまう
「ウソだろそんな変な関数や式のわけがない」
「関数の中身は別の場所に書いてあるんだろ」
俺もそう思って何度も何度も何度も何度も何度も何度も何度も何度も見返したんだよ
しかし、基になるようなもんがどこにも書いてねえし
こんな構文で成り立つのかって文になってるんだ
最初の2問めで20分くらい考えて
もういいやこんな会社って思って荷物をまとめてサッサと帰った
次に行った会社の試験は実にマトモ
次どころかどこの試験でもちゃんとプログラミング言語の仕様どおりの構文で
すげえ安心できた
「もしかしたら現実の仕事ではあんなワケのわからん構文なのか」
って不安になって、もしそうなら俺はプログラマにはなれないって思っていたから
お前ら日々の仕事時間どのくらいなのか
自分は８時間＋サービス２時間 瑕疵担保期間の人件費は見積もりに入れたほうがいいの？
先輩はバグ無しを前提にしてるから見積もりに含めないって言ってるんだけど
実際には毎回なにかしらバグが出て10人日程度消費してる >>37
普通含めるだろ。
もしバグが出たら先輩に無給で対応して貰え。 俺はバグなしで進んだ前提で見積もった工数に統計的なバグフィクス工数積んでる >>37
会社の費用の分類ルールによるんじゃない
開発期間と別だから別にした方がいいと思うけど
一定品質でないような会社なら個別に見積もった方がいいかもね 【サムスン勝利！】「ギャラクシーS8」シリーズがアップルの「iPhone8」を抑え、米国の消費者評価でトップに立った
http://www.chosunonline.com/site/data/html_dir/2017/10/18/2017101800683.html
米コンシューマー・リポートがこのほど、米国市場で販売されるスマートフォンを評価した結果、
ギャラクシーS8とギャラクシーS8プラスが小数点の差で1、2位となった。
昨年上半期に発売されたギャラクシーS7もアップルのiPhone8プラス（4位）、iPhone8（5位）
を抑え3位に入った。iPhone8プラスとiPhone8はバッテリーの使用時間で評価が伸び悩んだ。
ギャラクシーS8シリーズは26時間の使用が可能だ。
凄いぞサムスン！
今時、喜んでiPhone買ってんのなんてチョッパリ猿くらいじゃね？ >>19
そりゃ自己満足の領域だよ
正解を写経させた方が速いに決まってる 入社試験を準備した！って、上が言うから
試験内容確認したら不具合あったから指摘したな。
しかし、受けた人達からは何も質問されなかったらしい。 >>43
上手く早く学習するには何が最適かって話だから正解如何は別の話だし、感覚的だから安易に求めんなよ
1.サイクロメティック
2.行数少ない方
3.yagni,kiss,oaoo,pie,dry,cqs全部
大体工数とのバランスで不正解を敢えて選ぶことも多々あるしな >>44
テスト不能なあらゆるドキュメントはゴミ
入社試験問題も仕様書も設計書も全部ゴミだ >>47
ロックンローラーがプログラマになったのか？ 報告連絡相談ができないとテストも満足にできなくて叩き出されるぞ テストで仕様や手順の知識つけて
慣れてきたらデバッグと修正させられて
ずるずると開発に呑み込まれる うちはテストから初めてプログラム全くかかずに上流に行くよ
プログラミング最初からできるやつは上流に回さず永久にプログラマ ありがとう
開発やってたんだけど、ある程度終わったからテストに回された >>19 体験を通した方が学びはいい
>>42 正解を写経させた方が速い
>>43 正解とは？
>>45 学習するには何が最適かって話だから正解如何は別の話
この流れ仕事でもよく見る。
おまえらならこいつらの会話は、どこに着地させる？ ジャップ相手にはサボってやれば良いんだよ
ささやかな復讐さ テストって処理の中身みないと何を引数に呼び出せば
いいかわからなくないし
ＤＢのどこの値が変わったとかもわからんよね 開発ルールを無視して開発してる人がいて何度注意を受けてもその場を取り繕うだけでしばらくするとまた再発する人ってどう対応したらいいの？
何度注意しても改善してくれないからこないだ本人の主張を聞いてみたんだけど、自己都合の屁理屈(言ってみたらワガママ)ばっかり言うから本当に困ってる 開発ルールってどういうのか
具体的な情報が一切ないからなんもわからん クソみたいに能力が高くない限り、上に言って退場してもらうしかないだろ
今は人材不足だから追加が望めるか分からんし、聞き分けがいいからと
いって能力が十分とも限らんけど >>63
仮定して回答してやる程度のことも出来ないなら書き込まなきゃいいのに
底が知れてると言うかお前仕事出来なさそうだな 開発ルールに忠実に上流が困るように丁寧に書くのが一流ってもんだよ
少しジャップにはお灸を据えてやらんとな プログラマーってうまくいかない時悲しい気持ちになっちゃうの？ ならない
視線が硬直し感情が鈍磨して無の境地になる >>61
人を入れ替えれば解決するけど、
デモデモダッテとか言うんだろ？ interfaceを勝手に変えるのはやめて頂きたい interfaceで独特なやつは嫌い
accessとかな
ジャップは大好きみたいだが >>61
無視されるルールは生産性や品質を下げている可能性が高い
屁理屈のわがままというがもしかすると問題の本質を理解してないだけかもしれんぞ
とりあえずそのルールの内容がわからないとどっちが悪いとも判断できんな >>60
処理内容を見て書くテストもあるっちゃあるけど
普通はテストが先に書かれるので処理内容は関係ない
DBアクセスのテストはDBに入ってまで調べない
DBはただの実装であって仕様ではない
ホスト側言語から見てエンティティのCRUDが成立しているかどうかをテストすれば十分 >>77
俺も1メソッド10行は無視したなｗ
ぜってー何もかけねーから >>79
全てのメソッドは3ステートメント以内で書ける >>80
かけたとしても面倒くせーよ
だって本来150行で1メソッドで書ける処理が15個もメソッドできるんだろ
把握するのが面倒臭い さらに1クラスにつきメソッド5個までとかくだんねー制限まであってさらにイミフ
するとたかが50行の処理でクラス作らなわからんのかお前はと
ちなみに1メソッド5個も華麗にスルー
しかも、既存のコードも明らかにやってねーし >>63>>64>>70>>71>>74>>77
レスありがとう
基盤に基幹システム向けに用意した非公開の機能があるんだけどそれを一般機能の開発に使われて困ってる
非公開の理由が、使い方が特殊(というか一般向けに作ってないから)正しい手順で使わないと期待してる結果にならない
事情を知らないコーダーが安易にソースの流用をするとまず間違いなくシステムエラーを起こす
こういう事態を招く恐れがあったから非公開で禁止にしてるのに、勝手に使うから案の定色んなところに派生が出来てる感じで収集がつかないことになってるんだよね
彼いわく
「中身を理解せずに勝手に流用するからそんなことになる」って言い張ってるんだわ
で、やめさせたいんだけどどうしたらいいと思うよ？ >>83
つまりそいつ一人のワガママのせいでプロジェクト全体のソースの流用性を落としてるってこと？
生産性にも関わる話だしそれは普通にアウトだろ >>83
派遣だったら派遣元にクレームつけて人を代えさせる。
自社の社員だったら、上司にそいつがいる損害を報告して別の部署に異動して貰うことにする。 ｯﾂ㍊㍊㍊㍊㍊ﾐｯ
ｯﾂ㍊㍊㍊㍊㍊㍊㍊㍊㍊ﾐｯ
ｯﾂ㍊㍊＞'"´ __,, ￣｀丶㍊㍊ﾐｯ
ｯﾂ㍊ｼ'´ _ ,ニ_二 三‐｀､u｀ヾ㍊㍊ｯ
. ﾂ㍊彡' ,'U_,..-ｭ￣ fﾆ三三ﾐヽヾ㍊㍊ｯ
ﾐ㍊彡! :丶/|::/!!:. :. .:ミ;＝｀ﾞ' ヾ㍊㍊',
㍊㍊ﾘ ,'f r",,ゞｨ_, i :. ヨ ●ヾ ',㍊㍊!
㍊㍊{ ' ｲ●ﾉ"´,:,! ' "'ーﾍヽ Nlﾊ⊥
㍊ﾐﾘﾊ .: '""_,.ノ,' ,. }、U tf{´i, l|
. Wﾘ小! .: ,ゝﾞ･ ･'' ヽ ｀!) Vl
ゞ干ﾐ} : U / _J＿ 丶 }'´ / 俺を支持しろ！
'､Yヾ :. （ ﾄｪｪｪｪｪｪｲ ） / ノ
ヾ.f'､:.:. ヽ｀ヽ⌒⌒ｼ /l'´ﾊｧﾊｧ
ヽ._）:.:.、 U ﾉ:::ﾉ:ノ ,. ' l
ﾄi､ヾ:. 、（＿ノ∪_,. - ' ｜
/^ヾ!､丶 ｀ U''"´ |
／ヽ 丶、 ｀¨¨´ ト､
／::::::::::丶、 ｀丶、 丶 | rゝ、 // こういう意味が無い例外処理をするのは勘弁してくれ
try
{
// 何らかの処理
// ネストが増えるだけだよ
}
catch (Exception)
{
// ここでせめて何かしろよ。慣例で catch だけしてんじゃないよ
throw;
}
// これは更に性質が悪い
try
{
// 何らかの処理
// ネストが増えるだけならまだしも
}
catch (Exception ex)
{
throw ex; // ここでスタックトレース消えるんだよ
} >>88
c#ならそうだね
Javaだと少し仕様が違う >>88
Javaやってたやつはc#で下の書き方する可能性大 >81は馬鹿で素人の典型だな
素人の寄せ集めで始めたプロジェクトのソースなんか１クラスにほぼ全部の処理書いてて嫌悪感が凄いからな
素人はこういう順番に何してるかわかるような丸ごとソース（爆）ｗを好むんだよな馬鹿だからｗ
機能追加で俺が参加して処理単位ごとに関数分割してるだけで今度は素人が嫌悪感を感じるらしいｗ
メリットが全くわからんのだろうな馬鹿だからｗ >>88
Javaでこの記述でエラー処理なった時に数百倍の速度ロスになるとこの掲示板で聞いたけど
それから使ってみた経験上、体感的に全くそういう速度ロスはないようだった >>82
>ちなみに1メソッド5個も華麗にスルー
しかも、既存のコードも明らかにやってねーし
そりゃそーだろうなぁw >>93
インライン展開されないことによるロスとか？そこまで大きいとは思えないけど >>93
javaが遅かった時代の話じゃないか？
確かに例外作成はそこそこコストかかるけど >>88
finally足すときにインデント壊したくないんじゃないの？ JavaやCの例外機構は破綻してる
最近deferとかusingブロックとsurpressedExceptionの仕組みでやっと解決された
天才どもが束になってとりくんでたのに
何十年もこんなことでつまづいて来たとか信じられん ■ このスレッドは過去ログ倉庫に格納されています
