फ्रंटएंड के लिए परियोजना अपघटन

आप जो पहले से जानते हैं उसके बारे में बात करते हैं।

यह हैबे पर मेरा पहला लेख है और मैं लेखक नहीं हूँ। लेकिन फ्रंटेंड 2018 को देखते हुए: वर्ष के परिणाम , हाथ उदात्त में पहुंच गए और लिखना शुरू कर दिया।

किसी भी कठिन कार्य में सरल व्यक्ति होते हैं। अपघटन को सही ढंग से करने की क्षमता बहुत जरूरी है ।

मैं व्यक्तिगत अनुभव से अधिकांश परियोजनाओं के उदाहरण पर चर्चा का नेतृत्व करूंगा।

मुझे यकीन है कि आप कहेंगे, " लेकिन हमारे पास यह बिल्कुल भी नहीं है और प्रतिक्रिया तेज, तार्किक और पठनीय है। जेएस का उपयोग करने वाली शैलियों का निर्माण किसी तरह का ऐड-ऑन नहीं है, यह फैशनेबल है, लेकिन फ्रंट-एंड डेवलपर्स की आवश्यकता नहीं है, क्योंकि हमारे बैक-एंड प्रदाता Feofan ने php में एक उत्कृष्ट रूप बनाया है। “लेकिन फिर भी।

पद
G1। जीनियस जो अपवाद हो सकते हैं, एक विशेष शानदार मामला है।
म *। सोचा था

यह पढ़ा नहीं जा सकता

तो चलिए शुरू करते है!

एम 1। डबिंग कोड खराब है।

M2। आपको हमेशा 100 कदम आगे सोचना चाहिए।

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

जाहिर है, एक सामाजिक नेटवर्क शुरू करना, हम तुरंत कह सकते हैं कि वेब संस्करण के अलावा मोबाइल एप्लिकेशन, डेस्कटॉप एप्लिकेशन भी होंगे। यहाँ से ...

एम 3। सर्वर भाग केवल एक बार लिखा जाना चाहिए। (एम 1)

और जब से हमारे पास एक वेब संस्करण, मोबाइल, डेस्कटॉप है, तब ...

एम 4। सर्वर साइड डेटा से संबंधित है।

सर्वर साइड को यह तय नहीं करना चाहिए कि किस बटन को खींचना है और किस रंग का होना चाहिए।

एक पत्र टेम्पलेट या html फ़ाइल जो [कर सकता है] भरी हुई है जब एक पृष्ठ को खोज इंजन द्वारा अनुक्रमण के लिए लोड किया जाता है वह भी डेटा के साथ काम कर रहा है। काश, आपको html को वहाँ हेरफेर करना पड़े (अनुक्रमण आवश्यकताओं के कारण, उदाहरण के लिए), लेकिन यह एक और समस्या है।

वास्तव में, व्यक्ति फाइलों के प्रारंभिक सेट (html, js, css) और डेटा को स्थानांतरित कर सकता है। यानी और यहाँ बैक लेआउट में शामिल नहीं है।

यहां प्रोजेक्ट का पहला ब्रेकडाउन हुआ: सर्वर का हिस्सा टूट गया। मैं इस बात पर बहस नहीं करूंगा कि यह किस भाषा में लिखा गया है, कैसे वास्तुकला की व्यवस्था की गई है (मुझे कृपया एमवीसी याद है)। यह मेरा व्यवसाय नहीं है ...

M5। हर किसी को अपना काम खुद करना होगा।

पूर्ण स्टैक कुछ परियोजनाओं को कवर करते हैं, और यहां आप इस बिंदु के साथ बहस कर सकते हैं और कर सकते हैं, लेकिन (एम 2) का उल्लेख करते हुए यहां मेरी स्थिति बन गई है: एक वर्ष में परियोजना को फिर से लिखने की तुलना में आपके क्षेत्र में दो पेशेवरों का होना सस्ता है। बेशक, जीनियस (G1) हैं जो हर जगह रहते हैं, लेकिन ऐसी इकाइयाँ हैं, जिसका अर्थ है कि आप उन्हें "As It Be Be" तर्कों में नहीं ले सकते।

मैं इस पाई से डिजाइनर, यूज़ेबिलिटी और सह की एक शाखा भी निकालूंगा।

सही ढंग से समझें, एक सामान्य फ्रंट-एंड विक्रेता एक मील के पत्थर को स्वतंत्र रूप से तैनात कर सकता है, एक लाख एनालॉग और उसकी कल्पना पर ध्यान केंद्रित कर सकता है, लेकिन हम (एम 2) पर गंभीर परियोजनाओं के बारे में बात कर रहे हैं, इसलिए अपने आप को चापलूसी न करें :) (जी 1)

ठीक है, हमारे पास डेटा (एपीआई, सभी आवश्यक तरीके, आदि) हैं, हमारे पास लेआउट हैं - और चलो शुरू करते हैं।

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

