チーム全体でソフトウェア製品を開発する場合、1人のプログラマが自分でどれだけ達成できるでしょうか。言い換えれば、PhotoshopやMS Wordなどを1人で書くことができますか?それができなかった場合、Web開発は1人のプログラマーが多くのことをできる領域になるでしょうか?
Linuxは現在、最初のイテレーションよりもはるかに大きくなっていますが、重要なことは、Linuxが十分な機能を備えて牽引力を得られることです。
大きなことは他とは根本的に違うものなら、やる価値があるという個人的なルールがあります。それ以外の場合は、 red ocean に飛び込みます。
ソフトウェアが十分に優れている場合は、それを真剣に検討する必要があります。 Minecraftの作成者であるMarkus "Notch" Perssonを例にとります。 IIRCは単独でゲームを開始し、ゲームが牽引力を獲得したとき、彼は協力者を探し始め、会社を立ち上げました。
単独で何かを成し遂げることに対して報いる一方で、大きなプロジェクトは、単一の天才ではなく、開発者のコラボレーションによってその可能性を実現します。
Google I/O 2009でのBen Collins-SussmanとBrian Fitzpatrickによる講演 (The The Myth of the Genius Programmer をチェックしてください。そこにあるすべての誤った期待を得る必要があります。ここで私が強調したい重要な点は、1人の開発者がすべての責任を負うこともありますが、背後にはより多くの人がいたということです。
Linus Torvalds以外の別の例は、John Carmackです。 EAがチーム全体を2か月と見積もったわずか4日で、彼はWolfensteinを移植しました。
コードの量ではなく、予想よりも少ないコードで大きな成果を達成できるようにするアーキテクチャと技術の知識です。
スキルと知識が(平均レベルを超えて)与えられれば、多くの仕事をまるで小さなもののように感じることができます。
私が行っている作業の性質上、自分でかなり大きなアプリケーションをいくつか開発しました。だから、そうです。私はこれについて何時間も続けることができましたが、今はあまり時間がないので、ここに個人的な経験からいくつかの長所と短所があります。
長所:
短所:
ある程度の献身とスキルがあれば、一人で間違いなく多くのことを成し遂げることができます。しかし、それは簡単なことではありません。優れたプログラマであるだけでは十分ではありません。プロジェクトを成功させるには、多くの場合、ユースケース、ユーザーインターフェイスの設計、ドキュメント、サポートなどについて考える必要があります。物事が順調に進んでユーザー数が増えると、すべてを単独で実行することはますます非現実的になります。つまり、より多くの人がプロジェクトに参加する(コミュニティへの参加、人を雇うなどの方法で)か、プロジェクトが停止します。
それは、彼/彼女が開発しようとしているソフトウェア、時間の制約、およびスキルに依存します。もし彼/彼女が簡単なMISアプリケーションを開発しているなら、彼が短時間でそれを実行できる可能性が非常に高いです。 Photoshop、MS Word、Blender、Flashなどの複雑なソフトウェアを開発することは可能ですが、時間がかかり、最も基本的な機能があり、機能はシンプルです。
そのすべては、スキル、費やした時間、それを実行する意欲に依存します。知識が多ければ多いほど、何かを達成するのにかかる時間が短くなります。あなたは、コードベースの非常に親密な知識を、唯一の開発者として得ることができます。これは、アウトを考え出す/リファクタリング/デバッグするプロセスをスピードアップすることもできます。
私は個人的にデスクトップからサーバーへの転送アプリケーションに取り組んできました。サーバーアプリケーション、デスクトップアプリケーションをコーディングし、すべて自分でテストしました。アプリケーションのインストーラーも作成しました。私はWindowsのシステムトレイアイコンにドラッグアンドドロップできるようにする方法を考え出し、新しいJavaライブラリを最初から作成しました。1年の間にこれを実行しました。開発とテスト。
このプロジェクト全体は、1つの主な試練でした。放課後毎日、週末だけでなくプロジェクトにも取り組んできました。 MS Word、Photoshopなどと同じくらい大規模ですか?いいえ。プロジェクトはまだ大規模であり、成長を続けています。多くのことを達成することは可能です。
私は現在、自分の空き時間に自分でそのようなプロジェクトに取り組んでいます(それはデスクトップアプリケーションではなく、Webアプリケーションですが、原則は同じです)。これが私がこれまでに見つけたものです:
1)ホイールを再発明しないでください。最初からすべてを行うのではなく、既存のライブラリ/フレームワークを使用します。ここで1つの注意点があります。ライセンスは、希望するディストリビューション/リリース/モデルに適用されるため、ライセンスに注意を払うようにしてください。一部の copyleft ライセンスでは、「派生作品」をオープンソースにする必要があります。一部のライセンスでは、非商用利用のみが許可されています。使用するライブラリ/フレームワークを追跡し、「クレジット」画面/エリア/何でも適切な帰属を提供できるようにする
2)繰り返し作業する。これは、 dukeofgamingが "Start Small"で言った と結びついています。結果を見ることができれば、プロジェクトに固執する可能性がはるかに高くなります。何かが機能しているのが見えるまで、開発は暗闇でのペイントと同じです。
3)早い段階でフィードバック/助けを求めることを恐れないでください。おそらく、あなたはすべてが得意ではありません。コーディングの低レベルの核心に精通している場合は、おそらくUIが苦手です。逆も当てはまります。特定の分野であなたよりも優れている人からアドバイスを受けることは決して害にはなりません。彼らは誰かが自分の考えを盗むことを心配しているので、多くの人々はこれを避けます。これを心配する必要はありません。誰かがあなたをコピーしようとした場合、それはあなたが価値のあるものにいることを意味します。アイデアは安く、実装が重要です。 AppleはMP3プレーヤーを発明しなかった、Microsoftはオペレーティングシステムを発明しなかった、Facebookはソーシャルネットワークを発明しなかった、そしてGoogleは検索エンジンを発明しなかった。彼らがしたことはユーザーにとって説得力のあるものにします(そして、吸わないでください)。