リファクタリングという言葉一つとっても

リファクタリングという言葉一つとっても、人によって解釈が異なってしまうのでは　というお話。

私が勤めている職場は、中途入社が多い会社で色々な経験や知識を持っている人が集まっている。

そんな環境で仕事を進める時には、「”自分が持っている知識と経験”と”相手の持っている知識と経験”は一緒ではない」という事実を忘れない事が大切だと感じている。

例えば「リファクタリング」という言葉一つとっても

ある人には

「他人がその言葉を使っているのを聞いた事がある。なんかコードを綺麗にする作業でしょ」という認識かもしれない。

ある人には

「コードの重複を省き、共通化する作業」という認識かもしれない。

ある人には

「書籍「リファクタリング」を読んだ事があり、体系化された手続きを理解していて、単体テストが必要で、マルチスレッドに対してのリファクタリングには注意が必要」という認識かもしれない。

ある人は

「リファクタリングとそのゴールの一つにデザインパターンがあると考えていて、「デザインパターン」を読んだ事（学んだ）がある」かもしれない。

ある人は

「機能追加と同時にコードの整理を行う」かもしれない。

このように「リファクタリング」と言う言葉一つをとっても、人によって理解、解釈は異なる可能性がある。そして人に対して、どう解釈しているかを確認する機会は（少なくとも今の環境では）あまりない。(そもそもこのこと自体が問題...なのかもしれないが）。

仕事で関わる人には様々な人がいる。「プログラミングに興味なく、生活の為に仕事をしている」「プログラミングが好きで仕事に積極的な人」などなど。そんな人全員に「リファクタリング」の本を読めとか、「リファクタリングはこう言うものだ」と押し付けることはあまり効果が無いと思う。

だから仕事上では「正しい定義や知識」よりも、「なぜそれを行うか」「具体的に何を行うか」「行なった結果どうなるか」「何を行わないか」という事を、関わる人が共通認識し作業に納得する事が大切ではないかと思う。

自分への戒めとして書き留めておく。