ガチプログラマーがリファクタリンしたときに感じたWordpressでコーディングする際の注意点
最近、既存のWordpressを修正する機会がありました。デザインは崩れているし、ソースコードを触るのは辛い状態だったので、大幅にリライトしてリファクタリングしました。テーマを既存のテーマAffingerに切り替えて、機能を実装するために本当に必要な最小限のソースコードに書き換えた結果、メンテナンス対象のソースコード量は一桁どころから二桁ぐらい減らせた印象です。
いままでちゃんと技術的な品質の管理や指導をしていなかったと反省です。
せっかくいろいろいじったので、ガチプログラマーがリファクタリンしたときに感じた、Wordpressでコーディングする際の注意点をまとめてみました。
既存のテーマをベースにするなら既存のテーマの思想や機能を活かして必要最低限の実装をする。
フルスクラッチでWebサイトを制作する時のように、理想ベースでワイヤーフレーム、カンプを作って、開発・制作に入るならば、Wordpressのテンプレート階層などをしっかり理解して、必要十分にフルスクラッチでテーマを独自実装したほうがいいと思っています。
しかしながら本当に自分たちが作りたいWebサイトにそこまでのオリジナリティーが必要かどうかは立ち止まって考えたほうがいいです。既存のテーマを活かせば、多少独自機能をいれても数日でも終わってそこそこの見栄えになります。しかしながらフルスクラッチで書けば、しっかりやらないとデザインは残念になりますし、工数も数倍以上に膨れ上がる可能性があります。
また逆に、Stingerなどの既存のテーマを利用しているのに、既存のテーマの思想や機能を活かさずに開発や制作すると、思ったように動かすのに逆に既存のテーマの実装が足かせになって大変になります。既存のテーマを使うならば、既存のテーマの思想や機能を熟知して、どこまでカスタマイズできるかをしっかり把握すること。そのうえでそれを活かした自分たちのサイトの設計をすることが大事です。
子テーマを使う
これはやってあたりまえの話です。カスタム投稿タイプやタクソノミーなどを活用して独自機能を実装する場合は、どうしてもテーマのテンプレートファイル等のPHPファイルのカスタマイズが必要になります。
ここで絶対やってはいけないのが親テーマそのものの修正です。既存テーマは多機能なので当然コード量も多い。そこを直接様々な個所をいじるとメンテナンス対象のコード量が爆増します。また、既存テーマがアップデートされた際に、それを取り込むのが難しくなります。
子テーマを使えば、独自実装部分が明確にわかるし、また独自実装の範囲が狭くなるので、把握しなくてはいけないメンテナンス対象のコード量が劇的に減ります。
ExePHPは使わずにショートコードを使う。
これも常識の範囲の話で、とにかく ExePHPは絶対に使用しちゃダメ。プログラムを記載する部分は、ショートコードなどを使いCMSから書くコンテンツから必ず切り離して、プログラム部分はGitで管理できるようにしましょう。
テンププレートにロジックを記載しない
テンプレートには、可能な限り条件分岐などのロジックを記載しないのがベストです。例えば、新着フラグを表示したいようなケースで、下記のような記述をテンプレートに直接書くのはやめましょう。
template.php
<?php if (date('U', (date_i18n('U') - get_the_time('U'))) < 24 * 3600 ){ echo '<span class="newlavel">New</span>'; } ?> <h2><?php the_title();?></h2>
こういった場合は、独自テンプレートタグを実装して、テンプレートは <?php the_xxx(); ?> のようなテンプレートタグを呼び出すコードを記載する。そして、functions.phpなどに独自テンプレートタグ関数を用意して、テンプレートからロジックを分離しましょう。
template.php
<?php the_new(24);?><h2><?php the_title();?></h2>
functions.php
function the_new($hour) {
if (date('U', (date_i18n('U') - get_the_time('U'))) < 24 * 3600 ){
echo '<span class="newlavel">New</span>';
}
}
ショートコードの実装関数や独自テンプレートタグ関数にロジックとHTMLが混在させない
さっきの例は下記のようにするとむちゃくちゃメンテナンス性があがります。
functions.php
function the_new($hour) {
if (date('U', (date_i18n('U') - get_the_time('U'))) < $hour * 3600 ){
get_template_part('partials/new-labe.php');
}
}
partials/new-label.php
<span class="newlavel">New</span>
ショートコードでも関数内にHTMLを直書きしないでget_template_partで外だししましょう。
空の固定ページ＆テンプレートでHTML実装をやめる
例えばslugがhogeな空記事の固定ページを作成して、固定ページ用テンプレートpage-hoge.phpを用意して、すべてHTMLに直書きをするのは避けたいです。
絶対にダメなわけではありませんが、運用中に文章の変更などが、簡単にできなくなります。
こういう場合は、固定ページの記事に、エディターを使って静的な記述を行うこと。どうしても必要な動的な記述はショートコードに分離したほうがいいです。
ハイコンテキスト病に立ち向かう
友だちから「IQ高いひとはハイコンテクストで周りとゴールを共有できないことがあるので気をつけて！」とアドバイスを受けました。
IQ高いかどうかはさておき、「ハイコンテキストでいろいろ共有できてないことが多い」というのは、間違いなく事実です。
背景には、会社の代表である、市場・会社や事業を20年弱見続けているので、ハイコンテキストなつもりなくても、ハイコンテキストなところがあります。
ただしそこを除いても、ハイコンテキスト流に、コミュニケーションへの労力を疎かにしている自覚はあります。
いろいろ考えると理由としては、帰納法・演繹法的が好きで無意識に相手に要求する。職務上の複数の立場に応じた使命・責任などを切り替えて考える癖がありそれを相手に要求してしまうところではないかと、思っています。
基本的には、相手のレベルにあわせて何をすればいいのかわかるように噛み砕く。何をすべきか考えさせるのではなくて、まずやるべきことをストレスなくできるように導く。行動して体で覚えてもらう。
その上で何故そうしないといけないかを伝える。自分が帰納法・演繹法的に考えたことを簡潔に伝える。が、基本伝わらないものだと思って、根気よく話し続ける。
と、頑張ってみます（≧∇≦）
大雪対応のふりかえり
先日の大雪ですが、うちはマニュアルがあるから大丈夫でしょ(http://motoyasu-yamada.hatenablog.com/entry/2018/01/23/100751)と安心していましたが、なんとなく気になることもあり社員アンケートをとりました。
やはりいくつか大きな問題がありました。
- こちらのマニュアルは知っていた。(Y/N)
- マニュアルにのっとってオペレーションした(Y/N)
- 昨日の対応時に不安なことはなかったか？もしくはマニュアルに不備などなかったか？
- あらためてマニュアルを再度読み直してください。何か質問・提案・改善できることありますか？
それに対する社員のみなさんからのご意見
発動条件を変えるべき
よく見るとマニュアルの字面通り対応していたら、問題が起きていた可能性がありました。 しかし、みなさんが趣旨を理解してくれて、無事問題はなかったようです。
発動条件を見直す必要があります。
また、リモート対応が可能な場合は、途中帰社・出社は無駄なので、全日リモート対応できるべきかもしれません。
- 今回の場合は日曜の時点で警報レベルの積雪との予報だったので、出社前にリモートに切り替えるとかの対応で良かったと思う
- １４：３０の警報に気づくの遅れた。家が近いため帰宅と業務に問題ないと判断して社内にいました。18時前後だと帰宅までに通常より時間かかると予想できたので、時間をずらして帰宅しましたがそれでも混んでいた。大雪だと翌日以降も影響大きく事故が起こりやすいので、早めの帰宅にすべきだったと思っています。
- 警報が出たときにはすでに遠い人は帰るのが難しくなりそうな状況だったので、警報がでなくても起きることが明らかなときは自宅勤務に切り替えなどしてほしい。
- 警報ではなく、「注意報」か「警戒呼びかけ」レベルで前日に判断してリモートの指示をするのがよさそう。帰りはどうしたって混む。
- あらかじめ大雪になると予報されている段階で勤務中に警報が出てからの行動では遅いと思いました。
- 警報が出てから対応すると遅いので、気象庁から「不要不急の外出を控える」呼びかけがあった場合、警報と同じとみなすなどのルールのほうがとよいかも
休業ではなくリモートワークにならないかという要望
法律の問題(参考資料)があるために、デフォルトは休業にせざるをえないと思っています。 しかしながら、仕事の種類・リモートワークの経験値から、条件が整っている場合に限りリモートワークを可能としてもいいかもしれません。
- 警報で帰宅した後、可能ならば作業するでよいと思います。 完全休業はせず、足元が悪くなる前に少し早めに会社を出て残件はリモートで作業しました。
- 大雪警報時は完全休業ではなく、リモートでの業務がありがたいです
- 警報が出る前に帰宅しリモート作業にしました。電車も混雑ありませんでした。出勤時に台風が迫っている時はマニュアルにのっとって行動しました。
- 休業で土曜日振替は負担が大きいので、リモート勤務のほうが助かる
- 休業した分は休日に振替出勤となっていますが、休日予定があったりするので、警報が出た日は家でリモートだったらありがたいです。
- リモート切り替えにするオペレーションにアプデしたほうがよいと思いました。
- 休日振替がうまくいかなそうなのでついそのまま業務してしまう
きっちマニュアルを作り強制させないといけない
「正常性バイアス」があるので、責任者の判断任せとか、個人の判断を尊重すると、大きな被害がでます。
- 思ったよりみんな帰らなくて不安になった。
- 早めに帰ったほうがいいのでは？みたいな感じが僕と杣さんくらいだったので、不安というかみんなそんな感じなのか...と思った
- 大雪警報なので災害時より緩く考えていました。マニュアルは確認しましたが業務のきりが良くなるまで会社を出ませんでした。
- 警報で休業は見落としていたが、近いので支障はなかった
- オペレーション事項を失念していたのもあるが、家が近いとなんとか行ける＆帰れると思ってしまっている。
大雪などの場合の対応もマニュアル化して各自が自主判断できるようにする
上司の仕事の一つが、日常的ではない出来事が起きた場合の判断です。
日常的ではない出来事が、上司がいるときに発生する、また上司が経験豊富だったらいいのですが、 上司が現場におらずに現場の状況を把握できなかったり、経験不足のまま判断を迫られたりで、適切な判断ができないことがらいます。
とはいえ、日常的ではないことの大半も、毎日起きないというだけで、年に何回かは起きることが想定されます。
なので、大雪などの場合の対応もマニュアル化して各自が自主判断できるようにしています。 大概の判断は、条件式をきっちり記載すれば、自動化できると信じています。
昨日はとくに判断を仰がれませんでしたが、なのである程度みんなが自主的に判断して動いていました。 うちのマニュアルでは次のようになっています。
基本的な考え方
- 出社が非効率的になるときは、出社しないで在宅で勤務する。天災・交通災害、育児・介護が原因の場合は特に。
- ルールを整備します。ルールをもとに各自が自主判断できるようにします。
- 追加のルールが必要な場合は、提案してください。
災害時(台風等)への対応
台風等により、気象庁から本社の所在地域に「暴風警報」が発令された場合、以下の基準により勤務の基本時間の変更措置をとります。 所在地: 東京都新宿区 警報の確認先: 気象庁
通勤時の判断について
＜考え方＞
- 準備を含めた通勤のために3時間が必要とする。
- 勤務時間帯の3時間前までに警報が解除されなければ、その時間帯は休業とする。
- 12:00を超えても警報が解除されなかった場合は完全休業とする
- 勤務時間中に警報が発令された場合は即時その日を完全休業とする
- 一部時間帯が休業の場合は終業時間を22:00まで延長する。
- 勤務可能時間が、4時間未満になる場合は、その日は完全休業とする。
- 一部時間帯休業の場合は、その月の他の営業日の基本勤務時間を延長する。
- 完全休業の場合は、「次の土曜日を出勤日にふりかえる」。月末で振り替えられない場合は、その月の他の営業日の基本勤務時間を延長する。
- 各部門での管理者が指示に従い、警報の発令や解除をふまえた対応をすること。
- 管理者からの指示がない限り、原則、一部時間帯休業または完全休業とする。出勤や自宅勤務は、控えるものとする。
- 管理者が緊急かつ重要な業務があると判断して指示があった場合に限り、一部時間帯休業または完全休業を自宅での勤務にすることがある
＜時間帯と警報解除期限＞
営業時間帯 警報解除 9:00-12:00 6:00まで 13:00-15:00 10:00まで 15:00-18:00 12:00まで
いま見ると気になるところが二点。
- 台風を軸に記載されている（もちろん限定されていないがわかりづらい)
- リモート勤務がなかったころの名残でリモート勤務ではなく休業となっている。
今回は何もありませんでしたが、これを機会に来年へ向けて改善しておきます。
プロダクト愛
「プロダクトへの愛」が大事。
プロダクト作りや運営のおいて、たまに「作りたい病」にかかってしまうことがある。
作りたいという想いがダメではなく、プロダクト愛に欠けるのがよくない。
ゲームならば、プロダクト愛とは、「遊んでくれる人に楽しんでもらいたい」が、とにかく重要。
「遊んでくれる人」に楽しんでもらおうという気持ちと無関係に、俺の自由に作りたいというだけのオレオレ病になってはいけない。
次に大事なのは、遊んでくれる人を理解するために、ターゲットとするユーザーが使っている競合や代替プロダクトの研究をすることだと思っています。
ちゃんと楽しんでもらうには、実際に遊んでくれる人をイメージして、どのような気持ちで何をしているのかを理解していく努力が必要だと思っています。
勝てる確率三割あれば挑戦するけど、事前に負ける可能性は確実に潰す
不確定な現実世界の中では、ビジネスに必勝の法則はないと思っています。
やろうと思っていることに勝てる確率が三割あると信じれるのであれば、それ以上の勝率を模索するより、軌道修正しながら全速力で進んだほうがいいはずです。
ただ、三割というのは、でたらめにやればいわけではありません。はじめる前には不安な気持ちがつきまとうので、もし三割勝率があると感じるなら、挑戦した方がいいということです。
逆に、負ける確率が高い、明らかに間違えていることはやるべきではありません。壁打ちなどで早めに仮説は検証して、明らかな間違いは潰すこと。負ける確率が高いことは、なんらかの手を打つ必要があります。
勝てる確率が三割でいいといからといって、負ける確率が七割あってもいいとというのとは全く違います。
