1. kaneko_tomo

    typo?

    kaneko_tomo
Changes in body
Source | HTML | Preview
@@ -1,186 +1,186 @@
これは2019年05月10日に開催したPHPerイベント[YYPHP#82]のイベントレポートです。
[YYPHP#82]: https://yyphp.connpass.com/event/122134/
[YYPHP]: https://yyphp.connpass.com/
[YYPHP]は一言で「PHPerの部室」です。PHPについて、雑に、ゆるく、ワイワイ話し合う集いです。毎回お題を決めずに雑談を出発点にいろいろなことを突発的にやります。集まった人でコードリーディングをすることもあれば、一緒に開発ツールを触ってみたり、フレームワークについての情報交換をすることもあります。開催はほぼ**毎週**、高田馬場にて。
__今回の配信動画__
<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">PHP雑談生配信 <a href="https://t.co/N9f9MjknrK">https://t.co/N9f9MjknrK</a></p>&mdash; suin❄️PHPでオブジェクト指向 (@suin) <a href="https://twitter.com/suin/status/1126798610085978112?ref_src=twsrc%5Etfw">2019年5月10日</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
__過去回の配信動画__
https://www.youtube.com/playlist?list=PLpOeTEye3Bg6PodrLHHC72jWMJYZz8VbG
## どんなコードがきれいなのか
* 他の人が見やすいコードが綺麗なコード(読みやすさ)
* ちゃんと役割が分かれているコード
* 他の人が見やすいコードの基準ってなんなのか気になる。
* どう意識したらそういうコードになるのか?
* インデント
* 命名規則が整っていて統一されている
* 『リーダブルコード』
* [リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) | Dustin Boswell, Trevor Foucher, 須藤 功平, 角 征典 |本 | 通販 | Amazon](https://www.amazon.co.jp/%E3%83%AA%E3%83%BC%E3%83%80%E3%83%96%E3%83%AB%E3%82%B3%E3%83%BC%E3%83%89-%E2%80%95%E3%82%88%E3%82%8A%E8%89%AF%E3%81%84%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E6%9B%B8%E3%81%8F%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB%E3%81%A7%E5%AE%9F%E8%B7%B5%E7%9A%84%E3%81%AA%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF-Theory-practice-Boswell/dp/4873115655)
* 最近型が大事だなっと思ってきた
* ちゃんとどんなクラスが返ってくるか分かるようなコードになっていると嬉しい
* 連想配列ばっかりだったりすると、何が入ってるか分からないので厳しい
* 読みづらいコード
* if文ネストしすぎてると読みづらい
* 波動拳
* ![](https://i.imgur.com/Y2fxJ9c.png)
* やたらコメントが書かれていると読みづらい
* コメントが間違っていたりして惑わされる
* functionばかり
* コピペで同じコードが量産されていると辛い
* クラスに1000行とかあるコード
* 10行目で定義した変数が500行目で使われているとか
* メインのコードは短く
## フレームワークって使ったほうが良いの?
いまバニラPHP(素のPHPのこと)で書いているので
* フレームワークを使っている人の意見
* 複数人で開発するときに使ったほうが良い
* 簡単にCRUDアプリが作りやすい
* Laravel
* 開発環境が管理しやすい
* 開発しやすい
* フレームワークの規約を知ってる人同士だとすぐ入れる
* 初速は開発速度が早い
* 例えばフレームワークで80%は実現できるけど、長くやっていると残りの20%を実現するのにやりづらくなってきたりもする
* MVCに沿って開発してるのに、複雑になってきてしまう場合とか
* サービスという概念がフレームワークにない場合は、自分で実装しないといけない
* フレームワークで想定してない使い方をする場合
* セキュリティとかはフレームワークがある程度守ってくれる
* バニラだと、自分で考えないといけないところが多い
* フレームワーク
* うっかりと落とし穴に落ちるのを防いでくれる
* 意図せずにXSSを作ってしまうとか
* エスケープ関数作ってたけど、入れ忘れてたとか
* フレームワークに規約があるので、チームワークしやすい
## リファクタリングはどうやったらいい?どういうことに気をつければ良い?
* どうやるか
* クラスやファンクションの長いのを整理する
* 複数の処理や機能が混ざっているので、分離する
* 読みづらいコードを整理する
* 最初は整理して分離するところから
* ディレクトリに分けたりもする
> テストコード書かないでリファクタリングとか、それt_wadaの前でも同じこと言えんの?
* リファクタリングする時は、テストコードがあるべき
* リファクタリングとは = 振る舞いを変えずに内部構造を変えること
* TDD ← おすすめ
* 段取り
1. テストコードを書く
2. リファクタリングする
3. テストして振る舞いが変わってないことを確認する
* [レガシーコード改善ガイド(ウルシステムズ株式会社 平澤章 マイケル・C・フェザーズ 越智典子 稲葉信之 田村友彦 小堀真義)|翔泳社の本](https://www.shoeisha.co.jp/book/detail/9784798116839)
* [新装版 リファクタリング 既存のコードを安全に改善する | コンピュータ・一般書,プログラミング・開発,その他 | Ohmsha](https://shop.ohmsha.co.jp/shopdetail/000000003881/)
> あとIDEのリファクタリング機能が最近は便利なので活用しましょう
## テストコード(ユニットテスト)を書きたいが、書き始めるタイミングがわからない
書きたいと思っているが、いつか着始めたら良いのか…
納期も有るし…
勉強する時間も必要だし…
* 勉強しながらテストを書かなきゃいけないが、納期が有るので、動くものを納品するのが優先
* 「動く」保証は何がするのか
* いまは手動でテストしてる
* エビデンスは取ってない
* やってる人はどうやってるか
* ローカルでは自分の開発で関わるところをテストする
* コードをpushするとCIサーバが全体的なテストを自動実行する
* エラーになるとアラートが上がってくる
* 「test」ディレクトリにテストコードが入ってる
* チームで開発している場合は
* みんなでせーのでテストを書き始めると良い
* 結合テストレベルでのテストから始める
* DBをモックにしたり
* APIサーバをモックにしたり
* 改修するタイミングで、1回に1時間テストコードを書いて増やしていく
* [テスト駆動開発 | KentBeck, 和田卓人 | 工学 | Kindleストア | Amazon](https://www.amazon.co.jp/dp/B077D2L69C/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)
* 負荷テストツール
* [Cloud Based Load & Performance Testing | Flood.io](https://flood.io/)
* [知らないと「PhpStormのライセンス料をドブに捨ててる」も同然のショートカットキーを教えてください - Qiita](https://qiita.com/suin/items/bda682201fed0936cf95)
## 受託で人で開発してるけど、複数人での開発方法の知見が知りたい
どうやったら管理がしやすいか
ほぼ一人なので、書くのも一人、マージするのも一人、な状態なので
* コード管理
* Git
* コミュニケーション
* スクラムで1週間毎にまわしていく
* [Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ〜Problemが10分で解決するチャットを作ろう | | Craftsman Software Inc.](http://c16e.com/1511101558/)
* コーディング規約を決める
* レビューができる
* 書くコードの量が増える
* 役割やタスクが振られる
* 自分が遅れると周りを遅れさせてしまう
* どう書いていいかわからないときに聞いたり聞かれたりできる
* 個人だけだと意外と書かないWiki系はちゃんと書いたほうが良い
* コードで表現できるモノはコードで表現しておくべき
* 自分が疑問に思ったこと
* 読み方、意味、業務知識などの専門用語の説明
* 教えたタイミングで教わった人に書いてもらうようにするとか
* > チケット駆動開発やかんばんでタスクを管理するのはいいぞ!
## 皆さん転職活動はどのような活動をしましたか?
* 転職エージェントに登録した
* 知り合い(先輩が社長だった)の会社に入った
* 起業した(not転職)
-* 就活に有利な技術のとらえか
+* 就活に有利な技術のとらえか
* 転職エージェント数社に登録していると、メルマガで分かる
* Pythonとかブロックチェーンとか
* ポートフォリオを作ったりしてた。
* 途中からはtwitter転職が便利!
* QiitaとかGitHubにアウトプットしている人のほうが有利な気がする
* Github上のコードだけじゃなくてQiitaとかnoteとか自分のブログみたいな記事も含めて、そういうアウトプットを増やしていくのはやっぱり評価されやすい
* 勉強会に参加して、勉強会主催会社にアピールするのもあり。
* 主催以外にも懇親会で知り合った人とか
## ローカルでgitで管理してるやつを、本番でも使うのってどうやるの?
* GitLab
手軽なのは
```
ssh 本番サーバ
cd /path/to/app/
git pull
```
productionブランチ, masterブランチを本番リリース用にするなど。
* GitHubとGitlabの違い
* GitHubはSaaS
* GitlabはCI/CDの機能がある
* CI:Pushするたびに特定の処理をしてくれるやつ(でいいよね?
* CD:↑できるならmasterブランチにpushされたら本番にデプロイだ!
* push とか pull は同じ
* GitlabはOSSなので、自社でインストールして使える
* > GitHubじゃないとCircleCIが使えない!
* [git pushでVPSにデプロイするには`git config receive.denyCurrentBranch updateInstead`で - Qiita](https://qiita.com/suin/items/abb7de5ce5fa0b4b96cb)
## YYPHPは毎週やってます
PHPについてワイワイ話したい方は、[YYPHPのイベント情報](https://yyphp.connpass.com/)をチェックしてみて下さい。
以上、YYPHPのレポートでした。次回もワイワイやっていきたいと思います! では、また来週!