プログラマーが持つべき資質 - 混乱から物事を正す

プログラマー|プログラマー|品質

プログラマーは技術職であり、基盤となるハードウェア通信プロトコルの確立からデータ伝送層の処理、オペレーティングシステムの構築、データベースの構築に至るまで、ITの発展において非常に重要な役割を果たします。さまざまなデータマーケティングプラットフォームの構築において、プログラマーは中心的な役割を果たし、IT業界の発展に多大な貢献をしてきました。

中国にはコーディングに熟練した人がたくさんいますが、中国のソフトウェア業界、特にネットワークアプリケーション開発では大規模なソフトウェア開発力と製品能力を形成することが難しいだけではありません。アメリカには遠く及ばないが、インドと比べてもかなり劣る。これらの問題は、中国人プログラマーの IQ や勤勉さ、あるいは国や民間の開発投資のレベルにあるのではなく、テクノロジー、プログラム開発、プロジェクト設計に関するイデオロギー的な誤解が大部分にあります。ソフトウェア業界の製品化能力の不足や大規模・大規模再利用システムの開発能力の欠如を招いてきたが、この誤解を変えることは、小規模ワークショップモデルや個人ヒーローモデルによって引き起こされる限界を解決するための重要なステップであると言える。ソフトウェア業界の仕事。

中国には 18.9 歳か 21.2 歳の子供たちがたくさんいます。彼らは独学でたくさんのコードを書いています。そのコードの中には非常に美しく、技術的な詳細のいくつかは非常に優れています。研究には非常に熱心ですが、間違った理解や意見に振り回され、システムやプログラムの全体的な理解を欠いている、とオンラインの友人がとてもよく言いました、彼らは実際には単なるコーディングファンであり、そうではありませんまったくプログラマーと呼ばれる資格はありませんが、私の知る限り、小規模なインターネット企業の CTO の多くはそのようなコーディング好きで、恐ろしい給料を稼ぎ、恐ろしいプロジェクトに携わっており、プロジェクトの結末は大抵恐ろしいものです。
プログラマーの基本的な資質:

真に資格のあるプログラマー、またはコード作業を真に完了できるプログラマーが持つべき資質。

1: チームスピリットとコラボレーション能力
これを基本的な資質として捉えることは、むしろ重要ではありませんが、プログラマーにとって最も基本的で最も重要な基盤です。高レベルのプログラマを孤独と呼ぶ人はナンセンスです。Linus のような天才であっても、奇跡を起こすには強力なチームを形成する必要があります。マスター間の協力の精神。ローン・レンジャーは、ちょっとしたお金を稼ぐソフトウェアを作って、ちょっとした財産を得ることができますが、彼らがいくつかの大きなシステムの研究開発チームに入り、商品化や製品開発の仕事に入ると、この資質のない人はまったく資格がありません。

2: ドキュメント作成の習慣
高レベルのプログラマはドキュメントを書かないと言う人は、間違いなくナイーブな子供です。コード プログラマとして、適切なドキュメントは正式な R&D プロセスにおいて非常に重要なリンクです。技術文書を書くのは普通のことですが、上級プログラマーやシステム アナリストになると、この割合はさらに高くなります。ドキュメントがないと、ソフトウェア システムは活力に欠け、将来のトラブルシューティング、アップグレード、モジュールの再利用の際に大きな問題に遭遇することになります。

