एका आठवड्यात कोडच्या 100,000 ओळी कसे वाचावे आणि दुरुस्त करावे

सुरुवातीला मोठा आणि जुना प्रकल्प समजून घेणे नेहमीच कठीण असते. आर्किटेक्चर हे वास्तुविशारद मूल्यांकनाच्या क्रियाकलापांपैकी एक आहे. सहसा तुम्हाला मोठ्या, जुन्या प्रकल्पांसह काम करावे लागते आणि परिणाम एका आठवड्यात वितरित करणे आवश्यक आहे.

एका आठवड्यात 100k किंवा त्याहून अधिक ओळींच्या कोडच्या प्रकल्पाचे मूल्यमापन कसे करावे, तरीही क्लायंटला खरोखर उपयुक्त असे परिणाम प्रदान करताना.

बहुतेक वास्तुविशारद आणि तांत्रिक लीड्सना समान प्रकल्प मूल्यांकनांचा सामना करावा लागला आहे. हे अर्ध-औपचारिक प्रक्रियेसारखे किंवा आमच्या कंपनीमध्ये केल्याप्रमाणे एक स्वतंत्र सेवा म्हणून दिसू शकते, तुमच्यापैकी बहुतेकांनी याला सामोरे गेले आहे.

तुमच्या नॉन-रशियन भाषिक मित्रांसाठी इंग्रजीतील मूळ येथे आहे: एका आठवड्यात आर्किटेक्चर मूल्यांकन.

आमच्या कंपनीचा दृष्टीकोन

आमच्या कंपनीमध्ये ते कसे कार्य करते आणि मी तत्सम परिस्थितींमध्ये कसे कार्य करते ते मी तुम्हाला सांगेन, परंतु तुम्ही तुमच्या प्रकल्प आणि कंपनीच्या गरजेनुसार हा दृष्टिकोन सहजपणे बदलू शकता.

आर्किटेक्चरचे दोन प्रकार आहेत.

आतील - आम्ही सहसा ते कंपनीमधील प्रकल्पांसाठी करतो. कोणताही प्रकल्प अनेक कारणांसाठी आर्किटेक्चर मूल्यांकनाची विनंती करू शकतो:

1. संघाला वाटते की त्यांचा प्रकल्प परिपूर्ण आहे आणि हे संशयास्पद आहे. आमच्याकडे अशी प्रकरणे आहेत आणि बहुतेकदा अशा प्रकल्पांमध्ये सर्वकाही आदर्शापासून दूर असते.
2. संघाला त्यांच्या प्रकल्पाची आणि त्यांच्या उपायांची चाचणी घ्यायची आहे.
3. संघाला माहित आहे की गोष्टी वाईट आहेत. ते मुख्य समस्या आणि कारणांची यादी देखील करू शकतात, परंतु प्रकल्प सुधारण्यासाठी समस्या आणि शिफारसींची संपूर्ण यादी हवी आहे.

बाह्य अंतर्गत मूल्यांकनापेक्षा अधिक औपचारिक प्रक्रिया आहे. क्लायंट नेहमी फक्त एका प्रकरणात येतो, जेव्हा सर्वकाही वाईट असते - खूप वाईट. सामान्यतः क्लायंटला समजते की जागतिक समस्या आहेत, परंतु कारणे योग्यरित्या ओळखू शकत नाहीत आणि त्यांना घटकांमध्ये विभाजित करू शकत नाहीत.

बाह्य क्लायंटसाठी आर्किटेक्चरचे मूल्यमापन करणे अधिक जटिल प्रकरण आहे. प्रक्रिया अधिक औपचारिक असावी. प्रकल्प नेहमीच मोठे आणि जुने असतात. त्यांच्याकडे अनेक समस्या, बग आणि कुटिल कोड आहेत. केलेल्या कामाचा अहवाल जास्तीत जास्त काही आठवड्यांत तयार झाला पाहिजे, ज्यामध्ये मुख्य समस्या आणि सुधारणांच्या शिफारशींचा समावेश असावा. म्हणून, जर आपण प्रकल्पाच्या बाह्य मूल्यांकनाशी व्यवहार केला तर अंतर्गत मूल्यांकन केकचा तुकडा असेल. चला सर्वात कठीण प्रकरणाचा विचार करूया.

