Slack見がち
なぜコードが書けないのか，あるいは仕事が遅いのか - masawadaの日記
に関連して。
むちゃくちゃ雑に書くけど、結局僕は3年前と変わってなくて、しかもこれだけでもなかなか上手く行っている。
今日はもっとIRC見づらくしようと思って、すごいダサい感じの対処方法だけど、クライアントを画面の外の方に押しやって、普通にショートカットでクライアントをアクティブにしても画面の外にあるから見えない状態みたいにしてみた。
仕事の仕方が悪かった - $shibayu36->blog;
あと必要のないチャンネルに入らないことも重要ですね。
そういえば、Slack自体を終了するという戦略を取らない理由もありました。僕はAlfredとかのアプリランチャーでSlackを開くとか、メールアプリを開くとか、そういういろいろが手癖になってしまっていて、結局終了していても見てしまう問題というのがあったのでした。それで、ウィンドウの外に配置して、更新があるかどうかも分からなくしておくと、手癖を実行しても何も見えないので、集中できるみたいな感じでした。
コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは
# TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ...
みたいなやつです。
コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。
最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。
問題点として次のものがあると考えました。
これらの結果として、
などの問題が起こっていそうです。
(1)の形式がバラバラ問題については統一すれば良いだけなので簡単です。テストなどで自動で検知しても良いですが、ひとまずコーディング規約でどれかに統一するように書きました。今回は「TODO」で統一するようにしました。
(2)のTODOコメントの温度感が分からない問題についてはいろいろ試してみましたが以下のようにしてみました。
以上、(1)(2)の解決案により、コーディング規約は最終的に
のようになりました。
ラベルが統一されて、MUSTのみにTODOコメントが付けられて、期限が書かれていれば、TODOラベルが残っていたらまずいということになります。ただし形式が決まっているおかげで、以下のようにしてある期限のTODOを全部洗い出すのも簡単です。これでやるべきことをやる前にリリースしてしまってバグる、みたいなことも減ってありがたいですね。
# 全てのTODOを洗い出す $ git grep 'TODO' # 5/21のTODOを洗い出す $ git grep -e 'TODO' --and -e '5/21release' # 検索リリースのTODOを洗い出す $ git grep -e 'TODO' --and -e 'search_release'
また以下の結果をCIで動かしておいて、適当にグラフ化しておくと、無駄にTODOが増えていないか確認もできてよいですね。
# TODOの数を出す $ git grep 'TODO' | wc -l
今回はTODOコメントを書くときの最近の工夫について書きました。他にもこういうことをしているとかあれば教えて下さい。
id:takc923 必ずやらないといけない期限が決まってるTODOはチケット化してる
id:nntsugu あるリリースまでに解決しないといけないことは、チケットを切ってバックログに積み、Versionを付けておくなりして1箇所に集約したほうが安全かな。"@TODO チケットのURL"とすると現状も確認便利かも。
ブコメでの上の指摘は良い指摘と思ったので、補足を追加します。
まず僕も期限が決まっているTODOはgithubでissue化し、かつチェックリストを作ったりします。ただしそれはTODOコメントと粒度が異なります。
例を使って説明をします。僕は最近はPullRequestは出来るだけ小さくし、新機能を追加する場合もユーザーに見えないようにした上でどんどんmasterブランチにmergeしたりしています。見えない形というのは、「ある機能のページ」や「それへの導線」は開発中にしか見えないようにする、みたいな感じです。その場合、
これによって、「本番でもページを見えるようにする」というgithubのTODOに対して、「どこを直すか」が明確になります。それによって、直すべき場所を忘れるという自体を無くす、もしくは一瞬で直すべきところを把握したいというイメージでした。
他にも「イベントが終わったら直したい」だったら、何をやるかという意味の「イベントのためのハードコードを消す」はgithubでissue化し、コード上のどこを変更するかを表すためにそれに関係するコードの部分にTODOコメントを書く、という使い分けになりそうです。
では「どこを直すか」という部分の細かい粒度のTODOもissueに書けばよいのでは、という話もありそうです。その場合、
という判断をし、TODOコメントにしています。
その他ブコメで指摘がありましたが
投資額の決め方とか、どういうポートフォリオにすればよいかが少し分からなくなっていたので、サンプル例が欲しいと思って読んだ。結構分かりやすかった。
この本は難しいことは考えず、まずはこの手順で投資を始めてみましょうみたいにインデックス投資の始め方を説明してくれている。自分が知りたかったところだと、端的にまとめると以下のような手順でポートフォリオを決めれば良いのではと書かれていた。
またリスク資産に割り当てるお金の上限をどう決めるかに関しては、いろんな方法はあるだろうけど、この本では以下のような手法が載っていた。一つの例として参考になった。
あともう一つ確かにと思わされたのは、リスク資産を取り崩す時の方法について以下のように言及されていたことだった。
少し考えればそうなるということはすぐに分かるんだけど、確かに改めて考えないと嵌りそうだなあと感じた。
総じて参考にはなったのだけど、もしこれだけ読んでいたとしたら本当にこれでいいのかと納得はできなかったと思う。僕自身は昔、「敗者のゲーム」を読んだ知識があったので、まあ確かにこのくらいでいいかもと納得できた。他にもウォール街のランダム・ウォーカーとかまだ読んだことがなかったのでそのへんも読みたい。
