プログラミングをしてきました。その間に、私が発見したもの。選んだプログラマーたちの巨大コミュニティです。私と同じツールを使っているにせよ、いないにせよ、プログラマーたちの多くは、本当の友人になりました。私が参加したカンファレンスでの基調講演の多くから判断するに、私たちはお互いに助け合い、学び、成長し、より良いソフトウェアを構築し、キャリアにおいて次のステップを踏み出すときには、一丸となってお互いをサポートしてきたと思います。信じているのは、私だけではないでしょう。「まっとう」なプログラマーたちに、皮肉を言われ、馬鹿にされ、過小評価され、批判され、嘲笑されて、最低の極みともいえるような評価を受けてきました。そのプログラマーたちは、我々をアマチュア集団とみなしています(彼らには過去に何か嫌な思い出でもあるのかもしれませんが、私は今、それについては何も知らないという立場で話をしています。より成熟した言語にしたのと、まったく同じことですね)。そんなことには動じません。コミュニティはより強固なものとなり、新しい製品、ライブラリ、ツール、機能を構築し続けています。コミュニティは壊れてしまいました。私たちの大きなエコシステム内には、変わりゆくものを認めようとしない人たちの派閥が存在します。彼らは、自分たちの偏見を頑なに守り、広い意味でのソフトウェアコミュニティでよく見かけるような、誹謗中傷をおこなっています。辱めと信用の失墜のために、仲間たちの手で無情にも個人情報が世界に晒された例や、プライベートな会話が公になってしまっている例もあります(彼らのプライベートな面が誰かに悪影響を及ぼすかどうかはともかくとして、こういった会話は秘匿されておくべきです)。私はこの問題が起こっているサブコミュニティのメンバーではないので、当記事では細かくは触れません。界全体の問題だと認識しています。ひとつのプロジェクトだけに参加している人というのは少ないので、意見や批判、解釈などは、直接関与していない人たちにも伝わるものです。よって、サブコミュニティ内の軋轢が、広範囲に影響するのは当然のことだと思うのです。支持者の間で、軋轢が高まっていることです。ついて、同様に批判的な発言をしています。支持者たちは、激しい敵対心を持って、批判に対し攻撃的に応戦する傾向があります(建設的な対応とそうでない対応、どちらの意味でも)。いった状況では、サブコミュニティがサイロ化されていくことも、またサブコミュニティ同士が、お互いへのやんわりとした批判を、自分たちのメソッドに対する全面的な攻撃と認識してしまうのも当然です。プログラミングの経験がある人のほとんどは、何らかの理由で、自分の使っているコードを批評した経験があるでしょう。原則やデザインパターンを適用すれば、時間の節約にもなりますし、イライラもせずに済みますよ」まで、いろいろです。どのような批評をするか、また批評をどう受け止めるかは、あなたがプロとして成長するための基盤となり、また周囲の人たちがあなたをどう評価するかの決め手となります。リーダーに従い、その能力を認める人たちが、仲間たちに対してどのような振る舞いをするかを決めることが、コミュニティのリーダーとしての一番大事な仕事なのかもしれません。プラットフォーム上で、叩き合いをやっています。あるフレームワークのスケーラビリティについてや、あるライブラリのコアメソッドの行数などについて、陰険な批判のコメントが見受けられます。一連のやりとりを読んだ人は「この人たちは、外野から、このフレームワークやツールを使うなと主張しているのだ。その選択が絶対に正しいと思ってるのだ」と思うに違いありません。要は、こういった議論を続けるということは、よくある問題の解決に対し、他のアプローチを試してみるというチャンスを、経験の浅いデベロッパーから奪うことなのです。率直に自分自身を表現すること、周囲の人たちに笑われるのを恐れずに、それぞれのフレームワークの利点と落とし穴について、議論する機会さえ与えないということなのです。彼らが仕事をする上で、どうやったら適切なツールを選択していけるのか、学んでいこうとするのを妨げているのは、私たちなのです。間違いなく、私たちはキャリアの前進を妨害しています。デベロッパーのエコシステムに対しても、有害です。デベロッパーにとっても障壁となります。対してネガティブなイメージを持っているという事実を考えれば、これ以上の参入障壁など、あってはならないはずです。恥ずかしながら、私もそのうちの一人でした。自分と同じことをしている集団が優位な状況で、そのトレンドの波に乗るのは容易いのです。ついて発言して、会場が大爆笑に包まれました。次の日、新人出席者の一人が、それによって肩身の狭い思いをしているとコメントするのを聞くまで、私は何も感じていませんでした。ファンが落としたボールが、誰かに不快感を与えてしまったことに気づいた瞬間でした。私も、そのユーザーの内の一人だったのです。反応を深く掘り下げるつもりはありません。理由はいくつかあるのですが、ひとつは、多くを推測してしまうと、彼の過去の行いに対し「ああすればよかったのに」などと批評することになってしまい、彼に対しフェアでないからです。次に、彼は私に、同様のテーマで記事を書く予定があると教えてくれたからです。比較を行っていたとき、多くの批判が寄せられていたという事実を教えてくれました。パターンが実装されていました。デフォルトで多くの追加機能が含まれていて、ビジネスロジックをフレームワークに結合するのが非常に容易でした。あなたの仕事を楽にしてくれる待望のツールとして、説得力のあるフレームワークだったのです。すべてがガラリと変わりました。使用している開発者は、ツールを選ぶ際や、プロジェクトの詳細を決める際、より多くの選択肢と柔軟性を求めていました。オリジナルがもう目的を果たしていないとわかれば、他のライブラリを簡単に組み込めて、簡単に交換できなければならなかったのです。本質は、バージョン1から2になるまでの間で、オリジナルとは別ものと言えるほどに、急激に進化しました。以外のパッケージとの相互運用性の面からいえば、ある意味無礼とも言えるほどの独善的なフレームワークが、変化を遂げたのです。は長い道のりを歩み、再利用可能なパッケージと、コンポーネントのセットに変換される形に進化しました。システムに、コンポーネントを簡単に組み込むことができます。開発者は、フレームワークが達成されたことをとても誇らしく思っていて、どのようにそれをやり遂げたのか、ノウハウを分かち合いたいと考えています。比べてアクセスしやすく、フレームワークとしても、はるかに入門者に優しいと感じています。話したことのあるデベロッパーも、ほとんどが私の意見に同意してくれました。ほうがカラーが強いので、ドキュメントが抽象的になることもなく、与えられたツールで、直接的に目標を達成することができるでしょう。Development)専用のツール、というラベルを付けたがる傾向が強く見られますが、複雑なプロジェクトでは使うことをおすすめしません。ユーザーからは当然、「〇〇のサイトでも使われてるんだよ、うるせえな」と返ってきます。本当使えないな」と言い返します。あらゆる人が「はぁ?ファサード?」と割り込んできます。公園で「俺の親父にかかれば、お前の親父なんて一発なんだからな」とやり合っている子供を見ているかのようです。対する個人的な意見になりますが、データベースに外部キーとインデックスを追加するときに、余計な手間がかかるのが不満です。データ構造の設計において、このプライオリティはかなり高めにしておくべきだというのが、私の考えです。プロジェクトを引き継いだ経験が数多くありますが、ひとつとして外部キーやインデックスを持っているものはありませんでした。これは、データの整合性から見ても、パフォーマンスの面から見ても、問題になりえます。その周辺のトレーニングリソースの多くは、ユーザーがコードをフレームワークに強く結びつけすぎているように感じます。単純なアップグレードであるはずの作業に、何ヶ月もの時間を費やしているデベロッパーがいました。彼が時間を割いていたのは、コントローラ上のファイルやロジックのファイルをコピーし、書き直す作業でした。コードが分かれていれば、この会社はアップグレードにかかる費用を大幅に削減でき、そのデベロッパーはもっと早く新機能の開発作業に移れたはずです。創始者の主張どおり、大規模なアプリケーションに利用できると思います。アプリケーションを拡張する際、ドキュメンテーションに何を見出していくのか、その試行錯誤の経験を十分に積んでいるデベロッパーでないかぎり、そんな使い方をしようとは思いつきもしないでしょう。コントローラーに結合するのは簡単です。コミュニティの人たちは、なぜ結合すべきでないのか、その理由を嫌というほど知っているように、私には思えるのです。ユーザーがそのプラクティスを馬鹿にして笑っている場面は実際に見てきています。このユーザーというのは、コードの分割について十分な知識があって、現在のプロジェクトのスコープには収まらない人たち、もしくは先ほど言及した、集団思考の波に飲まれている若手デベロッパーでしょう。その優れたアイデアを認めようとしないリーダーに、彼らのチャレンジ精神は削がれてしまっているのです。コード分割から派生して起こったこの議論は、より深刻な問題の一症状に過ぎません。我々デベロッパーが持つ問題の核心は、好みのツールをみずから選択し、同様の問題を同様の方法で解決した人たちと、団結しすぎてしまうことです。知っているものを使い続けることによって、自分自身に制限がかかってしまいます。同じ思考を持つ集団の中に浸かりきることで、コーディングの成長は止まってしまいます。ゴールデンハンマーを使うことで、みずからのキャリアの妨げとなりえる、足かせを作り上げてしまうのです。ある方法で何かを解決したからといって、他の誰かのアプローチがより良いとか、悪いということはありません。そこには、違いがあるだけなのです。私が最も懸念しているのは、経験の浅いデベロッパーの選択に、潜在的に及ぼす影響の可能性です。人間誰しも、誰かに個人的にアドバイスをした後、その人が同じ道をたどれば、満足感をおぼえるものです。若いデベロッパーたちに、我々のバイアスをかけて、「面倒くさいし別の方法は試さなくていいか」と思わせてしまってはいけません。プログラミングなんかするなよ」と伝えることに、一体何の違いがあるというのでしょう?私たちは環境を有害化しています。学んだり、実験したり、遊んだり、開発しようとする人たちの邪魔をしています。私たちがすべきことは、経験に基づいてアドバイスをし、他の解決策を試そうとする人たちのサポートをすることではないでしょうか。あなたの上に立つ人が、どのように人を批判し、また批判を受けるのかを見てみましょう。「これは建設的な、コミュニティを良くするためのフィードバックだろうか?この人は、私が何かを学び取るべき人だろうか?」と。コミュニティのリーダーは、こう考えてみてください。「私は、自分の足かせを周囲の人にも嵌めてはいないだろうか?自分の選択が、他の人に悪影響を及ぼしたことはないだろうか?」と。保守的なネット上の叩き合いや怒りの感情は、集団の中で発生する問題を解決してはくれません。私たちが今やっていることは、人々から、このグローバル・プログラミング・コミュニティの仲間になろうという意欲を削ぐ行為です。コミュニティでブーメランを投げ合うのはやめようPHPコミュニティソフトウェア開発バックエンド原著者の許諾を得て翻訳・掲載しています。海外で話題の記事を翻訳して届けるエンジニアのためのメディアです。