大規模な Android アプリをリファクタリングする前にしたこと - ┗┐＜(՞ਊ՞)＞┌┛

メリークリスマス！！この記事は、はてなエンジニアアドベントカレンダー2016の25日目の記事です。昨日は id:tarao による 開発速度と品質のトレードオフの判断基準の合意 でした。 僕は id:funnelbit と言う者です。はてなでは Android アプリを担当しています。 突然ですが、ソフトウェアというものは腐ります。腐るというのは、メンテナンス性が失われたり、機能追加が困難になってくることを指します。原因は複雑なコードが絡み合ってしまったり、ライブラリのバージョンが古すぎたり、もはや世間では時代遅れのライブラリをつかっていたり等です。特に長期間問題を放置すれば腐りやすくなります。 こうなってくるとエンジニアとしてはリファクタリングを考えるようになります。リファクタリングには規模の大小があり、リネームやモデルの修正程度で済むものから、アプリ全体の設計を変更せざるを得ないケース

[halfrack]

良い

[braitom]

リファクタリングをする際、事前に考えるべきことがまとめられている。Androidアプリだけでなく一般的に使える内容。

[kikuchy]

作業状況を可視化したい…！　まずはリスト化…

[bigchu]

リファクタリングの目安の時間、期間大事よな...致命的じゃなきゃだらだらやっちゃう。

[to4iki]

"なぜリファクタリングをするのかを明確にする"

[Rei19]

名前大事ですね。うちだと主語と目的語がごっちゃになって英語的におかしくならないようにとか観点に入れてます

[saku_na63]

わかりがありすぎる