プログラミング哲学6-製品と設計

製品とプロジェクトの違いは、製品を開発するときに計画があることと、プロジェクトを開発するときに研究があることです。 未解決の問題がある場合、プロジェクトで使用するデータベースをまだ決定していないとしましょう。この問題、つまり調査を研究する必要があります。 これは技術研究と呼ばれます。 研究、これはまったく必要ありません、地球規模で完全に新しいものです。橋を建設する場合、この特定の場所で土壌を探索する必要があり、この土壌が探索されるまで、製品としての橋はまだ存在していません-プロジェクト。 どのような土がまだ知られていないので、何から橋を作るか、どのようにそれを強化するか、予算を計算して作業スケジュールを計画することは不可能です。



もちろん、どのプロジェクトも計画に似ており、一連のアクションがあり、いくつかの期限を設定することもできますが、これまでに未踏の白い点があります。これは穴のある計画、つまりプロジェクトです。



製品を開発でき、多くのテクノロジーを研究している場合、市場で競争上の優位性を得ることができるため、製品開発ではなくプロジェクトに参加したいという願望は、このような病気です。 プログラマーは、次のように考えています。さて、ここでこの小さなことを探求し、発明し、みんなを引き裂きます。 そして、研究には無期限の期間があり、あなた自身またはプログラマーが「まだこれを行う方法を理解する必要がある」と言ったら、すぐに自分自身に注意してください。ここでは、研究について、つまり製品ではなくプロジェクトについて話しています。 このプロジェクトには、研究のために不明確な時間枠があります。



このプロジェクトは精神で考えることを特徴としています。長い間、私たちはスーパー機能、メガテクノロジーを研究し、すぐにすべてを集めて製品を手に入れました。 製品の顕著な違いは、「すべてを収集する」段階が非常に早く、ほぼ即座に始まり、スケジュールのほとんどがすべての部分を微調整することに専念していることです。 それどころか、プロジェクトでは、この段階はスケジュールの終わりにかなり近づいています。 プロジェクトのスケジュールは1万本の釘を打つのに似ています。すぐに把握にかかる時間を把握し、系統的に打つことができます。 一般的に、プロジェクトは「すでにこれを行っているので、この特定の製品に対してもう一度行うだけでよい」という感覚を持っています。 さらに、同じスケジュールに従ってプロセスを繰り返して、別の類似製品を作成できます。 多くの成功したプロジェクトは、スケジュール全体を最初から最後まで見ていた人がチームを去り、組織プロジェクト全体、作業スケジュールを複製し、研究と実験を意識的に避けてより良い品質でのみ同じことを行うため、正確に成功しました。



たとえば、入力フィールドが突然フォーカスを失ったり、間違って移動したりする場合、プロジェクトの観点からすると、これは取るに足りない詳細であり、製品の観点からすると、これは評判を深刻に損なう可能性がある欠点です。 または、フォームには同じタイプの2つのボタンがありますが、1つは10番目のポイント、もう1つは11番目のポイントです。 些細なことは10分でなくなります。正しいファイル、正しい場所を見つけ、修正し、確認する必要があります。 スーパーテクノロジーはありませんが、少なくとも10分間オフです。 そして、通常、製品には何百、何千ものそのような些細なことがあります。それらは小さく、たくさんあります。これにより、製品開発者の主要な武器を使用して、スケジュールを立てることができます。 今日、私たちは明日、そして30日間、30個のジャムを修正し、すべての既知の係数で、2000個のピース​​と詳細を取得します。 そして、プロジェクトでこれを行う時間はありません。



プロジェクトが悪く、製品が良いと言いたいのなら、そう言うでしょう。 これら2つの概念を明確に区別したいだけで、多くの労力を節約できるように思えます。 プロジェクトは、それ自体でこの現象は素晴らしいです、研究も本当の創造性です。 さらに、プロジェクトは、研究の確率的およびゲームの本質全体を実現し、これらの不明確な期間でさえ賢明に配布および設計することができます。 結局のところ、これは単なる不明確な投影ですが、あなたはまさにあなたが何をしているかを明確に理解する必要があります。 私は個人的に、経験から、製品計画を開始する前にすべての研究を行っていましたが、使用されたすべての技術、原則、規則を調査する必要があります、質問はありません、研究の最後に基本的な決定を行う必要があります長所と短所があり、計画段階、つまり製品開発に進みます。



