私のネガティブなインターンシップの経験は現実の世界を代表していますか？
インターンとしての私の現在の経験が実際の業界を代表するものであるかどうか、私は興味があります。
背景として、私は主要な大学の2つのコンピューティング専攻と数学専攻の大部分を通過しています。私はすべてのクラスに参加し、それらすべてを崇拝してきたので、私はプログラミングにひどくはないと思いたいです。私は大手ソフトウェア会社の1つでインターンシップを取得しましたが、途中で、非常に低い品質のコードにショックを受けました。コメントは存在せず、それはすべてスパゲッティコードであり、間違っている可能性のあるすべてのものはさらに悪いものです。私はたくさんの家庭教師/ TAingをしたので、私は悪いコードを読むことに非常に慣れていますが、私が見ている主要な業界製品はそれらすべてに勝っています。文書化されていないAPIを見つけたり、（完全に文書化されていない）製品の他の部分の動作を判別したりするために尽きることがないので、私は1日10〜12時間働いて、どこかに行く気がしません。私はこれまで毎日仕事を嫌う仕事を残しており、これが私の人生の残りの部分で何が待ち受けているのかを必死に知りたいのです。
私はインターンシップで短いストローを描きましたか（不条理に大きな給与はそれが低品質のポジションではないことを意味します）、またはこれは現実の世界のようなものですか？
彼らはそれをReal World™と呼んでいます。
実際の企業の世界で遭遇するものの99％はがらくたと見なされます。それは正当な理由で説明します。がらくたとはみなされない1％はやがてがらくたになります。
＃1コードを書く、＃2 ????、＃3利益！
最初にビジネスは利益を上げるために存在しますnot存在することで、完全に理論的にクリーンで設計された、純粋なアカデミックコードの山が生成され、完璧な黄金のリポジトリに格納されます。彼らが生み出したソースコードを販売するビジネスの人たちでさえ、近づきさえしていません。
ビジネスの世界では、コードは終わりを意味するです。一部のコードがビジネスの問題を解決し、作成と維持にかかるコストよりも多くのお金を稼ぐ場合、それはビジネスにとって望ましいことです。あなたがコードを書くためにあなたを雇うことは、企業がコードを入手するためのただ一つの方法です。
理論0-実践∞
理想的にはメンテナンスの方が問題になるはずですが、短期的には経済的に勝てないため、通常はそうではありません。長期的には、ソフトウェアのライフサイクルは通常比較的短く、特にWebベースのアプリケーションはすぐに時代遅れになり、頻繁に書き直されます。
社内の基幹業務アプリケーションは、多くの勢いベースの理由により、無限のゾンビプロジェクトとして認識されているものとして生まれ変わります。これらのプロジェクトは実際にはsuccesses事業を利益を上げ続けるため、継続されます。
理論的には、理論と実践の間に違いはありません。実際にはあります。 -ヨギベラ
理論的には、100％のコードカバレッジを備えた完全に設計された完全にクリーンな元のコードベースは、企業の経費を節約するはずです。実際には、有効な投資収益率に近いものを提供することすらできません。
ソフトウェアライフサイクルの物理学
ソフトウェアの世界では、非常に強力なエントロピー力も働いています。 allソフトウェアが Big Ball of Mud に退化することを非難するのは必然のブラックホールです。
[〜＃〜] bbm [〜＃〜] から始めれば遠いほど良いですが、最終的にはすべてのソフトウェアシステムに十分な時間が与えられます。 100％のエントロピーにどれだけ早く近づくかは、どこから始めて、どれだけ早く技術的負債を積み上げ、それに対する関心の高さによって決まります。
ソフトウェアシステムは縮退して腐敗します原因メンテナンスの欠如のためではなく、メンテナンスの欠如のためです。何年もの間コードが変更されていないシステムは、定義上、すべての要件と目標を満たし、成功しています。
最大エントロピーに近いところから始まったため、絶え間ない変更が必要なのはシステムであり、絶えずつつかれて推進されているシステムであり、マイナスの変更を加速するのはメンテナンスです。
グッドイナフはグッドイナフ
Webサイトのように絶えず変化する短いライフサイクルシステムは、ユニットテストで100％のコードカバレッジの高価な大規模な事前設計の恩恵を受けません。これは、償却時間が短すぎてコストを回収できないためです。
上記の内部ビジネスラインアプリのような長いライフサイクルシステムでも、100％のコードカバレッジユニットテストへの大規模な投資の恩恵は実際にはありません。非線形の方法。
そのため、サポート終了計画の方が重要であり、交換システムは何かがリリースされた直後に計画する必要があります。新しいシステムを導入する必要があります。
彼らは私が知る限りBBMについて教えていません。私はそれが何であるかを知っている最近のCSの卒業生に出会ったことはありません。
それが Good Enough is Good Enough であり、多かれ少なかれ何でもありません。
ソフトウェアスラムロード
不動産スラムの領主がいる理由は、彼らが所有している貧弱な建物を駆け下りて利益を上げているためです。荒廃した資産の増分メンテナンスに費やすよりも多くの利益を生み出します。そうしなかった場合、建物を解体して取り替えます。しかし、そうではありません。増分コストは、建物全体のオーバーホールや交換よりはるかに少ないためです。物件を荒廃するために喜んで支払う顧客（テナント）もいます。
建物の所有者、スラム街の支配者、または非居住者は、関連するコストで実質的な利益につながらない完璧さについての学問的な考えがあるために、不動産にお金を費やすことはありません。
お客様が問題なく機能しているソフトウェアシステムへのアップグレードに料金を支払う必要はありません。目に見える実質的な利益を得るために、コードの作成と再作成だけにお金を費やすビジネスはありません。
マイクロソフトが最も支配的で成功しているソフトウェアスラムロードです。 Windowsは、ごく最近まで、主要な基本的な書き換えを開始していませんでした。そして、彼らはまだカーネルからすべてのレガシーコードを落としていません。それは彼らにとってビジネス的に意味をなさない、人々は過去10年間に設定した期待の低いバーを受け入れる用意がある以上です。
予後
これは、ソフトウェア開発に携わってきた20年以上のパターンです。すぐに変わることはありません。これは、人々が何らかの信念体系から抜け出すことを望んでいる方法ではなく、ビジネスへの外力の現実です。ビジネスは意思決定を推進し、利益は彼らがあなたの給料を支払うことは悪いことではありません、短期的または長期的なビジョンは無関係です。これは、定義により常に変化する短期的な業界です。 利益を上げるのに十分良いと主張する人はビジネスを理解していません。
私は15年間のコンサルティングに費やし、すぐに十分なのはそれだけで、それ以外にはお金がかかることを学びました。ええ、私は物事が完璧であることを望みましたが、あなたがコードベースを販売しているのでない限り、あなたが販売する時間の99.99999％solutionあなたが払い戻されることは決してありません。
進歩と希望
アジャイル手法は、少なくとも哲学的に、正しい方向への良い一歩です。彼らは、一流市民としての混乱と絶え間ない変化に取り組み、それを受け入れます。彼らは独断的な慣行を拒否し、方法論と慣行、ならびに要件と技術を変更すべきであることを認めます。
彼らは、時間の不足または要件の変更、スタッフの変更、および技術的負債の概念を持つソフトウェアシステムの活性度によって導入されるエントロピーを受け入れます。
しかし、アジャイルは万能薬ではありません、それは物理学の基本的な法則を変更するつもりはなく、コードベースは関係なく腐敗します。腐敗が完全に手に負えなくなり、管理できなくなる前に、腐敗に対処することを計画するのは経営者次第です。
アジャイルは、正しく行われると、エントロピーの管理、速度の低下、追跡、測定、計画的な方法での処理に役立ちます。止まらない！
キャリア決定
これが本当の哲学的問題である場合は、他のキャリアの選択を検討する必要があります。物事の仕組みには背後に有効なビジネス上のメリットがあるからです。 オープンソースプロジェクトにはこれ以上の実績がなく、多くの場合、コードは私が目にしたほとんどの企業コードよりもさらに悪いものです。
インターンとしての私の現在の経験が実際の業界を代表するものであるかどうか、私は興味があります。
いいえそうではありません。それはあなたのキャリアレベルと経験の代表です。それはすべて、企業が内部の品質管理の観点からどのように機能するかについて学ぶことの一部です。
背景として、私は主要な大学の2つのコンピューティング専攻と数学専攻の大部分を通過しています。私はすべてのクラスに参加し、それらすべてを崇拝してきたので、私はプログラミングにひどくはないと思いたいです。私は大手ソフトウェア会社の1つでインターンシップを取得しましたが、途中で、非常に低い品質のコードにショックを受けました。
あなたのスキル、経験、教育は、他の人が行う仕事の質に影響を与えません。あなたがそれらの慣行を変更する権限を持っていないという理由だけで。大学の成績がよかったかどうかは関係ありません。あなたが現在働いている会社の運営方法は変わりません。それは素晴らしいことですが、あなたはこのすべての背景を持っています。それは本当にあなた自身のためであり、彼らのためではありません。だからこそ、あなたが愛するものを研究することが重要です。
私は大手ソフトウェア会社の1つでインターンシップを取得しましたが、途中で、非常に低い品質のコードにショックを受けました。コメントは存在せず、それはすべてスパゲッティコードであり、間違っている可能性のあるすべてのものはさらに悪いものです。私はたくさんの家庭教師/ TAingをしたので、私は悪いコードを読むことに非常に慣れていますが、私が見ている主要な業界製品はそれらすべてに勝っています。
長年のプログラミングで学んだことは、「コードの品質」と「許容可能なコード」には違いがあるということです。真実は、権威を持つ誰かがソースコードを許容できる状態で見つけるか、または受け入れられないが必要であると考えるかのどちらかです。私たちが関与するプロジェクトをすべて片付けることができればいいのですが、多くの場合、その作業を行うためのリソースを割り当てることは、企業の関心や予算にはありません。翌日の太陽が昇るまで論理的な議論をすることができますが、なぜこれを修正するのが良いのでしょうか。しかし、経営陣が現在の状態が「許容できる」と判断した場合、ほとんど何もできません。それはすべて、誰が物事を実行するかに直接関係しています。彼らは良い内部品質を評価するか、そうではありません。あなたは明らかにそれを大切にしているので、この現在の状態はあなたを困らせます。
この種の問題の例は、内部の品質管理に依存するあらゆる業界で見られます。ソフトウェア開発から製造に至るまで。これを問題としてではなく、単にソースコードの現在の状態として理解する必要があります。これはその通りであり、何かを見つけるのにX分かかり、何かを修正するのにX分かかります。
企業はこの余分な時間を気にしないか、許容できると判断します。
文書化されていないAPIを見つけたり、（完全に文書化されていない）製品の他の部分の動作を判別したりするために尽きることがないので、私は1日10〜12時間働いて、どこかに行く気がしません。私はこれまで毎日仕事を嫌う仕事を残しており、これが私の人生の残りの部分で何が待ち受けているのかを必死に知りたいのです。
なぜ、大学で長時間学習して主題を研究することが許容されていたのに、現在、ソースコードを研究するために長時間学習することが認められていないのですか。雇用主があなたを雇った理由は、彼らがあなたがそれを処理できると思ったからだと私は確信しています。
少しアドバイスさせてください。優れた開発者は、フォローしているチームメイトにいつ助けを求めるべきかを知っています。答えが常にコードにあるとは思わないでください。いくつかの質問をするだけで、時間を節約できました。速度を上げるために助けが必要なようです。
第二に、私たちは労働条件を知りません。長時間労働することは、非常に多くの業界で日常の事実です。自分で解決する必要がありますが、私はあなたに話すことができます。あなたの仕事を嫌うことは決して良い兆候ではありません。あなたはその気持ちに対処し、その根本に到達する必要があります。この体験がネガティブだと思ってすみません。
私はインターンシップで短いストローを描きましたか（不条理に大きな給与はそれが低品質のポジションではないことを意味します）、またはこれは現実の世界のようなものですか？
あなたは学校で非常にうまくやっていたが、今ではインターンシップがあり、あなたはそれほどうまくやっていない。あなたはすでに現実世界にいるように聞こえます。それは人生の一部です。問題は、あなたはそれについて何をするつもりですか？それは私の友人、重要な唯一のものです。私たちはあなたに何をすべきかを言うことができません。あなたは自分で決心しなければなりません。
あなたの年齢での経験は、私が経験したどの機会よりもはるかに優れていたように思えます。 90年代の私にとっての生活は、家賃を払って次の契約を見つけるのに苦労しました。幸運だと思ってください。
25年とさまざまな企業や業界の後、私は言うことができます：
はい、それはかなり一般的です。
これが、エンジニアが通常はかなりの給与を支払われる理由です。エンジニアは、厄介なホッジポッジに遭遇するのが得意であり、変更を加えながら、全体をリファクタリングして地獄を見つけるという差し迫った欲求に抵抗できなければなりません。それは本当にやっているはずです。私はそこであなたに感情を投げ込みました-あなたが遭遇するコードについてそのように感じるのは普通です！
あなたが目にするコードは、多くの場合、さまざまなアプローチや標準、さまざまな命名規則などを備えたさまざまなプログラマーによる無限の反復を経ています。
しかし、何が起こるかというと、$圧力は常にオンになっています。どのようにそしてなぜより良いコードが長期的には唯一の方法であるかを説明するのは常に魅力的ですが、多くの仕事では時計が短期の迅速な解決策を求めています。プロジェクトの標準を破壊するのに必要なのは1人のエンジニアだけです。これを防ぐ方法を理解し、（合理的に可能な場合は）適切なアプローチを守って実際に対処する非常に優れたマネージャーが必要です。
1つ確かなことは、「優れたコード」という用語は主観的すぎて役に立たないことです。もちろん、それはあなたにとって主観的なものではありません。具体的な理由/項目をリストすることができます。ただし、他の人々は、さまざまな項目と優先順位をリストし、一部は技術的でなくても、彼らが重要であると考えているため、主観的です。
ドレッカのように、これは憂鬱に聞こえるように聞こえるので、私はもう少し前向きにしましょう。
- 多くの場合、組織は適切なことを行っている最大の技術コンポーネントを持つ組織があります。
- 会社が新しいほど...そしてコード...それがよりクリーンになる傾向がある。スパゲッティは時間と人のために成長します。
- TDDとBDDを行う人もいれば、そうしない人もいます。範囲は巨大です。
- 約10年後、現在、テクノロジーベース全体が変化しているため、業界にとどまっている人は、初心者と同じように追いつくことができません。
最後に、Anthony Blakeが指摘するように、時間、コスト、品質の3つの要素が常にあります。
関連する表現が好きです"pick 2"！
みんなの経験が違うので、これについてはたくさんの意見があります。
私が遭遇する開発者の約半数は、意欲的ですが、平均的な能力を持っています。上部には華麗な人々の小さなグループがあり、下部には小さなグループがいますが、彼らは実際にそれを取得できないので、基本的に何か他のことをするべきです。残念ながら、他の無能な愚か者の小さなグループもいます。彼らは他の誰よりもはるかに賢く、通常どのように彼らをフォローするべきかについてかなり直面しています。
プロジェクトに関しては、私は多くの仕事に従事し、すぐにいくつかの確立されたプロジェクトの "面倒を見る"ように求められました。私は通常、あなたが上で概説したものを正確に見つけます-文書化されていない、過度に設計された、バギーなスパゲッティ。時々私はそれを修正することができます。古いコードである必要はありません。「手助けする」ように依頼された新しいプロジェクトでもこれを見つけました。
ほとんどの会社がインターンにくだらない仕事を与えようとしているという事実から心を奪う必要があります。楽しいのは、2つのことをした後です：1-自分自身を証明したこと、2-他の人の過ちを直す以外のことに取り組む時間を作った。つまり、能力と主導権を示さなければなりません。
不正なコードを処理する本当のトリックは、何が回収可能で何が回収不可能かを理解することです。これは経験と研究によるものです。
あなたが持っている他のキャリアオプションは、確立された企業での仕事をやめ、スタートアップで仕事をすることです。そうすれば、維持する必要のある古いコードは不要になるので、より良いものを構築する手助けをする機会があります。欠点は、スタートアッププロジェクトに課せられるプレッシャーは、ショートカットとハックが本来あるべきではないときに使われることを意味します。
プログラマーは、早期または予定どおりに納品するために、テクノロジーの負債を喜んで引き受けることがよくあります。残念ながら、この技術的負債の影響は、手遅れになるまで、開発者や管理者によってしばしば見落とされ、最小化され、無視され、または却下されます。
これが憂鬱に聞こえる場合は申し訳ありません。他の誰かがもっと前向きな作品を作れると確信しています。 :-)
ここにいくつかの素晴らしい答えがありますが、私のビットを追加させてください。
現実の世界へようこそ-残念ながらこれは非常に一般的です。
下の図を参照してください。
企業向けソフトウェアでは、2つ以上を選択でき、1つを犠牲にする必要があります。
あなたが発見したように、企業の世界の大部分はスピードと価格で行きます。
業界を完全に示すものではありませんが、私の5年以上の限られた経験からです。私はあなたのインターンシップを通して働き、その経験からできる限り多くのレッスンを受けます。特徴と指標を探します。たとえば、あなたの次のポジションでは、間違いなく一連のインタビューを通過する必要があります。このプロセスは双方向の道であり、会社の雰囲気をつかむ機会を与えてくれます。これは非常に重要であり、おそらくあなた自身の幸せと幸福につながるでしょう。
まとめると、テルテールの兆候を見つけます。
- 誰が会社を経営していますか？それは、単一のマネージャー、マーケティングチーム（そうであれば、近づかない）、開発チームなどですか？.
- 技術的な評価はありますか？経営陣、監督者、チームのメンバーがお互いをどのように扱うかを見てください。テクニカルリーダーが話し始めたときに、マネージャーがあらゆる種類の眉の動きを行っているインタビューに参加しました。その後、彼らがソース管理を使用しなかったことを学習した-あなたは私にドアを十分に速く見せることができませんでした。
- ビジネス目標？会社は毎日の財務目標のように毎日生活していますか、それともあなたが参加している長期計画を持っていますか？ソフトウェア開発は一般に数か月かけて行われるため、統合失調症の性質を持つ企業が存在すると、通常、ソフトウェアが乱雑になります。
- 深く掘り下げる-技術的な質問をするとき、人々がシャッフルするかどうかを確認します。ソース管理、ドキュメント管理、リリースプロセス、バグレポート、管理スタイル、T＆Cなど.
生きて学び、あなたの次の役割について考えてください。仕事とビジネスの世界についてよりよく教育されるので、悪い経験をすることはそれほど悪いことではありません。
まあ、私はビジネスでの2番目の10年間実行しています。完璧なクリーンなコードはめったに発生しませんが、発生したとしても、長くは続きません。概して、あなたは自分が常に過去の間違いを修復しようとしているのに気づくでしょうが、（悲しいことに）現在の間違いを犯すために時間の制約と貧弱なリーダーシップによって強制されています。
非常に特殊な種類のソフトウェアビジネスをしている場合を除き、機能的な製品をドアから出すというプレッシャーは他のすべての懸念を無効にし、特定のポイントを超えた最適化は無意味であると見なされます。プログラムが5分で実行され、5分で実行する必要がある場合、実行時間を2分に短縮するために数週間の猶予はありません。
奇跡によって、有能な管理、明確な目標、お金、才能、そして時間の完全な合流点があり、クリーンで優れた製品を生産している場合...それを維持する唯一の方法は、 二度と触れないでください。ほとんどの場合、メンテナンスと拡張の優先度は非常に低く、変更は事実上ゼロ通知で常に必要であり、不規則に拘束されてしまいます。
昨日、この一つのプロジェクトについて考えていました。それは私にとって非常に明白なパイプの夢だったので、本当に最低限の機能しか持たないがらくたをドアから跳ね上げました。時間と資源の浪費だと思っていました。
まあ、驚き、驚き、誰もがそれを愛し、それはうまくいきました。それで、私は製図板に戻り、それを正しく行いました。そして新バージョンはすごかった！しかし、その後、経営陣の入れ替わりがあり、すべてが「新しいビジネスの方向性」に賛成して廃棄されました。
2番目のイテレーションは、社内で本当に中途半端な展開でしたが、それについて別のことは聞いたことがありません。これは、少なくとも10のビジネスユニットがまだそれを使用していることがわかっているので面白いです（仕事を委託するソフトウェア）予定より約2年遅れています）、どうやら壊れることはありません。
これで最後のポイントになります。あなたが奇跡的なものを生み出したとしても、それがとてもうまく機能するという事実は、誰もそれに少しでも精通していないことを意味します、そしてそれが壊れるとき（通常、彼らは何か愚かなことをしたため）、彼らはあなたよりもあなたの名前を悪化させます毎週第3火曜日に壊れるそのことを書いたあの馬鹿者を呪いなさい。
私はこの質問に対する答えを簡単な引用で要約しようとします：
All code turns to crap given enough time and hands.
残りは単なる物語です...
予算のあるコードへようこそ！経営陣が開発を急いで、計画を立てずに、手抜きを行うのでは、大きな違いがあります。大学を卒業して最初のプログラミングの仕事を得たとき、私は現実世界のショックの同様の経験をしました。ドキュメントなし！時間の経過とともに私は多くの時間を学びました、正式なドキュメントを書いて最新に保つことは単に時間の無駄です。幸いなことに、それは素晴らしいチームでした。それは彼が何をしているかを知っている男によって導かれました、そして他のチームメンバーはコードを正しい方法で書くことを本当に気にしました。それ以来、私の経験はあなたの経験と似ています。恐ろしいコードがたくさんあり、悪いコードがたくさんあり、無知な「開発者」がたくさんいます。すべての優れた開発者にとって、100人の悪い開発者がいるようです。
あなたは永遠にあなたの仕事を憎む運命にありません。少し前に投資しても構わない長期的なメリットを認識できるほど賢い会社を見つけなければなりません。最速の方法ではなく正しい方法で物事を行うことが有益であることを証明することができ、これまでに働いた会社では非常に尊敬され信頼されています。時間の経過とともに、スパゲッティコードは修正されるか廃止され、コードが引き継がれます。妥協する準備をしてください。時々、何かをプログラミングするための最もクールで最も堅牢な方法は、やり過ぎであり、それを迅速かつ汚い方法で行うことは問題ありません。
ひどく低品質なコードを何と考えるかを言うのは難しいですが、ええ、そういうプログラマーは（定義上）非常に優れています。ソフトウェアが進化するにつれて、人々は間違いを犯します。時間がたつにつれてこれらが蓄積し、ビジネスのプレッシャー（およびプログラマーの怠惰/無知）によってリファクタリングが行われます...珍しいことです。
コード品質は主に2つの要因に依存します。
最初は常にお金です。高い社会的圧力を持つ企業は通常、低賃金を支払い、経験の浅い開発者を雇い、スケジュールを厳しくし、開発者を活用するための時間もお金もありません。
第二は人です。最初に、予算を決定する人は、コード品質への支出を選択する必要があります。次に、彼らはそれを「生きる」ことを望む人々と関わらなければなりません。ご想像のとおり、50歳のトップダウンのDelphiプログラマー（ステレオタイプ化や申し訳ありません）を最新のJava Developerに変換するのは難しいかもしれません誰がCIビルドを行い、疎結合コードを生成します。多くの開発者は、（おそらく若い）仲間によるレッスンを嫌っています。彼らは、誰かが池で釣りをしたり、王座をがらがらしたりするのを嫌っています。
つまり、そうは言っても、すべての企業の隣にレガシーコードがあるという事実を考慮すると、実際にはその多くが得られると思います。あなたができることは、ボーイスカウトのように振る舞うことです：森に行って、ゴミを拾って、それを片付けてください。次回は、ステップスルーする混乱が少なくなります。
大手ソフトウェア会社でインターンシップを受けました
すべての会社が同じというわけではありません。ほとんどの企業では、くだらないチームやくだらないソフトウェアコードベースを見つけることができます。しかし、優れたチームと優れたコードベースを見つけることもできます。
Solarisの人たちは、大企業に見られるようなコードベースの種類について、非常に優れた正直な説明をしたと思います。 http://hub.opensolaris.org/bin/view/Community+Group+ on/dev_solaris
私はこれまで毎日仕事を嫌う仕事を残しており、これが私の人生の残りの部分で何が待ち受けているのかを必死に知りたいのです。
いいえ、15年以上コーディングを行っていますが、今でも大好きです。
すべてが完璧であると言っているのではありません。私はいくつかの恐ろしいコードベースといくつかの素晴らしいものを見てきました。秘訣はあなたにぴったりの場所を見つけることです。
大企業と小企業は大きく異なります。同じ会社のチームA内では、チームBとは非常に異なる場合があります。適切なバランスを持つチームを見つけてください（たとえば、挑戦的なプロジェクト、楽しむ文化、給与が良いなど）。
幸運を！
みんなと話すことは本当にできないけど、私が言えることはここにある。
私はこの分野で30年以上働いていませんが、いくつかのことを言うのに十分なほど見ました。プロジェクトの寿命は、人間のようです。初期設計は、20年の開発後の1つのプロジェクトなどの現在のニーズに適合しない場合があります。そうは言っても、多くの人がコードを改ざんして、最初は不可能と思われていたものを追加しました。
レガシープロジェクトやかなり古いプロジェクトの醜いコードを想像するのはそれほど難しくありません。誰もが最初の設計を完全に理解することを期待することはできません。悲しいことですが、それが現状です。
とはいえ、レガシープロジェクトのリファクタリングは常に可能であるとは限らず、場合によっては望まないことさえあることに留意する必要があります。私は彼らが私が取り組んでいたプロジェクトの代わりを開発している会社で働いていました。新しいプロジェクトよりもうまく機能するのではないかと恐れて、プロジェクトをリファクタリングしすぎることは許されませんでした。このプロジェクトが新しいプロジェクトよりもうまく機能する方法はないと確信しています。このフレーズは、「改善しないで、うまく機能させる」のようなものでした。
結局、私はよく読んだり聞いたりするので、あなたはそのようなプロジェクトをしばしば持っていないでしょう。あなたは大企業の代わりにスタートアップで仕事を見つけることを試みるべきです。スタートアップは非常に興味深いものであり、希望どおりに進んでいないことがわかった場合は、最終的には迅速に進むことができます。
また、あなたにできることの1つは、私は本当に何も約束しませんが、コードが本当に悪いと感じ、リファクタリングが必要な場合。チームと共有してください。その醜いコードを書いた人があなたと協力しているかもしれないことを覚えておいてください。それは人々の気持ちを害することではありませんが、あなたが取り組んでいるプロジェクトがしばらくすると崩壊し、人々はそれを改善する代わりにそれが何をしているかを理解するのにより多くの時間を費やすでしょう。自分のためにそれを保持するよりも、問題を率直に話し、伝える方が良いです。運が良ければ、プロジェクトをリファクタリングするかもしれません。
プロジェクトをリファクタリングすると、設計の選択に問題があると指摘されてしまう可能性があります。そして、リファクタリングがそれほど頻繁に行われない理由を理解するかもしれません。うまくいけば、チーム全体がリファクタリングする必要がある場合、誰も指摘されません。彼らは皆を撃ちます=）
これは短い答えになるでしょう。
教育は、資格を持ち理想主義的であると感じさせるのに非常に役立ちます。これは良いことであり、理想主義に固執する必要があります。
もしあなたがまったく客観的で、将来自分の仕事を振り返ることができれば、それは非常に充実した経験にはなりません。自分に嘘をつくか、何も学ばない限り、あなたは自分がしたことを改善するための多くの方法を見ることになるでしょう。
一般に、全世界があなたの周りでこれを行っています。ですから、あなたが過去から仕事を見るとき、例外は別として、それは劣っていて改善の必要があるように見えます。このように感じない場合、それはあなたが間違った仕事をしている、またはその給料が高すぎることを意味します。
良いニュースは、他の人の過ちや過去との比較から利益を得ることができるということです。すべてのアプリケーションが適切に機能し、保守が容易であれば、新しい開発者は必要ありません。私の意見では、他の開発者の残骸を保守することは有用な学習経験であり、すべての青空開発者にとって必須のトレーニング要素であるはずです。
私はあなたと同じようなものを見てきました。私はそれが発生した場合の2つの経験があります。
- 開発があまりにもプロジェクト主導の場合。重要なのは、時間通りに機能を提供し、その後サインオフすることだけです。次の変更は、他の誰か、新しい予算を持つ他のチーム/プロジェクトマネージャーによって行われます。
- 一部のソフトウェアを長期間にわたって保守しているソフトウェアは、いずれにせよそのソフトウェアを知っているため、開発者は怠惰になる傾向があります。学問の原則は遠く離れています。
それは悲しいことですが、それはいくつかの場所ではそうです。
少し変更を加えて、それに慣れるか、別の会社に変更して、インタビューでコードのスクリーニングを依頼できるかどうかを確認してください:-)
あなたのネガティブな経験は、有名な有名ブランドの会社の典型的なものであり、多くの開発者は、彼らが最初に働く機会があったときよりも、非常に注意深く、恐れをもってアプローチすることを学びます。基本的に、管理層が多ければ多いほど、平凡さが支持されます。中間管理職は、コードの品質について上級管理職に報告しません。彼らは、X時間で提供された機能について報告し、機能を使いこなせるだけの長さで機能することを望んでいるニートUI機能に関するPowerPointプレゼンテーションを提供します。それがすべて1か月後に崩壊する場合、それは通常誰か他の人の問題であり、彼らはそれを知っています。
そう、そうです、そのような場所でライフルである開発者は、あまり気にしない傾向があります。彼らはそこで生き延びられなかった。私はそれがシリコンバレーについて言ったと聞きました、もしあなたが怠惰になりたいのなら、有名な人の一人のために働くことです。エキサイティングな仕事が必要な場合は、まだ世帯の名前ではない最近のスタートアップを探してください。私はシカゴで働いており、ここで同様の現象を保証できます。
一般的な規則として（私は確信している多くの例外はあると思います）、小規模で、コードを書き続けている人々によって管理または所有されている企業では、品質の高いコードが高く評価されます。多くの場合、報酬は少なくなりますが、私の意見では、仕事のほうがはるかにやりがいがあります。
エントリーレベルの開発者は、最初は誰のために働くかについて多くの制御をすることはほとんどありませんが、1年以上あなたの履歴書で有名になると、採用担当者と人事担当者は間違いなく興奮します。また、最初の6か月ほどで完全にひどい人のために働くことで習得するよりも、かなり学ぶことができます。また、どのベストプラクティスが実際に重要で、どのベストプラクティスが技術的であるのかを理解するのにも役立ちます。流行。
そしてもちろん、主流の人気のコーポレートツールを使って作業する場合、才能レベルの中央値がかなり下手になることがよくあります。主なスキルがJavaとC＃の組み合わせである場合は、視野を少し広げます。中級レベルのErlangまたはPython =または：o JavaScript。
そして、誰かにあなたに何か違うことを言わせないでください。どのように進めればいいかわからないかもしれませんが、がらくたコードは！@＃$ ing高くつきます。