3: 標準化され標準化されたコード記述習慣
一部の有名な海外ソフトウェア会社のルールとして、コードの変数名、コード内のコメント形式、さらにはネストされた行のインデントの長さや番号まで、関数間の空白行が明確に定義されているため、良好な記述習慣は、コードの移植やエラー修正に役立つだけでなく、異なる技術担当者間のコラボレーションにも役立ちます。
一部のコーディング ファンは、高レベルのプログラマが書いたコードを他の人は決して理解できないと主張していますが、この主張は、自分自身がプログラマと呼ぶに値しないことを証明しているだけです。コードは可読性が高く、これはプログラマーにとっての基本的な品質要件です。
Linux の構造全体を見ると、標準化され標準化されたコーディング習慣がなければ、世界的な研究開発協力はまったく想像できません。
4: 要件を理解する能力
プログラマは、モジュールの要件を理解する必要があります。多くの子供たちは、プログラムを作成するときに、すべてのパフォーマンス指標をハードウェア、オペレーティング システム、開発環境に帰し、モジュールのパフォーマンスを無視します。自分のコードを考えてみてください。広告交換プログラムを書くのは非常に簡単です。そのようなプログラマーには、何百万、さらには何千万ものアクセスがある場合にパフォーマンス指標を達成する方法がわかりません。システムがなければ、太極拳チェーンの並行アクセス能力を達成することはできません。パフォーマンス要件の指標の中でも、安定性、アクセス サポート機能、セキュリティはすべて重要であり、プログラマーは、システム内でモジュールが動作する環境、モジュールが受ける負荷圧力、およびさまざまな可能性を評価する必要があります。危険と悪意のある攻撃の可能性。この点で、成熟したプログラマーが経験を積むには、少なくとも 2 ～ 3 年のプロジェクト開発と追跡の経験が必要です。

5: 再利用性、モジュール式思考能力
一部のプログラマーは、数年間プログラムを書いているうちに、熟練した労働者になり、毎日新しいアイデアを持たずにコードを書いているという話をよく聞きます。これは、実際、一部の中国人ソフトウェアの才能の最大の無駄遣いです。これらは熟練したプログラマーの主な仕事となり、実際にはこれらは完全に回避可能です。
再利用性の設計とモジュール的な考え方では、機能モジュールや機能を完了するときに、モジュールをシステムから分離できるかどうかを考えるという単純な考えに限定されないようにします。パラメータを変更するだけで、他のシステムやアプリケーション環境で直接参照できるか? これにより、ソフトウェア開発部門と作業グループがすべての開発プロセスでそれを検討できれば、プログラマも無駄にならずに済みます。反復的な作業に多くの時間を費やし、革新的なコード作業により多くの時間とエネルギーを投資できるようになります。
たとえ 1970 年代に書かれたものであっても、一部の優れたプログラム モジュール コードは、現在一部のシステムの機能モジュールとして非常に適している可能性があります。しかし、現在私が目にしているのは、多くの中小企業のソフトウェアは、アップグレードされるかすぐに機能しなくなるということです。コード全体が書き直されることが多く、反復作業のほとんどは時間とエネルギーの無駄です。

6: テストの習慣
一部の商用および正式な開発では、フルタイムのテスト エンジニアが不可欠ですが、フルタイムのテスト エンジニアやプログラマーがいれば、ソフトウェア開発を自己テストできないというわけではありません。プロジェクトにとって非常に重要な特徴は、問題の発見が早け​​れば早いほど、プログラマーが各コードと各サブモジュールの完了後に慎重なテストを実施できるため、潜在的な問題を排除できることです。できるだけ早く発見して解決することで、システム構築全体の効率と信頼性を最大限に確保できます。
テスト作業では、実際には 2 つの側面を考慮する必要があります。1 つは通常の呼び出しのテスト、つまり、プログラムが通常の呼び出しで基本的な機能を完了できるかどうかを確認することです。残念ながら、これが最も基本的なテストの責任です。多くの企業では、これが唯一のテストとなっています。2 番目の側面は、高圧負荷下での安定性テスト、潜在的な異常なユーザー入力下でのテスト、モジュールの影響など、異常な呼び出しのテストです。システム全体の部分的な障害が発生した場合のテスト、異常なリクエストが頻繁に発生してリソースがブロックされた場合のモジュールの安定性テストなど。もちろん、プログラマーはコードのすべての部分に対してこのような完全なテストを実行する必要はありませんが、プログラマーはプロジェクト全体におけるコード タスクのステータスとさまざまなパフォーマンス要件を明確に理解し、的を絞った方法で関連するテストを実行し、特定のテストを実行する必要があります。問題をできるだけ早く解決するには、上記の要件を理解するスキルが必要です。

