読者です 読者をやめる 読者になる 読者になる

歩きやすい道と歩きにくい道

最近思うのがどんないいプログラムでも時間が経つと旧式化し老朽化しうるということ。
それも意外と早く。それに対してプロダクトの寿命はずっと長いということ。

それで困るのが、そのときは最善なコードを書いた、ちょっと先のことも考えて柔軟性も持たせた!しかしここのメンテ辛いなぁ。。。というケース。

ただそこにもいろいろ話があって、

そのメンテしようとするプログラムが機能追加することが多いとか、パフォーマンス対策でよく改修が必要なところとかだと比較的変更しやすかったり

一方、機能追加があまりないとか、特に問題が発生せずいい感じに動いているプログラムはいざメンテしようとすると難しさを感じることがあります。


!

世話のかかるプログラムほどメンテ、継続的な改善がしやすい?

人がよく歩く道は整備され歩きやすい、
人がめったに歩かない場所は整備がされておらず歩きづらい。

ということは現実の世界でよくある話かと思います。
これと同じことがプログラミングでもありそうです。

"人がよく歩く道は整備され歩きやすい" というのは、"そのメンテしようとするプログラムが機能追加することが多いとか、パフォーマンス対策で改修することが多いなどの場合は比較的変更しやすい " という場合です。
一度自分が行った改修箇所についてはその知見があるため安心感があります。自分でなくとも先人が行った改修、作業と同様の作業などは安心感があります。もしかしたらそこに何か罠があったのなら先人がすでにそれを踏んだあとだったり。
あとは、そのプログラムの開発当時にはできなかった、実際に稼働した後だからこそできる改善がされていることもあります。開発当時よりも仕様がより明確になっている、新しい技術が取り込まれている、など


"人がめったに歩かない場所は整備がされておらず歩きづらい" というのは、 "機能追加があまりないとか、特に問題が発生せずいい感じに動いているプログラムはいざメンテしようとすると難しさを感じることがあります" の場合です。
まずそのプログラムを理解する必要があります。そのうえで、ここのプログラムをこうすればよさそう!とわかってもありうるリスクを検討する必要もあります。本当に?他によくない副作用はない?万が一のときの影響範囲は?などなど


!


では、継続的な改修のしやすさのためにどうするか

完璧なプログラムなんてないので必要なときに必要な改修はやはりする必要があります。
対策としていくつか、

  • テストを書く(道の例えで言うと、その道がどこからどこにつながっているかを示すこと)
  • CIを回す(交通量を増やす)
  • 監視、アラート
    • そもそも改修が必要な時がわからないといけないので。道が崩壊していたらなるべくはやく気づいて対応したい
  • 可読性
    • 国道 or 酷道
    • 不要な道は作らない
      • => やっていることがわかりやすいプログラム
      • => コメント、ドキュメントも一度書いたならその後のメンテが必要なもの。コメント、ドキュメントを書くのに時間を割くよりはそのコードに注力したい
      • => そのプログラム(道)を見る(通る)人が誰なのか
  • 重要な処理部分で問題が起きないように
    • 道のたとえで言えば、通行止めをする
    • => 権限で制御、ネットワークで制御
    • => 盛大に落ちるテスト、監視
  • ここにコードが集中しそう
    • 道のたとえで言えば、道でないところをショートカットしようとする対策。あえて歩きづらくするとか
    • => 用途を絞った命名にする、とか
    • => 使っているライブラリ等のバージョンのチェック

!



コードを生き物と表現される方もいますが、ここでは継続的改修のしやすさに注目して「道」と表現してみました。

emphコマンド released - コマンドライン出力をカラーリング

すでにカラーリングツールはいくつかあると思いますが、
「〇〇の構文を解析して色付けする」というのではなく、ログなどの時系列なデータ向けに、
一行単位で完結するカラーリングツールがほしいと思ったので作ってみました。
golang製。

インストール

$ go get github.com/karahiyo/emph

適当に楽しむ

$ git clone git@github.com:karahiyo/emph.git
$ make install
$ make integration_test

使い方

カラーリングの設定はtsvな設定ファイルとなります。
第一カラムに色付けしたい文字列を正規表現で書いて、
第二カラムに mgutz/ansi · GitHub のStyleFormatの仕様でカラーリング設定を書きます。

$ cat ~/.emph/nginx
"^[0-9.]*"    "246"
"200"         "green"
"500"         "black+bB:red"
" \[.*\] "    "63"
"GET"         "46"

$ tail -f /var/log/nginx_sample_log | emph -c ~/.emph/nginx

すると、こんな感じに、

f:id:karahiyo:20150524154645p:plain

見やすそう!
といってもこれくらいなら、色付けしなくとも500でgrepするくらいで十分そうですが。。。


(おまけ)サンプルニンジャ
f:id:karahiyo:20150524155222p:plain

Haskell練習 ~LifeGame

最近H本読み進めています。

