老いたプログラマー：満足できるコードを書く方法

今日、友人がWeiboで私にこんな質問をしました。

「@老码农的私存地、私は最近学習目的で管理システムを作成しました。終わりに近づくにつれて、以前のコードが悪くなっているように感じます。先輩、もっと良いコードを書きたいです。あなたの経験を共有し、アドバイスをいただけませんか？」

返事を数文書いたところで、140 文字で自分の考えを明確に表現するのは難しいと気づきました。良い教師になるために、そして自分が知っていることすべてを話すために、私は自分の答えをブログ記事に書くことにしました。

まず最初に、このブログを書いているからといって、自分のコードがうまく書かれていると思っているわけではないことを明確にしておきたいと思います。実際、私は自分のレベルについて非常に明確です。アプリケーション システムに取り組むプログラマーとして、私はフレームワークやシステムに取り組む大物たちと同じレベルではありません。そして、応用レベルでも、私のレベルは二流か三流としか言えません。プログラミングが好きだから、一生懸命頑張ってきただけです。でも、何はともあれ、好きな仕事ができるだけで満足です。そこで私は質問を少しいじって、「以前書いたコードが悪かったと感じている」という要点に着目し、友人の「どうすればコードを良くできるか」という質問を「どうすれば自分が満足できるコードを書くことができるか」という質問に変えました。

話を元に戻すと、私自身の経験では、コードを書くことはエッセイを書くことと非常に似ており、書き始める前のアイデア出しのプロセスが最も重要です。高校生の頃、中国語の先生が私に、中心となる考え、各段落の主な考え、記事の文脈、主要な修辞技法などを繰り返し検討し、構想に少なくとも 3 分の 1 の時間を費やすべきだと教えてくれたのを覚えています。これらすべての要素をよく考えれば、一気に書くことができます。

コードを書く場合も同じで、アイデアが最も重要だと思います。使用する技術プラットフォーム、フレームワーク、ツールなどが決まっていると仮定して、記述を開始する前に、開発時間の 3 分の 1 以上を費やして、すべてのデータ構造とその関係を検討します。たとえば、複数のクラスを定義すること、クラス間の関係は何か、各クラスにはどのような属性があるか、各クラスにはどのようなメソッドがあるかなどを定義する必要があります。これらが最もコアとなる部分です。これらのデータ構造は、可能な限り詳細に検討する必要があります。たとえば、関数の実装は適切であっても、パフォーマンスが理想的でない場合は、データ構造の設計を改善する必要があることを意味します。これらの詳細は、十分であると感じるまで繰り返し検討し、相互確認する必要があります。これを踏まえて、実装の詳細、テストケース、コードの読みやすさに注意を払えば、満足のいくコードを書くことができるはずです。具体的な手順は次のとおりです。

1. データ構造とコアアルゴリズム

データ構造の重要性について、偉大な Linus Torvalds がかつて次のようなことを言っていました。私も同感です。「下手なプログラマーはコードばかり気にする。上手なプログラマーはデータ構造とその関係ばかり気にする。」(低レベル プログラマーは常にコードばかり気にするが、高レベル プログラマーは常にデータ構造とその関係ばかり考える)

データ構造が明確に考えられれば、コアとなるアルゴリズムは自然に浮かび上がってきます。各クラスの各メソッドをどのように実装するかが問題となります。たとえば、中央値クエリ メソッドを実装する必要がある場合、データがリスト形式で保存されることが事前にわかっている場合は、挿入ソート メソッドの使用を検討できます。データ形式が自己バランス バイナリ ソート ツリー (AVL) の場合は、ルート ノードを直接返すだけで済みます。

データ構造によってアルゴリズムが決まるので、データ構造を検討するときは、データ構造をその自然な特性と一致させるように最善を尽くす必要があります。そうしないと、その後の実装が悪夢になります。たとえば、多階層構造を 2 次元配列として定義すると、信頼性が高く、組織図をテーブルで管理するのと同等のように見えます。ただし、部門を追加または削減すると、このレベルの配列要素の移動は言うまでもありません。次のレベルの要素の移動は簡単に混乱し、パフォーマンスが非常に悪くなります。2,000 行のコードを記述したとしても、多くの境界条件がまだ間違っている可能性があります。逆に、子-兄弟リンクリストを使用してツリー構造を表現すると、操作は非常に簡単になり、おそらく 100 行で十分です。

2. 関数の実装

アイデアが決まった後、実行プロセスにも多くの創造的な活動が必要になります。自分がよく知っていて経験のある分野であれば、当然簡単に対処できますが、慣れていない技術もあり、試してみる必要があります。学生の中には、この分野を嫌う人もいます。たとえば、私はようやく Struts 2 をマスターしましたが、リーダーから Grails フレームワークを学ぶように言われました。私はとても不満を感じました。ざっと見ただけで Grails の問題点をいくつも見つけ出し、できるだけ遠ざかろうとしました。しかし、このような考え方は、技術レベルを継続的に向上させることを妨げると言わざるを得ません。プログラマーにとって、最大の課題であり最大の喜びは、常に新しい技術を学ぶことです。この考え方がなければ、すぐに遅れを取ってしまいます。