調査とは、適切なテクノロジーとツールの検索、独自のアルゴリズムとスタッフトレーニングの作成、初期パフォーマンス調査、顧客または市場が必要とする機能のリスト、さらには便利な操作モードの検索です。 つまり、事前に不明であり、正式に決定できないすべてのものです。 つまり、製品の開発、つまり計画と作業スケジュールのコンパイルを開始する頃には、白い斑点や質問はなくなり、計画は堅実で具体的で重いレンガでできているはずです。 すべてがはっきりしていると感じて、ただ作業をしたり、釘を打ち込んだり、競合他社の製品のチップからクローンを作成したりするだけで、製品が完成したと言うことができます。 もちろん、それは成功しないことが判明する可能性があり、計画や参照条件の定義の間違い、または実際の実際の作業の誤りがありましたが、これはすでに次のプロジェクト/製品で考慮されます。



経験を蓄積し、製品から製品へ、プロジェクトからプロジェクトへ仕事のアルゴリズムを移す能力は、一般に、開発において正しい道を進んだ人を区別します。 たとえば、ボタンのフォントを変更するのに平均で少なくとも10分かかることを長い間知っていましたが、これはほんの数秒であるように思えました。 グラフのブリックを入力すると、実行の複雑さ、実行時間、必要な資格に応じてすべてのタスクとサブタスクをソートする機能が主な計画スキルです。 それほど複雑ではないが、メモリを大幅に使い果たすという特性を持つタスクの種類は、次のタスクに進むのに時間がかかります。 あなたがプログラマーのオフィス全体または孤独のマネージャーである場合、いずれにしても、あなたは常に外部から自分を見て、次の小さなステップが完了したことを喜ぶだけでなく、次のことをすぐに考える必要がありますが、常に理解し、大声で言い、どんなタスクを書き留める必要がありますどのくらいの期間が決定されたか、どのようにタイプされたか、さらに計画を立てるためにどのような経験を引き出すことができるかが決定されました。



この意味で、開発者自身がプログラマーではなく、開発チェーンのリングを正しく評価できない開発マネージャーは災害です。 そのような人はすぐに現れ、通常は何度か彼を驚かせるのに十分なほど追い払われる必要がありますが、なぜそんなに時間がかかったのですか？ プログラマーのマネージャーは、ある距離を予想外に素早く通過した場合にのみ驚かされます。 そして、それは望ましくありません。 プログラマーが頭の中ですべてを持ち、用語で新しい行の瞬間に深く切り替える必要がない場合、彼は何かをほぼ瞬時に行うことができることは明らかです。 つまり、ボタンを3つの異なる場所で修正し、それを行うのに10分かかりましたが、同じ種類の作業であるために非常に迅速に発生し、3つのボタンすべてが連続して修正されました。 ただし、コード内のある場所でボタンを修正する必要がある場合は、プロトコルのグリッチを修正し、次に別のボタンを修正し、次にゼロによる除算を見つけ、別のボタンを修正します。各ボタンの修正には10分かかります。 さらに、1つのステップでの開発プロセスと切り替え時間だけでなく、熱意と故障の攻撃も考慮することができます。 マネージャーの最も重要な才能は、セルフマネージャーであろうとチームマネージャーであろうと、突然の勉強のために仕事が遅くなったときを追跡する能力です。 通常、しわのある額や仕事から気をそらしたいという願望は良い兆候です。 これは、何かが頭に足りないという開発者がメモリに保持されておらず、計画のポイントでの均一な動きが黙っていることを意味します。 ここでは、経験と深い理解を示し、質問を「解決」する必要があります-研究は避けられないことを理解し、計画プレートに不明確なサイズの大胆な行を追加し、それを解決するためのすべての努力を放棄するか、実証済みの代替ソリューションを適用して質問をバイパスします。 製品を製造する場合、あなたの仕事は「うまく機能する」ことではなく、予測可能性を完全にするプロセスを設定することです。



