2016-04-03

ES6をしばらく使ってみての所感

ここ数ヶ月、お仕事で以下構成での開発をしています

React
Redux
ES6

徐々に解ってきたと思う（たぶん）ので、感覚がホットなうちに備忘も兼ねて整理。

※個人的な感想も含みます。

良かったところ

React : コンポーネント再利用時の安心感

いままで → なんか心配

従来は、フロントエンドはjQueryをメインに開発をしていました。

jQuery プラグインするなど、後々再利用可能な形で部品化することは従来も行っていましたが、いざ使う時に「これ本当に大丈夫か？」という気持ちになることも多々。

他のプラグインとの相性は？
名前空間の汚染がないか？
依存するHTML上のid/class/attributeで悪影響がないか？

ルールを徹底したり、ドキュメントとして注意点をちゃんと残しておいたりすればある程度は回避できますが、最後は「ある程度覚悟して信頼する」という工程を通っていたと思います。

React : あんしん

Reactでお約束に則ってコンポーネントを作成していくと、propsベースとなり内部には状態保持せず、かつコンポーネント外のDOMには影響を与えない作りとなります。

直接DOM操作もやろうと思えばできるため、100%安心！というわけではありませんが、ポイントなのは「基本的に作ってれば大丈夫」というところだと思っています。

気をつけていれば安全なコンポーネントにできる
特殊なコードを書いたときだけ安全ではないコンポーネントになる

では大きな差があると思っていて、後者のほうが圧倒的に信頼できます。

React : パフォーマンスの改善がしやすい

無心でひたすらコードを書いていくと、徐々にパフォーマンスの劣化が気になってきます。その時に、パフォーマンス改善のためのツールが用意されているのは大きかったです。

今のところほとんどのケースにおいては

Perfomance Tools でボトルネックになってるコンポーネントを探す
shouldComponentUpdateでがんばる

でだいたい問題とならないレベルまで改善が可能でした。パフォーマンス劣化時に、問題となる範囲が想定しやすいのも良いですね。

jQueryをdisっているわけではありませんが、効率の悪いセレクタを探したりDOMの操作回数をできるだけ減らす努力をしたりして地道に頑張っていたのはなんだったのかと。

（とはいえ、対応できないレベルのパフォーマンス問題にぶつかったら考えは変わるかもしれません・・

ES6 : たくさんの幸せ

ES6が便利すぎて半端じゃないです。ES6なしではjs書けない体になりました。

アロー関数

コールバック系が書きやすいし読みやすい
self = this がいらない幸せ

spread operator

argumentsって書く頻度が激減

スコープまわりのあれこれ

ブロックスコープとか
const/let とか
即時関数もあまり使わなくなった気がする

これだけじゃないですが、本当に痒いところに手が届くようになった感じ。もう戻れない。

つらかったところ

記述が超増える！！

React/Reduxともにですが、どうしてもコード量が大幅に増えます。

Reactの場合、Reduxのところでも少し触れましたが、propsが怒涛のリレーになることが多いです。階層が深くなればなるほど propsが増えていき、コードの記述量が増えて行くのはなかなか大変。

Reduxについては、ビジネスロジックとデータ(store)の管理を綺麗に分離することができますが、確実に大幅にコードが増えます。

レイヤーが増えるから仕方ないとは思うのですが、簡単な画面の作成時でも

view
container
component
action
reducer

などと、多岐に渡る修正が必要となり、新規ファイル作成量も多いです。「1つボタンを増やして、押したらAPIを読んで結果を別のとこにレンダリング」というだけでも、結構なコードを書く必要があります。

おまじない的にコードを書かないといけない感じもあり、java/strutsを使ってweb開発していたころを思い出しました。

役割を分離できることで粒度の細かいテストを書けるなど、恩恵が大きいのも理解はできるのですが、恩恵以上にすごい勢いでコードが増えていくな〜と。

