コードレビューと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が好きで
WEB+DB Press Vol.101のPerl Hackers HubにAnikiに関する記事を寄稿しました - 時計を壊せ
このブログを読む方にはご存知の人が多いと思いますが、ぼくはAnikiというO/Rマッパを2015年に初めてリリースしました。ふざけた名前ですが実装と機能は真面目です。 イメージとしてはTengを自分なりにブラッシュアップしつつ少し高機能にして拡張性を高めたモノという感じです。 2016年に安定版となる1.00をリリースし、この記事を書いている今現在の最新版は2017/07/20にリリースした1.06になります。 metacpan.org 今の時代にO/Rマッパはとてもありふれており、枯れています。 安定したO/RマッパとしてはPerlだとTengやDBICが挙げられるでしょう。 では、そんな時代にO/Rを新しくつくる意義ってあるの？どうやってつくるの？Anikiはどうなってるの？という疑問は当然湧いてくることでしょう。 その問いに対する自分なりの答えとして「Anikiで学ぶ実践的なO/Rマ
ORDER BY狙いのキーが何故速いか - 時計を壊せ
どの最適化が効くんや…とググった。 以前も調べた気がしたが思いだせず、ひたすらググる羽目になったので、 反省してブログに残す。ふつーにmysqlのdocumentに書いてあった。 http://dev.mysql.com/doc/refman/5.7/en/limit-optimization.html If you use LIMIT row_count with ORDER BY, MySQL ends the sorting as soon as it has found the first row_count rows of the sorted result, rather than sorting the entire result. If ordering is done by using an index, this is very fast. バージョン古いけど日本語のほ
クソコード、あるいは技術的負債 - 時計を壊せ
クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