7: 学び、要約する能力
プログラマーは、才能が簡単に排除され、取り残される職業です。なぜなら、技術が進歩するのは 3 年か 2 年かかるからです。プログラマーが落ち着いて生計を立てたいのであれば、そうしなければなりません。新しいテクノロジーをフォローし続け、新しいスキルを学びます。
学習能力が高いことは、どのような職業においても昇進するために必要な動機です。プログラマーにとって、この要件はさらに高くなります。ただし、学習の適切なターゲットを見つける必要もあります。彼らは、自分の学習能力を自慢するために、ASP、PHP、および JSP を学習したと話します。新しい言語と呼ばれるものを習得しても、そのような技術者は表面的なものや名詞を盲目的に追求する資質を持ち合わせておらず、ネットワークプログラムを作成するときに通信伝送プロトコルを理解せず、アプリケーションを改善するときに割り込みベクトル処理を理解していません。
要約が得意であることは、学習能力の表れでもあります。研究開発タスクやコードを完了するたびに、プログラムの適用状況とユーザーのフィードバックを意図的に追跡し、いつでも要約して、自分なりの内容を見つける必要があります。欠点を見つけて、少しずつ改善していくことで成長できるのがプログラマーだけです。
成長能力のないプログラマは、たとえ今は達人に見えても、すぐに遅れてしまうのでおすすめしません。
上記の資質をすべて備えている人は、資格のあるプログラマーであると言えます。上記の資質は IQ によって決まるものではなく、一部の大学の教科書で学ぶこともできません。必要なのは、プログラマーの理解する能力だけであることに注意してください。自分自身の仕事は意識の問題です。

したがって、上級プログラマ、あるいはシステム アナリスト、つまりプログラム プロジェクトの設計者として、上記のすべての資質に加えて、次の資質も必要です:

まず、要件分析能力
プログラマーは要件を理解することで適切なコードを完成させることができますが、組織や研究開発プロジェクトのマネージャーは、顧客のニーズを理解するだけでなく、自分自身で要件を策定する必要があるのはなぜでしょうか。
一般に、研究開発業務を行う際、顧客やマーケティング部門から要件が提示されることがありますが、このとき研究開発部門にとって要件は一部の機能に過ぎません。要件、より正式には、完全なユーザーの見解を得ることが可能ですが、顧客には技術以外の要素が多く、完全かつ明確な、または専門的なパフォーマンス要件を提示することが難しい場合があるため、これだけでは十分ではありません。しかし、プロジェクトの主催者と計画者は、これらの要件の存在を明確に理解し、要件分析レポートを作成するときにそれらを適切に提示できなければなりません。同時に、プログラマーが失敗しないように、それらの要件を設計指示に完全かつ明確に反映する必要があります。これらのガイドラインをコーディングするときに何も失われません。
プログラマーは、ユーザーのニーズが置かれている環境を正しく理解し、ターゲットを絞った需要分析を行う必要があります。たとえば、同じソフトウェアが ASP レンタルによってリリースされる場合と、ライセンスによってリリースされる場合には、前者の方がより優れたパフォーマンスが求められる可能性があります。後者はサポート能力と安定性を重視し、後者はさまざまなプラットフォームでの汎用性と、インストールと使用の簡単さをより重視する場合があります。