एंटरप्राइझ प्रकल्प आर्किटेक्चर मूल्यांकन

मूल्यमापन करण्यासाठी एक सामान्य प्रकल्प हा एक मोठा, जुना, एंटरप्राइझ प्रकल्प आहे ज्यामध्ये बर्याच समस्या आहेत. एक क्लायंट आमच्याकडे येतो आणि आम्हाला त्याचा प्रोजेक्ट ठीक करण्यास सांगतो. हे एखाद्या हिमखंडासारखे आहे, क्लायंट त्याच्या समस्यांचे फक्त टोक पाहतो आणि पाण्याखाली काय आहे (कोडच्या खोलीत) याची त्याला कल्पना नसते.

ग्राहक ज्या समस्यांबद्दल तक्रार करू शकतात आणि त्यांना माहिती असू शकते:

• कार्यप्रदर्शन समस्या
• उपयोगिता समस्या
• दीर्घकालीन तैनाती
• युनिट आणि इतर चाचण्यांचा अभाव

समस्या ज्या क्लायंटला बहुधा माहित नसतात, परंतु त्या प्रकल्पामध्ये उपस्थित असू शकतात:

• सुरक्षा समस्या
• डिझाइन समस्या
• चुकीची वास्तुरचना
• अल्गोरिदमिक त्रुटी
• अयोग्य तंत्रज्ञान
• तांत्रिक कर्ज
• चुकीची विकास प्रक्रिया

औपचारिक आर्किटेक्चर पुनरावलोकन प्रक्रिया

ही एक औपचारिक प्रक्रिया आहे जी आम्ही एक कंपनी म्हणून फॉलो करतो, परंतु तुम्ही तुमच्या कंपनी आणि प्रकल्पानुसार ती सानुकूलित करू शकता.

क्लायंटकडून विनंती

क्लायंट सध्याच्या प्रकल्पाच्या आर्किटेक्चरचे मूल्यांकन करण्यास सांगतो. आमच्या बाजूची जबाबदार व्यक्ती प्रकल्पाची प्राथमिक माहिती गोळा करते आणि आवश्यक तज्ञांची निवड करते. प्रकल्पावर अवलंबून, हे भिन्न तज्ञ असू शकतात.

समाधान आर्किटेक्ट - मूल्यांकन आणि समन्वयासाठी जबाबदार असलेली मुख्य व्यक्ती (आणि बर्‍याचदा फक्त एकच).
विशिष्ट तज्ञांना स्टॅक करा – .नेट, जावा, पायथन आणि इतर तांत्रिक तज्ञ प्रकल्प आणि तंत्रज्ञानावर अवलंबून
मेघ तज्ञ - हे Azure, GCP किंवा AWS क्लाउड आर्किटेक्ट असू शकतात.
पायाभूत सुविधा - DevOps, सिस्टम प्रशासक इ.
इतर तज्ञ – जसे की बिग डेटा, मशीन लर्निंग, कार्यप्रदर्शन अभियंता, सुरक्षा तज्ञ, QA लीड.

प्रकल्पाची माहिती गोळा करणे

प्रकल्पाविषयी शक्य तितकी माहिती गोळा करावी. आपण परिस्थितीनुसार भिन्न तंत्रे वापरू शकता:

• प्रश्नावली आणि मेलद्वारे संप्रेषणाच्या इतर पद्धती. सर्वात अप्रभावी मार्ग.
• ऑनलाइन बैठका.
• माहितीच्या देवाणघेवाणीसाठी विशेष साधने जसे की: Google doc, Confluence, Repositories, इ.
• साइटवर "लाइव्ह" मीटिंग्ज. सर्वात प्रभावी आणि सर्वात महाग मार्ग.

तुम्हाला क्लायंटकडून काय मिळाले पाहिजे?

मुलभूत माहिती. प्रकल्प कशाबद्दल आहे? त्याचा उद्देश आणि मूल्य. भविष्यासाठी मुख्य उद्दिष्टे आणि योजना. व्यवसायाची उद्दिष्टे आणि धोरणे. मुख्य समस्या आणि इच्छित परिणाम.