実際には作業スケジュールも加味しないといけないので、全コードに対してテストを書いている余裕がないのが現実だったりもします。その時に、コードが多ければ多いほどネガティブな影響を受けやすいのではないかと。

とはいえ、Fluxのデータフローを1方向にするという思想自体はとても良いものだなと思います。コードが増えるは増えるのですが、実際に読む際には流れを追いやすい。

このあたりは実装側の問題もあるかもしれませんが、同じような問題に悩んでいる人は多いのかな〜・・？

ES6 : 使う準備が大変

ES6が、というわけではありませんが、ビルド環境の整理が大変です。このあたりは私の先輩がゴリゴリに組み込んでいましたが、それでも大変そうでした。

あとは使っているとあれもこれも入れたくなってくるので、どんどんカオスになっていくpackages.json。

ある程度自重するのも大事なのかもしれません。

まだまだ解ったような解っていないような感じですが、トータルでまとめると

React : 良い
Redux : つらい
ES6 : 良い

といった感じです。

React/Reduxについては、ベストプラクティスと言うのはおこがましいですが、円滑に開発を進めるための勘所みたいなところも多々あると思います。

そのあたりについてはまた別の記事でまとめてみます。

2016-02-14

Toyama.rb #03 「倉貫義人さんと語らう会」を開催しました！

勉強会リモート Toyama.rb

f:id:mugi1:20160206131126j:plain

2/5（土）に、Toyama.rb #03 かつスペシャル企画として、「倉貫義人さんと語らう会」を開催しました！

toyamarb.doorkeeper.jp

語らう会？

今回お招きしたゲストは、株式会社ソニックガーデンの代表取締役倉貫義人さんです。「納品のない受託開発」という新しいビジネスモデルや、リモートワークを積極的に実施されるなど、様々な新しい取り組みを行っている方です。

私個人としては、以前から書籍を購入して拝読していたのもあり、お名前は知っていたのですが、「あの有名な凄い人」のような、雲の向こうの人だと思っていました。

身近なつながり

きっかけとなったのは、Toyama.rbにも参加してくれている私の会社の先輩が、倉貫さんと知り合いだったことです。その先輩からの紹介で、今回のイベントに繋がりました。いずれにしても、Toyama.rbをやっていなければ実現しなかったと思うので、思い切って始めて良かったです。

内容

どんな内容にしたらいいか？と相談・検討していた結果、「ビアバッシュにしたらいいんじゃない？」という話に。

いいですね、ビアバッシュ！やりましょう！ビアバッシュってなんですか！！？

(...googleで検索 )

どうやら普通のセミナーとは違い、お酒や軽食を片手にわいわいとゆるい感じで歓談するイベントのことを指すようです。たのしそう！ということでビアバッシュに決定。

メインテーマは、今回倉貫さんが2冊目の書籍「リモートチームでうまくいく」を出版されたこともあり、リモートワーク・リモートチームを軸に進めることとなりました。

準備

こちらのブログを鬼のように参考にさせていただきました。本当にありがとうございます。

d.hatena.ne.jp

イベント当日

イベント当日は以下のようなタイムスケジュールでした

1時間ほど : 倉貫さんによるセッション
15分ほど : 準備
2時間ほど : ビアバッシュ

初めて参加してくれた方も多く、普段のもくもく会の倍ほどの人数が集まりました。（Ruby！というテーマではないので、あまりToyama.rbの名前を出さなかったのもあるのかもしれません）

f:id:mugi1:20160206140412j:plain

最初の1時間は倉貫さんのセッションです。

富山県という地域の特性か、SIerのエンジニアの方が多い印象で、リモートワークという刺激的なテーマに対して、かなりのめりこんで聞いていた方が多かったように思います。

私自身は内心、「ちゃんとビアバッシュのピザ届くのか・・！？」とドキドキしていたのは秘密。

（ちゃんととどいた）

f:id:mugi1:20160206150103j:plain

ピザが届いたタイミングでビアバッシュ開始！
（ピザーラのピザはとてもおいしかった。）