好奇心が強い世帯の比較。どんな比較も単なる比較であり、原則を説明することしかできないことを理解する必要がありますが、それは夕食の調理です。 自分で食事をする必要があるときは、食べ物をすばやく調理でき、その過程で実験や研究を行うことができます。 塩を増やしたり減らしたり、新しい調味料を試してみてください。ガラディナーを作り、親愛なるゲストを養う必要がある場合、状況は根本的に異なります。 コストは直線的にスケーラブルである必要があり、5人のゲスト、つまりガラディナーの推定コストは自分のランチスナックの5倍高いことを意味しますが、実際には、コストは食材の選択と実行と提供の徹底の両方で大きさによって異なります費やした時間。 これはプロジェクトおよび製品です。 休日のボルシチを試してみる人はいませんし、もしそうなら、彼はそれを後悔します。 ゲストはちょうど5時に来ます。つまり、締め切りがあります。 サービングとディテール、チーズを薄いスライスにスライス、ジャムを均等な層に広げる費用は、お祝いの設定よりも通常の家庭の夕食で10倍簡単です。 これは製品であり、お祝いのディナーです。 お祝いのランチやディナーを実行する複雑さは、その中ですべてが決定され、各操作が長年デバッグされているという事実によって補われます。最高でも、ホステスは1つの珍しい料理を決定します、厳密に判断せずに、「競争上の優位性を求めて」と言うことにしました。 さらに、ほとんどの操作は標準的なものであり、最終的にはキッチンにいるすべての人が実行できるため、すべてが完全に拡張されます。



コミュニティに私のプロジェクトDeodarを紹介してから1年になります。 これはもともと典型的な「プロジェクト」でした。製品の実際の実装を行うために必要な研究の量は、私がすぐに巨大であると特定しました。 そもそも、私が興味を持っている開発ツールの質の悪さの欠如は、何年も、何十年もの間、私を落ち込ませました。 お気に入りの開発ツール、エディター、IDE、デバッガーの新しいバージョンをインストールするときに、開発者がどれだけしたか、基本的に何も変わっていないことを不思議に思いましたか？ 一般に、オープンソースプロジェクトの主な傾向は、根本的な変更、完全なリファクタリングを避け、代わりにますます多くの新しいハンドル、オゾナイザーをマシンに取り付け、ドアを塗り直すことです。 健全なバージョンの反復プロセスでは、随時すべての方向に根本的な変更を提供する必要があります。 これらの基本的な変更の1つは、問題の解決策です。これは、日常の言語では「十分に小さいもの」と呼ぶことができます。 つまり、素晴らしいツールがあり、すべてが時代遅れになりつつありますが、必要な通常のささいなことは十分ではありません。このため、数十万人時のリソースで開発された製品は、機能のために開発に1日かかります。



開発者にとって、非自明なタスクを解決し、ツールに依存することは非常に重要であり、このツールへの依存が計画における戦略的決定の採用を決定します。



「あきらめることにした...」というフレーズを何回聞いたことがありますか？ 私の若さはロシアのボーランド製品の全盛期に落ち、私は専門的にプログラムすることを学び、Turbo Pascalと後にDelphiを使用しました。 これに関連して、F4（カーソルで実行）、Control + Enter（カーソルでファイルを開く）、インスタントコンパイルなどの環境ツールに依存する作業スキルを開発しました。 1つのボタンでコンパイルし、カーソルの下に停止してプログラムを開始し、1つのボタンで終了してコードの編集を続行できることが重要になりました。 Visual Studioで通常のモードで作業しようとすると、コンパイル速度が桁違いに遅くなりますが、1つのボタンでデバッガーを起動し、もう1つのボタンでプログラムを起動し、前のブレークポイントを削除して新しいブレークポイントを設定する必要があるため、これは不可能なプロセスです気が散る。 数日間、私は何とか問題を解決するマクロを書きました。 もちろん、これらは私の個人的な好みですが、問題は各プログラマーが独自の個人的な好みを持っていることです。それらがなければプログラマーはいません。画家でさえメソッドやツールに対する独自の個人的な好みを持っています。 私の知り合いの一人である工作機械の調整装置は、手元にガソリンの入った風呂がないと機能せず、食前の清潔さのためにいつでもすぐに手を洗うことができました。 そのようなお風呂がない別のワークショップで働かなければならなかったとき、彼はひどく苦しみました。 些細なことですが、そのような些細なことから、ワークフローも発展します。