第二に、プロジェクト設計手法とプロセス処理能力
プログラマは、少なくとも 2 ～ 3 つのプロジェクト設計手法 (トップダウン設計手法、ラピッド プロトタイピング手法など) を習得でき、次のことができる必要があります。プロジェクトの要件とリソースの割り当てに基づいて、プロジェクトの全体設計に適切な設計手法を選択します。設計手法の選択を誤ると、研究開発サイクルが遅れ、研究開発リソースが無駄になり、さらには研究開発成果に影響を与える可能性があります。
プログラマーは、データ フロー図を作成してデータ ディクショナリを確立する必要があり、システム全体の処理フローを形成するために、データ フロー図を作成する必要もあります。プロセスに問題があるシステムは、どんなにコードが美しく、各モジュールが精緻であっても、良いシステムにはなりません。もちろん、プロセス分析を適切に実行し、適切なプロジェクト設計方法を選択するには、需要分析機能を十分に把握する必要があります。

第三に、再利用設計とモジュール分解機能
これはまた古い話のようですが、この問題は以前に基本的な性質の観点から説明されませんでしたか?
モジュールのタスクに従事するプログラマとして、彼が直面する特定の機能モジュールの再利用性を考慮する必要があります。システム アナリストとして直面しなければならない問題はさらに複雑であり、これに従ってシステム全体を分析する必要があります。モジュール分析機能は、多くの再利用可能な機能モジュールと機能に分解され、モジュールごとに独立した設計要件が形成されます。たとえば、自動車の生産は、最初は各コンポーネントが個別に取り付けられていましたが、その後、機械化された大量生産の到来により、自動車工場は組み立てラインで自動車を生産するようになりました。独立したコンポーネントはある程度の再利用性を持ち始め、その後標準化が大きなトレンドとなり、異なるモデル、ブランド、さらには異なるメーカーの自動車部品も簡単に交換およびアップグレードできるようになり、自動車生産の効率が最大化されます。成熟したソフトウェア業界でも同様で、一部の関連プロジェクトやシステムでは、たとえば、Microsoft の多くのデスクトップ ソフトウェアや、多くの操作モジュール (ファイルを開く、保存など) が自由に置き換えられます。ファイルなど) など) は、再利用される同じ機能モジュールのセットであり、これらのインターフェイスは、簡単に接続できるようにいくつかのクラス ライブラリを通じてデスクトップ アプリケーション開発者に提供されます。これは、再利用可能なモジュール設計の明らかな証拠です。
大規模で複雑なアプリケーション システムを、少数のパラメーターのみに依存してデータ接続を完了できる、比較的独立した再利用性の高い多数のモジュールの組み合わせに分解することは、上級プログラマーやシステム アナリストにとって重要な作業、適切なプロジェクトの最も重要なタスクの 1 つです。設計手法と明確なフローチャートは、この目標を達成するための重要な保証です。

4つ目、プロジェクト全体の評価能力
システム設計者として、全体の状況からスタートして、会社のリソース配分が合理的で適切かどうかなど、プロジェクト全体を明確に理解できなければなりません。プロジェクトのスケジュールが効率を最大化できるかどうか、時間通りに完了することが不可能ではないかどうかなどです。プロジェクト全体や各モジュールの作業量の評価、プロジェクトに必要なリソースの評価、プロジェクトで遭遇する可能性のある困難の評価など、いずれも多くの経験を積んで初めてできる状態です。継続的な要約と蓄積によって達成されます。欧米では、ソフトウェア システム設計のリーダーの中には 4 歳、50 歳、あるいはそれ以上の高齢者もおり、コーディングに関しては若い人たちに比べてはるかに活動的ではありませんが、プロジェクトの評価に関しては、彼らは何十年も働いています。経験の蓄積は最も重要で貴重な財産です。中国にはそのような世代のプログラマーが不足しているのが主な理由であり、その年齢のプログラマーが基本的に研究部門によって生産されており、プロの製品化されたソフトウェア開発によって生産されるわけではないためです。製品の研究開発の経験。
五つ目、チームの組織力とマネジメント能力
プロジェクトを完了するには、チームの協調的な努力が必要です。プロジェクト設計者または研究開発マネージャーは、その専門的な性質上、チームの総合力を最大限に発揮できるようにする必要があります。テクニカル指標とファクターはその中で設計されています。
1 つ目は、作業の定量化です。定量化がなければ、適切なパフォーマンス評価を行うことは困難です。また、プログラムの定量化は、コードの行数だけでは計算できません。そのため、技術管理者は、複雑さや複雑さを正確に評価できる必要があります。モジュールのワークロード。
2つ目は、チームコラボレーションモデルの調整です。一般的に、プログラム開発コラボレーションは、プログラマー間の能力レベルの差に応じて、グループに分けられます。研究開発のニーズに応じて、適切なチーム編成方法を選択し、メンバーの責任とタスクを緊密に組み合わせて、チームの効率を最大化します。
高いコーディングスキルを持つ人は、資格のあるプロジェクトの R&D マネージャーになれない可能性があります。この分野の能力の欠如は、しばしば見落とされます。

