リーダブルコードを読み返した感想

会社の人に、もう一度この章読んでみてと言われたので読み返してみました。
そしたら、いろいろと「あー、最近できてないな」と思うことがあったのでメモ

指定された章は

  • 7章 制御フローを読みやすくする
  • 8章 巨大な式を分割する
  • 9章 変数と読みやすさ

7章 制御フローを読みやすくする

条件式の引数の並び順

この節はふと気を抜くと雑になりがちなので、メモ

左辺: 「調査対象」の式。変化する
右辺: 「比較対象」の式。あまり変化しない。

割りと仕事では日付のロジックをいれることがある。
販売期間内か?という判定のときは

1
2
if Date.today >= start_date ||
Date.today <= finish_date

の方が読みやすいということかな。意識してみます。

if/else ブロックの並び順

  • if 文で条件式を書く際は、優劣や単純さを意識して書くこと
    • メインとなる処理を先に持ってくる

ここは、まぁ…意識できてる…かな?

三項演算子

三項演算子は読みやすくもなるし、読みにくくもなる。
なんでも三項演算子を使えばいいというものでもない。
私自身は、割りと普段から使わないように心がけているので、逆に三項演算子使ったほうが読みやすいのに…。と言われるケースもありますw

do/while ループを避ける

do/while も割りと普段は全く使わないですね〜。
レスポンスに next_page など含まれる場合のときにレスポンスが終わるまでループさせるとか。そういったときにしか使わないので大丈夫かなと思ってます。

関数から早く返す

この節は私はちゃんと意識しないとなと思っているところですね。
ガッとコード書いてふと見たらひとつのメソッドの処理がめちゃくちゃ長くなってしまっている…。ということが割りと多いです。
多分、テストファーストでミニマムにメソッドを追加していくということができていれば自然とできるようになりそうな気はしてます。

ネスト

ついついコードを書いていったら「あー、この判定もしなくちゃ」となってネストが深くなりがちですねw
私の場合は 2 つ以上ネストが深くなってきた時点でメソッドに切り出したりとかします。
それが結局読みやすいコードになっているかは自信が無いですが…。
でもそれを意識すれば、ネストは浅くなるし、早めに返すとか、ループ内部のネストもなくなったりなど自然とできてくるのかなとか思っています。

8章 巨大な式を分割する

説明変数

これは私はよくやりますが、やりすぎて無駄な変数が多くなってしまうことも… (-_-;)
あと、説明変数のつもりでも逆にわかりにくい命名をしてしまい、意味をなさないこともあります。
語彙力ェ…

要約変数

私は条件式の中に似た記述が出た時点で変数に格納したくなるので、この例であれば大丈夫かなと思います。
条件式以外の場面で要約変数ってどこで使うのかな。

ド・モルガンの法則

この法則は忘れがちなのでメモ。
「not を分配して and/or を反転する」
逆は、
「not をくくりだす」

下記は同じ条件式

1
2
!(a || b || c)
!a && !b && !c

これもそうかな…?

1
2
3
if in_stock.blank? || (Date.today < start_date || Date.today > finish_date)
skip
end
1
2
3
unless in_stock.present? && (Date.today >= start_date && Date.today <= finish_date)
skip
end

後者の方がわかりにくいw
あと、不等式も多分反転させる気がする。

短絡評価の悪用

「頭がいいコードに気をつける」
私はあまり頭が良くないのであまり一行でいろいろやったりはしないですねw
ruby だとメソッドチェーンとか簡単にかけますが、私はあえてしなかったり。
同じチームの方でこういうコードを見かねたことがあったので、コードレビューのときにこの話を引き合いにコメントしてみるのも良いかも?

複雑なロジックと格闘し、より優雅な手法を見つける

複雑なロジックにぶつかることも多々ありますが、そこで「反対」から考える。というのがほ〜なるほどって感じでした。

巨大な文を分割する

どこから巨大なのだろうとは思いますが、割りと 3 つ以上条件式が並び始めたら危険な匂いを感じますねw
あと、 “highighted” のタイプミスは全く気付かなかったw

