「コードに夢見ることは」感情的「な行為」の記事で触れた「大牛」の最後の章を終えました。
前に、この記事を読んで記事を読んだ後、ビーチ来場者の外国人のIT部門を感じるだけでなく、彼らは、よく知られているプロジェクトの多くを実現する優れたソフトウェアの多くをしたものの、ため息をつく、しかし、彼ら（書籍正直に言うと文字）プロジェクト管理機能とソフトウェアを開発する能力は本当に限られています。彼らは常に、壮大な野心はチャンドラーを行うために、彼らは常に、最新の技術を使用して、オープンソースに期待して、プラットフォームを期待して、ユーザーに最高の体験を提供したいのですが、明確な時間制限がない野心的な目標を楽しませ、彼らは知りませんでした自分の能力の欠如が、彼らは本当に世界を変えることができると感じ、それは「自分自身の理解の欠如、オンデマンドで知識の欠如、この莫大な投資を行い、現実の知識の欠如、巨大な長いの消費であります何も素晴らしい「プロジェクト。
実際のソフトウェア開発を実現する前に、ソフトウェア開発プロジェクトのプロセス全体では、無数の障害のように、このような巨大な失敗は常にだけではなく、私を思い出させる、と私はソフトウェア開発プロセスについて考えさせ、思考することができますのみ、詳細な開発計画を策定する必要がありますが、また、独自の強みと弱みの明確な理解が明確に設定された時間と開発目標の期間を開発しました。
テキストで述べたように、ソフトウェアの設計は、2つの意味があり、一つは、我々は製品を構築したいであり、第二は、私は2つの異なる役割があると考えている製品は、ソフトウェアエンジニアリングに実装できるようにすることです - 主題の専門家やエンジニアが。コードだけに、プログラマは、常に専門家やエンジニアになることができない方法を知っています。コードは、ソフトウェア開発のための基礎ですが、コードのソフトウェア開発の一部だけが、すべてのコアのソフトウェア開発を表すものではありませんが、コードが、ソフトウェアの設計プロセス、管理プロセスではありません。課税のようなソフトウェア開発プロセスは、任意の不安定性のモジュールが他のモジュールに影響を与え、さらには建物全体が崩壊する原因となります。コーディングや設計プロセスのかどうか、私たちは常に、コード内のコードの結合を考慮するだけでなく、滝によるタスク分解は、この処理モジュールやアイデアを分割し、分割統治の考え方を採用し、あなたも見ておくべきです異なるモジュール間の相互作用。ソフトウェア開発のライフサイクルは、実行の欠如、設計サイクル偏差ニーズなどに影響を与えるコードの長さがあるかどうか、開発プロセスの状況を考慮することが不可欠です。チャンドラーの開発者や意思決定者、そのライフサイクルと本当の知識と理解、そして最終的には同様のプロジェクトの失敗につながります。
そして、すべての職業は、常にプログラマのポイントは厳しいですし、我々は明らかに神が追記されていないプログラマ、良いコードのどの部分ではないことを認識しなければなりません準拠し、それは常に、連続試行、継続的な改善を通じて常にあります気性。
私自身のソフトウェア開発プロセスでは、多くの場合、中央のか、新しいアイデアが機能が表示されますを追加する必要がありさえ方法の開発に大きな変化があるだろう、この本を読んだ後、私は、APPの再行うヘッドに毎日流行登録システムに到達しましたすでに完了セクションに加えて、詳細な計画は、また特徴と日程計画のすべては、その学習能力や知識、現在入手可能なに基づいており、機能的なデザイン、企画・開発サイクル、毎日のスケジュール計画部が完了していないが含まれています。これらの詳細な計画、ソフトウェア開発プロセスのアイデアはそれほど明確であることを初めて、今日私は、開発の進捗状況の進行状況を確認本当に開発してきた情熱を残しタスクの実装、後。
私は機能が達成されたスムーズ今日行ったインターフェースを参照すると、ワードエンジニアリングソフトウェア工学のより深い理解を持っているようです。私は、継続的な学習と成長との本質と信じている、と私はソフトウェア工学のより深い理解することができます。また、おかげで「コードにドリーミングは、」この本は私のソフトウェア開発プロセスのインスピレーションを与えます。