ソフトウェアエンジニアリングを意図的に実践する方法
読み終わったばかりです この最近の記事 。それは非常に興味深い読み物であり、いくつかの素晴らしい点を示しています。特に私に飛びついたポイントはこれでした：
違いは、彼らがこの[等しい]時間をどのように費やしたかでした。エリートプレーヤーは、平均的なプレーヤーよりも約3倍多くの時間を意図的な練習に費やしていました。
この記事（読みたくない場合）は、バイオリン奏者について説明しています。もちろん、ソフトウェアエンジニアである私は、ソフトウェアの能力に目を向けました。確かに、非常に自然な才能のある個人がいますが、何度も何度も、彼らの技能で本当に例外的になるのは、意図的な練習を通して能力を伸ばしている人々です。
私の質問は、ソフトウェアエンジニアリングとコンピュータサイエンスの「スケール」をどのように実践するかです。ピアノを練習するときは、スケールに費やす時間を増やし、楽しい曲に費やす時間を減らします。ソフトウェア開発で同じことをするにはどうすればよいですか？
早期の回答を差し控えるために、「オープンソースプロジェクトに取り組む」などの回答は本当に正しいとは思いません。確かに...それはあなたのスキルを向上させるできるが、あなたのクラフト全体にとって重要ではない何かに集中するのと同じくらい簡単に行き詰まる可能性があります。 「トゥインクルトゥインクルリトルスター」を習得し、ショパンを演奏することはできません。
だから、もう一度、私は尋ねます-誰かが意図的にソフトウェアエンジニアリングを実践することをどのように提案しますか？
私たちがソフトウェアエンジニアとして行うことと、バイオリニスト（またはその他の物理的な練習が必要なこと）が行うことには違いがあります。バイオリニストは、楽器との相互作用の非常に具体的なパターンを脳に教えるため、体系的に何時間も費やします。
ソフトウェアエンジニアリングの実践には、学習パターンも含まれます。実行するプロジェクトが多いほど、機能するものと機能しないものについて（うまくいけば）より多くのことを学びます。優れたソフトウェアを作成するための標準的なレシピはありません（そのため、私たちの職業を純粋な科学ではなく「技術」と比較している人もいます）。したがって、私のアドバイス＃1、コードを記述してから、さらにコードを記述します。そして、もしあなたが取り組んでいることが楽しいものであるなら、それはあなたにそれほど教えていないとは思わないでください。 IS fun;それはあなたの興味をより長く保ち、あなたはそれだけ多くのことを楽しむでしょう。
参加したくない場合は、オープンソースプロジェクトに参加する必要はありません。自分の目標を設定するだけで、何かに興味を持って、コーディングを開始できます。あなたはそれを完了する必要さえないので、プロジェクトの途中でそれをドロップして他の何かに行くことに決めたとしてもがっかりしないでください。最も重要なのは、そのプロジェクトから離れるとき、使用したテクノロジーについてより優れたスキルと知識を持って離れる必要があります。
アドバイス＃2 実用的なプログラマ を読んでください。この本からの主な留意点は、ソフトウェアの記述方法を考えるときと同じように、ソフトウェアを書くことを考えるためのプロセスを後戻りしてレビューする必要があるということです。仕事をするときはいつでも、それを棚に置いて先に進むだけでなく、それをもう一度見て、もっと上手にできる方法を考えてください。実際に行ってやり直す必要はありませんが、それについて考えることで、イントロで述べたパターンを認識するように脳を鍛えます。
アドバイス＃3：コードの作成に情熱を傾けている他の人々と話してください。彼らがやったことや、彼らがどのように物事に取り組んだかを聞いてください。そして、彼らにあなたが何をしているのか説明してください。私は職場に友人がほとんどいないので、定期的に彼らのキューブに足を踏み入れ、自分が取り組んでいるソフトウェアの設計をすばやくスケッチします。ときどきうなずくかもしれませんが、他の場合には、このボックスをここに移動してこのクラスを取り除くと、2日間の作業を節約して、A、B、Cの利点を得ることができるかもしれません。
アドバイス＃4、いくつかのプロジェクトを実行し、いくつかのパターンを見つけた後。戻って、有名な GoF本 のような本を読んでください。既に作業を行っている場合は、a）作成者が話していることのいくつかを認識し、b）プロジェクトに取り組むことができたさまざまな方法を発見します。
アドバイス＃5、常に自分自身を読み、挑戦し続けます。今私がテクノロジーXを知っているモードに入る必要はありません。したがって、私は専門家です。どれだけ学んだと思っても、覚えておくべきことは無限にあります。そのため、大規模な計画では、まだそれほど多くのことを知りません。ブログを読み続けてください。新しい言語を学ぶ。たとえば、私は主にC++でプログラミングしていて、F＃と関数型プログラミングについて読んでいて、オブジェクト指向コードに関数型の概念を適用し始めました。一部の場所では、これにより、複数のスレッドとデータ同期の使用が大幅に簡略化されました。
上記のどれもソフトウェア工学ではありません。それはすべて、無計画な方法でのプログラミングにすぎません。
ソフトウェアエンジニアリング（SE）は、ソフトウェアの設計、開発、運用、保守に対する体系的で厳密な規律のあるアプローチ、およびこれらのアプローチの研究に関係する工学分野です。つまり、ソフトウェアへのエンジニアリングの適用です。
特に、エンジニアリング手法を適用すると、ソフトウェアをエンジニアリングできます。このようなテクニックを学ぶには、関連するSE修士号を学ぶのが一番です。独学でプログラミングについて学べるかもしれませんが、自分でエンジニアリングを学んでいるとは思えません。
例：プログラマーが来て、コードの作成、コードの最適化などを始めます（プログラマーにとって重要なのはコードであり、コードだけです）。多くの場合、複雑なプロジェクトは遅れ、予算は数桁を超え、ソフトウェアは要件を十分に解決しません。これはソフトウェア危機として知られています。その答えはSEの規律です。
SEが来て、まず問題領域を理解したいと考えています。エンジニアリングアプローチ、特に要件エンジニアリング（RE）が適用されます（要件抽出->要件分析->要件仕様->要件検証）。
REの結果は通常、コンテキストモデル、行動モデル、ビジネスプロセスモデルなどのモデルのセットです。これらのモデルから、SEはビジネス上の問題を理解し、ソフトウェアソリューションを設計します。
通常、設計では、SEが要件モデルをコンポーネントベースのシステムアーキテクチャに変換し、各コンポーネントのコンポーネント設計を個別にエンジニアします。これにより、コンポーネント境界、コンポーネントインターフェイス、およびコンポーネントを構成するクラスの特定の仕様が生成されます。
次のステップは、これらの（通常は自動生成された）インターフェースにアクセスして実装を作成する人です。その人はプログラマかもしれません。最後に、SEはソフトウェア検証を行い、すべてが元の設計と要件に対してテストされます。
SEでは、プロジェクトには通常、エンジニアがプロジェクトを計画、制御、および監視できるプロジェクト計画があります。特に、ソフトウェアは仕様どおりに、時間通りに、予算内で設計されています。
ソフトウェアの実装フェーズでは、すべてのアーティファクトのドキュメントが作成され、多くの構成アイテム（CI）が生成されます。これらはなんとかして管理する必要があります。通常、SEには、ソフトウェア構成管理（SCM）リポジトリと変更管理があります。 SEのもう1つの部分は、ソフトウェアプロセス（SP）、つまりRUP、スクラム、DSDM、Crystal、Waterfallなどです。
結果を常に再現できるように、SPは、例外なく、文書化されたとおりに文書化され、厳格に従う必要があります。 （ISO 9000）。これはソフトウェア品質を指します。
SEのもう1つのトピックは、ソフトウェアの測定と推定です。これにより、SPの効率、チームのパフォーマンス、推定プロジェクトサイズ（LOC-コードの行数）、つまりCOCOMO、推定プロジェクトの配信（人日）などを測定できます。
この短い回答が説明する以上に、SEにはまだまだたくさんあります。コードを書くだけでなく、SEのアプローチを適用するのは、SEを実践する方法です。
SEはまだ新興分野であるため、非エンジニアが自分自身をエンジニアと呼ぶことが起こります。彼らが工学的アプローチを適用していない限り、彼らは単なるプログラマーです。
詳細については、Ian Sommervilleによるソフトウェアエンジニアリングおよびwww.ieee.org/www.computer.orgを参照してください。これらのリソースでは、SEはエンジニアリング分野です。 Stack Overflowや多くの企業では、残念なことに、SEという用語を借りて、プログラミングの別名として使用しています。
頭に浮かぶ2つのことは Project Euler とGoogleの AIチャレンジ です。特に、日常業務の言語以外の言語で行う場合、この種の問題は能力を伸ばすのに十分なほど制限されていますが、明確なアプローチをとるのに十分なほど単純です。
私は今年AIチャレンジを行っていますが、最も魅力的だと思うのは、問題が基本的なアルゴリズムで解決できるほど単純であるということですが、素朴な方法で行うと、1ターンあたりの制限時間に達します。 。時間の制約内で動作させるためには、基本の重要な部分だけでなく、その背後にある根本的な理由も理解する必要があります。
機能してテストに合格するコードのブロックを作成したら、「このコードの方が優れているか」と自問してください。この文脈では、それが一部であっても、より良いということは必ずしもより高速またはより効率的であることを意味しません。コードの明快さも重要です。誰かがそれを見て、それが何をしているかを理解できます。そのコードをあなたの最高の仕事の代表として、潜在的な雇用主に提出するかどうかを自問してください。
自分の個人的なコードのためにこれを行うだけではありません。このようなサイトにアクセスして、実用的な例を提供する必要がある質問に答えてください。いつかは学習しているだけの人がコピーして使用する可能性のあるコードを書くことは、強力な動機になる可能性があります。自分の本名でこれを行うようにしてください。そうすれば、自分のものであると主張するしかありません。
これを行うもう1つの方法は、あなたがそうだと思いますが、コードの提供を要求するブログを書くことです。繰り返しになりますが、これにより、あなたは世間の目に非難されやすいコードを書くことを強いられます。
他の人が読んで精査するコードを書くとき、それはスケールの練習に相当すると思います。
1つのアプローチは、比較的の重要なプロジェクト（たとえば、1000行を超える）を取り、それを他の言語に移植することです。これはあなたの言語によってあなたのためになされた多くの仮定を浮き彫りにすることがわかります。
もう1つのアプローチは、より大きなプロジェクト（見積もりでは少なくとも10KLoC）を特定し、それを書き始めて、速く書き始めることです。それを書き続け、それがその目標を達成した後、それを維持してください。これは、時間とともに変化するコードベースの管理について説明します。
ただいくつかの考え。
作家はどのように本を書く練習をしますか？
わかりました、つまり、コードを書くことは楽器を習得することとは異なります。プログラマーの役割は、ライターまたはcomposerが正しいコードを見つけようとすることです。そのため、これらの専門家がどのように彼らの技術を実践するかを自問する必要があります。実際、私たちの職業にはもっと多くのことがあると思います他の工学分野よりも共通しています。
作家は本を書いて作文を練習し、composer音楽を作曲して作曲を練習するので、プログラマーはプログラミングによるプログラミングを練習する必要があります。