機能要望 > その他 > EC-CUBE2.11.0正式版に向けたソースリファクタリング |
その他
スレッド表示 | 古いものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
KAJI |
投稿日時: 2011/2/2 11:20
対応状況: −−−
|
一人前 登録日: 2008/1/24 居住地: 投稿: 121 |
Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング 皆さま
株式会社ロックオンの梶原でございます。 色々、ご意見ありがとうございました。 ご要望の方向性は結構似通った部分があり、今後の方向性を決める上で、非常に有意義なスレッドになったと思います。 ということですが、今回時間的にも2.11.0で行えることには限りがあり、検討した結果、今回のリファクタリングに関しては、以下の方針で進めていくことにします。 ○今回は基本的にLC_page系のリファクタリングを実施する。 ⇒検討の結果、以下リファクタリングガイドラインにて一旦FIXとさせていただきたく思います。 リファクタリングガイドライン ※LC_page以外(SC_Helper系等)のリファクタリングは計画としては入れないが、余力があれば行ってもよい。 ※_Exクラスは削除しない。(追加ページ等が発生した場合は、_Exも追加する) ※PHP4.3.11で動作するコードで記載する。(2系のシステム要件です。) 以上のような形で進めていきたく考えております。 皆さまからのご意見は、今後のための貴重なご意見として参考させていただき、また機会を改めて議論をさせていただきたく思います。 リファクタリングの進め方に関しましては、別途スレッドを立てて進めたいと思います。 |
seasoft |
投稿日時: 2011/1/31 2:20
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング 引用:
実際に80文字で折り返されたら、査読スピードが落ちるケースも多いと思います。(特にバリデーションの定義とか) また、1行に収めるために短縮した命名を行うような事にも繋がりかねないと思います。 Zend Framework PHP 標準コーディング規約に非常に的確なガイドラインが書かれていることですし、あえて明記しない方が良いのではないかと思います。 # 「1行の行数は」→「1行は」ですかね。
|
tao_s |
投稿日時: 2011/1/30 4:26
対応状況: −−−
|
仙人 登録日: 2008/8/20 居住地: 東京 投稿: 799 |
Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング カスタマイズした際にどの部分をカスタマイズしたかが解りやすいので、個人的には_Exはあっても良いかな?と思います。
ただ、色々面倒が多いのも知ってます。 CodeIgniterやconcrete5を良く使っているので、EC-CUBEにもオーバーライドの機能があれば嬉しいなー、と思っています。 あと、現状の仕様では、まず_Exを読みに行きますが、/data/class_extendsにファイルがあったらそっちのインスタンスを生成する様にしたいです。 こんな感じで
※まったくテストしてないので動くかどうかわかりません。
|
seasoft |
投稿日時: 2011/1/30 1:26
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング 変数名について提案があります。スレッドが混在してきましたので、別スレッドに分けさせていただきます。
http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=7441&forum=14
|
ECCUORE |
投稿日時: 2011/1/30 0:32
対応状況: −−−
|
長老 登録日: 2009/10/22 居住地: 東京 投稿: 248 |
Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング 引用:
賛成です。 Helperは、機能単位になるとスッキリしますよね。 個人的には、全体的な思想としてredさんのAction思想にプラスしてghanaさんのクラスを分ける案と、HelperとかModelの思想がいいです。 Modelは、Table単位、フォーム単位なのですかね。
|
nanasess |
投稿日時: 2011/1/30 0:31
対応状況: −−−
|
神 登録日: 2006/9/9 居住地: 投稿: 2314 |
Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング 引用:
これはごもっともで, SC_Helper_DB は, 機能ごとに分割する等整理が必要です. SC_Utils も, DBアクセスを伴うものの他, エラー制御関数も, あまりよろしくないですよね. ただ, 今回のリファクタリングの期間では, ページクラスだけで精一杯な気がします. |
seasoft |
投稿日時: 2011/1/29 12:15
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング 引用:
私も一応賛成です。 EC-CUBE 本体ソースにも、_Ex を使わない(「存在しない」ではない)ものが存在し、その基準が分からず混乱しています。(実装誤りかと思い確認したこともありますが、仕様らしいです。) また、決済モジュールにも、_Ex を使わないものが存在します。実際、決済モジュールを使用した支払い時のみ金額計算を誤まるという事故を発生させた、非常に苦い経験もあります。 さらに、決済モジュールには _Ex を上書きするものも存在したと記憶しています。 リファクタリングが進めば、_Ex の利用性(ユーザビリティ)が向上し、また _Ex が存在することでリファクタリングが進みやすくなるというメリットも感じています。しかし、上述のような基本的な問題を解決できなければ、最終的には失望を生むことになると感じ、賛成を表明します。
|
AMUAMU |
投稿日時: 2011/1/29 2:30
対応状況: −−−
|
神 登録日: 2009/5/2 居住地: 東京都 投稿: 2712 |
Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング 確かにSC_Helper_DBが、取りあえずの共通関数置き場になっているような感じで整理が必要だと思います。
またSC_Utilsも同じような状態なのも気になります。 あとDBアクセスが伴うものもSC_Utilsにあるのは良いのかとか・・・
|
tao_s |
投稿日時: 2011/1/28 21:47
対応状況: −−−
|
仙人 登録日: 2008/8/20 居住地: 東京 投稿: 799 |
Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング 個人的にはSC_Helper_DB.phpが長いんで見にくいです。
SC_Helper_DBはあまりに抽象的な名前で処理もいろんな物が含まれていると思います。 ここをもうちょっと具体的な SC_Helper_CategoryとかSC_Helper_CartとかSC_Helper_Customerとかに分けるのはダメでしょうか? と言うか、そうするとhelperなのにmodelみたいになっちゃいますね...
|
KAJI |
投稿日時: 2011/1/28 19:53
対応状況: −−−
|
一人前 登録日: 2008/1/24 居住地: 投稿: 121 |
Re: EC-CUBE2.11.0正式版に向けたソースリファクタリング 各位
株式会社ロックオンの梶原でございます。 皆さま、色々ご意見をいただいており、誠にありがとうございます。 まだ、議論を収束させるのもあれですので、このままご意見を募集し、色々な観点で 揉んでみたいと思います。 (非常に色々考えていただき恐縮です。今回対応できないにしても、ベストだと 思う案をいただければ幸いです。) 最終結果はまたまとめてご提示できればと思います。 まずは、ご意見を頂いております、皆さまへの御礼まで。 |
(1) 2 3 4 » |
スレッド表示 | 古いものから | 前のトピック | 次のトピック | トップ |