  |
はてなキーワード: オブジェクト指向とは
関数型プログラミングにある程度なれているstaticおじさんだけど
オブジェクト指向なんて今どき使う意味ないし。バインディングとビューモデルとかださくて、ほかはまあ、普通使っていればわかるだろうというかなんというか。
マネジメント層の話が出てきた割に、その後にマネジメントの話は出てこない。最後に1文あるだけ。
オブジェクト指向の概念が身についてないベテランも結構いるってことは、
オブジェクト指向の概念が身についてなくてもベテランでいられるわけだ。
そういう状態で仕事を続けると何が問題かって、若いメンバーに敬遠されるとか社畜だとかその程度のことしか話にてでこない。
プログラミングという言葉がアフィブロガー御用達になって、SNSでプログラマーを名乗るのが憚られる感じの昨今。
プログラミングを勉強すればフリーランスで一生困らないみたいなこと書いてあるけど、そんな夢のスキルじゃないよ。
それなりにベテラン()を見てきたけど、結局はマネジメント層になれなければ会社にしがみつくことになる人が多い。
これはvueかReactか、javaかRubyかみたいな話じゃなくて、もう少し基本的な部分。
例えば大きいのはオブジェクト指向とクラス/インスタンスの概念。
他には、ガベージコレクタ、例外処理、マルチスレッド、デリゲートやラムダ式、非同期処理、バインディングとビューモデル、イテレータ、null安全。
今プログラミングを学んでる人には当たり前かもしれないけど、これらは十数年かけて徐々に当たり前になっていった。
ITバブルでブイブイ言わせていたけど、これらをうまく扱えないベテランは結構いる。
固定長メモリとポインタとmemsetで全てをまかなってきた層や、静的なモジュールで全部の画面を作ってたVB屋とか。
若いころは勉強すればいいと思うだろうが、理解はできてもそれを流暢に使いこなし適合するのは意外と難しい。
プログラムの中でその人の担当箇所だけいまいち読みにくくて、取り回しの悪いものになってしまう。いわゆるstaticおじさんというやつ。
これはベテランのイラストレータやシナリオライターが、デッサンや構成力はあっても、なんか古臭いものが出来上がってしまうのに似ている。
こうなると若いチームメイトや新しいプロジェクトからは敬遠される。
もちろん、COBOLの案件が未だにあるように、レガシー資産を利用した仕事で腕を振るえる場所は結構ある。
ただそういった環境は既存の人材・企業にがっちり掴まれてることが多く、後から見つけて入り込むのは簡単ではない。
ほとんどの参加者は、コンピュータサイエンスなどの学位を持っているわけではなく、国内のSIerなどでパソコン弄りをしてるだけのただのオタクです。
彼らの大半は、まともなコードが書けるわけでも、インフラ等の保守ができるわけでもありません。
非エンジニアの連中に到っては、流行りのIT用語を援用したポエムを作ってるだけであり、話を聴く価値はありません。一部の技術のある人たちも、そういう人たちに合わせて話をしています。
よく、「プログラマはつねに最新技術を学ばないといけない」などと言われます。
これはある意味正しいのですが、この主張が指している対象は、新しいツールやフレームワークの単なる「使い方」であって、根本理念ではないのです。
実際のところ、ソフトウェア技術なんてものは、コンピュータの黎明期から大して進歩していません。進歩しているのはほぼ全部ハードウェアの技術です。
例をあげれば、「オブジェクト指向」なんてものはC言語ができた時点で既に確立されており、有能なエンジニアはみんな知っていたのですが、90年代に入りJava等が普及すると同時に量産型のコード書きの間でにわかに流行りだしました。
エンジニアが第一義的に学ぶべきなのは、コンピュータサイエンス全般の基礎であり、それを欠いた人が流行りに飛びつくのは虚しいだけです。
本人がポエムつってんだから、ポエムでいいじゃん。そんなの人それぞれだろ。オブジェクト指向のカプセル化だなんて深淵な概念だし、この問いなんて哲学的であるとさえいえる。だいたい、カプセル化とは「データとそれを操作する手続を一つにして，オブジェクトの内部に隠ぺいすること」である、なんていったら、怒られるんじゃないか。隠蔽ってなんだよ。トートロジーかよ。この問題に正解したとしてカプセル化を使いこなせるわけでもないし、分かった気にさせるこけおどしでしかない。そういう霞みたいな文章をポエムっつんだよ。
※ ただし一般的にはポエムという語にはそういう下卑た意味合いはないと思います。 悪い意味でポエムという言葉を使うのは確かによくない風潮だと思うので今後は控えるようにします。俺は元増田ではありませんが。
情報処理技術者試験の資格を取っても実質的に得るものはありません。「実質的に」というのは、技術者としてのスキル向上に貢献するということであり、「報奨金が貰える」とか「履歴書に書ける」などの技術と無関係なものを含まないということです。
なぜ、情報処理技術者試験が役に立たないのかと言えば、出題内容が表面的な知識問題に極端に偏っており、本質的な理解を問うていないからです。たとえば、オブジェクト指向の三要素に「カプセル化」「継承」「ポリモルフィズム」がありますが、これらを御題目のように唱えていても何の意味もありません。しかし、情報処理技術者試験ではこれらの用語さえ覚えておけば、しっかり点になります。
https://www.fe-siken.com/s/kakomon/19_haru/q42.html
こんなのは単なるポエムであり、これが解けたところでコードが書けるわけでも、良い設計ができるわけでもありません。
数学で喩えれば、「加減法」とか「代入法」のような用語を暗記して、具体的な連立方程式の解き方は分からないようなものです。
ひどい問題は挙げればキリがありません。
https://www.ap-siken.com/s/kakomon/22_haru/q44.html
図の名称を答えさせる問題。図を読み取らせる問題なら、まだ理解できますが。そもそも、UMLなど別に技術者として知っておくべき知識でもありません。
https://www.fe-siken.com/s/kakomon/23_aki/q50.html
これも、こんな分類自体、覚えたところで何にもならないわけですが、その用語を答えさせる問題。いかに、この試験がエンジニアリングやプロジェクト管理の本質と関係ないかがよく分かります。
極めつけはこれ。
https://www.fe-siken.com/s/kakomon/17_haru/q52.html
地方の公立中学校の定期試験レベルのひどい問題です。出題者は、1だの2だの4だの7だのといった数字と語句の対応を覚えることが重要だと思っているのでしょうか。
つまり、ある種の発達障害ではない意識高い系ポエマーを認定するための試験であり、そもそも技術者のための試験ではないということです。あとは、中小企業診断士などを受ける人が試験免除を獲得するためとか。
そもそも、コンピュータやプロジェクトマネジメントの技術を、資格試験で勉強しようというのがピントがズレています。それらは既に良質な解説書が豊富にあるのだから、それで勉強すればいいのです。
放課後、親に無断で学校の先生に精神科のような場所に連れられ、「それは鬱ではなく、思春期による一時的な悲しみではないですかね」と医者に言われてから10年が経った。
あの頃から相変わらず、成長していない。
高校での成績は上位10%に入っていて、4年で卒業することが難しいと言われた大学もなんとか4年で卒業できたので、決して頭は悪くはなかった。
ただ、人との会話は不得意で、友人を作ることはできなかった。
でもそういった人々はこの世にある程度はいて、みんなどこかで働けているからきっと大丈夫だと自分に言い聞かせていた。
面接はことごとく落ち、大学卒業後も内定を貰えずそろそろ死のうかと検討した矢先に運よく入社したところは、後になって知ったが定着率が低い会社だった。
そこで気付いてしまったのは、自分がエンジニアに向いてないどころか、社会人に向いてないことだった。
一通書くのに最低でも30分-1時間はかかった。（相場が分からないけど長い気がする）
顧客のメールを読んでも、内容がふわっとしていて意味が理解できないことがあった。
相手が何を言っているか分からなかった（要求だったり、用語だったり）。
分からないことをそれとなく伺ってみたら「お宅の会社はその程度なんですね？分かりました」と言われ、会社の信用を下げてしまった。
その後、その顧客とのメールに怯える日々が続き、毎日嘔吐した。
あんなに自信があったプログラミングだったのに、小規模システムのコードでさえ想像を超える入り組み具合で読めなかった。
というのも、フレームワークといったものにも触れたことがなかったり、インフラ側は全く学んでこなかった。
「オブジェクト指向」というような概念的部分はテストの為に暗記したことはあれど、実際に言語の特徴や構造の違いを理解できたことはなかった。
フロントエンドとバックエンドの違いもよく分からず、自分が得意だったものがなんだったのか分からなくなった。
何よりも、自分には新しい知識をインプットする力が驚くほどになかった。
最終的には、自分のキャパを超える残業や上司による罵詈雑言で数秒に一度頭がまっしろになって仕事に手がつかない状態になり、辞めた。
能力のある社員もすぐに辞めていることから、会社にも改善すべき点はあったのだろうが、それが実際の問題ではなかった。
自分の能力の無さはどこに行っても通用しないんだろうな、ということが分かってしまった。
スポーツをしていた人が採用されるのを話に聞くが、その理由が初めて分かった。
コミュ力も体力あるし、ちょっとやそっとのことでは根を上げないからだ。
自分はコミュ力もないし、メンタルも弱く、自己肯定感もなく、唯一自信のあった学歴や技術力も実際には意味をなさなかった。
私の考えはあまりにも浅はかで、高校や大学でしっかり勉強をしていれば、あとは会社からのサポートで仕事をこなせるようになると思っていたことだ。
一応自分なりに努力はしたつもりだった。勉強も、精神的な面においても。
在学中や就業中に精神科に通い、鬱やPSTDと診断された。いろんな薬を試したことはあるが、薬の副作用の眠気や吐き気で通常時より無能になったので向いていなかった。
カウンセラーは話を聞いてくれることは有難いが、危険人物として扱われたりしたことがあったり、何の解決にも至らないのでお金がもったいないな、と個人的に思った。
大学を卒業して引きこもっていた頃、会話の練習をするためにひきこもり当事者会的なイベントに参加した。
それぞれ背景は違うが、頑張って外出をして知らない人と会話してみよう、と集まった人たちは皆、優しかった。
不審者のようにそわそわしてしまってもいじめられることはないし、互いが傷つくことのない当たり障りのない会話ができたし、人とゲームができて楽しかった。
同じ境遇にいる方たちと過ごして一番に感じたのは、自分はやはりこちら側の人間なのではないかということ。
学校やインターネットで人と会話をして友人を作れるような人や、仕事をこなせている世間一般の人たちのようには到底なれない。
社会不適合者が運よく社会復帰することができても、精神が弱い上に周りに溶け込めない為、続きはしない。
少し前にとある記事に「生涯バイトなんて、将来のことを考えているの？」というニュアンスのブコメがあったが、どんな形態であれ生きる為に働き続けてきちんと自立できている人がどれだけ偉いことか、と思う。
もしいつか真っ当な人間になれたら、あの時精神科に連れてってくれた先生に御礼を伝えようと思っていたけど、未だに連絡が取れていない。
生活保護の条件にも当てはまらないから、貯金が尽きたら死んでゆくと思う。
10年超のプログラマやってるものだけど自分の成長過程を書いてみよう
・プログラムによる既存業務の効率化は目に見え易いので、非効率だった多数の人材と自分が匹敵する能力を持っていると勘違いしやすい点。
・オブジェクト指向やプログラミング自体に事象の抽象化や細分化、項目化といった思考が必要で、物事の数学的把握が必要な点。
・効率化によって職を失う人間はこの先も増えるが、自分達の仕事は減らないだろうという漠然とした思い込み。
・定量的、数学的把握は説明がしやすく、業務やプレゼンへの応用は楽だが、数値から漏れた部分や把握できないイレギュラーは無視しがちである点。
４つ目は敢えて言うなら文系の素養が必要で、これを持っている人間が一流。プログラムにできない（し辛い）部分を把握するプログラマーは自分の仕事の無意味さを認める事になるが、これを抱えたまま仕事をするのはメンタルの面からも大変。他に挙げるとすれば、専門用語が多く仲間内で親交をする傾向が高いので外部からの目に気付き辛い点、一種の官僚化だろうか。
それから６つ目(笑)と言ってもいいかもしれないが、プログラムその物の社会的意義まで頭の回っていない人間が多い印象はある。業務効率化による収益増は当然、自分の給料に反映されるが、そこから漏れた部分の責をプログラマは問われない。
一例を挙げれば、（文書に限り）郵便事業が縮小による情報伝達の効率化という恩恵は万人が受け、効率化に伴う収益は電子化業者が郵便事業者と分け合ってきたろうと推測されるが、電子化業務従事者は封書や葉書の印刷業者や納品業者、インク製造業や製紙業界までに頭を回す事が出来ない。もっと言えばパルプの精製や原料の輸出入にも関わり、産業としてはまさしく革命が起きていると言っても良いが、それを自分の仕事に係わる物だと捉えているプログラマーはまずいまい。
負の側面として電子文書は膨大な労力をかけてフォントや外字の整理を今も強いられ、ファイルフォーマットや送受信データ形式の細かな不整合を放置したまま進んできたが、それに関して電子化業務側からの社会への問いかけといった視点はなきに等しい。加えて、数値化不能な（文書に限る）郵便業務の益は、配達員と顧客のコミュニケーションや地域事情の把握、高齢者福祉に関わる面にまで及ぶのであり、それをモニターの前にいるプログラマが担うのは不可能である。
二行目に関しては特権意識とは全く関係がなく、言語による思考を行っていない人間に言語で話しかけるのが間違っているのではないか、と考える。
絵描きや作曲家の例を挙げれば理解は容易である。これらは頭を使っている、いない、の問題ではなく使い方が違うだけの話だ。
そもそも、頭を使うの対義は身体を使う、になるのかしれんが、ヒトがどちらか一方だけを使うなど有り得ないし、その活動の比重が脳に偏っていれば偉い、と言うのは思い上がりである。
プログラミング言語を印象批評している記事に触発されて、自分も印象批評してみようと思う。
JavaScript以外にもブラウザ上でぐりぐりするのにはJava AppletとかFlashとかSilverlightとかいろいろあったけれど、結局標準化を成し遂げたHTML5に淘汰されちゃった感じがする。LiveScriptからJavaScriptに改名されたり、規格を話すときはECMA Scriptだったりといろんな別名を持つ。一応、プロトタイプベースのオブジェクト指向言語なんだけれど、それを意識してコードを書く人がどれくらいいるかは謎。
Pythonは小さいコードを書くのには楽だけど、これで大きなコードを書くと思わぬ変更で思わぬことが起きるのでつらい。しばらく使うとPythonイヤイヤ病にり患し、goを使うようになるらしいとか、ならないとか。pythonで大規模なコードを万一書こうと思うなら、カバレッジが高いテストを書いてくれと思う。
Javaは初期のころオートボクシング / アンボクシングもなく、ストイックなオブジェクト指向言語だった記憶がある。ただ、staticを多用してオブジェクト指向とは程遠いコードも簡単に書けるので、Javaで書いているからと言ってオブジェクト指向だと思うのは禁物である。
PHPはWebネイティブな言語で、初期のころHTTP POST/GETなどで渡された変数がそのままプログラム中に出てくる機能や初期化していない変数を最初に使うと空文字列あるいは0で初期化するという機能があった。また、文字列と数字を臨機応変に切り替える機能もあり(今もそうかは知らん)、数字と文字の比較を比較演算子(==)でシームレスにできる。パスワードチェックみたいなコードで===ではなく、==を使っているとPHPを知らないバカ扱いされる。
C#はHello Worldくらいしか書いたことないから知らん。monoのような互換環境があるのは知っているけれど、わざわざPC Unix上でmonoを使う気分にはなれなかった。
C++は黎明期に使った感じと、C++11以降に使った感じが驚くほど違う言語。今はかゆいところには大抵STLで手が届くし、autoを使えばイテレーションで腱鞘炎になることもない。PC Unixにも最初から環境がインストールされているか、簡単にインストールできるので毛嫌いせず使うとよいと思う。
Rubyはぎょっとする変更をよくやるというイメージ。これで書かれたプログラムを長年愛用してきたが、ぎょっとした変更を入れられて動かなくなったのでgoで書き直した。その点ではpythonも3でおいていかれたので嫌い。
TypeScriptは書いたことないから知らない。JavaScriptだと大規模コードを書くとつらいのでTypeScriptを使おうという人がいるのは知っている。大規模なコードを書くとしたら、インタフェースに合った呼び出しかコンパイル時にチェックしてくれるような強く片付けされた言語のほうがよくなってくるというのはわかる。
Cは片付けし、構造化したプログラムを書きやすくしたアセンブラ...というイメージだったんだけど、C99くらいから便利機能がいろいろ入ってそうでもない感じになった印象。昔はCのコードを見たら最適化した後のx86アセンブリが見えていたんだけれど、最近は見えなくなってしまった。子供のころ、本屋で秘伝C言語問答 ポインタ編に出会ったのがこの業界に入るきっかけだったのかもしれない。ほかの言語でいろいろ楽に書けるから、カーネルをいじるか、システムコールをたたくかするときくらいしか自分の中では出番がなくなってしまった。
これ以下のランキングのもその気になったら書こうかな。
たとえば、DI（Dependency Injection）で検索すると、すごい数の解説記事が出てくる。それも、プログラミング初心者向けではなく、開発者向けに。
だけど、ぶっちゃけDIなんて、解説が必要なほど難しいこととも、内容のあることとも思えない。
これって、アレと同じなんだよな。数学でいつまでたっても、(-1)×(-1)=1になるたとえ話とか、0.99...=1の説明とかに夢中になってる人たち。普通に数学ができる人は、そんなのはさっさと卒業して内容のあることやるものなんだが。
おそらく、理解力の低いプログラマと、コードは書けないがオブジェクト指向は大好きなポエマーの相乗効果で、こういう話題が盛り上がったんだろうなー。
ねぇXちゃんさぁ。なんでこんな動的なオブジェクトをstaticにしてんの？
これさぁ、そこそこ重いけどさ、セッションごとに生成される一時的なインスタンスで持ってるだけでも十分パフォーマンス的に問題ないよね？
なんでプロセス間でわざわざ共有してんの？
ネットワークリソースつったって利用者はたかだか数百人でしょ？
その中でリソースを同時利用するってゆってもたかだか十数人でしょ？
プロセス内でこのオブジェクトを全共有することでリソースの削減なんてたかが知れてるよね？
それをわざわざプロセス内でこのオブジェクトを全共有ってマジ管理できるの？シンクロナイズドとか書いてっけどさぁ？削減できるリソースの量に比べて超危険すぎねぇ？
コミットログ見たけど、ぜんぜん性能問題とかと関係のない問題の修正だったみたいだけど、なんでこんな危険なコードになったわけ？
Xちゃんさ、そもそもコードが品雑なんだけど、これエンプラJava案件なのよ
なんでCの組み込みコードみたいにif文の鬼ネストとか、引数に空のList渡して破壊的に値を設定するような、読みづらいコード書いてるわけ？
Listくらい普通に返り値で返しなさいよ…
状態管理もif文の鬼ネストやめて専用クラスとかEnum使ってコマンドパターンで対処しなさいよ
もしかして、Xちゃんオブジェクト指向にピンときていないのかな？
俺ちゃんはどっちかってーっとPHPパーなので、ゴリゴリのオブジェクト指向はそりゃ専門じゃないよ
それでもさ、interfaceとか使って、各処理の実装を切り分けるとか、やりようはいくらでもあるじゃん。
あと不要なnullチェックも多すぎです。コンストラクタで初期化が保証されているfinalなフィールド値がnullかどうかなんて確認しないでください
ユーザー入力、DB入力、環境リソースとか、外部の情報起源じゃない変数がnullとか、明らかなバグなんだから暗黙的なぬるぽでクラッシュさせましょう
こんなバグが出荷に乗ることなんてありえません。わざわざ専用のエラー処理で専用の例外飛ばすとか無意味です。
いちいちなんか冗長で複雑なんですよねぇ。
俺ちゃんみたいな若造が、ベテランのXちゃんにこんなこといいたくないけどさ、
Xちゃんのコード。どこか昭和の匂いがするんだよねぇ。悪い意味で。
