2010-03-06 13 views
6

मुझे एक बड़ी PHP वेबसाइट मिली है जिसे मैं अब देखभाल करने वाला हूं। इसमें सैकड़ों अलग-अलग PHP फ़ाइलें शामिल हैं, लेकिन मुझे संदेह है कि आधे से भी कम वास्तव में उपयोग किया जा रहा है। उनमें से ज्यादातर शायद हटाया जा सकता है।कैसे बताएं कि कौन सी PHP फाइलें वास्तव में उपयोग की जाती हैं और कौन नहीं हैं?

लेकिन आखिरी चीज जो मैं वास्तव में करना चाहता हूं वह प्रत्येक फाइल के कोड से गुज़र रही है और जांच कर रही है कि इसके लिंक, शामिल, आवश्यक ... आदि। दूसरों के लिए या क्या इसे सुरक्षित रूप से हटाया जा सकता है।

क्या आप जानते हैं कि ऐसा कोई उपकरण है जो ऐसा करने में सक्षम है?

+0

अच्छा सवाल, ध्यान रखें कि आप सभी फाइलें नहीं पकड़ सकते हैं। क्योंकि आप फ़ाइलों को गतिशील रूप से शामिल कर सकते हैं और कौन सी फाइलें शामिल हैं वे चर की स्थिति पर निर्भर कर सकती हैं। – Thirler

+0

मुझे कोई कारण नहीं दिख रहा है कि इस सवाल को ऑफ-विषय के रूप में क्यों रखा गया था, जबकि यह http://stackoverflow.com/questions/1811421/determining-which-php-source-files-are-not-used प्रश्न नहीं था। इसके अलावा, मुझे नीचे दिए गए अधिकांश उत्तर उपयोगी हैं और मैंने उस व्यक्ति को चिह्नित किया जो मेरे लिए उत्तर के रूप में सबसे अच्छा काम करता था। – NumberFour

+0

इसे भी आजमाएं: http://php.net/inclued –

उत्तर

8

phpxref पर एक नज़र डालें, यह आपको जो चाहिए वह हो सकता है।

क्रॉस-संदर्भ PHP वर्ग, फ़ंक्शंस, चर, स्थिरांक और आवश्यकता/उपयोग शामिल हैं।

+3

वह ** eval ** के माध्यम से आमंत्रण संभाल नहीं करेगा। न ही यह फाइलों के समूह को संभाल लेगा जो एक दूसरे का संदर्भ देते हैं, लेकिन जिसके लिए बाहर से कोई संदर्भ नहीं है। –

0

इसे प्राप्त करने के कई तरीके हैं, लेकिन सभी में कुछ मैन्युअल कार्य शामिल होंगे।

आप शायद सबसे अच्छा इंस्टॉल कर सकते हैं और एक डीबगर (जैसे Xdebug) का उपयोग कर सकते हैं जो आपको PHP यात्रा के मार्ग को दिखा सकता है जैसे आप उनके माध्यम से क्लिक करते हैं।

एक और तरीका 'स्क्रिप्ट', 'include_once', 'आवश्यकता', 'requ_once' पर मेल खाने वाली एक स्क्रिप्ट लिखना है। शायद 'eval' और 'fopen', 'file_get_contents' आदि के लिए भी जांच करें। सुनिश्चित करें कि आप परीक्षण/बैकअप लें।

+0

और मुझे अभी एहसास हुआ - कोई href = file.php भी एक संभावित मैच है! तो स्क्रिप्ट/grep दृष्टिकोण को भी ध्यान में रखना चाहिए। – MattW

2

phpdcd

phpdcd पर एक नज़र PHP कोड के लिए एक मृत कोड डिटेक्टर (DCD) है है। यह सभी घोषित कार्यों और विधियों के लिए एक PHP प्रोजेक्ट स्कैन करता है और उनको "मृत कोड" के रूप में रिपोर्ट करता है जिन्हें कम से कम एक बार नहीं कहा जाता है।

लेकिन इससे किसी भी आश्चर्य की उम्मीद न करें।

2

स्वचालित उपकरण के साथ कोड का विश्लेषण करने में समस्या यह है कि आपको फ़ाइलों के बैच मिल सकते हैं जो एक-दूसरे से जुड़ते हैं, लेकिन फ़ाइलों का बैच कभी भी उपयोग नहीं किया जाता है। इसके विपरीत, एक फ़ाइल हो सकती है जिसे सीधे एक्सेस किया जा सकता है, लेकिन अन्य फ़ाइलों का उपयोग नहीं करता है, न ही यह किसी अन्य फाइल द्वारा शामिल किया गया है।

आमतौर पर जो मैं करता हूं, निराशा में, प्रत्येक फ़ाइल में लॉगिंग जोड़ता है। जब फ़ाइल का उपयोग किया जाता है तो लॉग फ़ाइल में __FILE__ सरल लिखें। यह बोर्ड भर में ओवरहेड जोड़ता है। लेकिन कुछ निश्चित समय के बाद, आपके पास फ़ाइलों की आपकी सूची वास्तव में उपयोग की जाती है और उपयोग की जाती है।

