リファクタリングをいつ、どのようにやるか
コードから不吉なにおいがしてきたなーと思うことはよくあるだろう。リファクタリングの機運かもしれないし、YAGNI原則を思い出して踏ん張るときかもしれない。では、いつリファクタリングをやるべきか、どのようにコードを整理していくべきだろうか？ リファクタリングには方針が必要リファクタリングの目的は、コードの拡張性を高めることだ。ここではそういうことにしよう。Open-Closed原則に従うように、凝集度を高め、結合度を低くするようにやっていけばいい。つまり、何か既存機能を変更するときはたった1箇所だけの変更で済むとか、もしくは新しい機能を足すときには既存機能を触らないで済むとか、そういう状態であれば比較的マシなコードになりえるよねっていうことです。 では、あらゆる変更に対してOpen-Closedであることはできるのか？おそらくそれは難しい思う。なので僕らは、経験的に「どの辺に変更が入りそうで
休日にカンファレンスがあるときに、参加者はどうするか？
土日や祝日にフルタイムで技術カンファレンスがあるとして、例えば参加しますよね、そのときにどうするか考えようという提起です。 カンファレンスは疲れるセッションを黙って座って聴いてるだけでもそれなりに疲れるし、せっかく参加するなら登壇者の人を捕まえて話をしたり、他の参加者と議論したり、もしくはワークショップセッションに参加したりとかしますよね。聴いてるだけみたいな参加の仕方をしても「あとで資料だけみればいいや」程度の価値しかないから。なので、フルタイムで1日参加するとそれなりに疲労するわけです。楽しさとは別に。 土日2daysなカンファレンスの場合、前の週フルタイムで働き、土日に疲労し、次の週またフルタイムで働くとか、たぶん働きすぎなので、最低でも次の月曜とかは休みたくなるのが人間ってものだと思います。私はそうする。 平日カンファレンスの参加は休暇を使いますか？CROSS 2016に登壇したと
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
はてな社に修行に行ってきた話
「社会人インターン」と称して2週間はてなのMackerelチームで働いてきましたので、その感想をつらつらと書きます。 おしゃれ感を演出している青山オフィスビデオチャットをいい感じに使ってるはてなといえば本社は京都ですが、東京のど真ん中、青山にもオフィスがあって、以前からビデオチャットでいい感じに中継したり会議したりしてる話は大昔からどこかに上がってた記憶がある。 Mackerel開発チームも東京、京都、その他にメンバーが散っていて、ビデオチャットは大活躍だった。朝会はそれぞれ zoom.us を立ち上げてみんなでビデオチャット。会議室で京都メンバーを交えた打ち合わせをするときは、備え付けのカメラとマイクで会議室の全景を写しつつ、大型モニターには京都の会議室の様子を写しているーというのが日常風景らしい。 こんなスペースでもビデオチャットできる用意がある先日 gitlab.com のトラブルで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