प्रकल्प माहिती. तंत्रज्ञान स्टॅक, फ्रेमवर्क, प्रोग्रामिंग भाषा. ऑन-प्रिमाइसेस किंवा क्लाउड डिप्लॉयमेंट. प्रकल्प क्लाउडमध्ये असल्यास, कोणत्या सेवा वापरल्या जातात. कोणते आर्किटेक्चरल आणि डिझाइन नमुने वापरले गेले.

नॉन-फंक्शनल आवश्यकता. कार्यप्रदर्शन, उपलब्धता आणि प्रणालीचा वापर सुलभतेशी संबंधित सर्व आवश्यकता. सुरक्षा आवश्यकता इ.

मूलभूत वापर प्रकरणे आणि डेटा प्रवाह.

स्त्रोत कोडमध्ये प्रवेश. सर्वात महत्वाचा भाग! तुम्हाला प्रकल्प कसा तयार करायचा यावरील रेपॉजिटरीज आणि कागदपत्रांमध्ये नक्कीच प्रवेश मिळावा.

पायाभूत सुविधांमध्ये प्रवेश. लाइव्ह सिस्टमसह कार्य करण्यासाठी स्टेज किंवा उत्पादन पायाभूत सुविधांमध्ये प्रवेश करणे छान होईल. जर क्लायंटकडे पायाभूत सुविधा आणि कार्यप्रदर्शनाचे निरीक्षण करण्यासाठी साधने असतील तर हे एक मोठे यश आहे. या साधनांबद्दल आपण पुढील भागात बोलू.

दस्तऐवजीकरण. क्लायंटकडे कागदपत्रे असल्यास ही चांगली सुरुवात आहे. हे जुने असू शकते, परंतु तरीही ही एक चांगली सुरुवात आहे. कागदपत्रांवर कधीही विश्वास ठेवू नका - क्लायंटसह, वास्तविक पायाभूत सुविधांवर आणि स्त्रोत कोडमध्ये त्याची चाचणी घ्या.

आर्किटेक्चर मूल्यांकन प्रक्रिया

एवढ्या कमी वेळेत एवढ्या मोठ्या प्रमाणात माहितीवर प्रक्रिया कशी करता येईल? सर्व प्रथम, काम समांतर करा.

DevOps ने पायाभूत सुविधा पहाव्यात. कोडमध्ये टेक लीड. कामगिरी मेट्रिक्स पाहण्यासाठी कार्यप्रदर्शन अभियंता. डेटाबेस तज्ञाने डेटा स्ट्रक्चर्समध्ये खोलवर जावे.

परंतु जेव्हा आपल्याकडे भरपूर संसाधने असतात तेव्हा हे एक आदर्श प्रकरण आहे. सामान्यतः, एक ते तीन लोक प्रकल्पाचे मूल्यांकन करतात. तुम्ही स्वतः अंदाज देखील काढू शकता, जर तुम्हाला प्रकल्पाच्या सर्व क्षेत्रांमध्ये योग्य ज्ञान आणि अनुभव असेल तर बहुतेकदा असे होते. या प्रकरणात, आपल्याला शक्य तितक्या सर्व प्रक्रिया स्वयंचलित करणे आवश्यक आहे.

दुर्दैवाने, तुम्हाला कागदपत्रे व्यक्तिचलितपणे वाचावी लागतील. योग्य प्रमाणात अनुभवासह, आपण दस्तऐवजीकरणाची गुणवत्ता पटकन समजू शकता. सत्य काय आहे आणि काय स्पष्टपणे वास्तवाशी जुळत नाही. काहीवेळा आपण दस्तऐवजीकरणात आर्किटेक्चर पाहू शकता जे वास्तविक जीवनात कधीही कार्य करणार नाही. प्रकल्पात ते प्रत्यक्षात कसे केले गेले याचा विचार करण्यासाठी हा एक ट्रिगर आहे.

प्रकल्प मूल्यांकन स्वयंचलित करण्यासाठी उपयुक्त साधने

कोड मूल्यांकन हा एक सोपा व्यायाम आहे. तुम्ही स्टॅटिक कोड विश्लेषक वापरू शकता जे तुम्हाला डिझाइन, कार्यप्रदर्शन आणि सुरक्षा समस्या दर्शवेल. त्यापैकी काही येथे आहेत:

