ドキュメントを書けば？
これ。当然私は「いいこと言ってるなぁ」派。
これに寄せられるいくつかのコメントについて。
新規サービスをテスト書かずに立ち上げた奴らが創業者利益でがっぽり勝ち逃げして後から入った真面目な若者が負債による圧迫で「こんな機能追加するのにこんなにかかるの？」みたいに詰められてる姿が目に浮かぶ
それはテストを書くかどうかの話より、技術的負債を積み上げ続けたまま勝ち逃げする人たちの批判ですかね。
テスト書いてあっても技術的負債が積み上がったプロジェクトだってあるし、テストはないけどプロジェクトのメンテナンスちゃんとしてるプロジェクトもあるし。
一般論としてテスト書いてる現場のほうがメンテナンスちゃんとしてる傾向にはあるだろうけど、直接の論点とは違うんじゃないですかね。
インフラとかライブラリ系はテスト書きまくっとくと安心感が凄い。簡単なテスト書いてるだけでも結構自分の思考の漏れが見つかる事多いしね。フロントはあんま関わらないからノーコメント。
そうそう、ライブラリは書いたほうがいいし書くべきなんですよ。読みづらいコードも増えるし。
でも、フロントはそんなにいらない。
テストを書くか書かないかは自由かもしれんけど動く事を保証するための動作確認をテストと言っているなら他人に説明するためのシナリオは必須だと思う
シナリオとは？ TDDのシナリオですかね。私はシナリオとかスペックという概念(仕様とテスト実装、両方を表すようで両方ともと違う)は無駄な中間概念だと考えているので嫌いです。
普通にドキュメント書いて、あとminitest書けばと思う。
「よくできたRSpecはテスト自体が英語で仕様を表す」みたいなのって水素水とか、声がけで水の結晶が〜みたいなレベルのカルト思想だと思う。
共感してる人は元記事の矛盾に気づいてるのだろうか?"ユーザーに価値を届ける"事には"ユーザーの価値を壊さない"事も含まれる筈なのだが;多分これが許されるのって最初から完璧なコードが書けて修正不要な場合だけ
テストを書けば確かに価値を壊すリスクは減るとは思う。これはビジネス側の解釈なのでケースによるけど、壊すだけの価値がある時点でテスト書けばよい。たいていのスタートアップは誰も使わないとかのレベルで停滞してるわけで。
自称出来る人のドキュメントなしテストコードなしのソースを引き継いだ経験のある人はまったく賛同できないだろうな。それやるならお前が一人で開発して一人で墓まで持ってけよって。
そう、これなんだけど、「テストが書かれていてドキュメントがない」状況とその逆だったら、ドキュメントがあってテストがないほうが全然よくない？ つまり、テスト書かなくてもドキュメントがちゃんと用意されてればこの問題はある程度緩和されると思う。実際、ここの仕様の意味がわからないというときにテスト読むって少し無理な注文だと思う。(少なくても教科書的に、「あぁこのメソッドはこういう振る舞いが期待されてるのか」と納得した経験はかなり少ない)
いいエンジニアはコメントを書かない、というかコメントにはBad Codeの臭いがあるのは確かにそうなのだけど、コメントを書かないにしてもドキュメントは書いたほうが良い。
例えば本番データを開発環境に投入するコマンドとか、キャッシュクリア、デプロイ手順(capistranoで自動化されてるにせよ普通にrollbackしようとしたら変なエラーが起きたりとかけっこうある)、ビジネスロジック上わかりづらいが重要な違いがあるメソッド(`Article.published`と`Article.visible`とか)。
ちなみに、昔自分がやったプロジェクトでRSpecでゴリゴリテスト書きまくってカバレッジも優秀なRailsアプリがあったのだけど、紆余曲折あって運営元が変わって、２年後くらいに見に行ったら一切実行されてないテストと「ドキュメントが一切ないクソプロジェクトなんですよ」という現場の声にショックを受けたので、今やドキュメント85, テスト15くらいの割合で考えてる。
2年連続でインフルエンザになる
確か去年はA型だったんですが、今年はB型になりました。節約のため高速バスで仙台に帰った翌日くらいから体調が悪くなったんで、バスの中で感染ったのだと思います。
しかし、今回のインフルエンザはけっこう辛かったです。去年ももちろん辛かったは辛かったんですが、高熱が出て翌日に病院に行ったらすぐにインフルエンザ陽性が出たのでイナビルという鼻から吸引するお薬をキメたら８時間くらいで回復したんですが、
今回のは熱が出て翌日に病院に行ったらインフルエンザ陰性。ただの風邪かと思いそのまま外で仕事してたらどんどん悪化したので２日後にまた病院に行ってようやく陽性反応が出ました。これは運が悪かったらしい。
で、今回はイナビルじゃなくて例のタミフル。これを５日間飲むらしいんですが、回復がけっこうゆっくりで未だ気持ち悪いんですよね・・・。
金曜 朝にバスから降りる(この時点で感染?)
土曜 なんともなし
日曜 ３８度くらい熱が出る
月曜 インフル陰性
火曜 仕事するも相当悪化
水曜 ずっと寝てる＋夜間の救急病院に行ってインフル陽性
木曜 ずっと寝てる
金曜 だいたい寝てる
というわけでまだ指先の動きが悪かったり足元がふらついたりします。
これ去年も思ったんですが、病院代と薬代、電気毛布買ったりで軽く１万超えてるし仕事しなかった損害分も考慮したらけっこうな打撃なので、高速バス・新幹線って時間的なものだけでなく乗るにしても季節考えるとか重要ですね。
Rails初心者に知ってほしい本当の脱初心者の方法
この記事読みました。まぁ感想を一言で言えば
まぁ言いたいことを順を追って言っていきます。
ロジックで用いる具体的な数字は定数に格納する
これは半分正しいですが半分間違いです。マジックナンバー死すべしみたいな人が短絡的にあらゆる数値をそのクラスの定数にしちゃったりしてますが、程度問題です。
例えば
@articles = Article.where(...).page(params[:page]).per(PAGINATE_ITEM_LENGTH)
みたいなやつ。こういうの、結局ここでしか使わないから修正箇所1個だけなんですよね。だからベタ書きでもいいと思います。 定数にしたほうがいいやつってむしろこういうやつで
$li_margin_top : 50px;
ul {
margin-top: -$li_margin_top;
}
li {
margin-top: $li_margin_top:
}
まぁ変更する頻度が高い、どこかの数字と連動している、とか。
CRUDとルーティング
ある時期まではとりあえずresourcesが使えないか考えるべしというのは姿勢としてはいいのですが、現実問題としてわりと厳しいです。 例えばあるレストランの詳細ページの中に、地図を表示するページとかメニューを表示するページとかいろいろ作る時
resources :restaurants, only: %w[show] do resource :maps, only: %w[show] resource :menus, only: %w[index] resource :reviews, only: %w[index] end
みたいな。まぁreviewsとかはいいんですけどmapみたいに明らかに1画面しか作らないなら
resources :restaurants, only: %w[show] get 'restaurants/:id/map', as: :restaurant_map・・・①
か
resources :restaurants, only: %w[show] do get 'map' => 'restaurants#map', as: :restaurant_map・・・② end
で十分ですよね。とくに①の方法は:idの部分を:nameとか:uuidとか変えられるのでオススメです。その際named_routesがそれっぽくなるようにちゃんとasオプションを付けましょう。
ちなみにshallowオプションは使うべきではない派です。
resources :restaurants, only: %w[show], shallow: true do resources :reviews, only: %w[show] #これでレストランのレビュー一覧ページはマッピングできるけど、ユーザのレビュー一覧は？ # それならRestaurant#ReviewsControllerとUser#ReviewsControllerにしたほうが良くない？ end
まぁas, namespace, pathあたりのオプションをちゃんと使えば良い話です。
クラスを継承してsuperメソッドを使う...
まずDevise使うのやめましょう。 あと、iOS使ってるとsuper.viewDidLoad()とか出てくるけどRailsでこれが出てきたら使うライブラリが間違ってるか設計がおかしいかのどちらかだと思う。
クラスをまたぐ処理はconcernに
concerns使うシーンがピンとこなかったんですが、モデルからデコレータに変換するメソッドだけを含むモジュールとかをconcernsにするとけっこう便利です。あとはpublished_atだけでModel#draft?, Model#published?, Model.published, Model#publish!などを付け足してくれるモジュールとか。
ただ、たまたま共通してるレベルのものをconcernsにするのは危険かなと思います。
scope
昔保守した案件で @article.visible.user_authenticated.high_quolity.(以下略)みたいに定義して、結局Article.publishedが抜けてたみたいな事故があり、案外scope定義しまくるのはリスクがあるというか、scopeがそんなに大量になる時点で何かがおかしい気がします。
後はアプリケーションの画面に強く関係するビジネスロジックをscopeにすべきではないです。
Helperメソッド
ページ数によってtitleタグを動的にとる程度であれば
- if @article.current_page > 1
title "記事一覧 #{@article.current_page} ページ"
- else
title "記事一覧"
とかで十分。どうしても欲しいなら@articleのデコレータ。これをヘルパーにしてるとメソッド名が枯渇する。
考え方として、Railsが提供してくれるlink_toとかの亜種を作りたいときにはいいと思う。
def noindex_nofollow_tag
"<meta content='noindex,nofollow' name='robots' />".html_safe
end
とか。
Test
minitest使ってるのはいいですね！
おわりに
いろんな現場、いろんなプロジェクト、規模やセキュリティの重要性、リリース後の動きとかによって書くべきコードは変わると思います。 私もまだまだ勉強中です。
批判あればご指摘ください
クロネコヤマトの経営学
２年ぶりに電車通勤生活になったことで、電車の中ではKindleで本を読むようになった。 で、この３日ほど読んでたのがこれ。
クロネコヤマトのヤマト運輸２代目社長の回顧録。著者は創業者で父親の会社に入社しながら2代目に就任し、70年代に大口顧客の三越を切って一般顧客を対象に切り替えていく。要するにB向けのビジネスモデルを縮小して、C向けの宅急便という新規事業に打って出た話。
2代目ながら東大経済学部卒で論理的。当時としては非常にビジョナリーで現代的な経営をしていたのが分かる。 ちなみに個人的には労働組合との関わり方について非常に細かく気配りしたような書き方があった点(現在のベンチャーではほとんど労組との関係性について悩むことはない)、当時の労組は業種的にも相当に影響力があったんだなという時代柄を感じる。 あとは国内航空会社の出来レース的な価格体系が海外格安航空にパイを奪われたという話を援用して敵は外にいると説いてるんだけど、今後はヤマト運輸の強敵が佐川急便からAmazonのドローンやGoogleの自動運転車、Uberになるのではと思うと全く聡明な見識だと驚かされる。
まぁさすがに本文中に「いくらなんでも荷物が空を飛ぶことはできないので〜」という描写があって、ドローン配達までは非現実だと思っていたみたいだけど。
Kindleで読めるのでおすすめです。
余談
最近はてブでゲーム作って会社ぶっ潰した24歳みたいな記事がバズったんですけど、ああいう感じで失敗起業家になぜ失敗したかインタビューしていく本とかあれば読みたいですね。
胡散臭い会社を見破る方法
ホームページだけはやたらと綺麗なのだが相手がどうも胡散臭い。会社の規模や実態がよくわからない。
こういうときは登記簿を照会すれば一発なのですが、さすがにもっとカジュアルな方法で相手の身元を確認してみたいでしょう。
そういう場合に法人番号検索が非常に便利です。
http://www.houjin-bangou.nta.go.jp/
お役所のページのわりにはけっこう見やすいですね。
例えばこれにアトラシエと入力してみます。
出ました。
といったふうに、会社が実在することと住所だけ確認できます。住所変更も登記してすぐに反映されました。
世の中、意外と会社のようで会社じゃない組織は多くあります。八百屋さんとかレストランとか。 でも名刺は「リストランテ・エビス」とかで、これを屋号といいますが、個人事業主には屋号を明記する欄はあるんですが屋号に書いてない屋号、というか店名を名乗っても罰則は(たぶん)ないです。
というか、そもそも個人事業主じゃなくても勝手に名刺を作って「うちはなになにの会社です」と名乗る分にはギリセーフです。というのは、お役所の書類とかをみると運営母体は個人事業主だがみなし法人のような形のときに、屋号を会社と名乗っていることを想定してるケースがあるんですね。 しかし、株式会社とかを勝手に名乗ると名乗ると会社法かなんかに引っかかります。
何がいいたいかというと、「うちはチームsakuragaokaっていう芸能キャスティング会社です」と名乗るのはかなりグレーであるけどまだ株式会社とかを名乗ってないので、これくらいのことをやってる人は多いということ。
だから胡散臭い会社の人にはちゃんと登記上の名義と代表者を聞いたうえで、存在を確認しましょう。最近シェアオフィスで常々感じることです。
ウェブサービスの時代は終わる
Googleが時価総額世界一になったそうだが、いわゆるウェブサービスの時代は徐々に先細っていく恐れがある。
これは私自身リスクとしてある程度現実味を持って考えていたことなのだが、最近ある人づてに著名投資家が同様の見立てをしていると聞いてあぁ、やっぱりそうなのかなと考えを強めた。
というのは、簡単にいえばインターネット上で有望市場とされているものがある程度刈り取られてしまっていること、参入コストの低下(プログラミングが楽になったなど)によりプレイヤーが過剰なことに起因する。
例えば有望市場、というか巨大市場という点では上から順に自動車、建設、外食、不動産、小売、アパレルなどだが、Cへの依存度が高い分野はすでに巨大プレイヤーがいるし、ぱっと思いつかない自動車にしても自動運転車のように根本から大きく変えようとしているチャレンジャーが存在する。建設はまだないかな・・。
よく最近の新規事業担当者は「10年前だったらもっと楽だっただろうなぁ」と言っているが、それは結果論であるという点を考慮しなければ全く正しい。
逆に言えばインターネット並に今後10年成長する市場を発見していち早くプレイヤーになれば、10年後に優位な立場になれる。
で、みんなが気になる10年にインターネット並の成長ができる分野はなにかというと、巷ではVRやIoT、人工知能あたりなのだろうけど、その著名投資家いわくバイオテクノロジーやサイバネティクス、ハードウェアだという。
例えば事例で聞いた話ではマグロの栽培漁業で、マグロが致命的に弱体化する悪い遺伝子を矯正して生存率が急落する初期の生育過程を乗り切ることで生産効率が飛躍的に伸びる技術が最近あるという。
意外と忘れがちだけど人間が摂取してるものは塩とか水あたりが例外なだけでほぼすべて動物か植物なので、食産業にも巨大インパクトがあるのはもちろん、当然医療でも応用できる。
でも遺伝子分野なんで今から勉強したって無理だわーと思うんだけど、逆に20年前にインターネットを始めた人たちってそれを無理じゃないと思った人なのかも。
まぁ本気で業界の切り替えができるとしたら20代はまだチャンスがあるので進む道が正しいのか毎日考えないといけないのかも。