私は常に、開発ツールの完成度などを前提としています。 マルクス主義者による生産手段の生産がどのように行われているかを知っています。これは先進経済と単純な機械化経済を区別します。 私の考えでは、真に改善された開発ツールは開発をパーセント単位ではなく桁違いに加速し、加速するだけでなく、開発者がさまざまな複雑さのタスクを引き受けることができると考えています。 約5年前、私は自分の要件を満たすC ++ IDEを作成するという野心的な試みをしました。 DaoIDEと呼ばれていました。 これを行うには、いくつかの基本的な問題を解決する必要がありました。 最初に、独自のテキストエディタを作成するか、Scintillaまたは他の同等のオープンソースを効果的に使用する方法を学びます。 私が覚えているようにテキストエディタ。 一般に、テキストエディターの作成は、複雑なプログラミングタスクの例です。 すべてが画面に表示され、最も複雑な構造であるため、上級者にとって理想的なタスクです。 テキストエディターに対する私の愛は、Aldus Page Makerアプリケーションで作業しなければならなかったときに栄え、このプログラムが何ができるかを公然と賞賛しました。それは80年代後半から90年代前半に書かれました。 私はたまたまゼロから、つまりゼロから何十ものテキストエディタを書いた。 そして、それは何百ものクイックプロトタイプを数えていません。 DOS用の最も単純なメモ帳から、複雑なマークアップと特別な要件を持つシステムまで。 そのため、エディターには特別な問題はありませんでした。 次に、デバッガーを処理する必要がありました.dbghelp.dllに基づいて、GDB、GDB-MI、WinDbg、およびそれらのさまざまな既製のスカートを介して、純粋なアセンブラーでデバッガーと環境との対話の多くのプロトタイプを作成しました。 その過程で私は恐怖に陥りました-それがどれほど難しいか、すべてがどれほど文書化されていないか、元々サードパーティのアプリケーションに組み込まれる単一のデバッガーではなかったことは明らかです。 それから、C ++コンパイラーに対処しなければなりませんでした。それに対する私の主な要件はコンパイル速度でした。 既存のコンパイラーの開発の歴史を詳細に調べ、最速のコンパイラー（コンパイルされたプログラムの速度ではなく、コンパイルされたプログラムの速度ではなく）が以前のSymantec C ++であるDigital Mars C ++（DMC）であることを確認する必要がありました。 私の推論はシンプルで、アプリケーションの開発プロセスでは何千回も実行する必要があり、最適化された実行可能出力はリリース時に一度だけ必要です。 DMCは多くの場合、ライバルよりも数十倍速く動作し、通常のDelphiリアクティブコンパイラに近いパフォーマンスを実現します。 しかし、彼は数十年前にライセンスされたオブジェクトファイルの形式のため、これらの実行可能ファイルをデビューする機会を与えませんでした。 MSVC、特に以前のバージョンは、GNU C ++よりも数倍高速でした。 しかし、クロスプラットフォームでひどいスラー化されたドキュメントが作成される可能性はありませんでした。それぞれのドキュメントは、変数のタイプを決定するなど、数日間調査する必要がありました。 このプロジェクトには少なくとも1年かかり、ほぼすべての時間が研究に費やされました。