रचना 101 आर्किटेक्टसाठी एक उत्तम साधन आहे. हे तुम्हाला मोठे चित्र, मॉड्यूल्समधील अवलंबित्व आणि रिफॅक्टरिंगसाठी संभाव्य क्षेत्रे दर्शवेल. सर्व चांगल्या साधनांप्रमाणे, यासाठी चांगले पैसे खर्च होतात, परंतु तुम्ही 30-दिवसांच्या चाचणी आवृत्तीचा लाभ घेऊ शकता.

सोनारक्यूब - एक चांगले जुने साधन. स्थिर कोड विश्लेषणासाठी एक साधन. तुम्हाला 20 पेक्षा जास्त प्रोग्रामिंग भाषांसाठी खराब कोड, बग आणि सुरक्षा समस्या ओळखण्याची अनुमती देते.

सर्व क्लाउड प्रदात्यांकडे पायाभूत सुविधा निरीक्षण साधने आहेत. हे तुम्हाला तुमच्या पायाभूत सुविधांच्या परिणामकारकतेचे मूल्य आणि कार्यक्षमतेच्या दृष्टीने योग्यरित्या मूल्यांकन करण्यास अनुमती देईल. AWS साठी हे आहे विश्वासू सल्लागार. Azure साठी हे सोपे आहे Azure सल्लागार.

अतिरिक्त कार्यप्रदर्शन निरीक्षण आणि लॉगिंग सर्व स्तरांवर कार्यप्रदर्शन समस्या शोधण्यात मदत करेल. अप्रभावी क्वेरी, बॅकएंडसह डेटाबेसपासून प्रारंभ करणे आणि फ्रंटएंडसह समाप्त होणे. जरी क्लायंटने यापूर्वी ही साधने स्थापित केली नसली तरीही, कार्यप्रदर्शन समस्या ओळखण्यासाठी तुम्ही त्यांना विद्यमान प्रणालीमध्ये द्रुतपणे समाकलित करू शकता.

नेहमीप्रमाणे, चांगली साधने योग्य आहेत. मी काही सशुल्क साधनांची शिफारस करू शकतो. अर्थात तुम्ही ओपन सोर्स वापरू शकता पण त्यासाठी तुम्हाला जास्त वेळ लागेल. आणि हे वास्तुशास्त्रीय मूल्यांकन प्रक्रियेदरम्यान नव्हे तर आगाऊ केले पाहिजे.

नवीन रिलिक - अनुप्रयोग कार्यक्षमतेचे मूल्यांकन करण्यासाठी एक साधन
डेटाडोग - क्लाउड सिस्टम मॉनिटरिंग सेवा

सुरक्षा चाचणीसाठी अनेक साधने उपलब्ध आहेत. यावेळी मी तुम्हाला मोफत सिस्टम स्कॅनिंग टूलची शिफारस करेन.

OWASP झॅप - सुरक्षा मानकांचे पालन करण्यासाठी वेब अनुप्रयोग स्कॅन करण्याचे साधन.

चला सर्वकाही एका संपूर्ण मध्ये एकत्र करूया.

अहवाल तयार करत आहे

तुम्ही क्लायंटकडून गोळा केलेल्या डेटासह तुमचा अहवाल सुरू करा. प्रकल्पाची उद्दिष्टे, अडथळे, गैर-कार्यक्षम आवश्यकता यांचे वर्णन करा. यानंतर, सर्व इनपुट डेटाचा उल्लेख केला पाहिजे: स्त्रोत कोड, दस्तऐवजीकरण, पायाभूत सुविधा.

पुढचे पाऊल. तुम्हाला मॅन्युअली किंवा ऑटोमेटेड टूल्स वापरून आढळलेल्या कोणत्याही समस्यांची यादी करा. अॅप्लिकेशन विभागात शेवटी मोठ्या स्वयं-व्युत्पन्न अहवाल ठेवा. सापडलेल्या समस्यांचे संक्षिप्त आणि संक्षिप्त पुरावे असावेत.
त्रुटी, चेतावणी, माहिती स्केलवर आढळलेल्या समस्यांना प्राधान्य द्या. आपण आपले स्वतःचे स्केल निवडू शकता, परंतु हे सामान्यतः स्वीकारलेले आहे.

