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

頭の中は異空間

生活を日々ハックしてよりよくするブログ

開発時に事故を防ぐために

どうも。

 

焦っていると凄く事故る!普段何気なくやってることでも、冷静さを欠いた状態だとミスを誘発する!

日常的なことにも何かしらを作っているときにも当てはまる。

特にシステム作っていてミスはつきものなので、出来るだけ起こさないようにマインドセットを書きます。

 


理解していないコマンドは打たない

凄く重要かつ当たり前な話だと思います。スピード重視だとよく分からないけどいつもこれで動いてるからいいや、的な発想でやっちゃうこともあるかも。でもそれが事故の引き金だったりします。例えば手順書にそれぞれのコマンドの意味をコメントで書いてあったとします。でもそれが、インフラ面の構築が変わったためにそのままでは使えなくなっていたとしたら?その時だけ特別に打ってはまずい局面だとしたら(具体的にはservice outしちゃいけないサーバが有るとか)?その時その時で都度考えて打たない場合、手順書通りにやってんのに事故ったぞどうしてくれんだってなります(俺は過去になりました)。

 

ドキュメントやマニュアルを過信しない

ドキュメント、手順書等はそのまま放置される可能性のほうが常に最新に更新され続ける可能性より高いです。多分どこも一緒じゃないかな?だから、手順書に書いて有ることを鵜呑みにするのは非常に危険っていう話です。だから概観と言うかこんな流れなんだな〜っていう感覚だけ掴んで細かいところは最新を知ってる人に聞くのが一番です。面倒だけど。

 

Rの高い重要プロジェクトと運用タスクを同時にやらない

ここでいう同時にというのは、gitとかsvnでいう同じブランチでやらないって意味です。

リファクタリングを大規模にしたくなるときがあります。それなりにRが出て重要なプロジェクトもあります。同時にやる必要ありますか?同時にやれば確かに手間が省けますがそれよりもデメリットのほうが目立つと思います。

 

余計にリリース日が伸びる

リファクタリングは言ってみれば、中の人(主に開発陣)の一方的な主張であってそれを提案したり売る側そしてユーザには一切メリットが感じられないもの。速度改善とかすれば別だけど。使っているサービスが最新の技術が使われているとか◯◯という言語で書かれているとか書き方がキレイだとか、一般ピーポーにはどうでもいいことで、そのために大事なプロジェクトのリリース日伸ばすんじゃねえよって思われている可能性高いと思います。いやもちろんリファクタリング自体はとても大事なんですが。

 

リスクが増える

リファクタリング自体もバグを生む可能性があります。やったほうがいいけど、大元の重要なプロジェクトのリスクと重ね合わせる必要があるか?って話。別々でいいじゃん。

そしてリスクの一端として、リファクタリングとして新たに仕組みを導入する場合、それが完了出来るかどうかというのも含めます。工数がなくて中途半端に導入とかふざけたことすると新旧が混在して余計わけがわからないよ。それリファクタリングじゃなくて改悪じゃんって言いたくなります。

 

 

パフォーマンス悪いときに無理しない

至極当たり前な話。体調悪いとか、前の晩からぶっ続けだとか、頭がまわらないとき。飲酒直後も当然NG。本番触る人が一番守らないといけないです。だからきつかったら遠慮なく主張すべき。本人の意志と裏腹に無理させる奴はカス。

 

1人で突っ走らない

自分が一番だと思わず誰かにレビューしてもらうくらいのつもりで(実際にしてもらったほうが良い)。案外自分で作っているときはその本人が気づけないミスをしていたりするものなので、自分を過信しない方が絶対良いって話です。あと周りに聞きづらいとかそういうのないので遠慮なく困ったら質問してはっきりさせてから先に進むべきです。

 

書いてからよくよく見てみると過去の自分結構地雷踏んでることに気づきました。

SEをブラック化させている要素の1つがこの障害なのは間違いないので、少しでも減らして速く帰ろう!