「副作用」の版間の差分
Administrator (トーク | 投稿記録) |
|||
(4人の利用者による、間の8版が非表示) | |||
1行目: | 1行目: | ||
− | '''副作用''' | + | '''副作用'''(読み:ふくさよう)とは、[[プログラミング]]において、ある[[メソッド]]の[[引数]]と[[戻り値]]以外の要素が、そのメソッドの動作に影響を及ぼすことをいう。 |
==概要== | ==概要== | ||
− | + | [[プログラミング]]における副作用とは、[[グローバル変数]]などの要素がある[[メソッド]]の動作に影響を及ぼすことをいう。本来であればメソッドの[[引数]]と[[戻り値]]だけを考慮すればいいはずであるが、メソッド内部で[[グローバル変数]]を参照するなどしていることにより、それらもすべて把握していなければそのメソッドを利用することができないという状態である。 | |
==オブジェクト指向で顕著になる== | ==オブジェクト指向で顕著になる== | ||
− | + | 副作用はとくに肥大化した[[オブジェクト指向プログラミング言語]]を使用したプロジェクトで問題視されることが多い。 | |
− | + | たとえば[[C Sharp|C#]]などの[[クラスベースオブジェクト指向]]における[[フィールド変数]]([[言語]]によっては[[メンバ変数]]や[[インスタンス変数]]とも呼ばれる)や[[プロパティ]]は、実質的に[[C言語]]などの[[グローバル変数]]となんら変わらなく、その内容がメソッドの動作に影響を及ぼすため、これらをすべて把握していなければ正しい利用は難しくなる。 | |
+ | |||
+ | また、[[オブジェクト指向]]では[[フィールド変数]]や[[プロパティ]]が[[クラス]]になっていることも多いため、その先々の[[フィールド変数]]や[[プロパティ]]がもたらす副作用まで同様にすべてを把握していなければならない。[[オブジェクト指向]]は小規模なうちは[[C言語]]における[[グローバル変数]]よりも影響範囲は少ないように思えるが、プロジェクトが肥大化し階層構造が複雑化した後には[[デスマーチ]]への片道切符であるといえ、まさに「[[階層化の有害性]]」であるともいえる。 | ||
プロジェクトの規模が小さいうちは問題になることは少ないが、複数人が関わるプロジェクトでは認識の食い違いなどが発生し、最終的に殴り合いになる。 | プロジェクトの規模が小さいうちは問題になることは少ないが、複数人が関わるプロジェクトでは認識の食い違いなどが発生し、最終的に殴り合いになる。 | ||
14行目: | 16行目: | ||
これらを回避する目的で様々な手法が考案されている。 | これらを回避する目的で様々な手法が考案されている。 | ||
− | + | ===プログラミング言語レベルでの回避策=== | |
+ | 副作用をもつ[[プログラミング言語]]を根絶しよう考案されたのが[[関数型プログラミング言語]]である。 | ||
+ | |||
+ | 関数型といっても[[JavaScript]]など多くの[[プログラミング言語]]は「副作用を低減しよう」というものであり、逃げ道的な要素を残していることが多く、まずは[[プログラマー]]の教育が非常に重要な要素となる。 | ||
+ | |||
+ | 一方で副作用を絶対悪とし完全排除を試みた[[プログラミング言語]]もあり、それらは「[[純粋関数型プログラミング言語]]」と呼ばれる。たとえば[[Haskell]]などでは[[引数]]と[[戻り値]]がすべてであり、それ以外は絶対に許されないという言語仕様で副作用を封じ込めている。ただ純粋関数型であっても業務システムではほぼ必須となる[[データベース]]などの広く共有する部分が[[グローバル変数]]的に機能するため副作用の完全なる排除は難しいのが実情である。 | ||
− | その他にも急激な変化は難しい[[プログラミング言語]]などは現状維持し、プロジェクトに関わる人々の人事などで副作用を軽減しようという手法が考案されている。それらをまとめて最近では「[[アジャイル]] | + | これらに移行するには慣れと経験が必要であり学習能力の低い[[プログラマー]]には難易度が高いという問題点を抱えている。 |
+ | |||
+ | ===プロジェクト運用レベルでの回避策=== | ||
+ | その他にも急激な変化は難しい[[プログラミング言語]]などは現状維持し、プロジェクトに関わる人々の人事などで副作用を軽減しようという手法が考案されている。それらをまとめて最近では「[[アジャイル]]」という。 | ||
+ | |||
+ | ただし[[ペアプログラミング]]や[[RAIDプログラミング]]は、[[派遣社員]]が大半を占め、[[人的リソース]]の入れ替わりが激しいに日本でこそ有意義な仕組みであるが、日本では実践しているという話はあまり聞いたことがない。 | ||
+ | |||
+ | また、やらないよりはマシな程度の効果ではあるが[[コードレビュー]]も有効であるとされる。 | ||
==関連項目== | ==関連項目== | ||
22行目: | 36行目: | ||
*[[人月の神話]] | *[[人月の神話]] | ||
− | + | [[category: プログラミング]] | |
− | |||
− | |||
− |
2024年3月13日 (水) 01:22時点における最新版
概要編集
プログラミングにおける副作用とは、グローバル変数などの要素があるメソッドの動作に影響を及ぼすことをいう。本来であればメソッドの引数と戻り値だけを考慮すればいいはずであるが、メソッド内部でグローバル変数を参照するなどしていることにより、それらもすべて把握していなければそのメソッドを利用することができないという状態である。
オブジェクト指向で顕著になる編集
副作用はとくに肥大化したオブジェクト指向プログラミング言語を使用したプロジェクトで問題視されることが多い。
たとえばC#などのクラスベースオブジェクト指向におけるフィールド変数(言語によってはメンバ変数やインスタンス変数とも呼ばれる)やプロパティは、実質的にC言語などのグローバル変数となんら変わらなく、その内容がメソッドの動作に影響を及ぼすため、これらをすべて把握していなければ正しい利用は難しくなる。
また、オブジェクト指向ではフィールド変数やプロパティがクラスになっていることも多いため、その先々のフィールド変数やプロパティがもたらす副作用まで同様にすべてを把握していなければならない。オブジェクト指向は小規模なうちはC言語におけるグローバル変数よりも影響範囲は少ないように思えるが、プロジェクトが肥大化し階層構造が複雑化した後にはデスマーチへの片道切符であるといえ、まさに「階層化の有害性」であるともいえる。
プロジェクトの規模が小さいうちは問題になることは少ないが、複数人が関わるプロジェクトでは認識の食い違いなどが発生し、最終的に殴り合いになる。
回避策編集
これらを回避する目的で様々な手法が考案されている。
プログラミング言語レベルでの回避策編集
副作用をもつプログラミング言語を根絶しよう考案されたのが関数型プログラミング言語である。
関数型といってもJavaScriptなど多くのプログラミング言語は「副作用を低減しよう」というものであり、逃げ道的な要素を残していることが多く、まずはプログラマーの教育が非常に重要な要素となる。
一方で副作用を絶対悪とし完全排除を試みたプログラミング言語もあり、それらは「純粋関数型プログラミング言語」と呼ばれる。たとえばHaskellなどでは引数と戻り値がすべてであり、それ以外は絶対に許されないという言語仕様で副作用を封じ込めている。ただ純粋関数型であっても業務システムではほぼ必須となるデータベースなどの広く共有する部分がグローバル変数的に機能するため副作用の完全なる排除は難しいのが実情である。
これらに移行するには慣れと経験が必要であり学習能力の低いプログラマーには難易度が高いという問題点を抱えている。
プロジェクト運用レベルでの回避策編集
その他にも急激な変化は難しいプログラミング言語などは現状維持し、プロジェクトに関わる人々の人事などで副作用を軽減しようという手法が考案されている。それらをまとめて最近では「アジャイル」という。
ただしペアプログラミングやRAIDプログラミングは、派遣社員が大半を占め、人的リソースの入れ替わりが激しいに日本でこそ有意義な仕組みであるが、日本では実践しているという話はあまり聞いたことがない。
また、やらないよりはマシな程度の効果ではあるがコードレビューも有効であるとされる。