長年運用されてきた PHP プロダクトをこれからも安心して使い続けるためには、 PHP 本体のアップデートが不可欠です。
本セッションでは、 PHP 4 の時代から20年以上運用されたプロダクトを PHP 8.3 までアップデートしてきたことで得られた知見と、 PHP 8.4 以降にバージョンアップするために何をするのか、を共有します。
レガシーと向き合う皆さんに役立つ実践的な知見をお届けします。
■ 話すこと
AIを利用したコーディングによって生産性が高まっていることは間違いありません。
0→1の生産性が高まった反面、設計不備による低品質なコードやテーブルも量産されてしまいます。
だからこそ、今こそデータモデルのあるべき姿を考え、その形にデータベースもリファクタリングしていくことが必要です。
そこで今回は下記の項目についてご紹介します。
コードレビューでは、人格攻撃をしてはならないとされています。
それは裏返せば、書かれたコードをレビューするときに
それを書いた人のことをどうしても考えてしまう、ということでもあります。
自分が攻撃(非難)されたように感じてしまうのも、同じこと。
自分が書いたコードは、あたかも自分の一部であるかのように感じる気持ちがあるのです。
しかし現在、生成AIがコードを書くようになってきています。
人間が書いているところを補完してくれたり、
自律的にコードを書いてPull Requestの作成までしてくれます。
では、そのコードはあなたが書いたものだと言えますか?あるいは、思えますか?
このトークでは、コードと私たちの距離について考察します。
(心理的な)オーナーシップの話だけでなく、責任の分界点についても見ていきます。
生成AIの導入で変わりつつある距離感について、一緒に考えてみませんか。
PHPはWeb開発の現場でカジュアルに使われてきましたが、「正しく」使うのが難しい言語だと言えます。
20年以上の歴史を重ねてきたWeb開発の現場でもさまざまな言語が生まれてきましたが、PHPの存在感は未だに衰えてはいません。
そのような言語の中でも揺れ動いてきたのが「静的(static)」と「動的(dynamic)」という概念です。
PHPは一般に「動的型付けのスクリプト言語」のように分類されますが、異なる特徴を持った言語も多く登場しています。
本トークではPHPの静的性と動的性について紹介し、PHPの現在地点、そして「静的解析」という技術がどのように問題解決につながるかを紹介します。
現代のコンピュータはハードウェアから私たちプログラマが書くプログラムの動作までの間が多くのレイヤーに分けられて動作しています。
レイヤーは自分より下を抽象化し、下のレイヤーを詳しく理解しなくても多くの場合プログラマはプログラムを書けます。
一方、プログラムが期待した様に動作しない時には下のレイヤーの動作の理解が問題の解決の助けになることもあります。
このトークでは私たちが愛するPHPをスタート地点にして、「VMって何?」「 PHPやJavaとC言語の根本的な違い」など、コンピュータプログラムがどの様に動作するのかを解説します。
コンピュータのレイヤー構造を理解すると、いままでは見えていなかった角度からプログラミングを楽しめるようになります。
このトークを通じて、低レイヤーが好きになったり、いろいろなレイヤーで面白いことをしたりする方が増えることを期待しています!
PHP は2015年以来、毎年11〜12月頃にバージョンアップが行われており、11月20日には待望の PHP 8.5 がリリース予定です。
かつてはゆるふわ言語の代表格として知られた PHP ですが、7.0 以降は型周りの表現力が大幅に強化された他、Readonly Property/Class の導入など、堅牢で読みやすく、壊れにくいコードを書くための強化が行われてきました。
そして PHP 8.5 では Haskell や Elixir など「関数型言語」にあるような「パイプ演算子」が導入されます。PHP にパイプ演算子……隔世の感がありますね。
本トークでは PHP 8.5 で導入される新機能の内、個人的に注目しているパイプ演算子と NoDiscard アトリビュートを中心に、どのようなメリットをもたらすのかを具体的なコードと用例を用いて解説します。
このトークでは、ある仮説を提案します。
技術的負債の、「利率」にあたる部分はチームメンバーの増加によって見かけ上増える
プロダクトの開発で機能とソースコードが変更されると貸借対照表の借方に新機能によって得られる価値(正味現在価値)が入り、貸方に技術的負債が入ると捉えられます。この、貸方に入る技術的負債が通常の負債とは異なる性質を持つと言うのが、この仮説の骨子です。
トークでは、貸借対照表や正味現在価値などの用語についても解説を加えます。
この仮説を通して、各チームで
・技術的負債の解消をするかどうか
・いつ技術的負債を解消するか
・カスタマイズをすべきかどうか
・カスタマイズをする場合はリファクタリングを計画するか
などについて議論を深めるきっかけにしていただくことを目指します。
※内容の正確さには注意を払いますが、私は会計学の専門家ではありません。