M6। विकास एक से अधिक फ़ाइल में होना चाहिए

बताओ, जाहिर है? हाँ, जाहिर है!

M7। सामने को 2 भागों में विभाजित किया गया है: एक जो डेटा के साथ काम करता है, और एक जो उन्हें प्रदर्शित करता है।

हमारे पास यह या वह हिस्सा नहीं हो सकता है। उदाहरण के लिए: केवल डिस्प्ले (स्थिर पृष्ठ) या केवल डेटा (कंसोल में स्क्रिप्ट, आदि) होना।

यहाँ मैं अमूर्त और प्रस्तुत करने का सुझाव देता हूं: आप एक पिज़्ज़ेरिया व्यक्ति हैं। आप कॉल प्राप्त करते हैं, पनीर को खूबसूरती से बाहर निकालते हैं और इसे खरीदार के पास ले जाते हैं। तर्क बताता है कि आप विशेष रूप से प्रभावी नहीं हैं (एम 1)। लेकिन अगर 2 और लोग आपके साथ काम करेंगे, तो यह बहुत अधिक ठंडा होगा! एक कॉल प्राप्त करता है (डेटा के साथ काम करता है), दूसरा वापस लेता है (प्रस्तुति), तीसरे ने पनीर को खूबसूरती से बाहर कर दिया :) (प्रस्तुति का शैलीकरण)

पहले से ही मैंने 2012 से "सीईपी", "स्पष्ट रूप से" सुना, लेकिन चलो फिर से ...

M8। JS डेटा के साथ काम कर रहा है।

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

M9। HTML का प्रतिनिधित्व

ग्राहक को पिज्जा दिखाता है, और प्रतिक्रिया (पैसा, समीक्षा) भी स्वीकार करता है और उन्हें प्रशासक (जेएस) को सौंपता है।

M10। सीएसएस - प्रस्तुति स्टाइल

पनीर के दो स्लाइस के बीच का इंडेंट।

ध्यान दें कि फोन पर व्यवस्थापक यह नहीं कहता है कि पनीर को कैसे स्टैक किया जाए, और पिज्जा में फोन पर बात करने वाला कोई व्यक्ति नहीं है। Js का उपयोग करके शैलियों में हेरफेर करने का कोई प्रयास, या html का उपयोग करके js में हेरफेर करना शुरू में एक ऐड-इन है, यह शुरू में बुरा है। कक्षाओं और इवेंट हैंडलिंग का आविष्कार एक कारण के लिए किया गया था।

आप एक वर्ग डाल सकते हैं: पेपरोनी, सलामी, लेकिन यह तय करने की आपकी क्षमता में नहीं है कि पेपरोनी पनीर कैसे रखा जाए।

आप नीचे बांध सकते हैं: यदि आपको लात मारी गई थी, तो भुगतान नहीं किया था, व्यवस्थापक को बताएं। लेकिन प्रशासक को पिज्जा में न हिलाएं। वह अकेला है, और कई पिज्जा हैं! यदि आपके पास ऑपरेटर के रूप में कई पिज्जा हैं, तो एम 1।

और इसलिए, जिसके लिए js, css, html जिम्मेदार हैं - हमने इसे समझ लिया।

अब आप प्रश्नों की पूरी शाखाओं से पूछ सकते हैं: पिज्जा कैसे पकाने के लिए, इसे कैसे तेजी से और अधिक सुविधाजनक तरीके से वितरित करें, और फोन पर ग्राहकों से कैसे बात करें।

मैं किसी भी तरह अब फैशनेबल शब्द " घटक " को परिभाषित करना चाहता हूं। वास्तव में, यहां तक ​​कि एक नियमित बटन पहले से ही एक "घटक" है, लेकिन मैं स्पष्ट उदाहरणों के साथ इसे फिर से परिभाषित करूंगा। एक बटन एक बटन है, और एक घटक है:

1. पोस्ट पूर्वावलोकन
2. टीका
3. फ़ाइल पूर्वावलोकन
4. हाब पर मतदान
5. ब्लॉक "रिक्तियों"
6. पोस्ट का एचटीएमएल टेक्स्ट, समीक्षाएं, वेबिनार
आदि

M11। एक घटक को हर जगह समान दिखना चाहिए।

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

संशोधन - यदि आवश्यक हो, तो मजबूर परिवर्तन। सीएसएस का उपयोग करके बनाया गया।

या यह एक और घटक है

(उदाहरण के लिए, दाएं कॉलम में पोस्ट पूर्वावलोकन पृष्ठ के निचले भाग में पोस्ट पूर्वावलोकन से भिन्न हो सकता है)।

M12। घटक में [html], [js], [css] शामिल हैं।

प्रत्येक भाग वैकल्पिक है।

