すみません。1日おくれましたが。。。

私が携わっているリニューアル案件で、つまずいた点／発生した問題点をつらつらと共有したいと思います。

今後、2系→3系への乗り換えを行う案件担当者が同じ箇所でつまづくことが少しでも減らすことができればと思っています。

以下リニューアル案件の詳細を簡単に、、、
年間受注件数：数万件以上
EC-CUBE Version：2.4→3.0.10
開発方針：本体プログラムへの修正※1
機能数：300以上
※1：当初プラグイン開発を検討しておりましたが、機能数・DBテーブルの移行等を考慮し、本体プログラムを修正していく方針に変更しました。

◯DB構造の微妙な変化
　大きくはDB構造が同じなので、当初あまり気にしておりませんでしたが、
　実際に開発・運用してみると微妙な違い逆にはまったり、テストフェーズにて不具合のような形で発覚しました。
　ですので、変更点をはじめの段階で抑えておくべきかと思います。
　数点上げると、
　・dtb_orderの考え
　　2系では、カート投入から購入完了までの間、dtb_order_tempで管理し、購入完了でdtb_orderにコピーという形でしたが、
　　3系では、全てをdtb_orderのみとして、statusによって購入完了前後の状態を管理する形になっております。
◯速度面
　今回Doctrine（ORM）の使用、Entityでデータを処理している等もあり、2系と比較すると速度面が開発当初気になりました。
　速度を気にするようなサイト作成の際ははじめの段階で、検証しておくことをおすすめします。
　※ただし、2016/12/11現在、キャッシュ機構などが改善されかなり速度は早くなってきております。
◯モバイル対応がなくなった。
　ここは、開発初期に顧客ときちんとネゴっておくことをおすすめいたします。
　本案件では、モバイルアクセス時、
◯管理画面のレスポンシブ対応について
　3系では、管理画面、フロント画面ともにレスポンシブ対応されており、
　顧客提案時も受けがよく受注のハードルはさがるのですが、
　ある程度の顧客になってくると、管理画面のレスポンシブ対応が逆に問題となる場合があります。
　具体的には、業務的に必要な項目を追加していくと、項目数が多くなり受注登録画面がとても縦長になってしまいます。
　反面、小規模の店舗主さんにとってはスマホから気軽に受注情報が見れるなど、顧客によって意見がわかれるところではあります。
◯決済プラグインのフックのやりかたについて
　全プラグインに関していえるかどうかはわかりませんが、
　本案件で使用した決済プラグインは、購入完了時の処理をまるごとフックし、本体の処理も含めてプラグイン側で実施している状態でした。
　そのため、購入完了時に別の機能を追加したい場合、決済プラグイン自体に手を入れる必要があり、
　結局決済プラグインをほぼ使用せず、決済会社へ接続するために提供されているAPIの部分だけを使用し、
　その他は、自前で実装する形になりました。
◯受注登録の商品追加/会員検索利用時、データ量が多いととまってしまう。
　この問題は、検索結果まるごと1ページに表示されるため発生しておりました。
　本案件では検索条件を増やして、絞り込んでから検索していただく運用で回避いたしました。
　※3.0.13で、本体にページング機能が追加されるようです。
　　https://github.com/EC-CUBE/ec-cube/issues/1917
◯メールアドレスが、「hogehoge.@docomo.ne.jp」「hoge..@docomo.co.jp」などのドットの使用パターンに対応していない。
　3系では、SwiftMailerを使用しておりその影響により日本独自使用のメールアドレスが送信できない仕様となっております。
　（リニューアル案件ではあるあるかと思います。）
　以下に対応策を作成いただいている方がおられましたので、それを参考にいたしました。
　https://slack-redir.net/link?url=https%3A%2F%2Fgithub.com%2Fnanasess%2Fec-cube%2Fcommit%2F5ef9bbc81d17469e2d3822defe1ef1744771cf1b

以上、他にもありますがつらつらと書かせていただきました。

問題点を書きましたが、
EC-CUBE3で開発したことによるメリットを少し書いておくと、
フレームワークが採用されていることにより、開発効率はやはりあがったように思います。
実際、実装のメイン担当者はエンジニア3年目の方でしたが、
FWの仕組みにうまくのれたときは、
スクラッチ開発での想定よりも早いスピードで開発してくれておりました。