C ++ Tao環境プロジェクトは、世界中で利用可能な既存のIDEビルディングブロックすべて、主にコンパイラ、デバッガを適用できないことを確認しただけで失速しました。 この問題を解決するために、ソースだけでなくコミュニティやこれらのツールの開発の歴史についても多くの時間を費やしました。 たとえば、GCCは決して迅速にコンパイルできず、さらに、バージョンごとにコンパイルが遅くなることに気付きました。これは市場の需要であり、開発の焦点です。 運営委員会自体が非常に具体的に機能し、コンパイラのデバイスが根本的に見直されることはないという事実は言うまでもありません。 ロジックはシンプルで、レクサー、AST、バックエンド、コード生成など、科学に従ってすべてが行われます。ここで発明するものは何もありません。 LLVM / Clangの作者のストーリーを含む最初のビデオを見たとき、私は喜びに飛びつきました。AppleとGoogleの考えがどれほど創造的で決定的であるかは明らかでした。 GDBデバイスは、歴史的にも技術的にも悪夢です。 ここで、これらのプロジェクトの恐ろしさを述べれば、それが好きではないという意味ではないことを明確にしなければなりません。 , , MSVC , ++ , , -! . , , , . .



, , , , . , . , . , , , , . , , , , , .



, , , ? . , , , . , , ? , . , , , , « » , , , — « ». , , . , .



YaUIを書いたとき、4つのプログラミング言語と3つの異なるプラットフォームを一度に使用する必要があったため、単一のデバッガーですべてをカバーすることはできませんでしたが、すでに完全に慣れており、コードの変更を通じてデバッガーなしのデバッグが大好きでした。さらに、すべての開発を通常のメモ帳++に変換し、コマンドラインでスクリプトを使用してコンパイルしました。その結果、3つのプラットフォームと4つの言語すべてで同じ開発アプローチを達成できました。 （Java、ObjC、C ++、JavaScript、Android、Windows、iOS）。巨大なIDEをまったく使用せずにコーディングでき、これらの巨大なブレーキングの世界への依存を取り除き、Node.jsをコンパイルして使用する必要がなく、デバッガーで別の欠陥が修正されるまで待つ必要がないことに気付いたとき、私はこのプログラミングスタイル。だから実際、Deodarのアイデアが生まれました。また、Windowsを放棄し、別の企業、つまり予測できない変更の原因への依存を減らしたいと考えました。ここで、実際に、この記事のメイントピックであるプロジェクトと製品に戻ります。これは、このようなことを書くことは非常に長い研究の後にしかできないことがすぐに明らかになったためです。つまり、実際に製品に取り組む前に、長期にわたる研究を意識的に行った方法を、私自身の例で示したいと思います。つまり、実際に製品に取り組む前に、長期にわたる研究を意識的に行った方法を、私自身の例で示したいと思います。つまり、実際に製品に取り組む前に、長期にわたる研究を意識的に行った方法を、私自身の例で示したいと思います。



, , , , . XWindow System, , , , , , , , , . - XWindow Protocol . , Anti Aliased Text. Windows , . OpenGL FreeType HarfBuzz. , , FPS. , , GDK, Qt, FLTK, SDL , GLUT, Pango . . . Xlib+FreeType+OpenGL textures.



. , Xlib . , . . hello world , . , . , , . , . , , . , , onKeyDown, onKeyUp hardware. BASH , . ? , , BASH , .



, V8 Node.js? ? . , npm . . Turbo Vision, . , JavaScript , , . : A->B->C A.draw() .draw(), .draw() .draw() , B.draw(). Turbo Vision . A.draw.apply(this), this.inherited.draw(). B.draw() , . , JavaScript, , , , . , JavaScript , dnaof .



, Notepad++, SublimeText , . . Escape BASH , , . , , JavaScript, - API , , , . , , . , , FPS , Ubuntu, -. . performance. , , , .



, , , — , , . - , , , . , , , , , . .



, . , , . , , . , « , ». , , , , , . , , , . , , . , , , , « » « », « ». , ? . , , ! , , , «», . , , . , . , , . , , , !



プログラミング哲学

6：製品とデザイン

5：Reactosとハチドリ

4：Shapitoテクノロジー

3：チチコフとプログラマー

2：神話と言語

1：3者間プログラミング