アカウント名:
パスワード:
ソフトウェア開発を生業としてるはずの会社なのに、プログラミング初心者とかパソコン初心者とかそんなのばかりがやってきます。
むしろ経験の無い人を採用したがる企業が多い時代がありましたが、今はそうではないんですかね？
# 変な癖が付いていると困るからだそうで…
当人はJAVAでオブジェクト指向プログラミングをしているつもりだけど、メソッドへのデータ受けわたしにグローバル変数を使う。 とか、 既存のクラスとか関数とかfooのソースをよそからいただいてきて barという機能に換骨奪胎したときに相変わらず名前はfooのままで使ってるとか、そーゆー癖がついているのは？
「僕は自宅のPCでもPASCALコンパイラを持ってるくらい熟練してるんです」と自慢してる奴が、1000行のメインルーチンにだけ(ユーザ関数/ユーザ手続き一切無しでgoto使いまくり)ってプログラミングをしてそれでいいと信じ込んでるとかいうのは？
コンパイルエラーが出なくなったらプログラムは完成だと思ってるとか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
建前はそうですが (スコア:0)
お手軽じゃない言語だと、1年生の必修のプログラミングの単位が取れなくて卒業できない学生が多発してしまう。 論外なレベルのプログラミング能力で情報系学科の卒業証書を渡して良いものか、忸怩たる思いがありますが。。
Re: (スコア:0)
駄目じゃないですかね？
もっと真面目に考えて下さい。
まあ使えない人間は、ただそれだけで去っていきますが。
# 中小企業にはできない人間を養う余裕はないので
Re: (スコア:0)
ソフトウェア開発を生業としてるはずの会社なのに、プログラミング初心者とかパソコン初心者とかそんなのばかりがやってきます。
＃そんなひとでも数ヶ月「講習」をやれば派遣社員として買ってくれるところがあるんでいいんですけどね。
＃＃そうやって育てられた(?)新人のうち、数年後どれだけこの業界に残っているかが心配
Re: (スコア:2, 興味深い)
むしろ経験の無い人を採用したがる企業が多い時代がありましたが、今はそうではないんですかね？
# 変な癖が付いていると困るからだそうで…
Re:建前はそうですが (スコア:1)
「変な癖が付いてるのはお前のほうだ！」
と先輩に言いたくなったことも。
そら３０～４０年前のプログラミングスタイルからすると、
現在のプログラミングスタイルは「変な癖」に見えるじゃろうて。
Re:建前はそうですが (スコア:2, 興味深い)
当人はJAVAでオブジェクト指向プログラミングをしているつもりだけど、メソッドへのデータ受けわたしにグローバル変数を使う。 とか、 既存のクラスとか関数とかfooのソースをよそからいただいてきて barという機能に換骨奪胎したときに相変わらず名前はfooのままで使ってるとか、そーゆー癖がついているのは？
「僕は自宅のPCでもPASCALコンパイラを持ってるくらい熟練してるんです」と自慢してる奴が、1000行のメインルーチンにだけ(ユーザ関数/ユーザ手続き一切無しでgoto使いまくり)ってプログラミングをしてそれでいいと信じ込んでるとかいうのは？
コンパイルエラーが出なくなったらプログラムは完成だと思ってるとか。
Re:建前はそうですが (スコア:1)
何年かプログラミングをしていると、数年前のコードを見て「ぅは、センスなさ過ぎ」ってのを感じるのは、そーゆーあたりですよね。
コーディングテクニックだけを見れば白紙からの方がいいかもしれませんが、付随して身についているコンピュータ関連のあれこれまで含めて考えると、白紙からは全然ダメダメって気がします。ISOイメージ焼けないとか、もうね、消えてくれ。
Re: (スコア:0)
そして、そういう変な癖がついたベテランがプログラミング未経験な新人を教育するから、そのチームで作られてるコードは Javaなのにほとんど全部の関数が staticになってるとか、変数名が szなんとかになってるとか、変な癖が継承されていくことに。
新人ならまだ矯正できるけど、ベテランになってしまうと矯正するのは難しいみたいですね。業務に追われて新しい技術を勉強する暇もなくなるし。
＃自分は新人に教える際に「俺のJavaは、C/C++の癖があるからあまり参考にするな」とか言ってるんだけど、
＃「そんなこと言ったら、新人君が混乱するでしょ」っていつも怒られてる。
みんな絵を描こう (スコア:0)
それが新人君であるか
逆に雇用しようとする企業のほうがそう染まってしまってるか、は、
ケースバイケースであり、
両方アルんだよね。
>当人はJAVAでオブジェクト指向プログラミングをしているつもりだけど
絵を描くといいと思う。
メモリ内のプログラムというかデータの「かたち」を
絵で表現するのね。
プログラマに絵を描かせれば、
どういうデータ構造を扱おうとしてるのかが
見えてくるし。
逆に教えるときも、
「こういう構造にするといいよ」
ってのを
Re: (スコア:0)
私は測定器制御のプログラムを書くことがあります。
変数は基本、グローバルです。名前さえかぶらなければ、
スコープで悩むこともないので。
オブジェクト指向なんて、くそくらえです。
癖として定着してしまうとまずいかも知れませんが、よほど
リソースの制限が厳しい場合でなければありなんじゃない
ですかね？
新人を調教するな (スコア:1, すばらしい洞察)
あ。これだよこれ。
問題は一方的に混乱「だけ」を嫌うことなんだよね。
つまり新人君にとって
師匠は二人より一人のほうが良い、
と言ってることになるのだ。
それは「育てる」ではなく「調教する」だ。
獣なみの芸しか仕込めない。
そういう姿勢の企業は多いようだし、
企業じゃなくてもそういうこと言う了見の狭い奴は結構居るんだよね。
社員を育てる気があるなら、「混乱」はさせるほうがマシだ。
＃「新人君は必ずどっかのFOSSプロジェクトに参加し鍛えられてこい」といいたくなるのでAC
Re: (スコア:0)
＃そういう場合でも、何とかしてローカル変数をエミュレートしようとするかもしれませんが。
グローバル変数の弊害ってのは、他人がメンテナンスする際にある場所で変数の値を書き換えたらどこにどういう影響が出るのかを注意深く解析しないといけないなどですね。時間がないからとか言って複数人でメンテナンスとかすることになったらさらに大変です。
Re:建前はそうですが (スコア:1)
Re:建前はそうですが (スコア:1)
しかしその類は、真っ新から教えたって使い物にならないかと orz
Re: (スコア:0)
require "棒読み"
def p(str)
棒読み(str)
end
case その先輩の40年前のスキル.to_s
when /lisp/i
p "むしろ今の時代はじわじわとLispに向かってるので、ちょうどOKなのでは？"
when /fortran/i
p "今の時代はじわじわとFortranから離れていってるので、かなり厳しいでしょうね。"
end