f:id:mugi1:20160206151530j:plain f:id:mugi1:20160206151524j:plain

倉貫さんのお話しされる内容は、いい意味で心に「グサリ」と来ることも多かったです。参加される方も色々思うところがあるのか、時折全員が空を見つめてしんみりしているのが印象的でした。笑

でも、そうやって改めて考える、というのも貴重な機会になったのではないかと思います。

リモートワークに限らず様々な質問も飛び交い、気づけばあっという間に時間となりました。

最後は全員で記念撮影をして終了！

f:id:mugi1:20160206174216j:plain

主催としては多々至らぬところもありましたが、無事にイベントを終えることができたと思います。

個人的な感想

個人的に倉貫さんのセッションやビアバッシュでの話で印象に残っているのは、「そもそもなぜ採用するのか？」というところに多くのテーマが集約していくところでした。

たとえば、リモートワークでセキュリティの部分が気になっていましたが、まず、オンプレ環境よりそもそもAWSなどのクラウド環境のほうがむしろ安全なのでは？というのは前から思っていた部分でした。

それでもセキュリティ面を課題とされるのは、個人による情報の不正利用などをリスクとして懸念している部分が少なからずあると思います。

であれば、「なんで信用できない人を採用するの？」ということに。

逆に言えば、チーム内・お客さんも含めて適切な信頼関係を築くことができていれば、柔軟に仕事に対応することができるようになり、コスト面などにおいても恩恵が大きいと。

採用してからのリスク対策などのためにコストをかけるより、最初の採用時点でじっくり労力とコストをかけることで、全体が円滑にまわる仕組みができているのはとても興味深かったです。

どうしてもこの業界にいると「そんなのは理想論だ」という意見も聞きがちですが、実現されているチームが存在している限り、これは理想ではなく真理なのでは、と思いました。

イベントを終えて

なんとも緊張しましたが、とても充実した１日となりました。
参加者の方にも楽しんでもらえた（と私は思っている）ようです。

そして、はるばる富山まで来てくださった倉貫さん、本当にありがとうございました！

次回

次回は平常運転でもくもく会を行います。

興味のある方はどうぞ！（今回も富山＆東京の２会場開催です！）

toyamarb.doorkeeper.jp toyamarb.doorkeeper.jp

2016-02-11

Toyama.rb #02 もくもく会とリモート

Ruby Toyama.rb 勉強会リモート Rails

仕事が激務で更新できていませんでしたが、Toyama.rb #02 / #03(ex回) を開催しました！

とても充実した内容となりました！

今回は #02 の主催レポートです。（ex回となった #03 については近日中更新）

Toyama.rb #02 - もくもく会

f:id:mugi1:20160109132608j:plain

第1回と同様、もくもく会を開催しました。

が、1回目と決定的に違う点が１つ。

リモート開催

第1回目の参加者のうち、数名は「心は富山、体は東京」という方でした。

（東京からわざわざ来ていただいたことに本当に感謝）

参加したいけど、さすがに毎回富山にくるのは難しい。。。ということで、@kunitoo さんにリモート側の主催者を担当していただき、東京側との２拠点同時開催とすることに！

課題

いいですね！やりましょうやりましょう！！！と勢いで言ったものの、課題がもりだくさん。

どうやって繋ぐの？
安定した回線確保できるの？
機器類とかはどうするの？

いろいろと相談・検討した結果。。。

解決案

接続
→ appear.in, だめなら GoogleHangout
回線
→ Toyama Free Wi-Fi に託す。だめならLTE（テザリング）で頑張る。
機器
→ 私がなんとかして用意

といった具合に。

特に心配だったのが回線。安定とかそういう以前に、そもそもポートとかの関係でまったく繋がんなかったらどうしよう？とも思いましたが、事前にiPhone + LTE + appear.in での接続確認をしたところ、意外と問題なく接続できることが判明。

つまり、私のパケット上限さえ無視すればいける！！

