Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

ariyasacca

2004|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

2012-03-18 (日) [長年日記]

[Software]辞めていった人達が作ったシステムの保守を楽しいものにする

この辺りの話題を眺めていて思うところあったので少し書いてみる。

別にはてな社やライブドア社がどうだって話ではなくて、システムやソフトウェアを開発する仕事の話です。

まず、大前提として、

  • 新しくスクラッチから書き起こす
  • 既にある機能と互換性を保ちながら改修する

プログラマにとっては、前者の方が圧倒的に楽しい仕事だと思ってます。(最近無くなったらしいけど)グーグル社の20%ルールは、開発者の創造性を巧く引き出せるよう上手に設計された制度です。

ただ、現実問題として、IT業界では後者の仕事を行う機会の方が圧倒的に多い。

私は2011年頃から

  • メイン設計者・開発者は退職してしまった
  • 年に数回は1からスクラッチで書き直そうよという話題が持ち上がっては消える
  • 既に利用者は大勢抱えているので現行版の保守は続けなければならない

といったライブラリ(非常にぼかして書いてます)のメンテナンスを細々と行うのが主要なお仕事です。最初は7人くらいでワイワイと開発してた筈が、いつの間にか1人になっているという。どうしてこうなった。まぁその話は関係ありませんから置いておきます。

あちこちから「イケてない」とか「ドキュメントが使えない」とか文句が来て、実際その通りだし、目の前にあるコードは事実としてクソ設計だという状況で、モチベーションを保つのは結構難しいものです。前任者を呪ってやろうと思った回数は数え切れません。

過去のことをネチネチ言っててもしょうがないので、最近はこういうことを実践して楽しみを見出すようにしてます。

TiDDする
1人TiDD(Ticket-Driven Development)をやります。自分でチケットを切って自分をアサインして自分で返信して自分でクローズする行為は最初、寂しさのあまり死にたくなりましたが、慣れてみると「今やらないといけないこと」が明確になって楽しくなりました。「あいつに仕事を頼む時はチケット切らないと」くらいに思われるのが目標です。
ローカルリポジトリでコミットを育てる
保守しているライブラリそのものはSubversionで管理されているけど、そこにコミットするまでの差分管理はローカルにGitやMercurialでリポジトリを作って育てるようにしています。これはローカルでもコミットしておいて安心感を得たいというのと、今後の自分のキャリアを考えた時、単純に分散バージョン管理システムに慣れておいた方が得策だろうという判断からです。
テストを書く
複数人で開発していた頃にユニットテストが無かった訳では無いのだけど、「察して下さい」レベルの品質だったので、バグ修正の度にテストケースを書き起こして追加してます。小さいながらも新規にコードを書く楽しみが得られるし、次にリファクタリングする時に楽が出来ます。一石二鳥。パフォーマンステストも書いておくと、面白いし数字を減らす楽しみが生まれます。
コードレビューする
リーダーからの提案で始めましたが、割と楽しい行為です。レビューへ提出するために綺麗な差分に整えようという意識が高まります。コミット後レビューであればTracやRedmineのリポジトリビューワ、コミット前レビューならこれまたTracやRedmineの添付ファイル(diff)を使うか、もう少し高機能なものであればReview Boardというソフトウェアが結構イケてます。

レガシーな現場ってどこにでも存在すると思うので、工夫をして楽しく仕事したいなぁと。どこまで実践できるかも、与えられた裁量に拠るところですが、今はそこそこ自由にやらせてもらえてます。

次なる野望はJenkinsで自動ビルドをする、なんだけど、時間が取れなくてなかなか進められない。

本日のツッコミ(全1件) [ツッコミを入れる]
ユーキさん (2012-03-19 (月) 22:33)

作業の負担、難易度については<br>前任者がどんなテンションで辞めたか?ってのが大きいと思います<br>私みたいに害意アリアリで、独占してた作業の引継ぎほぼゼロで<br>いなくなる奴もおるでよ<br>罰ゲームみたいな仕事3年もやらされた意趣返しだと思ってるので<br>自己正当化しちゃいますけども


最近のツッコミ

  1. 雷悶 (2024-11-26(火)19:01)「1年後には能登麻美子さんと早見沙織さんの声を聴き分けられるようになります(できない)。」
  2. ArcCosine (2024-11-25(月)23:11)「すごい声優に詳しくなっている……。」
  3. ともお (2024-05-29(水)20:59)「真上からの恐怖🫨」

参号館  の中の  日記(ariyasacca)