一般に、新しいソフトウェアの作成は、ほとんどのプログラミングジョブの主要な部分ですか？[閉まっている]

私は10年以上ソフトウェア開発に携わっていますが、「新しい」ものを作成することはめったにありません。「新しい」という用語は曖昧な用語であることを理解していますが、明確な新しい大規模プロジェクトから既存のプロジェクトの新しい大規模な機能に至るまで、その定義を定義します完了するには2週間以上かかります）。大まかなガイドラインは、書面による仕様が必要な場合は新しいものかもしれません。ほとんどのプログラマは私が話していることを知っていると思います-あなたはゾーンにいて、大量のコードを速いペースで書いています。

とにかく、自分がやったことを振り返ってみると、「新しい」仕事に費やされている時間は10％未満だと見積もっています。「この既存のシステムをこの新しい環境で動作するように適応させる」など、確かに多くの計画が必要ですが、実際のコーディングと「新しいもの」は、コード全体の多くの場所で小さな変更を行うことになります。同様に、小さな機能のリクエストについては-何をすべきかを知っていれば、これらは1時間以内に完了することがよくありますが、そうでない場合は、コードを読んで何をすべきかを考え出すだけです読むことではなく、行うことでより良くなります）。

一般的に、私はほとんど何も実際に作成していないように感じます。ほとんどの場所でこれが当てはまると思います-新しい製品がかなり早く出て、その時点で誰もが興奮してコードを速いペースで叩き出しますが、一度ライブになるとメンテナンスモードに移行しますその後の変更のいくつかは、「新規かつ創造的」と見なされます。

私が間違っている？私はほとんどのプログラミングの仕事を正確に説明していますか、それともほとんどのプログラマーは新しいものを頻繁に作成していると感じていますか？

ソフトウェアの多くの作業はメンテナンスです。もちろん、雇用管理者が実際にこれを教えてくれることはありませんが、確かにそうです。

はい、あなたの認識は正確です。新しいシステムを作成するよりも、システムのメンテナンスにはるかに多くの時間、お金、および労力が費やされるのは絶対的な理屈です。したがって、明らかに、ほとんどのプログラマーの時間配分にはそれが反映されます。

この理由の一部は、多くの人々が「新しい＆創造的な」ことをするとき、彼らはひどくそれをするので、システムを維持するのが難しいことです（これは特に彼らが自分でメンテナンスをしたことがない場合-小規模なグリーンフィールドプロジェクトに常に取り組んでいる人は、本当に有能であると主張することはできません）。

もう1つの（おそらく大きい）理由は、ほとんどのシステムが1回限りのイベントだけでなく、継続的に役立つように設計されていることです。そのため、開発に費やした時間よりもずっと長く慣れ続けています。しかし、その間に、法律、市場、研究、ユーザーなど、あらゆるものが変化するために、要件は変化します（そして追加されます）。そして、それはメンテナンス作業を意味します。

レガシーシステムは成功したシステムです。プロジェクトの50％が失敗する初期の開発プロセスを生き延びました（成功が再定義された後でも！）。彼らは変化するビジネス環境を生き延びました。彼らはおそらく、Javaで全体を書き換えるか、当時流行していたものをすべて書き直すという、若い素朴なプログラマーによる約10の提案を生き延びたでしょう。彼らは幸運なことに、ソフトウェアが提供していた部門、会社、または機関が、さまざまな予算削減、再編成、合併などを生き延びたのです。

おそらく、作成されたソフトウェアの5％未満が10年後も実行されています。

したがって、これについてうめくよりも、そのようなダーウィンのサクセスストーリーに取り組むことは特権であり、現実の世界で何が機能するのか、そしてその理由を学ぶ機会だと考えています。

古い開発に依存しない新しいプロジェクトによく使用される用語は、greenfield projectです。求人一覧にこの用語が表示されることがあります。他の人の失敗した仕事を引き継ぐのではなく、ゼロから始めることを知っていると、仕事が魅力的になります。

成功したソフトウェアプロジェクトは、一般に、新しいプロジェクトとしてビルドするよりもメンテナンスに多くの時間を費やします。そのため、完全に「新しい」ものをたくさん作らなくても驚くことではありません。