（とはいえ、第1回開催時のもくもく中は意外と静かだったので、開始と終了時だけ繋がれば最悪なんとかなるかな〜という算段でした。）

当日

富山会場6名、東京会場5名（残念ながらおひとりは風邪で欠席）が集まってくれました！

あわせれば11名なので、1回目よりも多い人数に。いやほんと皆様ありがとうございます。

イベント企画

ソニックガーデン伊藤さんのブログでもかなり前にご紹介いただいていますが、今回は東京とのリモート開催に加え、西脇.rb＆神戸.rb さんともリモートで接続し、ちょっとしたイベントを盛り込みました。

同じ日に勉強会開催で、かつ同じ日にリモート開催という、なんとも色々と偶然が重なった結果実現に至りましたが、まず発案していただいた伊藤さんに感謝です。

イベント内容

短い時間でパッとできるもの！ということで、会場別対抗 Rubyクイズ大会を開催。

私は事前に問題を知っていたので、背後でニヤニヤしながら見ていました。

総力で挑む富山会場の図 f:id:mugi1:20160109145855j:plain

クイズ自体も盛り上がりましたが、何よりも、普段Rubyにはそこまで関心の無い参加者の方(※)からも「Rubyにちょっと興味が出た」と言ってもらえたことが嬉しかったです。

※Toyama.rbでは、Rubyがベースだけど何やっても別にいいよ！というスタンスでございます。

最後に記念撮影をして、無事にイベントは終了！

f:id:mugi1:20160211164455p:plain

第2回をやってみて

リモート開催でも意外となんとかなりました。不安いっぱいでしたが、致命的なトラブルはなかったように思います。

Toyama Free Wi-Fi が想像以上に安定していたのもあります。ありがとう富山県。

ただ、やはりすべてがうまくいったわけではなく、改善すべき点もいくつか。

発表がしづらい

クイズ大会終了後は、再度Toyama.rb側はもくもくに戻り、最後には例のごとく成果発表会を行ったのですが、これがいまひとつだったかな〜というのが反省点です。

まず、発表者がappear.inに入っていただき、両会場でそれをスクリーンに映すような形をとったのですが、空気感がうまく共有できず、あまり質問もなく淡々と進む感じになってしまいました。

マイクをちゃんと用意できなかったのが根本原因なので、次回はなんとか改善したいな〜と思います。

ともあれ

全体で見ればうまくいったのではないかな？と思います。何事もやってみるもんですね！！

西脇.rb＆神戸.rbのみなさん、勉強会に参加していただいたみなさん、本当にありがとうございました！

３月開催予定のもくもく会も同様に２拠点開催予定なので、興味のある方は気軽にご参加をどうぞ！

ちなみに....

今回のもくもく会で、私は react-rails を触っていました。
基本はこちらのQiita投稿を参考に写経。

仕事でRubyは使わないものの、react/redux/es6 あたりはガッツリ使うので、せっかくなのでそれ絡みで何かやってみよう！という感じ。

サーバサイドレンダリングの動きを確認できたようなできなかったような。。

react-railsに限った話ではないですが、Railsとエッジなフロントエンド技術を併せた場合の無難な着地点ってどこになるんでしょうね？次回はそのあたりをやってみようかな〜

懇親会のもつ鍋。うまかった。 f:id:mugi1:20160109180921j:plain

2015-12-08

Toyama.rb もくもく会 1st を開催しました！

Rails Ruby プログラミング勉強会

f:id:mugi1:20151205124515j:plain

2015/12/5 富山県民会館にて Toyama.rb もくもく会 1st を開催しました！

そもそもの成り立ち〜開催終了までのレポートです。

そして意外とこれが（思いつきで導入したわりに）好評でした。
目の前にいるのにチャットってどうなの！？という気持ちもわかりますが、もくもくに集中しだすとまったく見なかったりもするので、ちょうどいい具合で関わりを作ってくれたんじゃないかと思います。