以上をまとめると、研究開発責任者やプロジェクト設計者として求められる資質や能力は、プログラムコードを書く能力ではないことが分かります。この資質を持っているとき、彼のコード作成能力はすでに非常に優れていますが、ここでの因果関係に注意してください。高レベルのプロジェクト設計者はすでに非常に優れたコード作成者ですが、非常に優れたコード作成者ではありません。良いコードはプロジェクトの設計作業において有能である可能性があります。ここでの問題は、IQ や教科書の問題ではなく、プログラマーが経験を積んで徐々に改善していくときに、どのような点を考慮すべきかが分からないという問題です。プロジェクトの組織化と再利用の設計、定期的な文書化と要約の習慣がなければ、依然として有能なプロジェクト設計者が大幅に不足することになります。

さらに、退屈な人がこの話を真剣に受け止めないように、この記事の目的は、アルゴリズムの専門家など、科学研究機関のプログラミングの専門家が商用ソフトウェアのプロジェクトやエンジニアリングを行うことであることを付け加えておきます。 、画像処理の専門家など、彼らの仕事は商用ソフトウェアを直接完成させるものではなく、研究プロジェクトであるため（もちろん、最終的には間接的に製品化されます。Microsoft Researchが行っている研究プロジェクトのように）、彼らが重視する品質は、これらの人々（専門家）は、プログラマーの基準で測ることはできません。

最後にもう 1 つ付け加えておきたいのですが、ソフトウェア プロジェクト開発の設計プロセスとは何ですか?通常の標準的な設計手法を例に挙げます (ただし、私はラピッド プロトタイピング手法が好きです)。

最初のステップは市場調査です。最大の価値を実現するにはテクノロジーと市場を組み合わせる必要があります。

2 番目のステップは需要分析です。この段階では、ユーザー ビュー、データ ディクショナリ、ユーザー操作マニュアルの 3 つが必要です。ユーザー ビューは、ソフトウェアのユーザー (エンド ユーザーおよび管理ユーザーを含む) が表示できるページ スタイルであり、多くの操作プロセスと条件が含まれています。データディクショナリはデータの論理的な関係を規定して整理するもので、データディクショナリが完成するとデータベース設計の半分以上が完了します。取扱説明書は、操作手順を定めた取扱説明書です。ユーザーの操作プロセスとユーザーのビューは要件によって決定されるため、これらを完了することはプログラム開発の制約とガイドラインとなることに注意してください。順序は区別されないため、開発作業と実際のニーズの間に乖離が生じることがよくあります。
上記の作業に加えて、要件分析に加えて、著者はプロジェクト設計者として、プロジェクトの完全なパフォーマンス要件仕様を作成する必要があると考えています。多くの場合、パフォーマンス要件はテクノロジーを理解している人のみが理解できるため、それには技術専門家が必要です。と需要者 (顧客または企業市場) 部門) は、実際のコミュニケーションと理解を得ることができます。