式を簡潔にするもう1つの創造的な方法

重複している処理はメソッドに切り出す…?という理解でいいのかな。
ruby は割りと DRY な原則という文化があるのでこのあたりは大丈夫かも?

9章 変数と読みやすさ

変数を削除する

この節は反省の多い節でした

  • 役に立たない変数
    • 私自身、過剰に説明変数を使いすぎてしまうところがあるので気をつけます…。
  • 中間結果を削除する
    • 私も割りと array とか hash とかの変数を作ってしまいがち…。
  • 制御フロー変数を削除する
    • while 文自体使わないので、割りと大丈夫…かな?
    • あと、 boolean だけ格納する変数もあまり作らないですね〜

スコープについて

  • 変数のスコープを縮める
  • C++ の if 文のスコープ
    • 条件式の中だけで使われている変数は、条件式の中で定義してしまう。というもの
  • javascript で「プライベート変数」を作る
    • 普段から変数を宣言する時は var をつける意識をします
  • ブロックスコープ
    • ブロックで定義された変数はその関数全体に「こぼれ出る」
      • これは知らなかったです
    • でも他の節の「中韓結果を削除する」といったプラクティスを活用すれば未然に防げる
  • 定義の位置を下げる
    • 私は普段は変数の定義は対象の処理の前に行うようにしているので大丈夫かなとは思ってます
    • ただまぁ気を抜くと定義と処理が離れてしまっていることもありそうなので、改めて気をつけます

変数は一度だけ書き込む

これもまぁ意識できているかなとは思います。

以上、感想になります。
普段意識できているところ、意識しないといけないと反省するところがあって、定期的に読み返してもいいのかなと思いました。

participant regional scrum gathering tokyo 2017 二日目

日経電子版 穴のあいたバケツ開発

アジャイルカルチャーが 組織に根付くまでの挑戦

個人プレイからチームプレイへと変革する組織

スケールアップする組織におけるLeSS実践と継続的改善手法

最短で成果を上げる!強いスクラムチームの作り方

期待マネジメント

  1. 目的や背景を確認
  2. 最終的な成果イメージを確認
    →全体像を絵で意識合わせ
  3. クオリティを確認
    →何を持って完了か
  4. 優先順位と緊急度を確認
    →マトリクスで共通認識をつくる
    →いつの時点での共通認識をいれることもポイント
  5. チーム内での期待を交換
    →強み・弱みを共有
  6. 期待値を調整する
    →期待値を下げることもプロとして大切

まずはやってみる

  • はじめから100点は目指さず、60点を目指す
  • 仮説思考
    • あらかじめ仮説を立てる
  • 情報収集
    -

Scrumありがとう、そしてさようなら-Scrum 破-

Regional Scrum Gathering Tokyo 2017 一日目

オープニング

単語

  • 採用でペアプロ
  • mob programingとは

シン・未来会議 - スクラムチームを支える組織づくり -

及部さんの発表
楽天の人

組織の話

  • 最初はスクラムの初め方が多かったけど、最近は組織とか事例の話が多くなってきた
  • 組織はエンジニアだから関係ない、興味ないということも
  • 「うちは・・・だから」
    • 現場とコミュニティとの温度差がある

そもそも組織は変わるべきか?
→ビジネストレンドの移り変わり
→技術の進化スピードの加速
「変化の対応」とその「スピード」が重要

スピード感が出ていなそうなもの

  • 年間計画
  • 評価制度
  • 採用サイクル

これらは本当に変えることが正しいのか?
理由があるのでは
「変える」ことは手段であって、目的ではない

エンジニアリーダーのふりかえりを初めてみた

  • 月一
  • 組織的な技術課題の解決やチームを越えた改善
    →うちでいう週間techチーム?
    その人達内では決められないこともあり、モチベが下がる

組織のふりかえりをしてみた
まず因果関係図を作ってみた
原因と結果がノードツリーでつながるようになるやつ

ループになっているものを見つけた(エンジニア不足を例に)
このループのノードひとつをつぶせさえすれば良い

