सख्त या व्यावहारिक होने के लिए?

Question

मैं महसूस कर रहा हूं कि विकासशील सॉफ्टवेयर (दूसरों के बीच) अपने आप से लगातार सवाल पूछने की एक प्रक्रिया है। कोड की गुणवत्ता, चिंताओं को अलग करने, निर्भरता कम करने से संबंधित प्रश्न ...

लेकिन मुख्य सवाल यह है: मानसिक अस्पताल में समाप्त किए बिना आप कितनी दूर जा सकते हैं?

मैं नई नौकरी के लिए आवेदन कर रहा हूं। कल मैं एक संभावित भविष्य के नियोक्ता के साथ था जो मेरी प्रोग्रामिंग कैपैबिलिटी का परीक्षण करना चाहता था। अभ्यास में से एक था: समझाएं कि यह कोड क्या करता है। मैं आवेदन के कुछ कोड (vb.net में winforms) के माध्यम से चला गया कि वे विकसित होते हैं (यह एक अस्पताल के लिए एक प्रशासनिक अनुप्रयोग है)। इससे मुझे वास्तव में यह देखने का मौका मिला कि वे चीजों को कैसे देखते हैं और यह निराशाजनक था।

कुछ उदाहरण:

• मैंने कहीं देखा: कॉल [सबरूटीन का नाम यहाँ डालें] -> मैं मारा गया था: VB6 से ऐसा कुछ नहीं है?
• उनके पास ado.net का उपयोग करके एक अलग डटलेयर है, लेकिन एक विधि मुझे कॉलिंग लेयर में एक डेटासेट की जांच करनी थी। इतना अलग डैटलेयर या नहीं, एप्लिकेशन को ado.net से जोड़ा जाता है (जो कभी भी किसी अन्य डेटा एक्सेस दृष्टिकोण पर स्विच नहीं होने पर भी समस्या हो सकती है)।
• यह डेटासेट के रूप में पढ़ा जाता है, इसलिए यह अभी भी डेटा-केंद्रित दृष्टिकोण है (बेशक, कोई यह तर्क दे सकता है कि आप "रोगी" या "LabAnalysisRequest" जैसी कक्षाओं में कितना तर्क / व्यवहार रख सकते हैं।
• मैं यह भी मानता हूं कि स्ट्रिंग कॉन्क्लेनेशन द्वारा एक sql क्वेरी के निर्माण को देखा है।
• वे संग्रहीत प्रक्रियाओं का उपयोग करते हैं (जो, मेरे लिए, इसका मतलब है: तर्क का बिखरना)
• विचारों / नियंत्रकों का कोई उल्लेख नहीं: यह सभी प्रकार से संचालित है
• सबसे बदसूरत चीज जो मैंने देखी:

      यदि TestEnvironment.IsTesting तो
         someVar = [कुछ हार्ड कोडित मूल्य]
      अन्य
         someVar = [कुछ गतिशील रूप से प्राप्त मूल्य]
      अगर अंत
      [शेष समारोह यहाँ]
  

स्कूल में मैंने जो कुछ सीखा, वह सब इतना अलग है: (दृढ़ता अज्ञेयवादी) डोमेन परत, दृढ़ता परत, प्रस्तुति परत, इकाई परीक्षण, ...

इसलिए मैं अपने प्रश्न को फिर से बताता हूं: एक व्यक्ति को कितना मौलिक या हठधर्मी होना चाहिए? एक प्रोग्रामर को अपने सिद्धांतों पर या केवल उस कोड को लिखना चाहिए जो काम करता है?

Comments

संभवतः prorammers.stackexchange पर संबंधित है क्योंकि यह सॉफ़्टवेयर विकास की सामान्य चर्चा और कोड के ब्लॉक के साथ विशिष्ट मुद्दों के साथ नहीं है।

— taylonr

दुनिया के अकादमिक पक्ष में कोई समय सीमा नहीं है। दुनिया के व्यापार पक्ष में, लगभग हमेशा समय सीमा होती है। और लगभग हमेशा वे बहुत जल्दी होते हैं।

— कार्लोस कैंपडरो

मैं कार्लोस से सहमत हूं। जब मैंने अपने वर्तमान टमटम पर काम करना शुरू किया, तो कोड के प्रति मेरा दृष्टिकोण था, "मुझे विश्वास नहीं हो रहा है कि यह कोड बहुत ही भयानक है!" कुछ हफ्तों के बाद, रवैया बदल गया, "मुझे विश्वास नहीं हो रहा है कि यह कोड केवल इस तरह का काम है।" यह पुरानी कहावत है: "गुणवत्ता, गति, लागत, दो उठाओ।" अच्छा कोड उत्पन्न करना या तो धीमा है, या महंगा है, और कभी-कभी न तो एक विकल्प है।

— शैतानिकपुपी

मेरा औपचारिक प्रशिक्षण इतना सीमित है कि मेरी हठधर्मिता / बुनियादी बातें बहुत कमजोर हैं। अगर मैं व्यावहारिक नहीं होता, तो मैं प्रलेखन या विज़िटिंग फ़ोरम के माध्यम से उम्र (अब मैं जितना भी करता हूं उससे अधिक) खोदता हूँ। दूसरा पहलू यह है कि जैसे ही मैं एक प्रोग्रामर के रूप में परिपक्व होता हूं मैं सीख रहा हूं कि कैसे प्रोग्राम नहीं किया जाता है। इसका मतलब है कि मेरी बुनियादी बातों या हठधर्मिता बढ़ रही है। मैं एक छोटी सी कंपनी के लिए काम करता हूं, मैं वास्तव में सबसे अनुभवी कोडर हूं और जब कोई प्रोजेक्ट होता है जो एक्स डेज में किया जाना है, तो मेरे पास उन मूलभूत कोनों को काटने के अलावा कोई विकल्प नहीं है। जब आप इसे फिर से देखते हैं और "WT ??" जाते हैं, तो अच्छा इनलाइन प्रलेखन अनिवार्य है

— टेकब्रैट

यदि आपने जो सबसे बदसूरत चीज देखी है, If TestEnvironment.IsTesting thenतो वह कोड बहुत अच्छे आकार में है।

Answer 1

मुझे पता है कि सीधे आपके सवाल का जवाब नहीं है, लेकिन मुझे अभी भी लगता है कि यह एक टिप्पणी से अधिक लायक है:

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

हां, उद्योग में, दस साल पुराने विरासत कोड आधार के साथ, जो विभिन्न पृष्ठभूमि, कौशल और जुनून के साथ तीन दर्जन डेवलपर्स द्वारा समय के साथ हैक किया गया है, तंग समय सीमा, संसाधनों की कमी और वित्तीय बाधाओं से प्रेरित है, कोड कभी नहीं होगा जिस तरह से आपको (सीखना चाहिए) उसे देखना चाहिए। आपको कुछ रियायतें देनी होंगी। लेकिन कितने, और जहां आप रेखा खींचते हैं, वह पूरी तरह आप पर निर्भर है।
बेशक, आपके द्वारा की जाने वाली कम रियायतों को खोजने के लिए नौकरियां कठिन हैं। लेकिन वे अधिक सुखद हो सकते हैं।

FWIW, मेरे पास अब तक (> उद्योग में 10 साल) कई डेवलपर्स के साथ एक बड़ी कंपनी में कभी काम नहीं किया (~ 30 डेवलपर्स सबसे अधिक था, एक दर्जन आदर्श), क्योंकि यह बहुत अधिक संभावना है कि आप एक छोटे में कुछ बदलते हैं कंपनी। जब तक मैं बच्चों को भूखा न रखने के लिए पर्याप्त पैसा कमाता हूं, तब तक मैं एक बड़ी कंपनी में एक छोटी सी कोजेल नहीं बनना चाहता, जहां मुझे बस इतना करना है कि बाकी गियर के साथ सिंक करना है।
मैंने नौकरी की पेशकशों को ठुकरा दिया था क्योंकि वे चाहते थे कि वे मुझे पास करें। मैं एक C ++ डेवलपर हूं, और वहाँ कई C ++ परीक्षण हैं जो इतने बुरे हैं कि यह आपके toenails को घृणित बनाता है, और मैं अपना समय पवनचक्की से लड़ने में नहीं बिताना चाहता, क्योंकि वे मोरों को काम पर रखते हैं जो स्वच्छ कोड नहीं लिख सकते हैं।
मैंने कुछ महीनों के बाद नौकरी भी छोड़ दी है क्योंकि उनके प्रोग्रामिंग दर्शन (लघु अवधि के लक्ष्य, अगले साल कभी भी बुरा नहीं) मेरी क्षमताओं (दीर्घकालिक कोड स्थिरता) के साथ फिट नहीं थे, उनके बावजूद साक्षात्कार में अलग-अलग कहने के बावजूद।

Comments

C ++ परीक्षणों में क्या गलत है?

— चावल का आटा कुकीज़

@ राइस: उनके सवालों में कीड़े हैं।

— sbi

मुझे लगता है कि यदि आप एक कंपनी में चलते हैं जो स्कूल में सीखी गई चीजों पर ध्यान देती है, तो आप एक कंपनी में काम करने से बहुत कुछ सीखने जा रहे हैं जहाँ आपको उन्हें बुनियादी बातों के बारे में शिक्षित करना होगा।

— गुस्ताव बर्तराम

मेरी टिप्पणी मूर्त हो सकती है लेकिन आपके उत्तर ने मुझे यह जानकारी दी कि किसी को "बिग कंपनी" के जाल में नहीं पड़ना चाहिए और ऊपर बताए गए कारणों के लिए कुछ महीनों में एक बड़ी कंपनी को छोड़ना ठीक क्यों है। उसके लिए धन्यवाद

— तरुण

Answer 2

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

यहां उन मुद्दों की एक सूची दी गई है जो मैंने संकलित किए हैं जो यह निर्धारित करेंगे कि आप किसी कंपनी की कोडिंग जीवन शैली में कितनी अच्छी तरह फिट हैं।

1. वे रिफ्लेक्टर के लिए अलग-अलग समय निर्धारित करने के लिए कितना महत्व देते हैं और अपने कोड-बेस को अद्यतित करते हैं। वे कैसे देखते हैं कि कोड-आधार को अपडेट करना एक प्रमुख निर्धारण कारक होगा कि आप कितनी अच्छी तरह से फिट होते हैं।
2. वे कितनी बार घर में कोडिंग के बजाय 3 पार्टी खरीदते हैं।
3. वे ओपन-सोर्स सॉफ्टवेयर के बारे में क्या सोचते हैं। क्या वे महसूस करते हैं कि उनके पास कोड बदलने में लचीलापन है। क्या वे इसे उसी तरह से देखते हैं जैसे कि 3 पार्टी खरीदना।
4. आप एक निश्चित अमूर्त परत पर काम करेंगे। क्या आप जिस टीम के साथ इंटरफेस करते हैं, वह आपके लिए अपना इंटरफेस निर्धारित करती है? निर्णय लेने में किस परत / टीम / इंटरफ़ेस के पक्ष में अधिक शक्ति है।
5. निर्णय लेने के दौरान पर्यवेक्षक प्रोग्रामर को कितना सुनते हैं। जब एक प्रोग्रामर लाल-झंडा फेंकता है, तो क्या पर्यवेक्षी रुक जाता है और अपने फैसले की समीक्षा करता है।
6. क्या आप प्रबंधन को अनुभवी प्रोग्रामर मानते हैं? वे अपने अनुभव को कैसे देखते हैं? क्या उनका अनुभव वैध है? क्या वे पुराने अनुभव को निर्णय लेने को प्रभावित कर रहे हैं?
7. कोड-आधार कितना चिपचिपा है?
8. वे अपने प्रोग्रामिंग टूल (IDE, आदि) को कितनी बार अपडेट करते हैं

इन सवालों के जवाब बेहतर फिट हैं कि आप उनकी प्रोग्रामिंग जीवनशैली को कैसे महत्व देंगे, यह देखने की तुलना में कि क्या वे आपकी हठधर्मिता से मेल खाते हैं।

डोगमा अनिवार्य रूप से टूट जाएगा (हमारे पास एक्स को अपडेट करने का समय नहीं है)। हालाँकि, प्राथमिकताएँ यह परिभाषित करेंगी कि आप उनकी शैली और निर्णय लेने से कितना टकराते हैं।

Answer 3

मुझे लगता है कि आपको इसे पूरे हिस्से के रूप में तौलना होगा। मुझे याद है कि मेरी पहली नौकरी एक समूह में एक स्थिति थी जो मुझे बताती थी कि वे ऑब्जेक्ट-ओरिएंटेड सी ++ कर रहे थे - जो कि मैंने स्कूल में कई साल किया था।

उनका स्व-मूल्यांकन गलत था - वे कुछ हद तक चंकी सी कर रहे थे। यह अभी भी बहुत कार्यात्मक रूप से प्रकृति में डिज़ाइन किया गया था और मुझे खुद को प्रिंटफ एंड गेटफ और अन्य सी तंत्रों को सिखाने के लिए खुद को सी बुक प्राप्त करना था जो मैंने कभी नहीं सीखा था। यह तथ्य कि टीम पर किसी को भी एहसास नहीं हुआ कि उनके कोड की तरह C कैसे इंगित करता है कि यह "C ++ डिज़ाइन" कैसे गिर गया। उस समय मेरा लक्ष्य OO विकास करना था, इसलिए यह एक तरह से ऑफ-पुट था।

लेकिन मुझे खुशी है, अंत में, कि मैं टीम के साथ फंस गया। वे बहुत ही चतुर लोगों के एक गतिशील समूह थे और मैंने अपने पैरों को बहुत मुश्किलों से गीला कर दिया, मुझे पूरे जीवनचक्र में काम करना पड़ा और समस्या डोमेन (पीकेआई) के बारे में मैंने जो कुछ सीखा उससे मेरे करियर में कभी भी उछाल आया है। कार्यात्मक स्थान में टीम जो काम कर रही थी वह अद्भुत था और मुझे अभी भी उस उत्पाद और उस कार्य अनुभव के बारे में बहुत ही शौक है। बेहतर अभी तक - मैं आज भी उन लोगों में से कुछ के साथ काम करता हूं (बाद में कई कंपनियां), वे अभी भी एक प्रेरणा हैं, और हम अभी भी अच्छा काम कर रहे हैं।

मुझे नहीं लगता कि एक कोडिंग भाषा की सर्वोत्तम प्रथाओं का सही कार्यान्वयन एक अच्छा कार्य अनुभव या एक अच्छी टीम का मेक या ब्रेक है - जो काम एक कैरियर को ईंधन देता है, वह इससे कहीं अधिक है, और यदि उत्पाद सभ्य है गुणवत्ता, टीम के पास काम करने की अच्छी स्थिति (जोएल टेस्ट की तरह) है और टीम ऐसे लोगों से भरी है जो स्मार्ट हैं और चीजों को प्राप्त करते हैं, फिर कार्यान्वयन की पूर्णता माध्यमिक है। अच्छे काम, अच्छे लोग, अच्छे काम करने की स्थिति जैसे कारकों को दूर करें - और यह चारों ओर चिपके रहने के लायक नहीं है - कोड को अजीब रूप से एक साथ रखा जाए या नहीं।

Comments

मुझे यह देखने के लिए नीचे स्क्रॉल करना पड़ा कि मैंने यह नहीं लिखा है!

Answer 4

मौलिक या हठधर्मी कैसे होना चाहिए? एक प्रोग्रामर को अपने सिद्धांतों पर या केवल उस कोड को लिखना चाहिए जो काम करता है?

यहां याद रखने वाली सबसे महत्वपूर्ण बात यह है कि आपका उद्देश्य क्या है ?

ज्यादातर कंपनियों में, जीवन में आपका उद्देश्य सही कोड लिखना नहीं है। आपका उद्देश्य उपयोगकर्ता के लिए मूल्य वितरित करना है। अच्छा कोड लिखना आमतौर पर एक अच्छा उत्पाद देने का सबसे अच्छा तरीका है जिसे बनाए रखना, परेशानी को शूट करना और विकसित करना भी आसान है।

अच्छा कोड एक उपकरण है जिसे आपको लागू करना चाहिए जहां यह आपको अच्छा आरओआई देता है।

कुछ उदाहरण:

1. मैं अपने एपीआई, विशेष रूप से अपने व्यवसाय के टीयर एपीआई को डिजाइन करने और कोडिंग करने में बहुत समय बिताऊंगा। बहुत सारे अन्य प्रोग्रामर उनका उपयोग करने जा रहे हैं और यह ठीक से डिज़ाइन किए जाने पर बहुत समय और समस्याओं को बचाएगा
2. मैं अपनी प्रस्तुति परत में नियमों को थोड़ा आराम करूंगा। वहाँ मैं और अधिक सुविधाओं को जोड़ने के पक्ष में कोड "पूर्णता" का त्याग करने के लिए इच्छुक हूं

लब्बोलुआब यह है कि आपके पास सिद्धांत होने चाहिए, लेकिन आपको उन सिद्धांतों को तोड़ने के लिए पर्याप्त लचीला होना चाहिए जब वे मूल्य से अधिक नुकसान लाते हैं।

Answer 5

मैंने कुछ वर्षों के लिए ई-कॉमर्स रिटेलर के लिए काम किया। जब मैंने वहां शुरू किया, तो उनके आंतरिक अनुप्रयोगों के लिए कोड सभी में एमएस एक्सेस के लिए वीबी में लिखा गया था, और यह कम से कम कहने के लिए भयानक था। मेरे पास 3 डेवलपर्स की एक टीम थी, और अगले कुछ वर्षों में हमने इसे उचित VB.Net अनुप्रयोगों के साथ बदल दिया।

लेकिन चूंकि मेरा काम पर रखने का बजट बेहद सीमित था, इसलिए मैं केवल जूनियर प्रोग्रामर ही खरीद सकता था। और, बेशक, उन्होंने जो कोड तैयार किया था, वह सब बहुत अच्छा नहीं था। लेकिन इसने काम किया और कंपनी ने इन एप्लिकेशन का इस्तेमाल हर दिन पैसा कमाने के लिए किया।

और फिर मैंने अपने लोगों के साथ काम करना शुरू कर दिया। OOD में, डेटाबेस डिजाइन में, MVC और C # में थोड़ा सा प्रशिक्षण। और वर्षों में, चीजें बेहतर हुईं। जब मैंने 4 साल बाद छोड़ दिया, तब भी कोडबेस महान नहीं था, लेकिन जब मैंने शुरू किया था तो यह 100 गुना बेहतर था।

आपके द्वारा वर्णित एक स्थिति अक्सर उपलब्ध संसाधनों के साथ करने का परिणाम है। हम एक आदर्श दुनिया में नहीं रहते हैं। एक ही समय में, यह वास्तव में एक अंतर बनाने का एक शानदार अवसर है।

BTW: इनमें से कुछ एप्लिकेशन अभी भी उपयोग में हैं, लगभग 3 साल पहले से अपरिवर्तित हैं, और वे अभी भी पैसे कमाते हैं।

Comments

ब्लैक बॉक्स के बारे में अच्छी बात यह है कि लोग यह नहीं देख सकते कि यह अंदर कितना काला है।

Answer 6

मुझे लगता है कि आपके सिद्धांतों से चिपके रहना बहुत महत्वपूर्ण है। आपको हमेशा दिए गए अवरोधों के भीतर सर्वोत्तम कोड का उत्पादन करने का प्रयास करना चाहिए। हालाँकि, यदि आप जोड़ते हैं "कभी भी खराब कोड को पढ़ना या बदलना नहीं चाहिए" तो सिद्धांतों की अपनी सूची में, आपको काम खोजने में बहुत कठिनाई होने वाली है। याद रखें कि 50% प्रोग्रामर अपनी कक्षा के निचले भाग में स्नातक थे। यहां तक ​​कि एक आदमी टीम पर, "आज आप" एक समस्या को हल करने के लिए "पिछले महीने की तुलना में" बेहतर है। गैर-आदर्श कोड के साथ काम करने में सक्षम होना नौकरी का सिर्फ एक हिस्सा है।

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

Answer 7

99% प्रतिशत मामलों में, आपको «हठधर्मिता» से चिपकना चाहिए क्योंकि आप इसे कहते हैं। हठधर्मिता अनुभवी व्यक्तियों द्वारा अभ्यास के वर्षों में की जाती है, और कुछ बिंदु पर व्यावहारिक प्रतीत होता है जो अक्सर नहीं होता है। यह आमतौर पर इस तथ्य से अधिक प्रासंगिक है कि आप उस समस्या को ठीक से संभालने के लिए पर्याप्त नहीं हैं।

हालाँकि, आँख बंद करके हठधर्मिता का पालन न करें। याद रखें कि कौन से निष्कर्ष लोगों को उस हठधर्मिता का अनुसरण करने के लिए प्रेरित करते हैं। क्योंकि आपको उन मामलों का एक छोटा हिस्सा मिलेगा जहां इसका पालन नहीं किया जाना चाहिए। वैसे भी, वे मामले बहुत दुर्लभ होंगे और आपको ऐसा निर्णय लेने से पहले हमेशा कुछ अन्य अनुभवी प्रोग्रामर के साथ चर्चा करनी चाहिए।

Comments

मुझे लगता है कि आप "सर्वोत्तम प्रथाओं" के साथ "हठधर्मिता" को भ्रमित कर रहे हैं।

— टॉबी

यही कारण है कि मैंने लिखा है "हठधर्मिता" और न केवल हठधर्मिता।

— deadalnix

वाह, मेरे कीबोर्ड पर वे दो चाबियां भी नहीं हैं। कोई आश्चर्य नहीं कि मैं उनका उपयोग नहीं करता।

Answer 8

जब यह मायने रखता है तो सख्त रहें। ब्रेस स्टाइल (या अन्य कोडिंग कन्वेंशन)? इससे कोई फर्क नहीं पड़ता। दुकान का उपयोग करता है एक का उपयोग करें। बिना किसी अच्छे कारण के इनकैप्सुलेशन (या अन्य मौलिक प्रोग्रामिंग सिद्धांतों) को तोड़ना? इतना तुच्छ नहीं।

स्टैक एक्सचेंज लेआउट के लिए तालिकाओं का उपयोग करता है (जैसा कि कई अन्य प्रमुख वेबसाइटें जो पैसा बना रही हैं )। क्या यह धुआं शुद्धतावादियों के कानों से निकलता है? ज़रूर करता है। लेकिन व्यावहारिकता हर बार पवित्रता पर विजय पाती है। शिपिंग उत्पाद हर बार इसे सही होने पर जीतता है।

एक ऐतिहासिक दृष्टिकोण से संपूर्ण डोमेन परत, दृढ़ता परत, प्रस्तुति परत, इकाई परीक्षण चीज अभी भी अपेक्षाकृत नई है। वहाँ सॉफ्टवेयर के नाव लोड हो रहे हैं जो अभी भी एक क्लाइंट / सर्वर मॉडल का उपयोग करते हैं, और इसे नवीनतम स्थापत्य शैली में नहीं बदला जाएगा क्योंकि यह "बेहतर" है।