今回はその練習で、LifeGameをしてみました。

初期状態をランダムに決めたいとSystem.Random使おうとしたらおっ!?となったのでいったんここまででmm

https://github.com/karahiyo/LifeGame_Haskell

何かしらのサービスを運用するようになって、のポエム。

人は何かしらの仕事をします。

仕事とは

何かを作り出す、または、成し遂げるための行動。 https://kotobank.jp/word/%E4%BB%95%E4%BA%8B-73099

なぜなら何かを成し遂げるためには、仕事をする必要があるからです。

エンジニアという人も何かしらのために仕事をします。

そのゴールの一番大きいのはおそらく、ユーザに価値ある何かしらのサービスを提供し、売上をあげることかなと思います(政治的に正しくない表現ですmm)。

その大きなゴールの達成のための手順はなかなか見えないので、より具体的な小さなゴールを設け、それを達成するために仕事をします。

で、今回私はその小さなゴールを達成できる仕事(=いい仕事)をするためには、を考えています。

仕事とは、何かしらのゴールのための意思決定の繰り返しと考えると、 話が単純であるなら、そのひとつひとつの意思決定がいい感じならその仕事もうまくいきそうに思われます。

では、いい感じの意思決定とは。

それについて、少しですが思うところを書きます。

設計、コーディングの中での意思決定

問題解決の方法がいくつか考えられるケースでは、どの方法を選択するか考える場面があるかと思います。

単純なコードレベルの比較であれば、簡潔であるか、軽量であるか、読みやすさ、保守性があげられると思いますが、それだけで答えが出ないのが現場の設計、コードなのかと思います。

いい仕事きれいな設計、コード

例えば、保守性よりも万が一の時のリスクが少ないものを選択するケースなど。

例えば、考える事をあとにする。あとから柔軟に対応できる(リリース時の心配事を含め)ことを保証して。

一回の実践のために

「一回だけでも実践してみると、頭の中だけで考えていたことの何倍も学びがある」

エンジニアであれば、テストを書くみたいな話に通じるところがありそうです。

では、本番系で一回の実践をしたいという話となるとでうでしょう。

=> どうやって一回の実践をするか

例えば、

  • 本番系での実践のリスクを小さくする
    • => 事前に
      • 影響範囲を小さくする
    • => 事後のために
      • リカバリ手順を考える
  • 本番系で実践しないとわからない、という状況自体を避ける
    • => 今後も改修のたびに ”一回実践してみないとわからない” のしがらみをつくるのか?
      • その仕事を捨てる
      • 別の方法を探す

以上、ポエムでした。

PS: 人工のコードも面白いですが、現場にしかない天然もののコードに最近はより興味。「大局観」磨きたい。

DoはPerfectで、何がBetterか。

“Done is better than perfect.”
~ 完璧であるよりも、終わらせる方がいい ~

Perfectよりも優れているDoとはなにか。
それはおそらくその時の環境におけるBestなDo。

『あれ、、、もしかしてトイレットペーパーとか持ってない?』
『ティッシュなら』

これがBestなDoneであり、その相手の課題の解決にはほぼPerfectであるDoかもしれない。

『あれ、、、もしかしてトイレットペーパーとか持ってない?』
『トイレットペーパーがなくて困っている人のための宅配サービスを作りましょう!』

穴はあるがこれが根本的な解決策だと考える、がしかしこの時の相手にとってはそれは解決策なりえない。
PerfectだがBestなDoに劣る例である。

つまり、“Done is better than perfect.”の文脈でのPerfectとは、今の課題ではなく将来の課題(まだ見えていない)に対するPerfectなDoのことであり、これは"そのときの環境でのBestなDo"に劣る。

“Perfect of right now is better than perfect of the future.”

“Done is better than perfect.”の文脈でのPerfectというのは解決しようとしている課題を膨らましすぎているのではないだろうか。

決してDoしとけばいいというわけではない。

求められている課題に対する"今必要なPerfect"をBestな形でDoするべき。

いい仕事をしようと思うのなら、今必要なPerfectのための課題を正しく把握し、
決して未来のPerfectという今すぐ必要ではないもの、はっきりと必要と見えないもののための課題をおいてはいけない。

顧客が本当に必要だったもの、とは
http://ninetailsfox63.hatenablog.com/entry/20110518/1305731666
http://cdn-ak.f.st-hatena.com/images/fotolife/n/ninetailsfox63/20110519/20110519000330.jpg


求められている課題に対する"今必要なPerfect"をBestな形でDoするべき。
といっても、Doしておけばいいわけではなく目指すべきは常にPerfect(今必要なPerfect)でありDoneで妥協しては行けない。


というポエムでしたmm


(追記)
そもそもPerfectな仕事とは。。。銀の弾丸的なもの?幻?よくわからない。
それなら今見えている課題に対してDoした方がいい!という解釈もありそう。

© karahiyo