महँगा आर्किटेक्चर फ़ैसला आमतौर पर वह पुनर्लेखन है जिसकी किसी को ज़रूरत नहीं थी। जो दुकान WordPress पर पहले से ऑर्डर लेती है, होमपेज नए फ्रेमवर्क पर जाने से सुरक्षित नहीं होती। जो उत्पाद ज़्यादातर API और बोर्ड है, उसे दुकान वाली थीम में ठूँसने से साफ़ नहीं होता। मैं वह स्टैक चुनता हूँ जो व्यवहार पहले से थामे है, और किनारा इतना तेज़ रखता हूँ कि एक व्यक्ति अभी भी पार देख सके।
जहाँ कारोबार पहले से रहता है, वहीं रहें
अगर आय WooCommerce चेकआउट है, काम उसी चेकआउट के पास है: थीम, वे प्लगइन जिन पर मैं सच में भरोसा करता हूँ, सर्वर, मेल, बैकअप। कैटलॉग को अलग फ्रंटएंड में ले जाना ताकि स्टैक नया लगे, एक प्रोजेक्ट है। वह अपने आप प्रोमो कोड या छूटे webhook की मरम्मत नहीं। इस हफ्ते निकलने वाले सादे PHP बदलाव के लिए मेरे पास उस माइग्रेशन से ज़्यादा धीरज है जिसका लाभ रूप का है।
Laravel अपनी जगह तब कमाता है जब चीज़ एक एप्लिकेशन हो, अपने नियम, अपनी कतारें, अपना एडमिन, और उसे पन्नों में मोड़ना न पड़े। खर्च की सीमा और इंसानी मंज़ूरी वाला कंटेंट पाइपलाइन उसी तरह का एप्लिकेशन है। मार्केटिंग साइट नहीं।
| सिस्टम पहले से ही है | मैं हाथ बढ़ाता हूँ | हाथ नहीं बढ़ाता |
|---|---|---|
| ऑर्डर लेती दुकान | WordPress, WooCommerce और उनके आसपास का सर्वर | दोबारा लिखना ताकि होम दूसरा फ्रेमवर्क हो |
| कतारों और एडमिन वाला ऐप | Laravel, या Nest अगर उस उत्पाद का बाकी हिस्सा पहले से TypeScript है | प्लगइनों का ढेर जो उत्पाद बनने का नाटक करता है |
| बोर्ड और API का साझा टाइप्ड इंटरफ़ेस | TypeScript, शुरू से अंत | सिर्फ़ बटनों के लिए दूसरी भाषा |
| पुनर्प्राप्ति, अंक, दस्तावेज़ों पर एक छोटी सेवा | Python | दुकान का PHP रनटाइम, वफ़ादारी से |
एक उत्पाद में एक भाषा, पूरे करियर में नहीं
एक उत्पाद के अंदर मैं एक मुख्य भाषा चाहता हूँ, ताकि API का बदलाव और स्क्रीन का बदलाव एक ही समीक्षा हों। अपने काम में मैं यह नहीं दिखाता कि सब एक भाषा है। PHP, TypeScript और Python यहाँ जानबूझकर प्रोडक्शन में हैं। गलती उन्हें एक अनुरोध पथ में मिलाना है क्योंकि हर परत किसी की पसंद थी।
PostgreSQL जब डेटा के रिश्ते हों और मैं चाहूँ कि डेटाबेस उन्हें लागू करे। MySQL जब दुकान पहले से वही चला रही हो और उसे हिलाना काम न हो। Redis कतार या कैश के लिए, सच के दूसरे स्रोत के रूप में नहीं। Docker और उबाऊ nginx जब डिप्लॉय बताना हो, जब ऑर्केस्ट्रेटर सीखने का मन हो तब नहीं।
दोबारा लिखने को वह घटना बतानी होगी जिसे वह हटाता है
नई फ्रेमवर्क को प्लान में आने से पहले मैं एक वाक्य माँगता हूँ। कौन सी घटना, जिसे वर्तमान स्टैक बंद नहीं कर सकता, इस स्थानांतरण से जाती है? अगर वाक्य स्वाद, भर्ती, या सम्मेलन की बात पर है, स्थानांतरण रुकता है। अगर वाक्य है “चेकआउट प्लगइन यह कीमत नियम नहीं बता सकता, और मैंने दो बार उसके आसपास पैच किया”, वह असली वाक्य है, और तब भी नई दुकान से पहले छोटी पैच देखता हूँ। छोटी पैच आमतौर पर वहीं होती है।
वही परीक्षा उस सेवा पर है जिसे दुकान के पास जोड़ने का मन होता है। कतार तब जायज़ है जब अनुरोध को दोबारा कोशिश से बचना हो। अलग फ्रंटएंड तब जायज़ है जब एक डेवलपर नहीं, दो क्लाइंट को वही API चाहिए। नई डेटाबेस विश्वसनीयता की समस्या वाले उसी तिमाही में लगभग कभी जायज़ नहीं। जो डेटा आपके पास पहले से है, वही सिस्टम है। उसे हिलाना अपना प्रोजेक्ट है, अपनी इन्वेंटरी के साथ, और वह प्रोमो कोड नहीं ठीक करता।
मैं एक दुकान और बगल की सेवा थाम सकता हूँ क्योंकि वे एक लिखे किनारे पर मिलती हैं: webhook, कतार, तालिका। मैं वह सिस्टम नहीं थाम सकता जिसके किनारे “उस हिस्से को बनाने वाले से पूछो” हों। वह व्यक्ति मुझे होना है, लॉन्च के बाद भी। नया औज़ार किराया दे। अगर वह हाथ बदलना या घटनाओं की एक श्रेणी नहीं हटाता, वह स्वाद है, और स्वाद रुक सकता है।
वह स्टैक चुनें जो अगली घटना को एक सिर में रखे। नयापन उसे हराना चाहिए, उलटा नहीं।