खरा वास्तुविशारद म्हणून, आढळलेल्या समस्या दुरुस्त करण्यासाठी शिफारसी प्रदान करणे ही तुमची जबाबदारी आहे. ग्राहकाला प्राप्त होणार्‍या सुधारणा आणि व्यवसाय मूल्याचे वर्णन करा. पासून व्यवसाय मूल्य कसे दाखवायचे आर्किटेक्चर रिफॅक्टरिंग आम्ही आधी चर्चा केली.

छोट्या पुनरावृत्तीसह रोडमॅप तयार करा. प्रत्येक पुनरावृत्तीमध्ये पूर्ण होण्यासाठी वेळ, वर्णन, सुधारणेसाठी आवश्यक संसाधनांची संख्या, तांत्रिक मूल्य आणि व्यवसाय मूल्य असावे.

आम्ही आर्किटेक्चरचे मूल्यांकन पूर्ण करतो आणि क्लायंटला अहवाल देतो

कधीही फक्त अहवाल पाठवू नका. ते अजिबात वाचले जाऊ शकत नाही किंवा योग्य स्पष्टीकरणाशिवाय वाचले आणि समजले जाऊ शकत नाही. थोडक्यात, थेट संवादामुळे लोकांमधील गैरसमज दूर होण्यास मदत होते. तुम्ही क्लायंटसोबत मीटिंग शेड्यूल केली पाहिजे आणि सर्वात महत्त्वाच्या समस्यांवर लक्ष केंद्रित करून आढळलेल्या समस्यांबद्दल बोलले पाहिजे. क्लायंटचे लक्ष अशा समस्यांकडे वेधून घेणे योग्य आहे ज्यांची त्याला कदाचित जाणीवही नसेल. जसे की सुरक्षा समस्या आणि ते व्यवसायावर कसा परिणाम करू शकतात ते स्पष्ट करा. तुमचा रोडमॅप सुधारणांसह दाखवा आणि क्लायंटसाठी अधिक योग्य असलेल्या विविध पर्यायांवर चर्चा करा. हे वेळ, संसाधने, कामाचे प्रमाण असू शकते.

तुमच्या बैठकीचा सारांश म्हणून, तुमचा अहवाल क्लायंटला पाठवा.

शेवटी

आर्किटेक्चर मूल्यांकन ही एक जटिल प्रक्रिया आहे. मूल्यांकन योग्यरित्या पार पाडण्यासाठी आपल्याकडे पुरेसा अनुभव आणि ज्ञान असणे आवश्यक आहे.

क्लायंटला केवळ एका आठवड्यात त्याच्यासाठी आणि त्याच्या व्यवसायासाठी उपयुक्त परिणाम प्रदान करणे शक्य आहे. जरी आपण एकटे केले तरी.

माझ्या अनुभवावर आधारित, मध्यभागी अनेक सुधारणा डाउनलोड केल्या गेल्या आणि कधी कधी सुरू झाल्या नाहीत. ज्यांनी स्वतःसाठी गोल्डन मीन निवडले आणि कमीत कमी श्रम खर्चासह व्यवसायासाठी सर्वात उपयुक्त असलेल्या सुधारणांचा फक्त एक भाग बनवला त्यांनी त्यांच्या उत्पादनाच्या गुणवत्तेत लक्षणीय सुधारणा केली. ज्यांनी काहीच केले नाही ते एक-दोन वर्षांनी प्रकल्प पूर्णपणे बंद करू शकतात.

तुमचे ध्येय क्लायंटला किमान किमतीसाठी जास्तीत जास्त सुधारणा दर्शविणे हे आहे.

विभागातील इतर लेख आर्किटेक्चर तुम्ही तुमच्या आरामात वाचू शकता.

मी तुम्हाला स्वच्छ कोड आणि चांगल्या वास्तुशास्त्रीय निर्णयांची इच्छा करतो.

आमचा फेसबुक ग्रुप - सॉफ्टवेअर आर्किटेक्चर आणि विकास.

स्त्रोत: www.habr.com