また、まったく新しいものを作成するのは大変な作業です。グリーンフィールドプロジェクトであっても、プラットフォーム、コンパイラ、フレームワーク、ライブラリなど、多くの役立つツールを選択するでしょう。これらの選択を行うとすぐに、プロジェクトに特定の制約が課されます。それは、あなたがもう新しい仕事をしていないと言うことではなく、「新しい」だけがここでの相対的な用語です。グリーンフィールドプロジェクトと呼ばなくても、既存のプロジェクトに機能またはモジュールを「新規」として追加するのは、そこから大きなステップではありません。

それはあなたが求める仕事に依存します。

私は純粋なソフトウェア製品会社で働いたことがありますが、そこでは小さなスタートアップチームで金メッキされた単一のアプリケーションに取り組みました。

それ以外の場合、社内R＆Dまたは外部製品をサポートするソフトウェアを必要とするテクノロジー企業で働いてきました。

良い点は、完全な開始から終了までの製品を構築し、必要なものを作成できることです。市場をリードする既存のアプリケーションに機能を追加するのにこだわっている場合よりも、新しいテクノロジーを試すこともできます。

欠点は、あなたが製品の一部ではなく、コストの一部であるということです。だから、「私たちはソフトウェアをやっていない」/「ソフトウェアはコアビジネスではない」という理由でプロジェクトを缶詰にしました。それは、企業がソフトウェアを使用せずに$ 10万の工作機械を販売できると考えるのは驚くべきことです！

レガシーコードを他の誰かの混乱を継続的にクリーンアップするものとして見るのではなく、それを多くの新しいプロジェクトに取り組む機会と考えてください。

考えてみてください。システムに追加されるすべての新機能は、それ自体が小さなプロジェクトです。ジョブを適切に完了したことを確認するには、SDLC全体を適用する必要があります。確かに、機能の仕様は与えられている可能性がありますが、通常、細かい詳細は残されているため、示されているように問題を分析し、変更を適用し、テストし、コーディングするための最適な方法を設計し、そして、それをバージョン管理システムにリリースし、将来的に維持する可能性があります。

完全にグリーンな分野で仕事をすることはあまりないというのは私の経験であり、幸運にもそうすることができれば、メンテナンスのかなりの部分からプロジェクトを見ることが期待されます。製品の寿命、または特定の雇用主との全期間。これは、製品との親密な経験がナレッジリポジトリになることを意味するためであり、他のことに移行するのはコストがかかると見なされる可能性があります。既存の製品で開始するのは、雇用主が最近リソースを失ったか、プロジェクトでより多くのリソースを必要としているためであり、彼らのビジネスは、ソフトウェアへの投資であまり大きな損失をもたらさないことを保証する必要があるためです。それがソフトウェアエンジニアであるという現実です。

私はソフトウェア開発者として最後の15人で22年近くITに携わってきましたが、その間、約5つの新しい製品を作成しましたが、ほとんどの時間はそれらの製品を長期間維持するか、製品。それぞれが私に解決すべき課題と問題を与えてくれ、それぞれは私が単なる一部である大きなプロジェクトとしてではなく、完了するべき巨大な一連のマイクロプロジェクトとして扱われました。

ちょっとしたメンタル体操が、あなたの日々の仕事に対する認識と楽しみを完全に変えることができるのは驚くべきことです。;-)

既存の製品を改善したり、既存のコードを新しい顧客や市場に適合させたりすることを含む多くのソフトウェア開発の仕事だと思います。

これは実際には「メンテナンス」ではありません。たとえば、VMWareはバージョン8をリリースしたばかりで、メイン製品のメジャーアップグレードです。VMWareの最初のコード行が作成されたとき、この作業を行った開発者はほとんどいなかったと思います。彼らは、ずっと前から引っ越してきた人たちによって書かれたコードの上にメジャーアップグレードを構築しました。

以上で職場ベータ版のGoogleの20％の個人的なプロジェクトのシステムがどのように機能するかについての質問があります。

