web-dev-qa-db-ja.com

いくつかの行コードのラッパー関数を記述する必要がありますか？

初期の段階では、たった数行のコードしかありませんが、メインロジックの干渉のシリアル化/非シリアル化を伴う、繰り返しの乱雑なコードが多すぎることがわかりました。だから私はチームメンバーにデータの読み取り/書き込み/更新などの操作のための関数をラップするように説得しようとします、例：

 void updateCopyTimes(int times)
  { 
    player->getExtendJson["AcopyTimes"] = Json::Value(times);
    player->updateExtendJson();
  }

  int getCopyTimes()
  {
       const int copyTimes = player->getExtendJson["AcopyTimes"].asInt();
       return copyTimes;
  }

私の意見を支持するポイントは：

1）ラッパー関数を使用すると、適切なコード階層を作成できます。ロジックに焦点を当て、シリアル化/非シリアル化をクリーンにして、どこにも拡散しないようにすることができます。

2）拡張が簡単で、mysqlフィールド（int/string/date ...）、別のmysql jsonフィールドにシリアル化するようにプログラムを簡単に変更できます。変更の影響を受けないメインロジックを使用して、チェックコードを簡単に追加できます。 。

非推奨者は次のように主張します：

1）私たちのプログラムでは、別のシリアル化形式に切り替える機会はかなり少なく、ほとんど不可能です。それをする価値はありません。

2）そのような関数をラップすることは考えすぎです。もしそうするなら、もっと多くのコードを書かなければなりません。そして、私たちが仕事を終えることができるなら、なぜあなた自身を悩ますのですか？

3）そして最も重要なのは、異なる開発者がこのルールに従うのが難しいことです。

つまり、どのような条件（操作タイプ、コード数量...）では、このようなラッパー関数が必要ですか？

c++serialization
5
wangdq

コードを読みやすくしたり、推論したり、保守したりできるようにする場合は、コードを新しい関数に分離する必要があります。

これは、関数に移動する行数とは無関係ですが、コードの小さなセクションの場合、どちらのバージョンが読みやすいかを主観的に判断する呼び出しです。

このようなコードにコメントマーカーが頻繁にある場合

void function_a() {
  some code

  // serialization
  serialization code
  // end serialization

  more code
}

これは、マーカー間のコードを独自の関数に抽出するとよいことを示しています。

3
Bart van Ingen Schenau

ラッパーは、アプリケーションコードからシリアル化を分離します。これは、私にとっては無愛想な「良さ」のようです。依存関係の逆転、単一の責任を参照してください。なぜ人々が基本的なソフトウェア工学の慣行に抵抗するのか、私にはよくわかりません。

5
Nick Keighley

Bartの回答に加えて、そのようなコードを独自の関数でラップすると、各関数の単体テストを簡単に記述でき、入力パラメーターの値とブレークポイント付きの戻り値を確認できるため、テストとデバッグがはるかに簡単になることがわかりました。関数の開始と終了。

あなたの質問に答えるために、私は通常、次の条件下でコードを独自の関数に入れます：

  • 実行されるコードは、他のコードから論理的に分離でき、単一のタスクを実行します
  • コードは複数の場所で再利用されます
  • 単一のタスクを実行するために必要なロジックは複雑ですが、入力パラメーターと出力戻り値が明確に定義されています
  • ロジックは将来変更される可能性があります

ほとんどの場合、あなたの意見は優れたソフトウェアエンジニアリング手法に沿ったものです。この方法でコードを記述するのはより手間がかかりますが、将来の保守性のためには優れています。この種の考え方はまた、単なるプログラマーを優れたソフトウェアエンジニアから分離します。

問題は、「ロジック/コードを独自のラッパー関数に入れるタイミング」だけではなく、「チームメンバーがソフトウェアエンジニアリングのベストプラクティスを採用するように導く方法」です。

コードを書く人の多くは自分のやり方で物事を行う傾向があり、私はあなたが彼らの考え方を変えるのは本当に難しいと思います。残念ながら、ほとんどの場合、顧客は結果を見たいだけであり、ソフトウェアエンジニアは、ベストプラクティスに従うのではなく、仕事を成し遂げて簡単な方法を取りたいだけです。

ソフトウェアの変更に関しては、ソフトウェアエンジニアが優れたソフトウェアエンジニアリングの原則に従っているため、ソフトウェアエンジニアが5時間ではなく5日間昼も夜も急いで作業して変更を行うことが、非エンジニアの観点からより「印象的」に見えます。 。

「正しい」方法で物事を行うことにより、将来追加の作業を行う必要がなく、時間と労力を節約できます。しかし、人間の本質は、それが何であるかということであり、ほとんどの状況で将来よりもむしろ今は報酬を得ようとする傾向があります。これは、ソフトウェアエンジニアリングだけでなく、人生のほとんどの側面（今食べるか、ダイエットするか、支出するか、節約するかを考える）に当てはまります。

この状況はおそらく人間の性質上変化しないでしょう、そしてまた、人々は仕事を成し遂げるために給料を支払われます、可能な限り最善の方法でそれをするためではありません。ただし、雇用と解雇の立場にあると、この考え方を変更できる可能性が高くなります。可能な限り最善の方法で物事を遂行できるエンジニアを選んで選ぶことができます。

2
William L

シリアライゼーションコードを抽出することは、それが本当に簡単なことでない限り、すべてのシリアライゼーションコードが1か所にあるという利点があります。これにより、通常、愚かな間違いを見つけやすくなったり、同じ方法ですべてのシリアライゼーションコードを修正したりしやすくなります（たとえば、すべてのJSONシリアル化コードにnull値の適切な処理を追加します）。

0
gnasher729