webのばかりの人って他の開発の現場も通用しますか？

基盤よりのJavaの開発経験は、5年くらいあるのですが、久しぶりにWeb系の現場に
入場して、うまくできず、経験がないと思われています。
恐らく、Web系の現場の人は、若いので、Web系の現場しかなく、Webの系の現場は
似たような現場が多いので、そんなことも分からないのかということで、経験年数が少ないと
思われたようです。
例えば、Web系の現場は打鍵が難しく、エラーが発生するとデバックをよくするので、
デバックが得意になるようですが、自分が開発していた基盤よりのアプリはLinux上で動いているため
リモートデバックになり、やりづらいし、エラーはソースで見極め、デバックは最終手段であったため、デバックもあたふたしています。また、一気通貫してソースを通るため、テストクラスを作って修正した部分だけ通すという必要がないです。Webは、打鍵をして、やっと、そのソースに到達するので、テストクラスを使った単体をよくやっているので、Junitが得意なようです。
自分のいた現場は、逆にWeb系しか経験がない人が入場したことがあるのですが、マルチスレッドプログラミングや、プロセス間の排他制御、ミドルの部分(OSの機能を利用する部分)が分からず、共に半年くらいで退場しています。で、思ったのが、Web系にいた人って他の開発の現場でも、うまくやっていけるのでしょうか？どうも、Webは製造よりも仕様自体(設計)難易度が高いようです。

No.4 回答者： don_go 回答日時： 2017/08/30 02:04

＞ところが、どっこい。

最近、現場を変えましたが、
これは、質問の中での「Web系の現場」とは別の現場ですか？
同じだとすると

＞久しぶりにWeb系の現場に
＞入場して、うまくできず、経験がないと思われています。
↑と
＞自分は、Javaの製造経験が3万ステップ以上あるので、客先面談の書類は
＞ほとんど通ります。
↑とでは、矛盾している様に感じます。
面談は通ったけれども、経験がないと思われているという事でしょうか？

No.3 回答者： tknakamuri 回答日時： 2017/08/30 01:05

>ところが、どっこい。

最近、現場を変えましたが、
>今は空前絶後の人手不足なんで
>、Junitよりも、PGの場合、どれくらい製造経験があるかが重要です。

日立系やIBMや金融系だと、自動でco/c1通してカバー率提出しないと
そもそも相手にして貰えないです。

Javaだけでなく、HTML、Javascript、cssも自動テストを要求されます。
顧客は提出された自動テストで自らも品質を確認します。そうして始めて
工程完了の承認が貰えるのです。

これが今のまっとうなやり方なんですよ。基盤系は大体10年ほど前から
Web系はここ3年くらいですね。

貴方は今の職場が合っているのかもしれませんが、
日々品質向上に努めているwebエンジニアを馬鹿にして
欲しくはないです。

今エンジ二アに求められているのは、コーディング経験より、
品質保証をいかに堅実に実行するかだと思います。

junit覚えただけではこれは達成できません。設計レベルでテストを前提
にしたコーディングを覚える必要が有ります。
製造経験とは無関係に普通半年～ー年くらいは苦労します。
ひと目コードを見れば慣れて無いのがすぐわかりますから
経験者には簡単に見透かされますよ。

あまりやったことなければ素人扱いは仕方ないでしょう。
一度しっかりやってみることをお勧めします。

この回答へのお礼

ご回答ありがとうございます。

＞＞日立系やIBMや金融系だと、自動でco/c1通してカバー率提出しないと
そもそも相手にして貰えないです。

HISOLで働いたことありますが、確かに、少し厳しい印象がありますが、現場によって変わりますよ。

>>今エンジ二アに求められているのは、コーディング経験より、
品質保証をいかに堅実に実行するかだと思います。

それは、あなたが、変りがいるような簡単な現場でしか働いことがないからでしょう！
どんなに、あがいても、作れたもん勝ちです。そういう現場あります！経験25年の人が製造できなくて
泣いている現場です。

＞＞製造経験とは無関係に普通半年～ー年くらいは苦労します。
人売りの現場で働いているからでしょうね。
CTOCで一回働いてください。考えが古いです。

異常です！！

お礼日時：2017/08/30 20:52

No.2 回答者： tknakamuri 回答日時： 2017/08/29 07:50

なんかズレてますね。

web系でjunit等の単体が盛んに行なわれるようになったの
比較的最近。前はテストクラスではなく、本物の画面からの打鍵ばかりでしたね。

モックや各種ツールが整備されて、打鍵以外でも比較的低コストで単体が
できるようになったのは比較的最近のことです。

で、単体テストとデバッグは別次元の話だと思うのですが、どうも話がまぜこぜで
よくわからんです。単体テストは仕様との差異を検出するツールで、結合以降の仕様変更に対抗する必須ツールです。完成させておけば、人知を遥かに越えた確実さとスピードで
仕様変更の漏れを検出します。

で、基盤系なのに、モジュール単位の単体をやってこなかったような記述が
ありますが、もしそうなら、そういう人は、今では普通門前払です。

前いた職場が異常だったのでは?

やり方を少し考え直した方がよいでしょう。

この回答へのお礼

ご回答ありがとうございます。

前いた現場の初期のころは、Junitを使用していました。
ただ、人手不足で長期入場する人が多くなるとJunitだと時間がかかり過ぎるので、
デバッグモードで通せばよいという流れになりました。

>>で、基盤系なのに、モジュール単位の単体をやってこなかったような記述が
ありますが、もしそうなら、そういう人は、今では普通門前払です。

ところが、どっこい。最近、現場を変えましたが、今は空前絶後の人手不足なんで
、Junitよりも、PGの場合、どれくらい製造経験があるかが重要です。
Junitはツールなので、使い方は3日もあれば覚えられるでしょう。
自分は、Javaの製造経験が3万ステップ以上あるので、客先面談の書類はほとんど通ります。

お礼日時：2017/08/29 21:49

No.1 回答者： don_go 回答日時： 2017/08/24 22:57

他の系統の開発現場で上手くやっていけるかどうかは、各人の能力・適性及び

その時点での力量次第としか...
それと、作業分担として、何の作業を割り当てられるか。
業務毎に作業の種類と特徴が異なっていても、共通している部分は有ります。
例えば、ビジネスロジックやデータベース処理は、Web系にもOA開発システム
にも有るので、同様な部分の作業を分担させれば(できれば)、とりあえずは
上手くやっていけるでしょう。
＃C言語の開発経験が有るからと、Java言語のWebシステムの開発に参加して
＃ビジネスロジック部分の開発を担当した経験有り。