Googleは、最高の開発者が新しいソフトウェア製品の作成に参加したいと考え、最終的に次のポイントリリースのために小さな機能を追加し、GUIを調整するのに何年も費やすことに気付いたと確信しています。

20％のプロジェクトを持つことで、Googleの開発者は、何か新しいことの始まりにそこにいる楽しみをまだ持つことができるので、Googleのプロジェクトを改善することを気にしないと推測します。

新しい機能を作成し、新しい仕様に準拠するために既存のコードの機能を変更することに時間を費やします。

他の人はそのメンテナンスを呼び出していますが、それは恐ろしい用語です。それは、プログラムが何をすべきかという新しいアイデアに適合するように、ソフトウェアを再設計し、リファクタリングまたは再コーディングすることです。

私はそれはあなたが働いている会社に依存すると言うでしょう。

私の最初の仕事は会計ソフト会社で、その主要製品はERPシステムで、Great PlainsやPeachtreeとほぼ同じレベルで競い合っていました（QuickBooksから、またはGPの難読化されたスキーマなどに飽きて横に移動したときのように） PTが間違っていると考えた場合、階層から完全にSAPのようなパッケージに移動しました）。その仕事は99.99％のメンテナンスであり、ソフトウェアの動作方法やそれができることを根本的に変えることなく、バグを修正し、「小さなもの」を追加することとして定義されました。CEOがシステムのページ1の書き換えを望んだときに会社を辞めましたが、インナープラットフォームなどの明確なアンチパターン（高度なカスタマイズを可能にする）基本的に顧客にthe然としたVS Designerを提供することにより、プログラムの

その後の私の次の仕事は、「ターンキー開発」を行う契約会社でした。顧客が指定したシステムはゼロから構築されたハードウェアとソフトウェアでしたが、プロジェクトが完了すると、顧客に引き渡され、顧客はそれを自分で維持するか、月額料金で会社のサービスを維持することができました。私の仕事は、これらの主要なプロジェクトの1つを開発することでした。そこで、私がそこで働いている間、私がやったことのほとんどは、始める前には存在していませんでした。それでも、開発は本質的に反復的です。すでに持っているものに常に追加し（持っているものが何でなくても）、回帰問題（新しいものが古いものを破壊する）を避けて修正する必要があります。そして、プロジェクトが「保証」ステータスに移行すると、

ビデオ監視と音声フィードバックを使用してアラーム信号の検証とその他の「仮想ガード」サービスを提供するセキュリティ会社の現在の仕事は、社内開発に戻っています。この分野は急速に成長しており、まだ発展途上です。常に新しい機器が市場に参入し、新しいことをしたい新しい顧客が登録され、既存の製品はULおよび政府の規制に適合しなくなりました。この仕事の99％は「統合」です。以前は存在しなかった新しいソフトウェアを作成し、1つの新しいが既存の機器またはソフトウェアを別の古い既存の機器またはソフトウェアと連携させ、両方で新しいことを行えるようにします。

それはあなたの役割の性質に大きく依存していると思います。

私は小さなチームの一員であるため、私が作成したすべてのものを維持およびサポートする必要があります。

5年前、私がしたことのほとんどは「新しい」ものでした。今では、既存のコードのメンテナンスに少なくとも半分の時間がかかり、さらに25％が既存のシステムの「新しい」バージョンです。

ただし、コードをリリースした後、開発者としてチームで単独でメンテナンスとサポートを行う場合、技術的にはすべてが「新しい」ものになります。独自のコードを維持する必要のない仕事を見つけたら、それを採用してください！

1. それはあなたの職位がどの程度危険かによって異なります：;-)

   会社が存続するリスクが高い新製品を開発する新会社で働いている場合、おそらく素晴らしい新製品を作成するでしょう。

   市場で安定した地位にある古い会社で働いている場合、メンテナンスモードでコーディングする可能性が高くなります;-)。

2. 新しいソフトウェアの作成は常に非常に魅力的です。真実正しい方法でこれをするのは難しいです。保守可能なコードを実行することは簡単な作業ではありません。

   これらの多くの側面について考える場合は、適切なログ、適切な監視、統計の取得、効率的で、馴染みのない人でもプロジェクト、文書化、自動テスト、テスト駆動開発に関与するのに役立つ記述設計を作成する必要があります。

