மென்பொருள் உலகின் அபத்தமான சட்டங்கள்

மென்பொருள் உருவாக்குநர்களைப் போன்ற ஸ்மார்ட் நபர்கள் இதை ஏன் அடிக்கடி திருகுகிறார்கள் என்று நீங்கள் எப்போதாவது யோசித்திருக்கிறீர்களா? செய்தவர்கள் இருக்கிறார்கள். இந்த இடுகையில் நாங்கள் மதிப்பாய்வு செய்கிறோம் நிபுணர்களின் நடத்தையை விவரிக்கும் சில எழுதப்படாத சட்டங்கள் கணினி.

எனது முதல் கணினி ஒரு கொமடோர் 64 ஆகும். கிட்டத்தட்ட 30 கி.பை. ரேம் கணினிக்காக இருந்தது, 32 கி.பை. சொல் செயலாக்கம், கேமிங், குடும்ப வணிக கணக்கியல் மற்றும் நான் வைத்திருக்கும் 6 ஜிபி கணினியுடன் நான் செய்யும் எல்லாவற்றையும் பற்றி இப்போது விட்டுவிட்டேன். இது கேள்வியைத் திறந்து விடுகிறது இன்றைய உபகரணங்கள் மென்பொருளின் தேவைகளுக்கு பதிலளிக்கிறதா அல்லது மென்பொருள் கிடைப்பதால் அதிக வன்பொருள் வளங்களைப் பயன்படுத்துகிறதா?

நியாயத்தில், விளையாட்டுகள் ஒன்றல்ல, கிராபிக்ஸ் ஒரே தரம் இல்லை, மேலும் திரைப்படங்களைப் பார்ப்பதும் இசையைக் கேட்பதும் சாத்தியமில்லை. இருப்பினும், ஒருவர் உதவ முடியாது, ஆனால் அதை நினைக்க முடியாது புதியவற்றை பங்களிக்காமல் பதிப்புகளை வெளியிடும் மற்றும் அதிக ஆதாரங்களை நுகரும் நிரல்கள் உள்ளன.

காரணங்கள் இங்கே.

ஜாவின்ஸ்கியின் சட்டம்

நெட்ஸ்கேப் டெவலப்பர் ஜேமி ஜாவின்ஸ்கி என்று வாதிட்டார் ஒவ்வொரு நிரலும் மின்னஞ்சல்களைப் படிக்கும் வரை அம்சங்களை உள்ளடக்குகிறது. அவர் வெற்றிபெறவில்லை என்றால், அவர் அவ்வாறு செய்யக்கூடிய மற்றொருவரால் மாற்றப்படுகிறார்.

அவர் அதைச் சொன்னபோது, ​​நகைச்சுவை என்னவென்றால், அவர் முதலில் மின்னஞ்சல் வாடிக்கையாளர்களாக கருதப்படாத நிரல்களைக் குறிப்பிடுகிறார். கூகிள் பிளேயில் உள்ள பல பயன்பாடுகள், தங்கள் வேலையைச் செய்யத் தேவையில்லாத தொலைபேசி கூறுகள் மற்றும் பயனர் தரவை அணுக அனுமதி கேட்கின்றன என்பது கண்டுபிடிக்கப்பட்டபோது இது வேடிக்கையாக இருந்தது.

பயனர்களை உளவு பார்க்கும் முயற்சிகளின் ஒரு பகுதியாக சிலர் இதை விளக்கினர். ஆனால் அதைச் செய்ய முடியும் என்பதால் வெறுமனே ஏதாவது செய்வது மனித இயல்பு.

பீட்டருக்கு கொள்கை மென்பொருளுக்கு பொருந்தும்

லாரன்ஸ் பீட்டர் ஒரு படிநிலையில், ஒரு நபர் ஒரு நிலைக்கு உயர்கிறார், அதற்காக அவர் மிகவும் திறமையற்றவர் என்று கூறி பிரபலமானார். ஆனால் சிக்கலான திட்டங்களைப் பற்றி ஏதாவது சொல்ல அவருக்கும் நேரம் இருந்தது:

"ஒரு சிக்கலான திட்டம் அதன் சொந்த டெவலப்பர்களால் கூட புரிந்து கொள்ள முடியாத அளவுக்கு சிக்கலானதாக மாறும்."

குறைந்தது ஆச்சரியத்தின் கொள்கை

1984 இல் ஐபிஎம் சிஸ்டம்ஸ் ஜர்னலில் வெளியிடப்பட்டது, இந்த கொள்கை பின்வருமாறு கூறுகிறது:

"தேவையான அம்சம் ஒரு பெரிய ஆச்சரியத்தை ஏற்படுத்தினால், அம்சத்தை மறுவடிவமைப்பு செய்ய வேண்டியிருக்கும்."

வேறு வார்த்தைகளில் கூறுவதானால், ஒரு பகுதி அல்லது அனைத்து மென்பொருளும் பயனர் பயன்படுத்தியதிலிருந்து மிகவும் வித்தியாசமாக இருந்தால், சிறந்தது மறுவடிவமைப்பு. வெறுமனே, அடைய முயற்சி செய்யுங்கள் அதிகரிக்கும் மேம்பாடுகள் சுவாரஸ்யமாக இருக்கும் அளவுக்கு பெரியவை, ஆனால் பழக்கமாக இருக்க போதுமானவை பயனருக்கு.

யூனிட்டியைத் தொடங்கும்போது மிகவும் மோசமான ஷட்டில்வொர்த் அதை கணக்கில் எடுத்துக்கொள்ளவில்லை.

சைபர்னெடிக் பூச்சியியல் சட்டம்