ちなみに招待は⬇︎をherokuにデプロイして利用しました。

rauchg/slackin · GitHub

発表会

もくもく後は発表会を行いました。

f:id:mugi1:20151205163704j:plain

良い意味で予想外だったのですが、これが思いのほか盛り上がり、ちょっと時間が足りない状態になってしまいました。

懇親会会場の予約が17:30で、発表中に17:35になっていて一人こっそり焦っていたのですが、さすがに参加者にはバレているかもしれません。

次回以降は、もう少し余裕をもって発表会の時間の確保しよう。

...といった具合で、あとはお片づけをして懇親会に繰り出し、
良い具合に酔っ払ったところで解散となりました。

主催してみて

勉強会に初参加したときも同じ事を言ってますが、「意外となんとかなるもんだな！」というのが感想です。

参加者がみなさん良い人だったのも大きいです。

勢いで全部やってしまった

私自身が一度必要な準備作業をすべて体験してみたかったのもあるのですが、ついついほぼ全部一人でやってしまった感が・・

やること自体は私は何ら苦ではないというか、色々経験できてむしろ少し楽しいぐらいだったのですが、コミュニティ自体の継続開催を考えたときに、一人で全部やってしまっていると、私が参加できない場合に開催できなくなってしまうので、これは反省点だな・・と思いました。

というわけで、次回以降少しずつタスクを分けていければみんな安心ですね！（@zappar200 さんよろしくお願いします！）

今後

確定というわけではないですが、極力月１回程度のペースで継続開催を考えており、次回2016年1月にも #02 を開催する方向で現在進めております。

そして・・

次回は東京にリモート会場も設けて開催予定です。

今回の #01もくもく会で関東在住の方が数名参加されていたのがきっかけです。

ちゃんと回線繋がるのか！？といった不安要素も多いですが、もくもく会中はslackがつながればいいんだからなんとかなるでしょう！といった、とりあえずやってみようぜ精神で開催します。

詳細はまたDoorkeeperで告知すると思いますので、興味のある方はぜひ一緒にもくもくしましょう！

最後に、参加していただいた皆様、
そしてきっかけを作っていただいた西脇.rb 伊藤さん、
本当にありがとうございました！

以上、主催レポートでした。

おわり

2015-11-29

Toyama.rb もくもく会 1stを開催します！

Ruby 富山勉強会 Toyama.rb

富山でRubyコミュニティがあればいいのにー！

と言っていたところ、
Toyama.rb が本当に誕生しました。

第一回イベントのお知らせ

2015/12/5に第一回もくもく会を行います。

toyamarb.doorkeeper.jp

詳細は上記Doorkeeperイベントページから！

（至るまでの経緯などはまた開催後に詳細なレポートを作成します。

参加について

2015/11/29現時点では6名/最大10名と、まだ4名分の枠があります。
興味がある方はぜひ気軽にどうぞ！

よくありそうな疑問・質問

Ruby初心者なんですけど・・
→そもそも私が初心者なので大丈夫です！
Rubyじゃないとダメですか？
→交流自体もひとつの目的なので全然okです！
勉強会がはじめて or あんまり行ったことないので心配です
→人生初参加の勉強会で富山から兵庫まで行った人が言うには、
行ってみれば意外と「あ、大丈夫だ」と思うそうです。

終わった後には懇親会も予定しています！（自由参加です）

あなたのご参加をお待ちしています！

2015-10-25

富山から西脇.rb & 神戸.rb主催 Rubyプログラミングキャンプ 2015 に参加してきました

プログラミング Ruby Rails 勉強会

2015-10-10〜2015-10-11にて、
西脇.rb & 神戸.rb主催の Ruby プログラミングキャンプ 2015に参加してきました！

主催の伊藤さんのブログにも掲載されております。blog.jnito.com

他の参加メンバーと違うのは、
私は「富山県からの参加」というところだと思います。