さて、なじみのない技術に遭遇したらどうすればいいでしょうか？私の経験では、急いでコードをプロジェクトに実装しないでください。自分でテスト プロジェクトを維持し、その中でドキュメントを確認して学習し、同時に小さな機能を作成します。まず、プロジェクトに実装する必要があるすべての機能をテスト プロジェクトで実行してから、プロジェクトにコードを記述します。これを行う利点は、単一の技術的問題を他の潜在的なバグから分離し、新しいテクノロジーを迅速に習得しやすくなることです。そうしないと、プロジェクト内で直接コードを記述してミスをした場合、問題の原因を特定するのに数倍の労力がかかります。

3. テスト

テストは重要であり、開発中のデータ構造の設計と同様にテストケースの設計も重要です。テスト ケースを設計するときは、データ構造を設計したときに考えたアイデアをすべて忘れるか、他の人にテスト ケースの設計を依頼する必要があります。そうしないと、すでに検討した領域を意図せずテストすることになります。この方法ではテストは成功しますが、ユーザーが使用すると、さまざまな境界条件によってあらゆる場所で問題が発生する可能性があります。

最初にテストケースを設計し、開発プロセス中にすべてのテストが合格することを確認する TDD アプローチを推奨する人もいます。個人的にはこの手法は好きではありません。開発品質管理や長期保守の観点からTDDが必要であることは認めますが、個人的に試した結果、テストケースを設計した後、開発の目的は機能を実現することではなく、テストを実行することにあると考えると、まったく面白くないと感じるのです。私自身、このことについて非常に葛藤を感じています。

ここで、Linus Linus の別の引用を思い出します。「回帰テスト」とは、コンパイルできれば成功、起動できれば完璧、というものです。(「回帰テスト」とは、何ですか? コードがコンパイルできれば成功、起動できれば完璧、というものです。)

もちろん、偉大な師匠のレベルはそこにあり、彼には傲慢になる資本があり、私たちが彼を真似する資格はまったくありません。しかし、TDD にも独自の問題があると私はまだ考えています。テストは非常に重要ですが、それをドライバー開発のレベルに置くのは、少し本末転倒です。これはあくまでも私の個人的な意見です。TDD について深く理解しているわけではありません。間違いなどありましたら、遠慮なくアドバイスをください。

4. コードの可読性

満足するには、コードが読みやすくなければなりません。目標は、1 年後、あるいは数年後に自分が書いたコードを入手したときに、そのコードのアイデアと実装を簡単に理解できるようにすることです。これには、命名と注釈の問題が関係します。

命名はスーパーマーケットの商品ラベルのようなものです。一目で何であるかがわかるようにする必要があります。たとえば、従業員クラスには到着日と退職日という 2 つの属性があります。これらを date1 と date2 と定義するのは読みにくく、dateOnBoard と dateQuit と定義するとわかりやすくなります。

コメントも非常に重要です。コメントは、コードの目的、アルゴリズムの設計アイデア、メソッド呼び出しのパラメータ形式の要件などを説明するために使用できます。名前を付けることはコメントすることであり、コード自体がそれを物語っていると考える人もいます。この発言は命名規則の重要性を強調するのには良いと思いますが、コメントは不要だと言うのは偏った見方です。ダイクストラが最短経路アルゴリズムを初めて発明したときに提供したコードにコメントがなかったらどうなるか想像してみてください。すべての変数名が正確かつ厳密に定義されていたとしても、彼のアルゴリズムを理解できる人は何人いるでしょうか。したがって、重要な場所や複雑な場所では、コードを読む人があなたの考えを明確に理解できるように、詳細なコメントをいくつか書く必要があります。

最後にまとめると、満足のいくコードを書きたいなら、急いで書かないでください。まずはアイデア、特にデータ構造について慎重に考え、それから大胆に試して実装プロセス中に慎重に検証し、適切なテストケースを設計し、コードの読みやすさを確保してください。そうすれば、コードの中で自分の最高レベルを示すことができます。しかし、結局のところ、レベルは人それぞれであり、自分が満足したからといって、他の人もそれを評価するとは限りません。これについての私の意見は、すべてが完璧であることを求めているのではなく、良心が清らかであればそれで十分だということです。最後に、技術レベルはゆっくりと向上しますが、最初から良いプログラミング習慣を身につける必要があることをお伝えしたいと思います。そうすれば、今後は半分の労力で 2 倍の結果を達成でき、一生役立つでしょう。

[更新] コメントで言及されていた、不確実な要件が設計と実装の困難につながるという問題に応えて、要件分析に関する別の記事「要件分析に関するいくつかの経験」を書きました。批判や訂正を歓迎します。

この記事の著者: Bole Online - Old Coder

この記事へのリンク: http://blog.jobbole.com/47966/

元のタイトル: 古いプログラマー: 満足できるコードを書く方法

キーワード: コード、コーダー