Clever Geek Handbook

Unixでのプログラミングの技術（だけでなく）。 パート6、コードコーディング規則

「 エリック・レイモンドによる」Unixのいくつかの簡単な開発ルールに焦点を当てた一連の記事を続けます。これは、私の最も深い信念において、他のオペレーティングシステムに拡張できます。 モジュール性 、 明clarity性 、 構成 、 分離および単純さの規則の最初の3つの部分ですでに話しました。 今日では、6番目のルールになります-



コード保存のルール：これを行う客観的な理由がある場合にのみ、大きなプログラムを開発する



私が書き込み専用プログラマーと呼ぶ世代のプログラマーがいます 。 これらは、作成するのが大好きですが、理解する時間がありません。 彼らは非常に短い時間で非常に効果的なモンスターを書くことができますが、1週間後にはすでに何かを変えるのは難しいと感じています。 特に変更がささいでない場合。 コードを保存するルールは、レイモンドの他のルールを反映しており、さらに、それらと密接にリンクしています。 よく定式化された1つの問題を解決するモジュールは、体積が小さいはずです。 これが機能しない場合は、考える必要がありますが、1つのタスクをいくつかの小さなタスクに分割することは可能ですか？ このルールの元の解釈には、「デモンストレーション」という言葉があります。これは、同僚に、さらに破ることができない、または実用的でないことを証明できる必要があることを意味します。



短時間で大量のコードを一度に開発することは、投資家の製品をもっと早く入手したいという理由だけでなく、多くの場合に引き起こされます（これが最も一般的な理由です）。 最大の不幸は、間違った場所に適用される過度の完璧主義です。 製品の最初のバージョンを完成させたプログラマーは、最初から「間違った」ことをすでに完全に理解しているため、日常的なサポートに従事し、自分の間違いの開発と修正を遅らせることは「退屈」になります。 そして、それらはすべてゼロから始まります。 これは通常、投資家に祝福として提示されます。 実際、これはより大きな問題への道です。 常に引用しているわけではありませんが、著名なブランドの間でも多くの否定的な例があり、コードを「読む」ことは書くよりもはるかに難しいことが知られています。 チーム内の人が少ないほど、コミュニケーションが少なくなり、意見や「異なる手書き」ができるため、製品の品質と一貫性が向上します。 しかし、この製品が他者によってサポートされていることを達成するために、このアプローチでは簡単ではありません。 「大した問題ではない」ため-技術文書と管理インターフェース（ 「SARCASM」プレート ）を作成します。



私自身の経験から、オブジェクトプログラミング言語ArtPublishingの開発を思い出すことができます。 Perlのテンプレート言語の既存の実装ではなく、C / C ++で作成しました。 後者は、主にパフォーマンスの点で私たちに適していませんでした。 その結果、テンプレートの言語は、かなり複雑なサイト（ オンラインストア 、コミュニティ、複雑な企業サイト、 イントラネットシステム 、そして最も興味深い、本格的なコンテンツ管理システム）が構築された言語であることが判明しました。 当初から、モンスターが判明し、正しく実行する必要があることを理解していました。 言語インタープリターを開発する上で最も重要なことは、非常に強力になることが約束されているため、開発のための準備を整えることです。 どこかで成功し、 どこかで -いいえ。 たとえば、文字列を格納するという誤った選択（「長い」、末尾に00）により、 UTF-8を使用するための非常に高価な改良が行われました。 一方、外部プラグインとAPIを使用することにより、いわゆる 「コア」。異なるクライアントの複数のサイトが同時に同時に作業したため。



言語をすばやくテスト操作に入れるために、まずPerlのテンプレートライブラリの構文を完全に繰り返し、テンプレートの処理をC ++に切り替えました。 私たちはすべてがchernobil.ruプロジェクトの例で動作していることを確信し、 Perlにはないあらゆる種類の有用な構成体で言語を構築し始め、後方互換性を残しました。 実際、システムの最初の実行は1つの「スタブ」で行われ、1つのスタブが実行可能なモジュールに置き換えられました。 誰かが興味を持っているなら、かなり貧弱な言語ドキュメントがここにあります 。 ちなみに、トピックから少し気を散らすものは、 C ++での翻訳者のリリースに非常に近かった。 単一の実行可能exe-shnikとdll-modules （Unixでは、それぞれ実行可能ファイルとso-modules ）の形式でバイナリコードにコンパイルされたサイトを想像してみてください。 つまり、デバッグ用のインタープリターと発行用のコンパイラーを備えたトランスレーターです。 2001年から2002年の場合、それはかなり興味深い解決策になるでしょうが、残念なことに、この言語は構文が巨大でした-しかし、これは避けられず、 Perlバージョンとの後方互換性に耐える必要がありました。 たとえば、フォーラムモジュールの機能は次のようになります。 
  ＆{../ templates / header（）};
 ＆{init（）};
 ＆{＃message_id = param（ 'id'）};
 ＆{＃message_parent = "&& {../ papa（#message_id）};"};
 ＆{＃tree = "&& {../ tree_message（#message_parent）};"};
 <！-％if {： '＆{＃message_id};'  ne ''：}->
 <！-％repeat source = "sql_uprate（#message_id）"-> <！-％/ repeat->
 <！-％repeat source = "sql_message（＃message_id、＃authorized_check）"->
         ＆{＃message_answer = .. / templates / message_answer（）};
         ＆{＃author = "＆f {#author};"};
         ＆{＃title = "＆f {#title};"};
         <！-％if {： '＆{＃user_mode};'  eq 'admin'：}->＆{＃admin_message = .. / templates / admin_message（）}; <！-％/ if->
         <！-％if {： '＆{＃email};'  ne ''：}->＆{＃author = "<a href='mailto:&{#emailasket;'>＆{＃author}; </a>"}; <！-％/ if- ->
         <！-％repeat source = "sql_forum（#forum_id）"->
                 ＆{＃path = "＆{../ templates / path（）};"};
         <！-％/繰り返し->
         ＆{../ templates / message（）};
 <！-％/繰り返し->
 <！-％/ if->
 ＆{../ templates / footer（）};
しかし、それでも、この言語でのひどいスタイルのプログラミングのために、重要な機能が1つ観察されました。 これはモジュール的に考える必要があります。 上記のようなロジックが内部にあるまれなファイルは、画面上のページのサイズを超えませんでした。 彼はいつも他の場所でそれを使用するためのインターフェースを持っていました。 新しい人が製品サポートに接続した場合、彼は常にデバッグのためにモジュールの小さな部分を開始し、それがどのように機能するかを見ることができます。



その結果、トピックに戻って、大規模システムを開発するための推奨事項を次に示します。
「 以前：シンプルさのルール 透明性のルール


More articles:


All Articles