日々の記録。

プログラミングのメモや感じた事などを記録。

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

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

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

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

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

ある人には

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

ある人には

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

ある人には

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

ある人は

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

ある人は

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

自分が言うまでもなく、「リファクタリング」と言う言葉一つをとっても、人によって理解、解釈は異なっていると思う。そして人に対して、どう解釈しているかを確認する機会はあまりない。(自分がどう理解しているか、を認識する事もあまり無いかもしれない。)

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

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

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

上で述べた事とは異なるけど、言語仕様や製品ドキュメントについては、せめて一次ソースを当たる事が大切だと思う。「言語仕様とリファクタリングの差が何か」を説明するには、まだ自分の中でまとめきれていない。仕様として規定されているか、思想かの違いか・・・?