3 番目のステップは概要設計です。これは、最初にシステムの機能モジュールを分割し、合理的な R&D プロセスとリソース要件を与えます。ラピッドプロトタイピング手法として、概要設計を完了してからコーディング段階に入る手法で、研究開発業務が新しい分野に属し、最初は技術責任者が明確な詳細な設計指示を与えることができないため、通常この手法が用いられます。実際、ラピッド プロトタイピング手法でプロトタイプ コードが完成した後、評価結果と学んだ教訓の要約に基づいて、詳細な設計手順を再実行する必要があります。外。
4 番目のステップは詳細設計です。これは、技術専門家の設計思考をテストする重要なレベルです。詳細な設計指示は、システム全体のモジュール性を保つために、コーダーに特定のモジュールを提供する必要があります。実際、厳密に言えば、詳細な設計仕様では、要件分析から各機能の各パラメータを詳細に定義する必要があります。設計から詳細設計仕様の完了までを完了すると、ソフトウェア プロジェクトは半分完了したと言えます。言い換えれば、大規模なソフトウェア システムが半分完成したとき、実際にはコード行はまだ開始されていません。ソフトウェアプログラマを単にコード作成者として理解している人は、根本的な間違いを犯しています。


5 番目のステップはコーディングです。標準化された研究開発プロセスでは、コーディング作業はプロジェクト プロセス全体の最大でも 2 分の 1、通常はナイフを研ぐスキルと呼ばれる時間の 1/3 を超えません。間違って薪を割る、設計 プロセスがうまく完了すると、コーディングの効率が大幅に向上します。コーディングの際には、異なるモジュール間の進行調整と連携に最も注意する必要があります。場合によっては、小さなモジュールの問題が全体の進行に影響を与える可能性があります。多くのプログラマーが作業を停止して待機することを余儀なくされるこの問題は、多くの研究開発プロセスで発生します。プログラマにとって、コーディング時の相互コミュニケーションと緊急解決策は非常に重要であり、常にこの問題に直面しなければなりません。有名な Microsoft が 3 か月連続でパッチを発行しなかったことがありますか?今までなかった！

6番目のステップはテストです
テストには多くの種類があります。テストの実行方法に従って、内部テストと外部テストに分けることができ、テスト範囲に従ってモジュールテストと全体的な共同デバッグに分けることができます。 ; テスト条件に応じて、正常動作条件テストと異常条件テストに分けることができ、テストの入力範囲に応じて、フルカバレッジテストとサンプリングテストに分けることができます。以上のことは、説明の必要もなく、容易に理解できると思います。
つまり、テストはプロジェクト開発において非常に重要なステップでもあり、大規模なソフトウェアの場合、常に予測できない問題が発生するため、外部テストには 3 か月から 1 年かかるのが通常です。
テストを完了し、承認を完了し、いくつかの最終ヘルプ文書を完成させたら、もちろん、不正行為をしようとしていない限り、今後アップグレードや修復などが行われます。ワンショット トランザクションを通じて資金を調達する場合は、このソフトウェアが完全に排除されるまで、ソフトウェアの動作ステータスを追跡し、継続的にパッチを適用し、アップグレードする必要があります。


これらの手順を書くのは自慢ではありません。正直に言うと、私は「ソフトウェアエンジニアリング」の本を持っています。これは大学のコンピューター専攻の必須コースですが、多くのプログラマーは決してそうではないことを私は知っています。 「ソフトウェア エンジニアリング」以外のことに興味がある人もいます。「30 日でマスター VC」などです。中には、私と同じようにゲリラ出身で、この専攻を正式に勉強したことがない人もいます。十分な単位を取得していました。

今、インターネットも非常に衝動的です。一部のコーディングファンは叫んで混乱しています。実際、たとえば、世界の高さを知らない著者がインターネット上でランダムに投稿することはほとんどありません。しかし、私はテクノロジーとプログラマーに関するこの種の誤解やナンセンスには耐えられないので、混乱に秩序をもたらすために立ち上がって声を上げなければなりません。また、まだ中毒に陥っているコーディングファンがそうすることを願っています。結局のところ、間違った人々が真剣に考えて正しい道を進むことができるのです。結局のところ、それらの賢明な頭脳は本来の価値を発揮するには程遠いのです。