コードレビューとPull Request、そしてその承認機能の副作用について考える - 時計を壊せ
用語 レビュアー 対象となるコードをレビューする人のことを指します。 レビュイー レビューを受ける人、つまりレビューする対象のコードを書いた人のことを指します。 tl;dr アプリケーション開発業務におけるコードレビューはコードの正しさや質そして一貫性を保ち、それらと同時にコードに対するチームとしての共有知を作り上げる良いプラクティスだと思います アプリケーション開発チーム内でのコードレビューにおいてPull Requestを使ったレビューのスタイルは一般的ですが、Pull Requestの承認は実際にはほとんど意味がないのではないでしょうか？ ほとんど意味がないにも関わらず、承認の有無によって業務フローが左右されることでそれが権威的に扱われてしまいオーナーシップを希薄化させ、結果的にコードレビューのコストが増加したりそれを行う目的を見失ってしまっていることはないでしょうか？ Pull R
Japan Perl Associaton代表理事に就任します - 時計を壊せ
SEE ALSO: blog.perlassociation.org なぜ平成も終わるこのご時世に？と思う方もいらっしゃると思います。 思いの丈を書いてみます。 昨今のWeb開発のトレンドとしては、動的型付け言語から静的型付け言語へシフトが進んでいます。 また、PaaS/SaaS/FaaSの普及により言語選択よりも技術選択とそのアーキテクチャがより重要になってきており、 *1いちプログラミング言語の重要性というものは、(特に動的型付け言語においては)昔ほど重要ではなくなっているのが実情かと思います。 その中でもPerlは、人気度でいえば比較的低い言語といえるでしょう。 LLと呼ばれる言語の中で最低の人気と言っても間違いではないかもしれません。 ひどいときには、1987年に作られたPerlと1959年に作られたCOBOLが並べて語られることすらあります。*2 それでも、ぼくはPerlが好きで
Job-Queue Workerの実装を管理するdaemon - 時計を壊せ
Message Queueとか だいたいみんな、Message QueueとしてGearmanとかQ4MとかResqueとかRabbitMQとかZeroMQとかまあたくさんあるけど、なにかを使っていると思う。 Perlの人だとQudoとかTheSchwartzとかをつかっている人も多いと思う。 でも、preforkなworkerを実装するとなるとSignal処理とかをちゃんとやるのが意外と難しい。 下の2つのスライドを読むと難しいんだなぁという事がなんとなくわかるとおもう。 YAPC 2012 - 続・Mobage を支える技術 Unix Programming with Perl 2 graceful shutdownとかgraceful restartとかは欲しいし、max_reqs_per_child的なこともしたいし、時間が掛かり過ぎているjobはリトライして新しいworkerで処
gitで新しくブランチを切るベストプラクティス - 時計を壊せ
普段から普通にやっている方法です。 git fetch git checkout -b $BRANCH_NAME origin/master git push -u origin $BRANCH_NAMEgit fetchでoriginを最新にして、origin/masterからブランチを切ります。 これで、プロジェクトの最新の状態からbranchを切る事が出来ます。 現在どのbranchに居るかを気にせずとも、branchを切る元を間違える事がないので安心です。 （例えばうっかり関係ないtopic branchから切ってしまう。といったことを気にしなくて良くなります。） また、git push -u origin $BRANCH_NAMEすることにより、 リモートブランチがupstreamとして紐付く為、いちいちgit pull origin $BRANCH_NAMEとかしなくて良くなり
クソコード、あるいは技術的負債 - 時計を壊せ
クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