実際にやったことやタイムテーブルなどは
伊藤さんのブログをご参照いただければ良いかと思うので、
私は勉強会初参加＆遠隔からの参加という観点でレポートにしてみます

申し込みまでの経緯

趣味のRuby

仕事ではJava/JavaScriptを主に利用していますが、
以前からRuby/Railsを趣味で触っていました。
ただ、やっていることといえば

Rails チュートリアルを写経
良さげなRails本を写経
良さげなRuby本を写経

と、出家したかのように写経ばかり。

一体次は何をしたら？と、独学の限界を感じ始めていたころ、以下ページに辿り着きました

nishiwaki-koberb.doorkeeper.jp

一泊二日のプログラミング合宿！
これは面白そう！でも・・

距離の壁

そもそも私は富山県に住んでます。
最近東京と新幹線が通りました。

そして会場は三木というとこだそうです。

三木！？どこ！？

約380km

これは遠い！

それでも参加してみたい

今まで勉強会というものへの参加に意欲的ではありませんでした。
参加したとしても、

ほぼ会社の命令で参加
出たほうがスキルアップできるかなぁ〜みたいな義務感で参加

みたいなケースがほとんど。

自分から「参加してみたい！」と思ったのは初めてだったので、こういう機会は逃したくないー！

でも、どうやら参加には定員があるようで、
パッと見たところ定員はあと１名・・・

「やっぱり人気なんだな。すぐ埋まるだろうし、埋まれば諦めもつくな」

と自分に言い訳をしつつも案内ページをちらちらチェックしていたのですが、これがまた意外と埋まらない。

それとなく妻に見せる

おもいきって妻に見せてみました。
だめ！って言われたらそれで諦めようと・・・

私「こんなのあるんだよねー、でも遠いからねー、きびしいよねー」

そして

妻「行きなさい！」
（※実際は富山弁）

まさかの背中を押してくれる結果でした。
これが決め手になり、その日の夜には参加ボタンをポチってました。

正直これが無かったら行ってなかったかもしれません。妻に感謝です。

初勉強会

というわけで飛び込んできた勉強会でしたが、ありきたりですが

とても楽しかった！
もっと早く参加すればよかった！

という感想です！

Rubyでもくもくしに行ったつもりだったのですが、むしろ技術への考え方や姿勢というものを改めて見つめ直すことができたほうが大きかったかもしれません。

そして何よりみなさん優しかったです。

実は勉強会前日からすごい体調が悪く、
声もほとんど出ないような状態で参加していました。
（この芸人さんに近かった）

「うわぁ、変な声のやつが田舎から来たわぁ」
と思われるな、と泣きそうになってたんですが、
そんなことは微塵もなく、とてもフレンドリーに接していただけました。

手を動かすことって大事

いままで勉強会といえば、話を聞くだけのようなものがメインでした。
けど正直、そういったスタイルで参加した社外勉強会は、９０％は内容を忘れています。

しかし、手を動かして得た経験は習得具合がかなり違うと思っています。

社内でも定期的に勉強会が行われていますが、これもやはり講師の話を聞くだけの形がほとんどなので、ハンズオン形式も取り入れていきたいですね〜

発表会って大事

そして、発表会があったのも個人的には大きかったです。

１日目と２日目の終わりに中間・終了発表の機会があり、一人５分くらいと短いものではありますが、これが集中具合をかなり上げてくれたと思っています。

発表会があるんだ、という簡易的なゴールが設定されていると

これを先にやったら間に合わないな
細かく作って成果として残そう
とりあえず中間までは〜を目標にしよう

と、必然的にダラダラしないで作業をすることができました。
メリハリって大事ですね。

遠方からの参加について

よかった点

違う世界に触れられた

私が調べた限りでは、富山にはRubyコミュニティがありません。
そして、いわゆるWEB系企業というのもそこまで多くないという認識です。

働き方というよりも、生き方のレベルから違う人々と触れ合えるのは
とても貴重な体験になったと思っています。

環境を変えてみる、というだけでも得られるものは多かったです。

