tawara's blog

雑記。個人の見解です。

Re: 頭の中のコードを形にするまで

bufferings.hatenablog.com

とても良かった。普段、キャリアのあるエンジニアの方がどのように開発をしているのかを、ステップに分けて説明されている。エンジニアとして二年目になるが、ただ開発しているだけという課題感が強い。もっとよいコードを書けるようになりたいと思っているのだけれど、取っ掛かりがわからずもやもやしていたので記事の内容は深く刺さった。いまの自分は記事でいうところの「とりあえず動くものを作っている」だけだと気づいた。もちろんテストも書くことはあるが、それはとりあえず動かすために書いたコードにあわせて、ユニットテストを書いているだけに過ぎなかった、ということが相対化できた。

特に「小さく分割する」という観点は恥ずかしいが、まるでなかった。技術書やネット記事でその重要性には触れているはずだが、普段の業務まで落とし込めていなかった。どうやってコードを改善したらよいのか、という一つの回答だと思う。この気付きで普段抱えているもやもやが8割くらい削れた。あとは、小さく書く技術を取得すればいいのだ。課題が明確になったので、行動を変えることができるはずだ。たぶん。

現場にいる強いエンジニアのPRをレビューするときに感じていた美しさ?は「小さく分割する」ことによってなのだと確信した。そこで、こういう記事見つけたんですけど、やっぱり意識してます? と聞いたら、してるよー と教えてくれた。優しい。具体的には次のようなことを念頭に置いてるみたい。

  • 関数の中身はできるだけ行数を書かない
  • 関数の入力と出力をきちんと意識する
  • 複雑な処理はコードを書かずにまずは関数とコメントだけで構成をつくる
  • ロジックはControllerに処理をかかず、Modelに処理を書くように意識する
  • 1ファイルは1000行を超えないようにする(超えるようなら用途で分割する) など

「複雑な処理はコードを書かずにまずは関数とコメントだけで構成をつくる 」これとかすぐに実践したほうがよいと思う。とても勉強になった。

また元記事には「いったん見てもらう」という工程がある。これは良いなと思った。いまのチームにはない文化なので、実践してみようかと思う。チケットに対するコードの知識がわりと属人的になっているのはチームの課題だと思っている。その解決策にもなり得るかなと思う。

かなり勉強になった。

(了)