ソフトウェア開発の「実装フェーズ」にて一番大事なことは　「共通化」 「抽象化」 です。
この2点にすべて集約できるぐらいとても大事です。

まず 「共通化」についてですが、プログラムコードは可能な限り小さく小さく作っていくことが大事です。

処理を完結に表現できるメソッド名をつけて、入力(引数)と出力(戻り値）を
シンプルにしましょう。

そして作成したメソッド同士の関心ごとが近い場合、それらをまとめてクラスを定義しましょう。

クラスの粒度にもよりますが、独立性があるクラスが抽出できた場合、他の開発メンバーも
利用でき、（あるいは他のプロジェクトでも利用できる）プロジェクト全体の開発効率を
上げることができます。

これらは作業は「ボトムアップ」の開発現場ではもちろん、「トップダウン」の開発スタイルでも
頻繁に発生します。

ここで申し上げた「ボトムアップ」はハッカソンのように、軽い打合せの後、
いきなりプログラミングからソフトウェアを作りだす開発です。

「トップダウン」はウォーターフォール・モデルのように基本設計、詳細設計
(ExcelやUMLの紙ベースの資料)を手渡され、それをもとにプログラマーが実装します。
主要なクラスやメソッドは設計フェーズ時に精度よく定義されているが
すべて完璧に設計できるわけではないので、実装フェーズでプログラマーがさらに
洗練させていく必要があります。

大規模案件では、ほぼ確実に「トップダウン」に近い形をとっていると思います。
設計フェーズ終了時点で、実装にかかるコストを確定できるためです。
そのコストをもとに開発ベンダーに実装フェーズ以降の開発の発注をかけることが多いです。
大規模案件ほど、プロジェクト制が多く、発注先（あるいは発注元)の企業に様々な人材
（2次受けベンダやフリーランス、デザイナー）がアサインされ、プロジェクト終了時に
メンバーが解散となります。

つぎに「抽象化」についてですが、クラス内部のメソッドの一部の実装を先送り（未実装）
にし汎用性の高い状態で定義することができます。
抽象化クラスは、具象化しなければ動作させることができません。
文章で説明するのは非常に難しいのですが、フレームワークと呼ばれるライブラリの内部は
この高度に抽象化されたクラスの集まりでしかありません。
クラス内部のところどころは歯抜けの状態ですが、それ以外の処理は密に連携され既に実装が
完了している状態です。
あとは利用者が欠けているパーツを当てはめる作業となりますので、フレームワークを利用する際は
その裏側で発生している処理をなんとなく理解している必要があります。

具体的にWEBアプリケーションのフレームワークで例えると、一般的に行われる処理がすでに
フレームワークの能力として備わっており、画面レイアウト、画面遷移、そのアプリケーションの
根幹をなす実装処理にリソースを割くことがきます。
フレームワークのおかげで発注元（お客様）のもっとも関心の高い「ビジネスロジック」の実装に
開発者が集中できるようになっているわけです。

ただ、案件により逆にフレームワークの構造が足かせになる場合があります。
融通が利かない場合もあったり、遠回りすることがあったりします。

例えばデータベースにアクセスするためのSQL文をフレームワークのORMが自動生成
してくれますが、DBチューニング時にSQL文の先頭にヒント句を入れる必要があったとします。
こうなった場合、フレームワークに頼らず直接データベースのAPIを通しSQL文を発行するように
プログラム修正が必要ですので、データベース関連の処理を全て見直す必要があります。

新規開発案件時はフレームワークの選別を慎重に行う必要があるでしょう。

世に存在するフレームワークライブラリのおかげで、開発効率が数倍上がるので
ほぼ全て現場で何らかのフレームワークが導入されていると思います。
そしてそれらを可能としている技術が「オブジェクト指向」となります。
フレームワークは多くの「デザインパターン」を参考に実装されています。
とくに「ポリモーフィズム」の概念は絶対に理解している必要があります。

これらをマスターすると、フレームワーク内部が透けるように見えてきます。

オープンソースの発展と企業側の導入が進み便利な世の中になりましたが
また本質を覆い隠す要因にもなりました。

開発チームがフレームワーク自体の不具合のため、開発チームの進捗が硬直した場合に
原因究明と代替案を提示できるエンジニアになると、一気に評価が高まりますよ。