凄まじく集中できる

遠方じゃなくても集中できるから！という意見もありますが、
遠方の場合は以下のような状態が自動的に発生します

お金の問題
時間的制約

遠方参加の場合はどうしても交通費などが発生します。
今回の私のケースでは、前泊もしたので、＋１日の宿泊費も発生しています。

さらに、気軽に出かけて参加というわけにはいかないので、次に参加できるのは一体いつになるのかはわかりません。もしかしたらもう参加できないかもしれません・・

こうなるともう「やるしかねえ！」という気持ちも少しは発生します。
生々しいですが、こういうのは単純で効果的なのかもしれません・・

よくなかった点

少し寂しくなる

参加者のみなさんと仲良くなれた（と私は勝手に思っている）のですが、これで次に会えるのが一体いつになるのか解らない、というのが寂しく、一番残念な点かもしれません。

本当に素晴らしいコミュニティだと思ったので、気軽に行けるなら毎回でも参加させていただきたいくらいでした。

慌ただしい

土日での合宿でしたが、私は金曜のお仕事終了後から移動したのですが、これがまたなかなかハード。

移動に５時間以上かかるうえ、体調も悪いということで正直ちょっとしんどかったです。「いけるっしょ！余裕余裕！」とナメてかかっていたのですが、もう学生の時のような若さはないんだな、と悲しい現実を突きつけられた気分でした。

次に遠方の勉強会に参加する機会があるならば、もう少し余裕をもったスケジュールを組んだほうがよさそうです。

今後

「ああ面白かった」で終わってしまうともったいない。
そういうわけで今後どうする？というところを考えてみました。

他の勉強会への参加

今回の参加で思ったのは
「参加してみればなんとかなる」というところでした。
積極的に（妻に頼んで）他の勉強会にもどんどん出てみようかと思います。

※ちなみに先週に早速他の勉強会に行ってきました。

Ruby/Railsでちゃんと形にする

今回の勉強会で作ったのは、プライベートネットワーク向け共有ファイルの検索システムでした。未完成ですが、そもそもは社内利用を目的に考えていたので、これを社内で稼働させて使ってもらえるところまではなんとか持っていきたい・・

とりあえず今もじわじわ機能を足してコミット中です

富山のRubyコミュニティをなんとかする

もくもくできるようなコミュニティが富山にもほしい！
なんとかしたい・・！
まずは仲間探しかな〜

本屋にRubyの本が売ってるんだから
きっと他にも富山でRuby好きな人はいるはず！

まとめ

参加してよかった！
悩んでる時間は無駄だった
西脇.rb & 神戸.rbのみなさんありがとうございました！

2015-09-11

SIerとリーダブルコードのほどよい着地点を考えてみる

プログラミング雑記

www.amazon.co.jp

リーダブルコード、良書ですよね〜

プログラマならぜひ一度は読んで欲しいと思いました

最近社内で勉強会でスピーカーをする機会があったので、
この本の内容の紹介と、特筆して紹介したい部分を話しました。

ただ、その際の資料作成と実際の勉強会での反応を受けて、
いろいろ思うところがありました。

1. 納期の壁

リーダブルコードに書かれている内容はすばらしいです、
やっぱり綺麗なコードが一番だと思います。

でも、やはり現実的には理想論的な部分もあると思います。

納期が存在する受託開発の場合、
どうしても付きまとうのが「で、間に合うの？」という話。

私：どうですか！？すごい読みやすくて綺麗なコードでしょう！？

上司：で、間に合うの？

私：いえ、無理です！！

上司：おい！

こうなるのは目に見えています。

そこで思うのは、
「そんな一気に綺麗にしようとせずに、少しずつ全員の意識を変えればいいじゃない」
という案

でも・・・

2. スポットメンバーの壁

全員が「いつものメンバー」なら問題なしです。
でもよくある状況として

私：この期間だときびしいです！

