20240724

FIXME with types

個人開発では割と「緩い(loose)」コミットを許容している。 仕事だともう少し推敲したりするようなところでも FIXME コメントとともにコミットしてしまうことが多いが 個人開発は継続性に重点をおいてこのようなスタイルにしている。Conventional Commits ならぬ Conventional FIXME と言えるかもしれない。

そんな感じでコミットを重ねていくと自然と FIXME が増えていくことになるが、そのうち FIXME もいくつかの種類に分類できることに気がついた。 Conventional Commits 同様、FIXME にも「型」を導入すると理解や検索の 点でよいかもしれない。

現在、思いつくのはざっと以下の通り。HANDLE ERRORS, O11Y(Observability), NEED TEST は機能が 一通り整ってから取り掛かるなど自分なりの開発方針を立てると、完璧主義の罠にも陥らずにすむし nitpicker にもならずにすむ。

• WRITE BETTER
• HARD CODING
• SENSITIVE DATA
• PERFORMANCE
• UGLY APPEARANCE
• NEED MORE
• NOT WORK
• HANDLE ERRORS
• O11Y
• NEED TEST

Rails にはサブコマンドの notes があるが、単純に FIXME の文字列で検索して表示しているわけではないようだ。

$ bin/rails --help | grep notes
notes                              Show comments in your code annotated with FIXME, OPTIMIZE, and TODO

$ bin/rails notes
app/controllers/auth_controller.rb:
* [55] [FIXME] WRITE BETTER
* 

$ rg FIXME 
app/controllers/auth_controller.rb
55:    # FIXME: WRITE BETTER

app/views/chartulas/_chartula.html.erb
13:      <%# # FIXME: NOT WORK %>

app/views/application/_outside_pages_navbar.html.erb
50:          <!-- # FIXME: HARD CODING -->

app/views/application/_inside_pages_navbar.html.erb
28:          <!-- # FIXME: HARD CODING -->

app/views/layouts/application.html.erb
13:  <!-- # FIXME: toggle_light_and_dark_mode
26:<!-- # FIXME: toggle_light_and_dark_mode

自分なりの開発プロセス標準

同様に、 自分の中で開発プロセス標準を定めておくと無理に進捗に焦らなくてよくなる。 5. Groundwork 時の Refactoring 時に集中して FIXME を直すと決めておけば精神衛生的にも気持ちの整理がつく。 例えば、私の Web サービスの開発プロセスの標準は以下の順番がベストプラクティスになっている。

2024-07-24 22:08:05 +0900 +0900