సమర్థత
అనుభవజ్ఞులైన ప్రోగ్రామర్లు మంచి నిర్మాణాన్ని చెడు నుండి సులభంగా చెప్పగలరు, కానీ దానిని కొన్ని పదాలలో వివరించమని అడిగితే, వారు అలా చేయలేరు. మంచి వాస్తుశిల్పానికి ఒకే ప్రమాణం లేదు మరియు ఒకే నిర్వచనం లేదు.
అయితే, మీరు దాని గురించి ఆలోచిస్తే, మంచి వాస్తుశిల్పం సంతృప్తి చెందవలసిన అనేక ప్రమాణాలను మీరు వ్రాయవచ్చు. ఒక మంచి ఆర్కిటెక్చర్ అనేది మొదటగా, ఒక ప్రోగ్రామ్‌ను అభివృద్ధి చేసే మరియు నిర్వహించే ప్రక్రియను సరళంగా మరియు మరింత సమర్థవంతంగా చేసే లాజికల్ ఆర్కిటెక్చర్.
ఒక ప్రోగ్రామ్ మంచి నిర్మాణాన్ని కలిగి ఉన్నప్పుడు, అది ఎలా పని చేస్తుందో మరియు కోడ్ ఎక్కడ వ్రాయాలో అర్థం చేసుకోవడం ఎల్లప్పుడూ సులభం. చక్కగా రూపొందించబడిన ప్రోగ్రామ్‌ను మార్చడం, పరీక్షించడం, డీబగ్ చేయడం మరియు అభివృద్ధి చేయడం సులభం. తెలివైన వ్యక్తులు మంచి నిర్మాణం కోసం క్రింది ప్రమాణాలను రూపొందించారు:
- సమర్థత;
- వశ్యత;
- విస్తరణ;
- స్కేలబిలిటీ;
- పరీక్ష సామర్థ్యం;
- కోడ్ నిర్వహణ.
సిస్టమ్ సామర్థ్యం. ప్రోగ్రామ్, వాస్తవానికి, కేటాయించిన పనులను పరిష్కరించాలి మరియు దాని విధులను బాగా నిర్వహించాలి మరియు వివిధ పరిస్థితులలో ఉండాలి. ఏదైనా ప్రోగ్రామ్ ఏమి చేయాలో అది చేస్తుంది (అది వ్రాసినట్లయితే), కానీ తరచుగా ఇది అస్సలు కాదు.
వారు చేస్తున్నట్టు చెప్పుకునే పనిని చేయని ప్రోగ్రామ్‌లను మీరు నిరంతరం చూస్తారు.
- Libre Office అనేది Microsoft Officeకి పూర్తి ప్రత్యామ్నాయం (నిజంగా కాదు);
- ఎడ్జ్ బ్రౌజర్ అన్ని వెబ్ ప్రమాణాలకు మద్దతు ఇస్తుంది (నిజంగా కాదు);
- బ్యాంక్ తన వినియోగదారుల వ్యక్తిగత డేటా భద్రత గురించి పట్టించుకుంటుంది (వాస్తవానికి కాదు).
మరియు మేము ఇంకా పనితీరు, విశ్వసనీయత, సమయానుకూల బగ్ పరిష్కారాలు లేదా తెలిసిన దుర్బలత్వాల గురించి సమాచారాన్ని ప్రచురించడం వంటి వాటిని తాకలేదు.
ఎవరూ పరిపూర్ణంగా లేరని స్పష్టంగా తెలుస్తుంది, కానీ ప్రోగ్రామ్ దాని ప్రాథమిక పనులను పరిష్కరించాలి. అందువలన, సమర్థత లేకుండా, ఎక్కడా.
వశ్యత
నా అభిప్రాయం ప్రకారం సమర్థత కంటే ముఖ్యమైనది వశ్యత మాత్రమే. ఏ అప్లికేషన్ అయినా కాలానుగుణంగా మారాలి, అవసరాలు మారినప్పుడు కొత్తవి జోడించబడతాయి. ఇప్పటికే ఉన్న ఫంక్షనాలిటీకి మార్పులు చేయడం వేగవంతమైనది మరియు మరింత సౌకర్యవంతంగా ఉంటుంది, ఇది తక్కువ సమస్యలు మరియు లోపాలను కలిగిస్తుంది, సిస్టమ్ ఆర్కిటెక్చర్ మరింత సరళమైనది .
చాలా తరచుగా, అనుభవం లేని ప్రోగ్రామర్లు / ఆర్కిటెక్ట్‌లు ప్రస్తుత పనులకు ఆదర్శవంతమైన నిర్మాణం అవసరమని భావిస్తారు. సంఖ్య ఒక సంవత్సరంలో మీకు ప్రకటించబడే పనుల కోసం మీకు ఆదర్శవంతమైన నిర్మాణం అవసరం. మీరు, ఇప్పటికే భవిష్యత్తు పనులు తెలియక, అవి ఏమిటో తెలుసుకోవాలి.
వాటిని అంచనా వేయడానికి ప్రయత్నించడంలో అర్ధమే లేదు, ఎందుకంటే ఎల్లప్పుడూ ఊహించనిది ఉంటుంది. కానీ అలాంటి పనులు కనిపిస్తాయని మీరు పరిగణనలోకి తీసుకోవాలి. అందువల్ల, అభివృద్ధి ప్రక్రియలో, అది ఎలా మార్చబడాలి అనే పరంగా ఏది పొందబడుతుందో అంచనా వేయడానికి ప్రయత్నించండి.
మిమ్మల్ని మీరు ఇలా ప్రశ్నించుకోండి: "ప్రస్తుత నిర్మాణ నిర్ణయం తప్పు అని తేలితే ఏమి జరుగుతుంది?", "ఎంత కోడ్ మార్చబడుతుంది?". సిస్టమ్ యొక్క ఒక భాగాన్ని మార్చడం దాని ఇతర భాగాలను ప్రభావితం చేయకూడదు.
వీలైనప్పుడల్లా, వాస్తు నిర్ణయాలను రాయిగా సెట్ చేయకూడదు మరియు వాస్తు దోషాల యొక్క పరిణామాలు సహేతుకంగా పరిమితం చేయాలి. "మంచి ఆర్కిటెక్చర్ కీలక నిర్ణయాలను ఆలస్యం చేయడానికి మిమ్మల్ని అనుమతిస్తుంది" (బాబ్ మార్టిన్) మరియు తప్పుల "ఖర్చు"ని తగ్గిస్తుంది.
ఈ విధానాలలో ఒకటి అప్లికేషన్‌ను మైక్రోసర్వీస్‌లుగా విభజించడం: ఇప్పటికే ఉన్న లాజిక్‌ను ప్రత్యేక భాగాలుగా విభజించడం సులభం. కానీ ఒక చిన్న ఫీచర్‌ని అమలు చేయడానికి ఒకేసారి డజను సేవలకు భవిష్యత్తులో మార్పులు చేయడం అతిపెద్ద సమస్య.
స్కేలబిలిటీ
స్కేలబిలిటీ అనేది ప్రాజెక్ట్‌కి కొత్త వ్యక్తులను జోడించడం ద్వారా అభివృద్ధి సమయాన్ని తగ్గించే సామర్ధ్యం. ఆర్కిటెక్చర్ అభివృద్ధి ప్రక్రియను సమాంతరంగా చేయడానికి అనుమతించాలి, తద్వారా చాలా మంది వ్యక్తులు ఒకే సమయంలో ప్రోగ్రామ్‌లో పని చేయవచ్చు.
ఈ నియమం స్వయంగా నిర్వహించబడుతుందని అనిపిస్తుంది, కానీ ఆచరణలో ప్రతిదీ సరిగ్గా వ్యతిరేకం. ప్రాజెక్ట్‌కి కొత్త వ్యక్తులను చేర్చినప్పుడు, అభివృద్ధి సమయం ఎందుకు పెరుగుతుందో వివరించే ఒక సూపర్-పాపులర్ పుస్తకం, ది మిథికల్ మ్యాన్-మంత్ కూడా ఉంది .
విస్తరణ
ఎక్స్‌టెన్సిబిలిటీ అనేది సిస్టమ్‌కు దాని ప్రధాన నిర్మాణాన్ని విచ్ఛిన్నం చేయకుండా కొత్త ఫీచర్‌లు మరియు ఎంటిటీలను జోడించగల సామర్థ్యం. ప్రారంభ దశలో, సిస్టమ్‌లో ప్రాథమిక మరియు అత్యంత అవసరమైన కార్యాచరణను మాత్రమే ఉంచడం అర్ధమే.
ఇది యాగ్ని సూత్రం అని పిలవబడేది - మీకు ఇది అవసరం లేదు , "మీకు ఇది అవసరం లేదు". అదే సమయంలో, అవసరమైన విధంగా అదనపు కార్యాచరణను సులభంగా పెంచుకోవడానికి ఆర్కిటెక్చర్ మిమ్మల్ని అనుమతించాలి. మరియు తద్వారా అత్యంత సంభావ్య మార్పుల పరిచయం తక్కువ ప్రయత్నం అవసరం.
వ్యవస్థ యొక్క నిర్మాణం అనువైనదిగా మరియు విస్తరించదగినదిగా (అనగా మార్పు మరియు పరిణామానికి సామర్ధ్యం కలిగి ఉండటం) చాలా ముఖ్యమైనది, ఇది ఒక ప్రత్యేక సూత్రంగా కూడా రూపొందించబడింది - "ఓపెన్ / క్లోజ్డ్ ప్రిన్సిపల్ " . ఓపెన్-క్లోజ్డ్ ప్రిన్సిపల్ ఐదు SOLID సూత్రాలలో రెండవది: సాఫ్ట్‌వేర్ ఎంటిటీలు (క్లాస్‌లు, మాడ్యూల్స్, ఫంక్షన్‌లు) పొడిగింపు కోసం తెరిచి ఉండాలి, కానీ సవరణ కోసం మూసివేయబడతాయి .
మరో మాటలో చెప్పాలంటే: సిస్టమ్ యొక్క ఇప్పటికే ఉన్న భాగాలను తిరిగి వ్రాయకుండా సిస్టమ్ యొక్క ప్రవర్తనను మార్చడం మరియు విస్తరించడం సాధ్యమవుతుంది .
దీనర్థం అప్లికేషన్ దాని ప్రవర్తనను మార్చడం మరియు కొత్త కార్యాచరణను జోడించడం ద్వారా ఇప్పటికే ఉన్న కోడ్‌ను మార్చకుండా కొత్త కోడ్ (పొడిగింపులు) వ్రాయడం ద్వారా సాధించబడే విధంగా రూపొందించబడాలి.
ఈ సందర్భంలో, కొత్త అవసరాల ఆవిర్భావం ఇప్పటికే ఉన్న తర్కం యొక్క మార్పును కలిగి ఉండదు, కానీ దానిని విస్తరించడం ద్వారా ప్రాథమికంగా అమలు చేయవచ్చు. ఈ సూత్రం "ప్లగ్-ఇన్ ఆర్కిటెక్చర్" (ప్లగిన్ ఆర్కిటెక్చర్)కి ఆధారం. దీన్ని సాధించగల పద్ధతులు తరువాత చర్చించబడతాయి.
సర్వ్‌లెట్‌లు మరియు ఫిల్టర్‌లు గుర్తున్నాయా? ఫిల్టర్‌లు ఎందుకు అవసరమవుతాయి మరియు ప్రత్యేక ఇంటర్‌ఫేస్‌లతో కూడా, వాస్తవానికి, సర్వ్లెట్లను ఉపయోగించి ఒకే లాజిక్‌ను అమలు చేయగలిగితే?
ఇది ఫిల్టర్ల (సర్వీస్ సర్వ్‌లెట్‌లు) భావన యొక్క ఆవిష్కరణ, ఇది వివిధ సేవా ఫంక్షన్‌లను ప్రత్యేక పొరకు తరలించడం సాధ్యం చేసింది. మరియు భవిష్యత్తులో, ఫిల్టర్ల ప్రవర్తనను మార్చేటప్పుడు, సర్వ్లెట్లను మార్చడం అవసరం లేదు.
ఫిల్టర్ల ఆవిష్కరణకు ముందు, అభ్యర్థనలను దారి మళ్లించడానికి బాధ్యత వహించే అన్ని సేవా తర్కాలు సర్వ్‌లెట్‌లలోనే ఉన్నాయి. మరియు తరచుగా తర్కంలో ఒక చిన్న మార్పు అన్ని సర్వ్‌లెట్‌ల ద్వారా వెళ్లి అందరికీ వివిధ మార్పులు చేయవలసిన అవసరానికి దారి తీస్తుంది.
పరీక్షా సామర్థ్యం
మీరు జావా బ్యాకెండ్ డెవలపర్ అయితే, మీ సర్వర్ అప్లికేషన్‌లు తరచుగా REST API వంటి పద్ధతుల సమితిని బహిర్గతం చేస్తాయి. మరియు మీ అన్ని పద్ధతులు ఉద్దేశించిన విధంగా పని చేస్తున్నాయో లేదో తనిఖీ చేయడానికి, వాటిని పరీక్షలతో కవర్ చేయాలి.
సాధారణంగా, API పరీక్ష కవరేజ్ మంచి శైలి. ఇది మీ API నిజంగా చేయాలనుకున్నది చేస్తుందో లేదో నిర్ధారించుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది. అలాగే, మరీ ముఖ్యంగా, మీరు సర్వర్ లాజిక్‌లో మార్పులు చేయవచ్చు మరియు మీరు అనుకోకుండా ఏదైనా విచ్ఛిన్నం చేయలేదని సులభంగా తనిఖీ చేయవచ్చు .
మీరు పరీక్షలు రాయడం ప్రారంభించిన వెంటనే, చాలా కోడ్‌లను పరీక్షించలేమని మీరు గ్రహిస్తారు: ప్రైవేట్ పద్ధతులు, బలమైన కలపడం, స్టాటిక్ క్లాస్‌లు మరియు వేరియబుల్స్.
"కోడ్ పనిచేస్తే మనకు పరీక్షలు ఎందుకు అవసరం?", అనుభవశూన్యుడు అడుగుతాడు.
"పరీక్ష చేయలేకపోతే మాకు వర్కింగ్ కోడ్ ఎందుకు అవసరం?", ప్రొఫెషనల్ అడుగుతాడు.
పరీక్షించడానికి సులభమైన కోడ్ తక్కువ బగ్‌లను కలిగి ఉంటుంది మరియు మరింత విశ్వసనీయంగా ఉంటుంది. కానీ పరీక్షలు కోడ్ నాణ్యతను మెరుగుపరచవు. దాదాపు అందరు డెవలపర్‌లు చివరికి "మంచి టెస్టబిలిటీ" యొక్క అవసరం కూడా స్వయంచాలకంగా మంచి రూపకల్పనకు దారితీసే మార్గదర్శక శక్తి అని నిర్ధారణకు వచ్చారు.
ఆదర్శ ఆర్కిటెక్చర్ పుస్తకం నుండి ఇక్కడ ఒక కోట్ ఉంది: "ఒక తరగతి యొక్క "టెస్టబిలిటీ" సూత్రాన్ని మంచి క్లాస్ డిజైన్ యొక్క "లిట్మస్ టెస్ట్"గా ఉపయోగించండి. మీరు పరీక్ష కోడ్ యొక్క ఒక్క లైన్ రాయకపోయినా, ఈ ప్రశ్నకు 90లో సమాధానం ఇవ్వండి అతని డిజైన్‌తో ప్రతిదీ ఎలా మంచి లేదా "చెడు" అని అర్థం చేసుకోవడానికి % కేసులు సహాయపడతాయి."
పరీక్షల ఆధారంగా ప్రోగ్రామ్‌లను అభివృద్ధి చేయడానికి మొత్తం పద్దతి ఉంది, దీనిని టెస్ట్-డ్రైవెన్ డెవలప్‌మెంట్ (TDD) అంటారు. ఇది మరొక విపరీతమైనది: మీరు కోడ్ వ్రాయడానికి ముందు కోడ్ రాయండి.
కోడ్ నిర్వహణ
నియమం ప్రకారం, ప్రోగ్రామ్‌లో చాలా మంది పని చేస్తారు - కొంతమంది సెలవు, కొత్తవి వస్తాయి. ఐటీ కంపెనీలో ప్రోగ్రామర్ సగటు పని సమయం ఒకటిన్నర సంవత్సరాలు. కాబట్టి మీరు 5 సంవత్సరాల వయస్సు గల ప్రాజెక్ట్‌కి వచ్చినట్లయితే, మీ సహోద్యోగులలో 20% మంది మాత్రమే మొదటి నుండి దానిపై పనిచేశారు.
ఇతరులు వ్రాసిన ప్రోగ్రామ్‌ను నిర్వహించడం మరియు అభివృద్ధి చేయడం చాలా కష్టం. ప్రోగ్రామ్ ఇప్పటికే వ్రాయబడినప్పటికీ, దానిని నిర్వహించడం కొనసాగించడం తరచుగా అవసరం: లోపాలను పరిష్కరించండి మరియు చిన్న దిద్దుబాట్లు చేయండి. మరియు తరచుగా దీన్ని వ్రాయడంలో పాల్గొనని వ్యక్తులచే చేయవలసి ఉంటుంది.
అందువల్ల, కొత్త వ్యక్తులు సిస్టమ్‌ను అర్థం చేసుకునేందుకు మంచి నిర్మాణం సాపేక్షంగా సులభంగా మరియు శీఘ్రంగా ఉండాలి . ప్రాజెక్ట్ తప్పనిసరిగా ఉండాలి:
- చక్కగా నిర్మాణాత్మకమైనది.
- నకిలీని కలిగి ఉండకండి.
- బాగా ఫార్మాట్ చేయబడిన కోడ్‌ని కలిగి ఉండండి.
- డాక్యుమెంటేషన్ చేర్చడం మంచిది.
- ప్రోగ్రామర్ల కోసం ప్రామాణిక మరియు సుపరిచితమైన పరిష్కారాలను వర్తింపజేయడం అవసరం.
మీరు 5-పాయింట్ స్కేల్‌లో పని చేస్తున్న ప్రాజెక్ట్‌ను సులభంగా రేట్ చేయవచ్చు . ఈ అవసరాలకు ప్రతిదానికీ రెండు పాయింట్లను లెక్కించండి . మరియు మీరు 5 లేదా అంతకంటే ఎక్కువ వస్తే, మీరు అదృష్టవంతులు.
ప్రోగ్రామర్‌లకు కనీసం ఆశ్చర్యం అనే సూత్రం కూడా ఉంది : సిస్టమ్ ఎంత అన్యదేశంగా ఉంటే, ఇతరులు అర్థం చేసుకోవడం అంత కష్టం. సాధారణంగా, ఇది వినియోగదారు ఇంటర్‌ఫేస్‌కు సంబంధించి ఉపయోగించబడుతుంది, అయితే ఇది కోడ్ రాయడానికి కూడా వర్తిస్తుంది.
GO TO FULL VERSION