上司：あと１ヶ月で４人月ぶんだな！よし、BPと新人で４人投入だ！

私：うわー！！

こういうケース。
妊婦さん９人集めても１ヶ月じゃ赤ちゃんは産めないの！！

上の例は結構極端ですが、
一時期だけ入ってすぐ抜けてしまうようなメンバーがいた場合、
リーダブルコードを徹底することによるメリットが薄くなってしまいます。

徹底したとしても

私：いいですか、綺麗なコードを書いてくださいね！

BPさん：はい、わかりました！

　〜１ヶ月後〜

BPさん：どうですか！綺麗なコードでしょう！

私：すてき！

上司：で、終わったの？

BPさん：いえ！では契約終了なのでさようなら！

私：さようなら！

上司：おい！

こうなります。

そして最大の障壁が・・・

3. 古株との意識の壁

リーダブルコードの勉強会内で
「returnを使ったガード文を利用してネストを浅くするといいですよ！」
と紹介しました。

すると、
「returnは１個しか使ったらダメだって教わった」
という意見が聞けました。

リーダブルコードに書かれている内容の中には、
古くからエンジニアをされている方が教わった内容と
相反する部分がどうしても出てくるようです。

他に考えられる例としては、たとえば
「変数は使う箇所の近くで定義する」
なども挙げられると思います。

こういうときにどう説明するのかが難しいな〜、
というより、どう説き伏せるかを考えないといけないんだな、と感じました。

というわけで

色々と問題がたくさん。
どうしていけばいいんだろう・・・？

私はあくまでも「リーダブルコードは素晴らしい」という考えです。
やっぱりこの考えは広めたい。

自分なりに少し考えてみました。

1. アンチパターンを用意する

ただし、あくまでも納期などを考える必要があるため、
ここでいうアンチパターンというのは

「こういうコーディングをしてはいけません！」

ということではなく

「こういうのはあんまり綺麗じゃないですよ」

というもの。

期間が無い状況などで出来るだけ高い効果を出すためには
ガチガチにしばるのではなく、ざっくりとした方針だけを示すのがベストだと思います。

そのときに、やはり口頭だけでは分かり難いので、
簡単な例を用意しておけばいいのかな〜と思いました。

極端な例ですが、たとえば変数名で

var newOrderIdForRegistrationNewManagedUser

とかを見せて、「ほら、長いでしょう？」みたいな。
覚えさせるよりも雰囲気を感じ取ってもらうほうがいいと思います。

2. 相反する意見の理由も知っておく

先ほどの例でいうと

「returnは１個だ！」

と言われて

「は！？バカじゃねえの！？」
と言わないようにしましょう。

今、returnを複数使うことで読みやすくなるケースがある、というのに理由があるように、
returnは1個だ、というのも根拠があるということです。

かくゆう私も「なんでだろう？」と思って調べたところ、
構造化プログラミングの考えから、goto＝悪！みたいな認識が広がり、

制御ルーチンは上からちゃんと読めるようにしようね！
↓
途中でreturnしたら飛ぶからこれもやめようね！

みたいなことだという認識です。

でもこれも立派な考えであり、先人の知恵です。
これを認めた上で

・言語や取り巻く環境などが変わっていること
・むしろreturnが多い方が可読性が上がること

などを説明すれば分かってもらえる・・・かもしれません。

（だめかもしれないけど

3. あきらめない

でました！精神論！

もはや究極はコレかなと。

もう正直、自分だけでも徹底的に頑張るしかないと思いました。
そしてその上でパフォーマンスも出すと。

身をもって綺麗なコードのメリットを証明するのが一番説得力がある気がします。

と言ってしまうとひどいですが、
案外周りを見渡すと同感してくれる人がいるもんだと思います。

むしろ意外と多いかもしれませんよ。

少しずつ意識改革を広げていくのも重要なことだと思います。

というわけで、結局何が言いたかったの？みたいな内容でしたが、
私は綺麗なコードを書いていきたいです。

お　わ　り