स्केलिंग प्रोजेक्ट्स के मामलों पर एक दिलचस्प केस स्टडी जो गतिशील और व्याख्या की गई भाषा का उपयोग करते हैं, डेविड पोलाक द्वारा शुरुआती स्केला में पाया जा सकता है ।
मैंने अपने मस्तिष्क में कोड को सरल, अधिक प्रत्यक्ष तरीके से व्यक्त करने का तरीका खोजना शुरू कर दिया। मुझे रूबी और रेल्स मिले। मुझे मुक्ति महसूस हुई। रूबी ने मुझे कोड की बहुत कम लाइनों में अवधारणाओं को व्यक्त करने की अनुमति दी। स्प्रिंग MVC, हाइबरनेट और अन्य "सुव्यवस्थित" जावा वेब फ्रेमवर्क की तुलना में रेल का उपयोग करना बहुत आसान था। रूबी और रेल्स के साथ, मुझे एक छोटी सी अवधि में मेरे सिर में जो कुछ था वह बहुत अधिक व्यक्त किया गया। यह उस मुक्ति के समान था जिसे मैंने C ++ से जावा में स्थानांतरित होने पर महसूस किया था ...
जैसे-जैसे मेरी रूबी और रेल परियोजनाएं कोड की कुछ हज़ार लाइनों से आगे बढ़ती गईं और जैसे-जैसे मैंने अपनी परियोजनाओं में टीम के सदस्यों को जोड़ा , गतिशील भाषाओं की चुनौतियाँ स्पष्ट होती गईं।
हम अपने आधे से अधिक कोडिंग समय लिखने के परीक्षण में खर्च कर रहे थे, और हमने जो उत्पादकता लाभ देखे, उनमें से अधिकांश परीक्षण लेखन में खो गए थे । अधिकांश परीक्षण जावा में अनावश्यक थे क्योंकि उनमें से अधिकांश यह सुनिश्चित करने की दिशा में सक्षम थे कि जब हमने विधि के नाम या पैरामीटर की गणना को बदलकर कोड को रिफलेक्ट किया तो हम कॉलर्स को अपडेट कर देंगे। इसके अलावा, मैंने पाया कि उन टीमों पर काम करना जहां दो से चार टीम के सदस्यों के बीच मन में मधुरता थी, रूबी में चीजें अच्छी हो गईं, लेकिन जैसा कि हमने टीम में नए सदस्यों को लाने की कोशिश की, मानसिक कनेक्शन नए टीम के सदस्यों को प्रेषित करना कठिन था ।
मैं एक नई भाषा और विकास के माहौल की तलाश में था। मैं एक ऐसी भाषा की तलाश कर रहा था जो रूबी के रूप में अभिव्यंजक थी लेकिन जावा के रूप में सुरक्षित और उच्च प्रदर्शन ...
जैसा कि आप देख सकते हैं, लेखक के लिए प्रोजेक्ट स्केलिंग में प्रमुख चुनौतियां परीक्षण विकास और ज्ञान हस्तांतरण में बदल गईं।
विशेष रूप से, लेखक अध्याय 7 में गतिशील और वैधानिक रूप से टाइप की गई भाषाओं के बीच परीक्षण लेखन के अंतर को समझाने में और अधिक विवरण में जाता है। अनुभाग में "मार्मिक रूप से किलिंग बनिज़: डवेमी के सीढ़ियाँ" लेखक एक विशेष रूबी उदाहरण के स्काला पोर्ट पर चर्चा करता है:
लकी स्टिफ क्यों ... ड्वेमी के एरे में रूबी के कुछ मेट्रोपोग्रामिंग अवधारणाओं का परिचय देता है जिसमें एक खरगोश जीवों की एक लड़ाई लड़ता है। N8han14 ने स्काला में काम करने के लिए उदाहरण को अद्यतन किया ...
रूबी कोड की तुलना में, स्काला कोड के पुस्तकालय भागों अधिक जटिल थे। हमें यह सुनिश्चित करने के लिए बहुत काम करना था कि हमारे प्रकार सही थे। हमें DupMonster और CreatureCons कक्षाओं में प्राणी के गुणों को मैन्युअल रूप से फिर से लिखना पड़ा। इससे ज्यादा काम है method_missing। हमें अपने जीवों और हथियारों में अपरिवर्तनीयता का समर्थन करने के लिए उचित मात्रा में काम करना था।
दूसरी ओर, परिणाम रूबी संस्करण की तुलना में बहुत अधिक शक्तिशाली था। अगर हमें अपने रूबी कोड के लिए परीक्षण लिखना था, तो यह जांचने के लिए कि स्कैला कंपाइलर हमें क्या आश्वासन देता है, हमें कोड की बहुत अधिक लाइनों की आवश्यकता होगी। उदाहरण के लिए, हम यह सुनिश्चित कर सकते हैं कि हमारा खरगोश एक कुल्हाड़ी नहीं मार सकता। रूबी में यह आश्वासन पाने के लिए, हमें एक परीक्षण लिखना होगा जो यह सुनिश्चित करता है कि |^एक खरगोश पर आक्रमण विफल हो जाता है। हमारा स्काला संस्करण यह सुनिश्चित करता है कि किसी दिए गए प्राणी के लिए परिभाषित केवल हथियार का उपयोग उस प्राणी द्वारा किया जा सकता है, कुछ ऐसा जो रूबी में बहुत सारे रनटाइम प्रतिबिंब की आवश्यकता होगी ...
उपरोक्त पढ़ना यह सोच सकता है कि जैसे-जैसे परियोजनाएँ और भी बड़ी होंगी, परीक्षण लेखन निषेधात्मक रूप से बोझिल हो सकता है। यह तर्क गलत होगा, जैसा कि इस बहुत ही प्रश्न में वर्णित सफल बहुत बड़ी परियोजनाओं के उदाहरणों से स्पष्ट है ("पायथन सफलतापूर्वक ... YouTube" के लिए उपयोग किया जाता है)।
बात यह है, परियोजनाओं का स्केलिंग वास्तव में सीधा नहीं है। बहुत बड़ी, लंबे समय तक रहने वाली परियोजनाएं अलग-अलग परीक्षण विकास प्रक्रिया को "बर्दाश्त" कर सकती हैं, जिसमें उत्पादन गुणवत्ता परीक्षण सूट, पेशेवर परीक्षण देव टीम और अन्य हेवीवेट सामान शामिल हैं।
Youtube परीक्षण सुइट्स या जावा कम्पैटिबिलिटी किट यकीन है कि द्विमूर्ति के ऐरे जैसे एक छोटे ट्यूटोरियल प्रोजेक्ट में परीक्षणों की तुलना में एक अलग जीवन जीते हैं ।