未来会議
2Hほどでやった
KPT中心の振り返り
課単位で

やりたくないではなく、やっていないだけだった

考えさせられた

  • 今までそれでよかったのか?
  • こんな問題を解決できてなかった
  • このスピード感でいいのか?

「現状維持では、後退するだけである」

つらい問題に出会ったら

今日のお話

  • 仕事ではロジカルに解決できない問題がある
  • そんな問題に「問題をほぐす対話」は有効
  • 対話をやってみませんか?

アジャイルラジオの人
関西からきた

対話に興味を持ったきっかけ

  • 境界線上は、板挟まれてつらい
  • 仕事でも大失敗をやらかす
  • そんなときに本を紹介された
    • 自分を立て直す対話

自分を立て直す対話

  • 組織で働く中で生まれる葛藤、自己矛盾。
  • 無理に解決するのではなく、問題を語り直し、凝り固まった状況をほぐし、問題を問題でなくしていく方法について紹介

にんげんだもの

  • ロジカルに解決できない問題もある
  • 100%分かり合えることなんてない
  • ぐるぐると何年も同じ問題にはまり込む

自分を立て直すとは

  • 自分がとらわれている問題からの脱却 + α
    • 人の力を借りて「問題をほぐす」
    • 被害者から主人公へ
    • 「智慧の車座」

1on1っぽい(感想)
すーさんに相談すると、割りと問題をほぐしてくれている印象がある

智慧の車座

  • 5 ~ 6人で30分から40分
  • 一人の問題を全員でほぐす

掟がある

  • 守秘義務
  • 正解は一つではない
  • 素朴な疑問を大切に
  • 無責任に発言する
    ↑良さそう
    なべはるさんの無責任会議っぽい

不安はあった
→やってみるとすんなりできた
出てきた問題
「お客さんにいいように使われて、裏切られる」
→信頼できないお客さんに、どう接すれば良い?
「現場を良くしていきたいけど、」
「上司の指導が厳しくて折れる。否定されて」
「人に仕事を任せることができなくて、自分がしんどい」
→人を信頼するにはどうすればよい?

  • 短時間で深い本気話になりやすい
  • 自分自身を改めてしり、サポートする人も得るものが多いそう
  • フォーマットに沿えば簡単にできる

  • 同じような役割・立場の人をあつめる

  • 仕事のつながりは薄いほうがいい
  • 計画的に定期的にやらないと終わる
    定期的にやる際、メンバーは変えたほうがいいのか?

How to Energize People - Agile Leadership

ワークショップ

マネジメント3.0とは
3冊の本
幸せまでの12ステップ

  • 感謝
    • カードをBOXに感謝のメッセージカードをいれる。
    • カードをボードに貼った
  • お互いを助ける
    • competence matrix(スキルマップ的なもの)
  • Eat Well
    • ちゃんと食べる
  • Exercise
    • 運動する
    • じげんの社内制度
    • 会社の福利厚生であるね(健康増進補助)
    • CLO(chef life officer)
  • Rest
    • よく休む
  • Experience
    • 新しい経験、学び
    • celebration grid(マネジメント3.0)
  • Hike
    • 郊外にハイキング(自然と触れ合う)
  • Give
    • ギフト。贈り物
  • Meditate
    • 瞑想
  • Socialize
    • 飲み会など
    • Personal Maps(マネジメント3.0)
      • 個人マップ。趣味、関心
  • Aim
    • ゴールや目的
    • Work Expo
    • 会社の中でどんなことを達成できたかを可視化。展示会など
    • フィードテックとかそんな感じ?
  • Smile
    • NikoNiko Calendar
    • green, yellow, orange での気持ちの差を表示している

Play Moving Motivators(マネジメント3.0)
カードはサイトからダウンロードできる

ケーススタディ

  1. team Communication is not good
  2. Job Interview
    面接。志望動機について
  3. New Team or New Project
    新しいチームメンバーなどについて知る

