YYPHP#48「みんな最初はどう学んだのか、エンジニア思春期、命名で気をつけること、UTF-8のNFCとNFD問題、技術的負債の解決方法、BDD」

これは2018年08月17日に開催したPHPerイベントYYPHP#48のイベントレポートです。

YYPHPは一言で「PHPerの部室」です。PHPについて、雑に、ゆるく、ワイワイ話し合う集いです。毎回お題を決めずに雑談を出発点にいろいろなことを突発的にやります。集まった人でコードリーディングをすることもあれば、一緒に開発ツールを触ってみたり、フレームワークについての情報交換をすることもあります。開催はほぼ毎週、高田馬場にて。

YouTubeでの配信映像はこちら-> #YYPHP #48【PHPの情報交換・ワイワイ話そう・仲間作り・ゆるめ・にぎやかめ】

参加者11名(リモート4名)

• PHP歴
  • 1年未満: 5名
  • 2年: 2名
  • 6年: 1名
  • 10年以上: 3名

みんな最初何やったんだろうというのを聞きたい

• ブロック崩し、ゲーム (BASIC)
  • たまをうったり返したり
  • 行番号をいちいちいれないといけないのが面倒だった
• AndroidのTwitterクライアント (１９歳くらい)
  • 本当に初めては中学校の授業でHTML組んだことですね
• ○☓ゲーム
• 専門学校のときにHTMLの中にPHPを書き込んで動的なウェブサイトを作った
• 40年ぐらい前なのでエラトステネスのふるいで素数とかライフゲームとかヒルベルト曲線描くとかそういう定番的なやつをしたのが初期かな。GAMEというBASIC的な言語を使っていました
• 最初はVBAでメッセージ表示するぐらいのアプリとは呼べないものが
• WordPress, EC-CUBEの魔改造、なんか書いたりコピペしたりして動くのが楽しかった

• サーバの管理をするための管理画面をPHPでつくった

• プログラミングを学び始めたときにやること

  • Hello Worldやる→DBから取ってきてHello Worldやる

• 入門の次にやること

  • 作りたいものがあるのだから、それに必要なものを学ぶのが一番はやい
  • Laravelだったらチュートリアルを一回やっておく
    • そうすることで何をフレームワークに任せればいいかがわかる
    • Basic Task List - Laravel - The PHP Framework For Web Artisans
    • Symfonyでの体験談
      • SymfonyにFormがあるのに自分でHTMLでフォームを作っていた
      • チュートリアルをやっておくとそういうことを防ぐことができる
  • Laravelの公式チュートリアル、確か5.1で止まってますよね

みなさんのエンジニア思春期

• エンジニア思春期とは
  • ある日からコードをバリバリかけるようになったと感じるが……
  • その後、その時期を黒歴史だったと感じる
• 頻繁にあるよね
  • 身につけたと思うが、あとでやりすぎだったと感じる
• デザインパターン期
  • とにかくデザインパターン使ってみたい
• 技術者だから、覚えた技はすぐ使いたくなってしまうと思う
• 抜け出すきっかけ
  • 本を読んで、「あの設計は良くなかったんだろうな」となって反省
• やってみないとわからない部分もあるし、失敗を恐れずにどんどんやったほうがいい
• 先生がいたほうが学習が早い
  • 自分の書いたコードに意見を求められる上級者のメンターがいたほうがいい
  • そういう人をどうやってみつけるか
    • 社内ですごいできるひとを捕まえる
    • 勉強会に行く
• PHP Code Snifferを
  • どのくらいの設定をしたらいいか
  • Rocro
• PhpStormのinspectionで悪いコードの書き方をある程度覚えられる
  • PhpStormのinspectionを更に強化するプラグイン
    • Php Inspections (EA Extended) :: JetBrains Plugin Repository
    • Php Inspections (EA Ultimate) :: JetBrains Plugin Repository

命名のときに気をつけていること