கணினி வரலாற்றில் முதல் பிழை உண்மையானது. ஒரு அந்துப்பூச்சி ஒரு மார்க் II கணினியில் ரிலே ஒன்றில் பறந்து ஒரு செயலிழப்பை ஏற்படுத்தியது.

உருவகத்துடன் தொடர்ந்து, சைபர்நெடிக் பூச்சியியல் விதி அதைக் கொண்டுள்ளது எப்போதும் ஒரு பிழை இருக்கும்.

இது எல்லா கணினி பயனர்களுக்கும் தெரிந்த ஒன்று. ஒரு இயக்க முறைமை எவ்வளவு சோதிக்கப்பட்டாலும், அது மிகவும் தாமதமாக இருக்கும்போது எப்போதும் கண்டுபிடிக்கும் தவறு உள்ளது.

கெர்னிகனின் சட்டம்

Linux Adictos தேடுபொறி நட்பு முறையில் நாங்கள் எழுத்தாளர்கள் எழுதுவதை உறுதிசெய்ய ஒரு செருகுநிரல் நிறுவப்பட்டுள்ளது. முதல் நாளிலிருந்தே நான் அதை வெறுத்தேன். இலக்கியப் பறப்புடன் எழுதும் எந்த முயற்சியும் உடனடியாக சிவப்பு வட்டத்தால் கண்டிக்கப்படுகிறது. நேரம் செல்ல செல்ல நான் பழகிவிட்டேன், நான் அரிதாகவே டச்-அப் செய்ய வேண்டியிருந்தது.

புரோகிராமர்களுக்கும் இதேதான் நடக்கிறது, புரிந்துகொள்வதற்கும் பராமரிப்பதற்கும் எளிதான ஒரு எளிய குறியீட்டை எழுதுவதை விட பல முறை அவர்கள் குறியீட்டுக்கான திறனை நிரூபிப்பதில் அதிக ஆர்வம் காட்டுகிறார்கள்.

எனவே கெர்னிகனின் சட்டம் பின்வருமாறு:

பிழைத்திருத்தம் முதலில் குறியீட்டை எழுதுவதை விட இரு மடங்கு கடினம். எனவே நீங்கள் குறியீட்டை முடிந்தவரை புத்திசாலித்தனமாக எழுதினால், நீங்கள் அதை வரையறுப்பதற்கு போதுமான புத்திசாலி இல்லை. '

90/90 விதி

நிஜ வாழ்க்கையில் ஒரு இலாப நோக்கற்ற திட்டத்தைத் தொடங்கிய எவருக்கும், ஒவ்வொரு திட்டமும் எதிர்பார்த்த லாபத்தில் பாதி சம்பாதிக்க, ஒவ்வொரு திட்டமும் இரு மடங்கு அதிக நேரம் மற்றும் பட்ஜெட்டை விட இரண்டு மடங்கு அதிகமாக செலவாகும் என்பது தெரியும்.

கணினி உலகில் இந்த சட்டத்தின் மாறுபாடுகள் உள்ளன. உதாரணமாக, ஒரு டாம் கார்கில் கூறினார்:

“குறியீட்டின் முதல் 90 சதவீதம் வளர்ச்சி நேரத்தின் முதல் 90 சதவீதத்தைக் குறிக்கிறது. மீதமுள்ள 10 சதவீத குறியீடு மற்ற 90 சதவீத வளர்ச்சி நேரத்தைக் குறிக்கிறது.

இது தெளிவாக இல்லையா? ஒருவேளை ஹோஃப்ஸ்டாடரின் சட்டம் உதவும்:

"ஹாஃப்ஸ்டாடரின் சட்டத்தை மனதில் வைத்திருந்தாலும் கூட, நீங்கள் எதிர்பார்ப்பதை விட இது எப்போதும் அதிக நேரம் எடுக்கும்."

உபுண்டு மற்றும் ஃபெடோரா டெவலப்பர்கள் அறிந்திருக்க வேண்டும் என்று நினைக்கிறேன். அல்லது குறைந்தபட்சம் ஒவ்வொரு 6 மாதங்களுக்கும் நினைவில் கொள்ளுங்கள்.

ப்ரூக்கின் சட்டம்

திறந்த மூல மென்பொருள் திட்டங்களுக்கு பெரும்பாலும் இரண்டு சிக்கல்கள் உள்ளன; நிதி மற்றும் கூட்டுப்பணியாளர்களின் பற்றாக்குறை. இரண்டாவது ஒரு பிரச்சினை இல்லை என்றால். புரூக்கின் கூற்றுப்படி:

"திட்டமிடலுக்குப் பின்னால் இருக்கும் ஒரு மென்பொருள் திட்டத்தில் உழைப்பைச் சேர்ப்பது அதை மேலும் தாமதப்படுத்தும்."

புதிய குறியாக்கிகளைப் புதுப்பிக்க வேண்டியதில்லை. மேலும் ஆவணப்படுத்தப்பட வேண்டியிருக்கும், அனைவரையும் ஒத்திசைவில் வைத்திருக்க அதிக அதிகாரத்துவம் தேவைப்படும், மேலும் சண்டைகள் இருக்கும்.

நண்பர் பார்கின்சன் மற்றும் அவரது கூற்று பற்றி நாம் மறக்க முடியாது நீங்கள் எவ்வளவு வெற்று இடத்துடன் தொடங்கினாலும் பரவாயில்லை. உங்களுக்கு எப்போதும் இன்னும் தேவைப்படும். அவர் அலுவலக இடத்தைக் குறிப்பிடுகிறார், ஆனால் ரேம் மற்றும் வட்டு இடத்திற்கும் இது பொருந்தும்.