చెడ్డ డిజైన్ కోసం ప్రమాణాలు
జీవితం చాలా సరళంగా పనిచేస్తుంది: తరచుగా, తెలివిగా ఉండటానికి, మీరు తెలివితక్కువ పనులు చేయవలసిన అవసరం లేదు. ఇది సాఫ్ట్‌వేర్ అభివృద్ధికి కూడా వర్తిస్తుంది: చాలా సందర్భాలలో, ఏదైనా బాగా చేయడానికి, మీరు దానిని చెడుగా చేయకూడదు.
చాలా మంది ప్రోగ్రామర్లు తప్పుగా రూపొందించబడిన సిస్టమ్ భాగాలతో అనుభవం కలిగి ఉన్నారు. కానీ మరింత విచారకరం, మీలో చాలా మందికి మీరు అలాంటి వ్యవస్థ యొక్క రచయితలు అని గ్రహించిన విచారకరమైన అనుభవం ఉంటుంది. మేము ఉత్తమమైనదాన్ని కోరుకున్నాము, కానీ అది ఎప్పటిలాగే మారింది.
చాలా మంది డెవలపర్లు చెడ్డ ఆర్కిటెక్చర్‌ను కోరుకోరు మరియు చాలా సిస్టమ్‌లకు దాని నిర్మాణం భయంకరమైనదని చెప్పడం ప్రారంభించే పాయింట్ వస్తుంది. ఇలా ఎందుకు జరుగుతోంది? ఆర్కిటెక్చర్ డిజైన్ ప్రారంభం నుండి చెడుగా ఉందా లేదా కాలక్రమేణా చెడుగా మారిందా?
ఈ సమస్య యొక్క మూలం "చెడు" డిజైన్ యొక్క నిర్వచనం లేకపోవడం.
ఏదైనా ప్రోగ్రామర్‌కు చాలా ముఖ్యమైన లక్షణాలు డిజైన్ నాణ్యత మరియు దాని “క్షయం” యొక్క కారణాలపై అవగాహన అని నాకు అనిపిస్తోంది. చాలా ఇతర సందర్భాల్లో మాదిరిగా, సమస్యను గుర్తించడం ప్రధాన విషయం, మరియు దానిని పరిష్కరించడానికి సాంకేతికత విషయం అవుతుంది.
"చెడు డిజైన్" యొక్క నిర్వచనం
మీరు తోటి ప్రోగ్రామర్ ముందు మీ కోడ్ గురించి గొప్పగా చెప్పుకోవాలని నిర్ణయించుకుంటే, మీరు ప్రతిస్పందనగా ఎగతాళికి గురవుతారు: "ఎవరు ఇలా చేస్తారు?", 'ఎందుకు అలా ఉంది?' మరియు "నేను పనులను భిన్నంగా చేస్తాను." ఇది చాలా తరచుగా జరుగుతుంది.
వ్యక్తులందరూ భిన్నంగా ఉంటారు, కానీ మీరు ఇప్పటికీ మీ తోటి ప్రోగ్రామర్‌ల కోసం కోడ్‌ను వ్రాస్తారు, కాబట్టి ప్రతి ఫీచర్‌ను అభివృద్ధి చేసే ప్రక్రియలో, ఇతర వ్యక్తులు మీ కోడ్‌ని చూసినప్పుడు మీకు ఎల్లప్పుడూ సమీక్ష దశ అవసరం.
అయితే చాలా పనులు వివిధ మార్గాల్లో చేయగలిగినప్పటికీ, డెవలపర్‌లందరూ అంగీకరించే కొన్ని ప్రమాణాలు ఉన్నాయి. కోడ్ యొక్క ఏదైనా భాగం దాని అవసరాలను సంతృప్తి పరుస్తుంది కానీ ఇప్పటికీ ఒకటి (లేదా అంతకంటే ఎక్కువ) లక్షణాలను ప్రదర్శిస్తుంది, అది చెడ్డ డిజైన్.
చెడు డిజైన్:
- ఏదైనా మార్పు సిస్టమ్‌లోని చాలా ఇతర భాగాలను ప్రభావితం చేస్తుంది కాబట్టి మార్చడం కష్టం. ( దృఢత్వం , దృఢత్వం).
- మార్పులు చేసినప్పుడు, సిస్టమ్ యొక్క ఇతర భాగాలు ఊహించని విధంగా విచ్ఛిన్నమవుతాయి. ( దుర్బలత్వం , దుర్బలత్వం).
- కోడ్‌ని మరొక అప్లికేషన్‌లో మళ్లీ ఉపయోగించడం కష్టం ఎందుకంటే ప్రస్తుత అప్లికేషన్ నుండి దాన్ని పొందడం చాలా కష్టం. ( కదలలేనిది , నిశ్చలత).
మరియు తమాషా ఏమిటంటే, ఈ లక్షణాలలో ఏదీ లేని (అనగా, అనువైనది, నమ్మదగినది మరియు పునర్వినియోగపరచదగినది) సిస్టమ్ యొక్క భాగాన్ని కనుగొనడం దాదాపు అసాధ్యం , మరియు అదే సమయంలో దాని రూపకల్పన చెడ్డది. .
అందువల్ల, డిజైన్ “చెడ్డది” లేదా “మంచిది” కాదా అని నిస్సందేహంగా నిర్ణయించడానికి మేము ఈ మూడు లక్షణాలను ఉపయోగించవచ్చు.
"చెడు డిజైన్" కారణాలు
డిజైన్‌ను దృఢంగా, పెళుసుగా మరియు కదలకుండా చేస్తుంది? మాడ్యూల్స్ యొక్క దృఢమైన పరస్పర ఆధారపడటం.
సులభంగా మార్చలేకపోతే డిజైన్ దృఢంగా ఉంటుంది . ఈ దృఢత్వం అనేది ఒక నేసిన సిస్టమ్‌లోని కోడ్ ముక్కకు ఒకే మార్పు డిపెండెంట్ మాడ్యూల్స్‌లో క్యాస్కేడింగ్ మార్పులకు దారితీస్తుంది. ఒక వ్యక్తి కోడ్‌పై పని చేస్తున్నప్పుడు ఇది ఎల్లప్పుడూ జరుగుతుంది.
ఇది తక్షణమే మొత్తం వాణిజ్య అభివృద్ధి ప్రక్రియను క్లిష్టతరం చేస్తుంది: క్యాస్కేడింగ్ మార్పుల సంఖ్యను డిజైనర్ లేదా డెవలపర్ అంచనా వేయలేనప్పుడు, అటువంటి మార్పు యొక్క ప్రభావాన్ని అంచనా వేయడం అసాధ్యం. అందువల్ల, వారు అలాంటి మార్పులను నిరవధికంగా వాయిదా వేయడానికి ప్రయత్నిస్తారు.
మరియు ఇది మార్పు ధరను ఊహించలేనిదిగా చేస్తుంది. అటువంటి అనిశ్చితితో, నిర్వాహకులు మార్పులు చేయడానికి ఇష్టపడరు, కాబట్టి డిజైన్ అధికారికంగా దృఢంగా మారుతుంది.
ఏదో ఒక సమయంలో, మీ ప్రాజెక్ట్ "ఈవెంట్ హోరిజోన్" దాటిపోతుంది మరియు దృఢమైన నిర్మాణం యొక్క "బ్లాక్ హోల్"లో పడటం విచారకరం.
పెళుసుదనం అనేది ఒకే మార్పు తర్వాత అనేక ప్రదేశాలలో విచ్ఛిన్నమయ్యే వ్యవస్థ యొక్క ధోరణి. సాధారణంగా మార్పు చోటుకు సంభావితంగా సంబంధం లేని ప్రదేశాలలో కొత్త సమస్యలు ఏర్పడతాయి. ఇటువంటి దుర్బలత్వం వ్యవస్థ రూపకల్పన మరియు నిర్వహణపై విశ్వాసాన్ని తీవ్రంగా దెబ్బతీస్తుంది.
ప్రైవేట్ పద్ధతులు లేనప్పుడు ఇది సాధారణంగా జరిగేది. అన్ని పద్ధతులను పబ్లిక్ చేయడానికి ఇది సరిపోతుంది మరియు మీరు పెళుసైన నిర్మాణ రూపానికి విచారకరంగా ఉంటారు. సూక్ష్మ స్థాయిలో దీన్ని ఎదుర్కోవడానికి ఎన్‌క్యాప్సులేషన్ సహాయపడుతుంది. కానీ స్థూల స్థాయిలో, మీకు మాడ్యులర్ ఆర్కిటెక్చర్ అవసరం.
ఒక ప్రాజెక్ట్ పెళుసుగా ఉండే నిర్మాణాన్ని కలిగి ఉన్నప్పుడు, డెవలపర్లు ఉత్పత్తి నాణ్యతకు హామీ ఇవ్వలేరు.
అప్లికేషన్ యొక్క ఒక భాగంలో సాధారణ మార్పులు ఇతర సంబంధం లేని భాగాలలో బగ్‌లకు దారితీస్తాయి. ఈ లోపాలను సరిదిద్దడం మరింత సమస్యలకు దారి తీస్తుంది మరియు ఎస్కార్ట్ ప్రక్రియ దాని స్వంత తోకను వెంబడించే ప్రసిద్ధ కుక్కగా మారుతుంది.
సిస్టమ్ యొక్క అవసరమైన భాగాలు ఇతర అవాంఛిత వివరాలతో బలంగా ముడిపడి ఉన్నప్పుడు డిజైన్ కదలకుండా ఉంటుంది . వారి స్వంత కోడ్ చాలా ఎక్కువ, వారి స్వంత ప్రత్యేక విధానాలు మరియు పరిష్కారాలు.
JUL లాగర్ మీకు గుర్తుందా, దీని డెవలపర్లు ఎటువంటి మంచి కారణం లేకుండా వారి స్వంత లాగింగ్ స్థాయిలతో ముందుకు వచ్చారు? ఇది కేవలం కేసు.
ఇప్పటికే ఉన్న డిజైన్‌ను తిరిగి ఉపయోగించడం ఎంత సులభమో డిజైనర్‌కు ఆలోచన ఇవ్వడానికి, కొత్త అప్లికేషన్‌లో ఉపయోగించడం ఎంత సులభమో ఆలోచించడం సరిపోతుంది.
డిజైన్ పటిష్టంగా జత చేయబడి ఉంటే, అప్పుడు ఈ డిజైనర్ అనవసరమైన వివరాల నుండి సిస్టమ్ యొక్క అవసరమైన భాగాలను వేరు చేయడానికి అవసరమైన పని మొత్తంతో భయపడతాడు. చాలా సందర్భాలలో, అటువంటి డిజైన్ పునర్వినియోగపరచబడదు, ఎందుకంటే దానిని వేరుచేసే ఖర్చు మొదటి నుండి అభివృద్ధి చేయడం కంటే ఎక్కువగా ఉంటుంది.
ఔచిత్యం
ప్రతిదీ మారుతుంది, కానీ ప్రతిదీ అలాగే ఉంటుంది. (చైనీస్ సామెత)
చాలా మంచి ప్రశ్నలు పైన లేవనెత్తారు. పెళుసుగా మరియు దృఢమైన వ్యవస్థల ప్రమాదాలు ఏమిటి? అవును, ఎందుకంటే అటువంటి ప్రాజెక్ట్ నిర్వహణ ప్రక్రియ అనూహ్యమైనది మరియు నియంత్రించలేనిదిగా మారుతుంది. మరియు ధర విపరీతమైనది.
వాస్తవానికి ఎంత సమయం పడుతుందో తెలియకపోతే, కొంత ఫీచర్‌ని జోడించడానికి నిర్వాహకుడు ఎలా ముందుకు వెళ్లగలడు లేదా ఇవ్వకూడదు? మీరు వాటి అమలు యొక్క సమయం మరియు సంక్లిష్టతను తగినంతగా అంచనా వేయలేకపోతే పనులకు ప్రాధాన్యత ఇవ్వడం ఎలా?
మరియు డెవలపర్లు అదే సాంకేతిక రుణాన్ని ఎలా చెల్లించగలరు, మేము దానిని చెల్లించేటప్పుడు, మరియు మనం రేక్ చేసే వరకు మనం ఎంత రేక్ చేస్తామో అర్థం చేసుకోలేము?
కోడ్ పునర్వినియోగం లేదా పరీక్షతో సమస్యలు కూడా చాలా సందర్భోచితంగా ఉంటాయి. యూనిట్ పరీక్షలు పరీక్షలో ఉన్న యూనిట్ గురించి కొన్ని అంచనాలను పరీక్షించడానికి మాత్రమే కాకుండా, దాని సమన్వయ స్థాయిని నిర్ణయించడానికి మరియు పునర్వినియోగానికి సూచికగా ఉపయోగపడతాయి.
ఈ సందర్భంలో బాబ్ మార్టిన్ నుండి ఇక్కడ ఒక కోట్ ఉంది: "మీ కోడ్‌ని మళ్లీ ఉపయోగించాలంటే, మీరు మొదటి నుండి అభివృద్ధి చేయడానికి అయ్యే ఖర్చు కంటే తక్కువ దాన్ని మళ్లీ ఉపయోగించుకునే ప్రయత్నం చేయాలి . " లేకపోతే, ఈ విషయంలో ఎవరూ బాధపడరు.
డిజైన్ సూత్రాలు మరియు నమూనాల ఉపయోగం ఒక ప్రయోజనానికి ఉపయోగపడుతుంది - డిజైన్‌ను చక్కగా చేయడానికి. వారి ఉపయోగం మీకు ఎటువంటి ప్రయోజనాన్ని ఇవ్వకపోతే (లేదా దీనికి విరుద్ధంగా, "మంచి డిజైన్" సూత్రాలను ఉల్లంఘిస్తే), అప్పుడు మీ సంరక్షణాలయంలో ఏదో సరైనది కాదు మరియు బహుశా, సాధనం ఇతర ప్రయోజనాల కోసం ఉపయోగించడం ప్రారంభించింది.