多くの人がそれを正しくやっていないので、コードを維持し、適切な状態に磨く必要があります。;-)

良いニュースは、あなたが会社に十分長くいるなら、新しいコードがどのように書かれているかに影響を与えることができるということです:-)

主にメンテナンスを行うかどうかは、少なくとも部分的には管理下にあります。私の場合、過去15年以上の私の仕事のほとんどは新しい開発です。これは、私が新しい開発を行えるようにする仕事を探しているからです。私は請負業者ではなく、一般的にウェブ開発はしていません。私はほとんど常に小規模な雇用主のために働いてきましたが、通常はニッチ分野（デスクトップGUI開発、QAツール、開発者ツール、垂直市場）で働いています。

また、チームの最高のプログラマーが（常にではありませんが）通常最高の仕事を得るということを直接目にし、経験しました。だから、あなたの会社で最高のプログラマーになることに集中してください。そうすれば、新しい開発があなたのやり方でやってくるのを見るでしょう。

メンテナンス開発は困難な作業であり、多くの点で新規開発よりも困難です。私の経験では、雇用主は、特に彼らがそれが得意である場合、開発者にメンテナンスをしてもらいたいと思っています。レガシーテクノロジで優れたメンテナンス開発者を見つけることは、最新のテクノロジで作業できる人を見つけることよりも困難です。

私は、すべてメンテナンスである製品チームと、すべて新規開発であるプロジェクトチームに分かれた会社で働いてきました。両側に優れた開発者がいましたが、メンテナンス担当者は間違いなくより専門的で、レガシーテクノロジーを使用していました。

プッシュバックして新しい開発作業を依頼することを提案できますか？また、雇用主がメンテナンスのみを行う場合は、先に進む必要がありますか？

私はそれが多くの要因に依存すると言うでしょう。どこで働いていますか、どのような製品を作っていますか、チームはどのように編成されていますか。

私が会社で働いた4年間、私の時間の70〜80％が何か新しいものの作成に費やされていると言えます。おそらくその50〜60％が完全に新しいコードである大規模なプロジェクトに費やされ、残りの時間は現在の機能の強化に費やされます。

私が知っていることの一部は、私の会社の仕組みです。私の開発チームの誰もが新しい機能の構築にこの時間を費やしているわけではありません。バグ修正/ハンティング以外に時間を集中させない人がいます。それがまったく新しい機能である場合、または彼らが助けを必要とする場合、調査のために私に引き継がれます。ただし、一般的に、バグハンターの小さなチームは、開発者の大規模なグループが中断することなく押すことを可能にします。

私はQuickBooksとExcel を使用した会社で唯一の開発者として3年近く働いてきました。これで、Windowsフォームアプリケーション、SharePointセットアップ、SQL Server +レポート、Excelアドイン、Outlookアドインができました。

ちょうど今日、ユーザーが苦情を言わない速度でメール要求を管理する機能を失ったため、チケットシステムを初めてセットアップしました。これはメンテナンスモードに入ったことを示しています。

私の以前の仕事は他の人が投稿したものに似ていましたが、次の仕事が何をもたらすかわからないということを示すためだけに、私の非定型の経験を投げ込むと思いました。私は疲れましたが、この仕事で学んだ量は仕事の価値がありました。

私が働いている会社のようないくつかのより大きな組織は、おそらくそれが書かれた開発言語がもはや使用されていないため（Delphiの誰か？）、またはプラットフォームが置き換えられているために（Windows XP） 、または規制要件により要求されます。たとえば、データベースと直接通信する2層プログラムは廃止され、セキュリティを強化するためにKerberos接続を使用する3層が採用されています。

ユーザーはまだそのオリジナルの機能を必要としているため、最新の技術を使用した完全に新しいバージョンが開発されます。

このタイプのものについては、5〜7年の交換サイクルが必要です。例えば、2020年までに、私が今書いているWPF（クライアント）/ Java（サーバー）ソフトウェアは古い技術になり、新しいものに置き換わると予想しています。