M13। एक ही घटक के उदाहरणों की संख्या के बावजूद, इसकी शैलियों को केवल एक बार पंजीकृत किया जाना चाहिए

उदाहरण के लिए, दाईं ओर पोस्ट का पूर्वावलोकन, नीचे पोस्ट का पूर्वावलोकन, अधिसूचना में पोस्ट का पूर्वावलोकन, और शैलियों केवल एक बार पंजीकृत हैं।

M14। केवल आधार को js घटक में पंजीकृत होना चाहिए

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

M15। एक घटक में घटक शामिल हो सकते हैं

उदाहरण के लिए, पदों की एक सूची।

M16। शैलियाँ एक अलग फ़ाइल में निकाली गईं

इन फ़ाइलों को कैश किया गया है, इसके अलावा, उन्हें इनलाइन लिखने का कोई प्रलोभन नहीं होगा, जिसका अर्थ है डुप्लिकेट करना।

M17। घटक शैलियों को मूल कक्षाओं के माध्यम से और केवल बाँधना चाहिए

किसी भी साइट का पृष्ठ विभिन्न आकारों के बहुत सारे बक्सों की तरह होता है, जो एक दूसरे में जकड़े घोंसले के शिकार गुड़िया की तरह होते हैं।

एक बॉक्स एक घटक है।

आपके पास बॉक्स और आइटम के साथ एक बॉक्स है। आपको यह सोचने की ज़रूरत नहीं है कि नेस्टेड बॉक्स के इनसाइड का वर्णन कैसे किया जाए। केवल यह बताएं।

यहां उन्होंने साइकिल का एक गुच्छा आविष्कार किया, लेकिन सज्जनों, नामों के साथ कोई समस्या नहीं होगी, जैसे ही आप अपने लिए घटकों के सेट का निर्धारण करते हैं। यदि आप VKontakte खोलते हैं और वहां घटकों की संख्या की गणना करते हैं, तो ठीक है, आप 30 टुकड़े गिनते हैं। (फेसबुक पर मत गिनो, केवल दर्द है)।

30 वर्ग के नाम के साथ नहीं आ सकते हैं? और ठीक है, वहाँ के साथ आने के लिए कुछ भी नहीं है:

M18। अन्य लोग आपके कोड को पढ़ेंगे।

तो प्राकृतिक नाम सबसे अच्छा नाम है

उदाहरण के लिए

1. पद-सूची
2. टिप्पणियाँ-सूची
3. समाचार-सूची
4. पोस्ट-पूर्वावलोकन
5. टिप्पणी-पूर्वावलोकन
6. समाचार-पूर्वावलोकन
7. पोस्ट-डिटेल
8. टिप्पणी-विस्तार
9. समाचार-विस्तार

अविश्वसनीय रूप से मुश्किल, हुह? और मुख्य बात समझ से बाहर है और बनाए रखना मुश्किल है

और "अन्य लोगों को पढ़ें" के बारे में भी सदस्यता समाप्त करें:

M19। Html, js, css को अलग से संग्रहित किया जाना चाहिए!

यदि आपको उन्हें एक साथ संयोजित करने की आवश्यकता है, तो उन्हें एक फ़ाइल में लिखने की तुलना में एक अलग समाधान के साथ आओ। रिएक्ट पठनीयता के मामले में सबसे घृणित है जो मैंने देखा है!

"बक्से" पृष्ठ को विभाजित किया गया था, फ़ाइलों को कैसे संग्रहीत किया जाए - चर्चा की गई। और क्या?

M20। लगभग कोई विशेष मामले नहीं हैं

और अगर ऐसा होता है, तो कल आपके प्रबंधक काम पर आएंगे और कहेंगे कि "ग्राहक के अनुरोध पर कार्यान्वयन को संशोधित करना आवश्यक है।" यथासंभव मोटे तौर पर कार्यों को हल करें।

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

M21। शैली लेखन के लिए अपघटन की आवश्यकता होती है

दुनिया ने हमें सिर्फ शानदार LESS, SASS नहीं दिया है।

आपकी परियोजना में फोंट, रंग, छाया का एक निश्चित सेट है, लगभग सभी गंभीर परियोजनाओं में रंग योजनाएं हैं, इसलिए शैलियों को लिखते समय, यह सब पैरामीटर है। और यहाँ निम्नलिखित महत्वपूर्ण है

M22। यदि आप फ़ॉन्ट रंग (आदि) को बदलना चाहते हैं, तो आपको केवल एक ही स्थान पर संपादन करना चाहिए

अंत में, मैं एक महत्वपूर्ण समस्या का उल्लेख करना चाहूंगा।

M23। समस्या का सही निरूपण सही समाधान की ओर ले जाता है।

शायद तब कोई css-in-js, facebook और ऐसा कुछ नहीं होगा जिसे नहीं कहा जाना चाहिए।

आपका दिन शुभ हो!