• テーブル名とか
• 多少長くなってもいいから、そいつの役割がぱっとみわかる
• プログラミングで命名が一番難しい
• 英語
  • 間違った英語をあてはめていると、ネイティブが入ってきたときに誤解を生んだりしてしまう

• ユビキタス言語に従うために日本語で書くのがいい

  • 仕様書も会話も日本語なのにコードだけ英語なのはおかしい
  • 最近はだいたいUTF8をサポートしてるから、日本語で書けるときは日本語で書くのが良い
    • むかしは日本語でかけなかったから仕方なかったが
  • 固有名詞多い業務システムなら、変数名日本語やる価値大いにありそう
  • 英語を使うのが現実的にコストが高い
    • 人数が増えれば増えるほど大変になる

      public function test_正常にマッピングが行われる(): void
      {
          $this
              ->次のような品番が与えられたとき('AAAA')
              ->マッピングすると()
              ->変形後の次の属性が('商品管理番号')
              ->次の値になっていること('AAAA');
      }
  

• UTF-8のNFCとNFD問題

  • MacとWindowsとLinuxでファイル名が日本語だとクラスロードでclass not foundになることが……
  • 例えば、「ユーザ.php」がMac(APFS以前)は「ユーサ ゛ .php」(サと濁点が別れる)として保存される

• 名前は長いほうがいい

  • grep検索をかけたときに、みつけやすい
  • だめだったこと
    • ディレクトリが深かったり、

• 2単語〜3単語が良い

• 発音できること

  • 正規表現、regular expression を regex と書く人と regexp と書く人がいるが、発音しにくい

• 規約があったら規約に従う

• boolを返すメソッドは is~, 三単現の-s(exists), has~

  • if ($従業員->入場済みか())
  • [].include?()

技術的負債の解決の仕方

• 踏み倒すという解決法もある
  • フルスクラッチ
• 書き直すにしても仕様がわからないののでどうしらいいかわからないことがある
• 徐々に良くしていく
  • テストがないコードにテストを書いていく
• これ以上負債を増やさない
  • PhpStormなどの静的解析できるツール
• 理想は技術的負債をつくらない
• コードは書いた時点で負債になる
• 陳腐化して負債になることも
• コードは生物自動テストをできるようにして、いつでもリファクタリングできるようにする
• 単体テストだけはできるようにしておく
  • たとえテストがあってもそれが信用できるか問題があって難しいですよね
• 不安に勝てない
  • 変えて動かなくなったら周りに責められるため
• 壊れたらまずいところを結合テストを書いた上で、リファクタリングする
• 経営判断が入ってくる
  • ソースコードのレベルだけの話ではない
  • 技術的負債を返すコストよりもメリットの方が上回っているか
  • 経営者がどこまで理解してもらえるかに変わってくる
    • 「技術的負債」ということばをしっかりを覚えてもらった
• 静的解析
  • 循環的複雑度
    • 50を超えると1回のデプロイで3つのバグがでる

業務システムがSymfony1,CakePHP1で動いていて、それをCakePHP3

ビヘイビア駆動（BDD）のテストについて聞きたい

• 日本語で書こうと思う
  • ニュアンスが人によって違う
  • 多くの人（協力会社とか）に書いてもらうなら、お手本になるコードを書いて、これを参考にやってねってお願いする
• 技術的な概念を隠して、仕様書的な感じに書くのがコツ
• 画面系のテストの場合
  • behat + selenium だと、命令が具体的すぎるので、
  • テストが壊れやすい
  • 実行時間がかなりかかる
  • 書き過ぎないようにするべき
    • １００％は無理
    • 主要なユーザ操作中心に優先順位つけて絞る
    • ２０％のカバーで８０％のバグを潰す

YYPHPは毎週やってます

PHPについてワイワイ話したい方は、YYPHPのイベント情報をチェックしてみて下さい。

以上、YYPHPのレポートでした。次回もワイワイやっていきたいと思います！ では、また来週！