आप नियमित रूप से लॉग फ़ाइल का विश्लेषण भी कर सकते हैं और आपके द्वारा उपयोग की जाने वाली फ़ाइलों से लॉगिंग को हटा सकते हैं, जैसे ही आप जाते हैं ओवरहेड को कम करते हैं। अंत में, आप उन फ़ाइलों की खोज कर सकते हैं जिनके पास अभी भी लॉगिंग कोड है, यह देखने के लिए कि किसके उपयोग नहीं किए गए हैं।

+0

टेस्ट कवरेज मूल रूप से आपके लिए यह लॉगिंग जोड़ता है। खुद ब खुद। मेरा जवाब देखें –

0

आप __construct मेथोड का उपयोग कर सकते हैं और इसका उपयोग होने पर इसे लॉग कर सकते हैं। उदाहरण बनाने के बाद आप __construct मेथोड सेट नहीं कर सकते हैं। तो उन्हें मैन्युअल रूप से जोड़ें;

class Someclass{ 
private $clsName; 
public function __construct(){ 
$this->clsName = get_class($this); 
YourStaticLogger::yourlogFunction("whatever you want to log" . $this->clsName); 
} 
//other things 
} 

आप केवल कॉल किए गए वर्गों को ट्रैक कर सकते हैं। मैं यही करूँगा।

+0

यह वही जवाब है जैसे "प्रत्येक फ़ाइल में लॉगिंग जोड़ें"। –

+0

अच्छा है, लेकिन यह कक्षा वर्गों द्वारा विस्तारित अमूर्त वर्गों और अभिभावक वर्गों के लिए काम नहीं करेगा क्योंकि बाल वर्ग माता-पिता वर्ग के __construct मेथोड को ओवरराइड करेगा और प्रत्येक उदाहरण के लिए केवल एक __construct चलाएगा। – eyurdakul

1

यदि आप एक परीक्षण कवरेज टूल का उपयोग करते हैं, तो यह बताएगा कि आपके द्वारा उपयोग किए जाने वाले सॉफ़्टवेयर की जो भी कार्यक्षमता के लिए निश्चित रूप से उपयोग किया जाता है।(जाहिर है, जितना अधिक आप सॉफ़्टवेयर का अभ्यास करते हैं, उतना ही इसे गैर-मृत भाग द्वारा निष्पादित किया जाता है।)। इसमें किसी बाहरी फ़ाइल को बाहरी HTML लिंक के माध्यम से सुलभ किया गया है; बेशक, आपको व्यायाम है जो लिंक है, क्योंकि यह आपकी एप्लिकेशन कार्यक्षमता का हिस्सा है।

फिर आप उन लोगों का निरीक्षण कर सकते हैं जिनका उपयोग नहीं किया जाता है, यह तय करें कि वास्तव में क्या मामला है।

हमारे SD PHP Test Coverage tool फ़ाइलें आप की जाँच करने के लिए, और आसानी से इस तरह के परीक्षण कवरेज डेटा एकत्र करने के लिए सक्षम इच्छा सभी की एक सूची को स्वीकार करेंगे। यह सारांश रिपोर्ट प्रदान करता है कि कौन सी फाइलों में कोई कवरेज है; 0% कवरेज वाले लोग हैं जो संभावित रूप से मृत हैं।

+0

क्या इसमें शामिल PHP स्क्रिप्ट शामिल हैं? उन लोगों के बारे में क्या जिन्हें एजेक्स एक्शन के माध्यम से बुलाया जाता है? मुझे लगता है कि एक विशेष स्क्रिप्ट के बीच मृत कोड खोजने के लिए, एक उपकरण का उपयोग करके @ पेक्का या @ गॉर्डन प्रस्तावित किया जाएगा तो अधिक उचित होगा। – Eldros

+0

@ एल्ड्रोस: इससे कोई फ़र्क नहीं पड़ता कि स्क्रिप्ट कैसे आती है (शामिल है, AJAX के माध्यम से)। प्रोजेक्ट सूची में एक फ़ाइल में रखे गए उपकरण, नोटिस करेंगे कि स्क्रिप्ट का आह्वान किया गया है, और इसी प्रकार स्क्रिप्ट के आमंत्रण की * अनुपस्थिति * को भी नोटिस करेगा। –

+0

@Eldros: स्रोत कोड का निरीक्षण करके उत्तर निर्धारित करने के लिए तथाकथित "स्थैतिक विश्लेषण" उपकरण सटीक होने की संभावना नहीं है। कोई रनटाइम पर एक विधि नाम इकट्ठा कर सकता है और इसे कॉल करने के लिए eval का उपयोग कर सकते हैं; बहुत कम स्थैतिक विश्लेषण तकनीकों (दूसरों को दूसरों के रूप में सूचीबद्ध विशिष्ट उपकरणों में अकेले रहने दें) इसे निर्धारित कर सकते हैं; इसलिए वे आपको बता सकते हैं कि कुछ उपयोग नहीं किया जाता है भले ही यह अक्सर निष्पादित हो; वे आपको बता सकते हैं कि कुछ भी प्रयोग किया जाता है भले ही यह कभी निष्पादित न हो। इसके विपरीत, परीक्षण कवरेज टूल हमेशा आपको सही तरीके से बताएगा यदि कुछ * उपयोग * निष्पादन द्वारा प्रमाणित है। –

संबंधित मुद्दे