質問
Q. チームで働く必要がない場合、どうすればいいか
A. 社会性などをモチベーションとする人がいる場合は、問題になるかと思います

Q. 2.0 と何が違うのか
A. 1.0 は間違い。トップダウンで全て決まってしまうようなマネジメントスタイル
2.0 は正しい意図を持って。バランス・スコアカードとか、ノー残業デーとか
結局はトップダウンになってしまっている
3.0 が、ネットワークに責任を持って、各々に

Q. このエクササイズをやった際、このカードが選ばれやすいとかある?国の違いとか
A. チームによって違うかなと思います。

Q. カードの中にmoneyがないのはなぜでしょうか?
A. この中に入ってないモチベーションはいくつかありますね。性別、食事など
完全に全てを包括はしていない。作った人が重要だと思ったものだけピックアップしている
逆に給与をあげすぎてしまうとモチベーションが逆に下がることがあることもあるらしい

Q. どうあるべきかの部分でマインドセットでいればいい?
A. モチベーションの結果が、時間で変わってくることはあるのかなと思います。それによる気づきとかはあるかなと

エンジニアの技術力評価は難しい? - 5年間運用してきた相互評価制度の改善の歴史 -

V社の小賀さん
技術評価会の話。他の部署に対してプレゼンするやつ
小さく挑戦
評価を公開(4年経ってやっとやれた)

Kaizen in Action

改善は継続することが大事
チームの改善よりも個人の改善も大事

定期的な休憩(たばこなど)
余裕を出す。余裕がないと改善できない

ECRS
Estimate
Combine
Rearrange
Simplify

瑕疵を分析する
バグを出してしまったさい、それを解決するのではなくプロセスを見ましょう

検知を早い段階でする
Build Quality-In
品質の作り込み

やったことを違うチームでシェアしてみる

生産性の話はしてないです。
より安全に、イージーに仕事をするにはの話

TWI
Training Within Industry

健康大切

余裕の時間
どんなに忙しくても、余裕の時間があると生産性は上がります

ディレクタとして感じたこと

feedforce Advent Calendar 2016の12日目の記事です。
昨日は @Lorentzca さんの去年より個人ブログのポスト数を2倍くらい増やせたのでなぜなのか書くでした✌

アドベントカレンダーも折り返し地点まできました。
2016年が終わるのもあと20日くらいですね。
私、新卒でエンジニアとして feedforce に join し、今年で3年目になりますが、今年を振り返って大きな節目があったので、それについて感じたことを書いていきます。

Read More

結局pairsは出会いの場を提供しているだけである

カノジョできないエンジニア Advent Calendar 2016の3日目の記事です。
昨日はServerman@VPSでOpenVPNを作ってくれるbashでした。
連日techな話を踏まえた記事があがっていますが、そんなの関係ねぇ!!!!!!!!!
もう私は振り切って、出会い系アプリってぶっちゃけどうなん?という話しかしないです。

ちなみに昨年も 出会い系アプリを使っても彼女ができない件 という内容で投稿しており、その第二弾、続きです。

なぜ昨年と同じネタで今年も投稿しているのか!!!!!!!!!!!
察してください。

Read More

ISUCON6 のオンライン予選に参加しました

2016/09/17(土)と2016/09/18(日) に行われた ISUCON6 のオンライン予選の2日目に参加しました。
ただまぁ、結果は惨敗でした。。。
でも MAX で一応 1 万点までいけたので嬉しかったです。

1
2
Score 9431
Best 11145

とはいえ、途中トップのチームが 40 万点とか出してて心がくじけました。。。
つらつらとやったことと良かったこと、次回に向けてをまとめていきます。

Read More

便利なRubotyプラグインの紹介

この記事はDark - Developers at Real Kommunity Advent Calendar 2015 - Adventarの21日目の記事です。

SlackのDarkチームに “ray” という名前でRubotyを入れているのですが、”dark”というhubotの方が圧倒的に使われています。
それが悔しいので、Rubotyの便利なプラグインを知ってる限りで個人の独断と偏見でひたすら紹介していきます。

Read More