ඔබට එය වළක්වා ගත හැකි නම් කේතීකරණ ප්රමිතීන් ලියා නොගත යුතු යැයි බොබ් මාමා යෝජනා කරන්නේ ඇයි?
ඔබ ඔහුගේ මතය පිටුපස හේතු විමසන්නේ නම් ඔබට පිළිතුරක් ලැබිය හැක්කේ ඔහු මෙහි පිළිතුරක් පළ කරන්නේ නම් පමණි ( අපගේ මතය අදාල නොවේ), කෙසේ වෙතත් ...
මා කේතීකරණ ප්‍රමිතියක් ලියා නොගත යුත්තේ ඇයි?
ඔහු ඒ ගැන නිවැරදි දැයි ඔබ අසන්නේ නම් : එය වළක්වා ගැනීමට ඔබට හේතුවක් නොමැති බව පැවසීමට (මෙතෙක්) ජනප්‍රිය නොවූ එකම තැනැත්තා වීමට මට ඉඩ දෙන්න.
එය ලියන්න . කෙසේ වෙතත් මම මගේ හේතු පැහැදිලි කිරීමට උත්සාහ කරමි ...
ඩේවිඩ් අදහස් දැක්වීමකදී යෝජනා කළේ ස්ටීවන්ගේ පිළිතුරේ ප්‍රධාන කරුණ වන්නේ ඔබ ලේඛන ලිවිය නොහැක්කේ මන්ද යන්න නොව ඒවා කුමන ස්වරූපයෙන්ද යන්නයි. මෙවලම් තුළ මාර්ගෝපදේශ විධිමත් කර ඇත්නම් (හුදෙක් අතින් කේත සමාලෝචනයක් නොවේ) එවිට මම එකඟ විය හැකිය (නීතියට වෙනත් දෙයක් අවශ්ය නොවන විට). අවාසනාවකට මෙවලම් සෑම දෙයක්ම පරික්ෂා කළ නොහැකි බව කරුණාවෙන් සලකන්න (ගණනය කිරීමේ න්‍යාය අපගේ මිතුරා නොවේ) ඒවා නිශ්චිත පරිවර්තන ඒකකයකට හෝ පැකේජයකට පමණක් සීමා වී ඇති නිසා හෝ ඔබේ ප්‍රියතම භාෂාව මායිමක් ලෙස හඳුන්වන ඕනෑම දෙයක් නිසා .
කෙසේ වෙතත් බොබ් මාමාගේ වචනවලින් ඔහු ඒ ගැන කතා කරයි කියා මා සිතන්නේ නැත.
එවැනි ජ්‍යෙෂ් senior විශේෂ expert යෙකු සමඟ මට එකඟ විය නොහැකිද? උපුටා දක්වන ලද ලිපියේ සෑම කරුණක් සඳහාම මම එසේ කරමි (විස්තර සඳහා මෙම පිළිතුරේ දෙවන කොටසද බලන්න). එයට හේතුව තේරුම් ගැනීමට උත්සාහ කරමු (කේතීකරණ මාර්ගෝපදේශ සුළු ආකෘතිකරණ ගැටළු සඳහා පමණක් නොවන බව ඔබ දැනටමත් දන්නා බව උපකල්පනය කර ).
- සමහර තත්වයන් යටතේ ලිඛිත කේතීකරණ ප්රමිතීන් නීතියෙන් අවශ්ය වේ.
- මම ලියකියවිලි කියවන අතර මට විශ්වාසයි මම තනිවම නොවේ. කණ්ඩායම් සාමාජිකයින්ට කාලයත් සමඟ වෙනස් විය හැකිය, දැනුම අවුරුදු 5-10ක් පැරණි කේත පදනමක් තුළ හෝ කණ්ඩායම් සාමාජිකයින්ගේ මනසෙහි තිබිය නොහැක. අභ්‍යන්තර මාර්ගෝපදේශ අනුගමනය නොකරන පුද්ගලයින්ට සංවිධාන වෙඩි තැබිය යුතුය.
- කේතීකරණ ප්රමිතීන්, ඒවා අනුමත වූ පසු , බොහෝ විට වෙනස් නොවන අතර ඒවා ඔබට දැන ගැනීමට අවශ්ය නම්. ප්‍රමිති වෙනස් වී ඇත්නම් ඔබගේ සියලු කේත නව ප්‍රමිතිය අනුගමනය නොකරන බැවින් ඔබගේ ලේඛන (කේතයෙන්) යල්පැන ඇත. නැවත ආකෘතිකරණය / ප්‍රතිනිර්මාණය කිරීම මන්දගාමී විය හැකි නමුත් ඔබට සැමවිටම අනුගමනය කිරීමට ලිඛිත බලයලත් මාර්ගෝපදේශයක් ඇත.
- රීතියක් උපුටා ගැනීම සඳහා 10/20K LOC පරීක්ෂා කිරීමට වඩා පිටු 5 ක ලේඛනයක් කියවීම වඩා හොඳය (ඔබ වැරදියට තේරුම් ගත හැකි BTW), ඒ ගැන සැකයක් නැත.
- සැලසුම් මූලධර්ම සහ කේතීකරණ ශෛලිය ගැන බොහෝ පොත් ලියා ඇති අයෙක් ඔබේම මාර්ගෝපදේශ ලිවිය යුතු නැති බවට යෝජනා කිරීම විකාරයකි, සමහර කේත උදාහරණ සමඟ ඔහු අපව ඉවත දැමුවහොත් වඩා හොඳ නොවේද? නැත, මන්ද ලිඛිත මාර්ගෝපදේශ මඟින් ඔබට කළ යුතු දේ පමණක් නොව කේතයේ නොමැති තවත් කාරණා දෙකක් ද කියනු ලැබේ: නොකළ යුතු දේ සහ එය කිරීමට හේතු හෝ නොකිරීම.
"නොමිලේ ස්වයං-සංවිධානාත්මක වැඩසටහන්කරණය" 16 හැවිරිදි නින්ජා කෙනෙකුට හොඳයි, නමුත් සංවිධානවලට වෙනත් අවශ්‍යතා ඇත :
- සමාගම් මට්ටමින් කේතයේ ගුණාත්මකභාවය ලබා දිය යුතුය (සහ අර්ථ දැක්විය යුතුය) - එය තනි කණ්ඩායමක් විසින් තීරණය කළ හැකි දෙයක් නොවේ. වඩා හොඳ දේ තීරණය කිරීමේ කුසලතා ඔවුන් සතුව නොතිබිය හැකිය (නිදසුනක් වශයෙන්, මිස්රා සමාලෝචනය කිරීමට හෝ එක් එක් රීතිය තේරුම් ගැනීමට පවා සංවර්ධකයින් කීදෙනෙකුට අවශ්ය සියලු කුසලතා තිබේද?)
- සාමාජිකයන් විවිධ කණ්ඩායම් හරහා ගෙන යා හැකිය: සෑම දෙනාම එකම කේතීකරණ ප්රමිතීන් අනුගමනය කරන්නේ නම් ඒකාබද්ධ කිරීම සුමට වන අතර අඩු දෝෂ සහිත වේ.
- කණ්ඩායමක් ස්වයං-සංවිධානය කරන්නේ නම්, කණ්ඩායම් සාමාජිකයන් වෙනස් වන විට කාලයත් සමඟ ප්රමිතීන් පරිණාමය වනු ඇත - එවිට ඔබට දැනට පිළිගත් ප්රමිතීන් අනුගමනය නොකරන විශාල කේත පදනමක් ඇත.
ක්‍රියාවලියට පෙර ඔබ මිනිසුන් ගැන සිතන්නේ නම් මට යෝජනා කළ හැක්කේ ටීපීඑස් ගැන කියවීම පමණි: මිනිසුන් කෙට්ටු වීමේ ප්‍රධාන අංගයක් වන නමුත් ක්‍රියා පටිපාටි ඉතා විධිමත් කර ඇත.
ඇත්තෙන්ම එක් කණ්ඩායමක් සමග කුඩා සංවිධානයක් විය හැක කණ්ඩායම එය ලියා කළ යුතුය සම්මත කර ප්රමිතීන් තීරණය නමුත්, පසුව, ඉඩ දෙන්න. Programmers.SE හි ඔබට එරික් ලිපර්ට්ගේ ලිපි කියවිය හැකිය: ඔහු පළපුරුදු සංවර්ධකයෙකු බව අපි කවුරුත් එකඟ වෙමු, ඔහු මයික්‍රොසොෆ්ට් හි සේවය කරන විට ඔහුගේ ලිඛිත මාර්ගෝපදේශ පිළිපැදිය යුතු විය (සමහර නීති වැරදියි , අදාළ නොවේ හෝ නිෂ් less ල නොවේ ඔහුට.) ජෝන් ස්කීට් ගැන කුමක් කිව හැකිද? ගූගල් මාර්ගෝපදේශ තරමක් දැඩි ය (බොහෝ අය ඔවුන් සමඟ එකඟ නොවෙති) නමුත් ඔහු එවැනි මාර්ගෝපදේශ පිළිපැදිය යුතුය. එය ඔවුන්ට අගෞරවයක්ද? නැත, ඔවුන් බොහෝ විට එවැනි මාර්ගෝපදේශ නිර්වචනය කිරීමට හා වැඩිදියුණු කිරීමට කටයුතු කර ඇත, සමාගමක් එක් සාමාජිකයෙකු (හෝ එක් කණ්ඩායමක්) විසින් සාදන ලද අතර සෑම කණ්ඩායමක්ම දූපතක් නොවේ .
උදාහරණ
- C ++ හි බහු උරුමය සහ කැදැලි පන්ති භාවිතා නොකිරීමට ඔබ තීරණය කළේ ඔබ සැබෑ කණ්ඩායම් සාමාජිකයින්ට එය හොඳින් වටහා නොගන්නා බැවිනි. පසුකාලීනව බහු උරුමයක් භාවිතා කිරීමට කැමති අයෙක් 1M LOC බ්‍රවුස් කර එය කවදා හෝ භාවිතා කර ඇත්දැයි සොයා බැලිය යුතුය. එය නරක ය, මන්ද නිර්මාණ තීරණ ලේඛනගත නොකළ හොත් ඒවා තේරුම් ගැනීම සඳහා ඔබ සම්පූර්ණ කේත පදනම අධ්‍යයනය කළ යුතු ය. එසේ වුවද, එය භාවිතා කර නොමැති නම්, එය කේතීකරණ ප්‍රමිතියට පටහැනි නිසාද, නැතහොත් එයට අවසර දී ඇති නිසාද, නමුත් බහු උරුමය හොඳ සුදුසුකමක් ඇති පූර්ව අවස්ථා කිසිවක් නොතිබුණිද?
- C # හි ඔබ පෙරනිමි පරාමිතීන් සැපයීම සඳහා අධික ලෙස පැටවූ ක්‍රම භාවිතා කර ඇති බැවින් C # හි විකල්ප පරාමිතීන් නොමැති විට ඔබේ කේත පදනම ආරම්භ විය. එවිට ඔබ වෙනස් වූ අතර ඔබ ඒවා භාවිතා කිරීමට පටන් ගත්තේය (ඔබට එවැනි කාර්යයන් වෙනස් කිරීමට සිදු වූ සෑම අවස්ථාවකම ඒවා භාවිතා කිරීමට පැරණි කේතය ප්‍රතිනිර්මාණය කිරීම). පසුව පවා ඔබ තීරණය කළේ විකල්ප පරාමිතීන් නරක බවත් ඔබ ඒවා භාවිතා කිරීමෙන් වැළකී සිටීමට පටන් ගන්නා බවත්ය. මෙම මොකක්ද පාලනය ඔබගේ කේතය ඔබ පවසනවා? සම්මත පරිණාමය නිසා එය නරක නමුත් කේත පදනම පරිණාමය වීමට මන්දගාමී වන අතර එය ඔබේ ලියකියවිලි නම් ඔබට කරදරයක් වේ.
- ජෝන් A කණ්ඩායමේ සිට බී කණ්ඩායම දක්වා මාරු විය. ජොන්ට නව ප්‍රමිතියක් ඉගෙන ගත යුතුය; ඉගෙන ගන්නා අතරතුර ඔහු වඩාත් සියුම් දෝෂ හඳුන්වා දෙනු ඇත (හෝ, වාසනාවන්ත නම්, පවතින කේතය තේරුම් ගැනීමට සහ කේත සමාලෝචනය දිගු කාලයක් ගත කිරීමට).
- කණ්ඩායම A කලින් බී කණ්ඩායමට අයත් කේත පදනමක් වෙත ගමන් කරයි. එය සම්පූර්ණයෙන්ම වෙනස් කේතීකරණ ප්රමිතීන් ඇත. නැවත ලිවිය යුතුද? අනුවර්තනය? මිශ්ර? ඔවුන් සියල්ලන්ම එක හා සමානව නරක ය.
බොබ් මාමා
පළමු පුනරාවර්තන කිහිපය තුළ ඒවා පරිණාමය වීමට ඉඩ හරින්න.
ඇත්ත, ඔබට ප්‍රමිතියක් නොමැති වන තෙක් සහ ඔබේ සංවිධානය විසින් එය තැනීමේ කාර්යය ඔබට පවරා ඇත.
සමාගම් විශේෂිත වෙනුවට කණ්ඩායම් විශේෂිත වීමට ඔවුන්ට ඉඩ දෙන්න.
නැත, ඉහත විස්තර කර ඇති සියලු හේතු නිසා. කේත හැඩතල ගැන්වීම විධිමත් කිරීමට ඔබ සිතුවත් (ඔබට විධිමත් කිරීමට අවශ්ය අවමම ප්‍රයෝජනවත් දෙය) හැඩතල ගැන්වීම පිළිබඳ නිමක් නැති (හා නිෂ් less ල) යුද්ධ පිළිබඳ මතකයක් තවමත් මට ඇත. මට ඒවා නැවත නැවතත් ජීවත් වීමට අවශ්ය නැත, සියල්ලටම වරක් එය සකසන්න.
ඔබට එය වළක්වා ගත හැකි නම් ඒවා ලියා නොගන්න. ඒ වෙනුවට, කේතය ප්‍රමිති ග්‍රහණය කර ගන්නා ආකාරය වේ.
නැත, ඉහත විස්තර කර ඇති සියලු හේතුන් සඳහා (ඇත්ත වශයෙන්ම ඔබ මාර්ගෝපදේශ වෙනස් වන විට ඔබේ සියලු කේත එක පහරකින් ප්‍රතිනිර්මාණය නොකරන්නේ නම්). ඔබේ කේතය එලෙසම තැබීමට ඔබට අවශ්‍යද? වත්මන් මාර්ගෝපදේශ තේරුම් ගැනීමට ඔබ කේත පදනම් පරීක්ෂා කරන්නේ කෙසේද ? ගොනු වයස අනුව සෙවීම සහ ඔබේ කේතීකරණ විලාසය ප්‍රභව ගොනු වයසට අනුවර්තනය කිරීම?
හොඳ නිර්මාණයක් නීතිගත නොකරන්න. (උදා: ගොටෝ භාවිතා නොකරන ලෙස මිනිසුන්ට නොකියන්න)
මාර්ගෝපදේශ කෙටි විය යුතු බව හෝ කිසිවෙකු ඒවා කියවන්නේ නැති බව ඇත්ත. පැහැදිලිව නැවත නොකියන්න.
ප්‍රමිතිය සන්නිවේදනය පිළිබඳ බව සියලු දෙනා දන්නා බවට වග බලා ගන්න, වෙන කිසිවක් නැත.
සුළු තොරතුරු ගැන පමණක් ප්‍රමිතියක් ලබා ගැනීමට ඔබට අවශ්ය නම් මිස හොඳ ප්‍රමිතියක් ගුණාත්මකභාවය පිළිබඳ වේ.
පළමු පුනරාවර්තන කිහිපයෙන් පසුව, කණ්ඩායම තීරණය කර තීරණය කරන්න.
පළමු කරුණ බලන්න සහ කේතීකරණ ප්‍රමිතිය සාමාන්‍යයෙන් සංවර්ධනය කිරීමට හා පිරිපහදු කිරීමට වසර ගණනාවක් ගත වූ ක්‍රියාවලියක් බව අමතක නොකරන්න: පුනරාවර්තන කිහිපයක්, සමහර විට කනිෂ් develop සංවර්ධකයින් සමඟ? ඇත්තටම? ඔබට එක් ජ්‍යෙෂ් senior (ඇත්නම්) සාමාජිකයෙකුගේ මතකය මත විශ්වාසය තැබීමට අවශ්‍යද?
සටහන් තුනක්:
- මගේ මතය අනුව සමහර භාෂාවලට වඩා අඩුපාඩු අනෙක් භාෂාවන්ට වඩා බරපතල ය, උදාහරණයක් ලෙස C ++ හි සමාගම් මට්ටමේ ප්‍රමිතියක් ජාවා වලට වඩා අවශ්ය වේ.
- මෙම තර්ක හැක සම්පූර්ණයෙන්ම (සහ අංකල් බොබ් හේතු අඩු විය හැක අදාළ නොවේ අන්ත ) ඔබ එක් කුඩා කණ්ඩායමක් ඇති තැන ඉතා කුඩා සමාගමක වැඩ කරන්නේ නම්.
- ඔබව කුලියට ගෙන ඇත (කණ්ඩායමක් ලෙස) ඔබ එක් නව ව්යාපෘතියක් සමඟ තනිවම වැඩ කරනු ඇත, එවිට ඔබට එය අමතක වී ඉදිරියට යනු ඇත. මෙම අවස්ථාවේදී ඔබ ගණන් නොගත හැකිය (නමුත් ඔබේ සේවායෝජකයා විසින් ...)