Testing your software system with resilient randomized tests – The focused generalist

மாற்றத்திற்கு எதிரான பின்னடைவு மற்றும் பின்னடைவைத் தவிர்ப்பது

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

இருந்து மோனிகா லென்ட் மூலம் நெகிழ்ச்சியான முகப்பு கட்டிடக்கலையை உருவாக்குதல்

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

ஐபிஎம் மூலம்

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

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

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

அலகு சோதனை மூலம் சிறிய துண்டுகளை சோதிக்கிறது

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

அடிப்படையில், ஒரு யூனிட் சோதனை என்பது எங்கள் பயன்பாட்டின் ஒரு சிறிய பகுதியைத் துரிதப்படுத்துகிறது மற்றும் அதன் நடத்தையை மற்ற பகுதிகளிலிருந்து சுயாதீனமாக சரிபார்க்கிறது. ஒரு பொதுவான யூனிட் சோதனை 3 கட்டங்களைக் கொண்டுள்ளது: முதலில், அது சோதனை செய்ய விரும்பும் பயன்பாட்டின் ஒரு சிறிய பகுதியை துவக்குகிறது (சோதனையின் கீழ் உள்ள கணினி அல்லது SUT என்றும் அழைக்கப்படுகிறது), பின்னர் இது சோதனையின் கீழ் உள்ள கணினிக்கு சில தூண்டுதலைப் பயன்படுத்துகிறது (பொதுவாக ஒரு அழைப்பதன் மூலம் அதன் மீதான முறை), இறுதியாக, அது விளைந்த நடத்தையைக் கவனிக்கிறது. கவனிக்கப்பட்ட நடத்தை எதிர்பார்ப்புகளுடன் இணக்கமாக இருந்தால், யூனிட் சோதனை தேர்ச்சி பெறுகிறது, இல்லையெனில், அது தோல்வியுற்றது, சோதனையின் கீழ் உள்ள கணினியில் எங்காவது சிக்கல் இருப்பதைக் குறிக்கிறது. இந்த மூன்று அலகு சோதனை கட்டங்கள் ஏற்பாடு, சட்டம் மற்றும் உறுதி, அல்லது வெறுமனே AAA என்றும் அழைக்கப்படுகின்றன.

டாப்டால் மூலம்

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

எந்தவொரு தீவிரமான மென்பொருள் உருவாக்குநரின் கருவிப்பெட்டியிலும் அலகு சோதனை ஒரு இன்றியமையாத கருவியாகும். […] அலகு சோதனைகள் மிகவும் எளிதானது; யூனிட் சோதனையை சிக்கலாக்கும் மற்றும் விலையுயர்ந்த சிக்கலை அறிமுகப்படுத்தும் உண்மையான சிக்கல்கள், மோசமாக வடிவமைக்கப்பட்ட, சோதிக்க முடியாத குறியீட்டின் விளைவாகும். […] யூனிட் சோதனைகளை எழுதுவது மற்றும் சோதிக்கக்கூடிய குறியீட்டை உருவாக்குவது என்பது சோதனையை குறைவான தொந்தரவை ஏற்படுத்துவது மட்டுமல்ல, குறியீட்டை மிகவும் வலுவாகவும் பராமரிக்கவும் எளிதாக்குகிறது.

டாப்டால் மூலம்

உங்கள் விவரக்குறிப்புகளைச் சோதிக்க சொத்து சோதனை

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

சொத்து அடிப்படையிலான சோதனைகள் எப்போதும் உண்மையாக இருக்க வேண்டிய சொத்தின் அம்சங்களைச் சோதிக்க வடிவமைக்கப்பட்டுள்ளன. நீங்கள் சோதிக்க விரும்பும் ஒவ்வொரு மதிப்பிற்கும் வெவ்வேறு சோதனையை எழுதுவதற்குப் பதிலாக, ஒரே சோதனைக்குள் பல உள்ளீடுகளை நிரல்படுத்தவும் சோதிக்கவும் அவை அனுமதிக்கின்றன. சொத்து அடிப்படையிலான சோதனையானது ஹாஸ்கெல் நூலகத்தால் பிரபலப்படுத்தப்பட்டது விரைவு சோதனை. சொத்து அடிப்படையிலான சோதனைகள் போன்ற சோதனைகளில் ஃபஸ் சோதனை அல்லது உதாரண அட்டவணைகளின் பயன்பாடு ஆகியவை அடங்கும் ATDD/BDD-பாணி சோதனை.

டெக் பெக்கனில் இருந்து

செயல்பாட்டின் பண்புகளில் கவனம் செலுத்தும் சோதனைகளை உருவாக்குவதே பதில் – “தேவைகள்”. இந்த பண்புகள் எந்தவொரு சரியான செயலாக்கத்திற்கும் உண்மையாக இருக்க வேண்டும்.

வேடிக்கை மற்றும் லாபத்திற்காக F# இலிருந்து

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

உங்கள் வகைகளின் மூலம் உங்கள் விவரக்குறிப்புகளைப் படம்பிடித்தல்

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

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

சீரற்ற உள்ளீட்டைக் கொண்டு சோதனை சாதனத்தை உருவாக்குதல்

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

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

விக்கிபீடியா

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

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

NET இல் பிரபலமான நூலகம் உள்ளது, அதை நீங்கள் பயன்படுத்தலாம் FsCheck.

FsCheck என்பது .NET நிரல்களை தானாக சோதிக்கும் ஒரு கருவியாகும். புரோகிராமர் நிரலின் விவரக்குறிப்பை, செயல்பாடுகள், முறைகள் அல்லது பொருள்கள் திருப்திப்படுத்த வேண்டிய பண்புகளின் வடிவத்தில் வழங்குகிறார், மேலும் FsCheck அதன்பிறகு, அதிக எண்ணிக்கையிலான சீரற்ற முறையில் உருவாக்கப்பட்ட நிகழ்வுகளில் பண்புகள் வைத்திருக்கின்றன என்பதை சோதிக்கிறது. பண்புகளை எழுதும் போது, ​​நீங்கள் உண்மையில் உங்கள் நிரலின் சோதனை விவரக்குறிப்பை எழுதுகிறீர்கள். விவரக்குறிப்புகள் F#, C# அல்லது VB இல் வெளிப்படுத்தப்படுகின்றன

FsCheck read.me

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

எ.கா: RPG-பாணி விளையாட்டு

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

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

நீங்கள் களஞ்சியத்தைக் காணலாம் இங்கே.

கடையில் இருந்து வாங்குதல்

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

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

type GameUnit = {
    Name: string
    Lvl: int16
    Job: CharacterJob
    CurrentState: CharacterState
    TotalXp: int 
    SkillPoints: int16
    Equipment: Equipment list
    Consummables: ConsumableItem list
}
type GameTestFixture = {
    Party: GameUnit list
    Store: GameStore
    PartyInventory: Inventory
}
let createSingleValueWithGenerator<'Value> (generator: Gen<'Value'>) =
    generator |> Gen.sample 1 1 |> List.head

let unitPartyFixture =
    let generateGameUnit() =
        let equipmentListValues = [0 .. random.Next(1, EquipmentSlotLimit)]
        let consummableItemListValues = [0 .. random.Next(1, ConsummableItemSlotLimit)]
        {
            Name = createSingleValueWithGenerator<string> stringGenerator
            Lvl = createSingleValueWithGenerator<int16> int16Generator
            CurrentState = createSingleValueWithGenerator<CharacterState> characterStateGenerator
            TotalXp = random.Next(0, MaxExperiencePointBeforeLevelingUp)
            SkillPoints = random.Next(0, MaxSkillPoints)
            Job = createSingleValueWithGenerator<CharacterJob> characterJobGenerator
            Equipment = List.map(fun _ -> createSingleValueWithGenerator<Equipment> equipmentGenerator) equipmentListValues
            Consummables = List.map(fun _ -> createSingleValueWithGenerator<ConsumableItem> consummableItemGenerator) consummableItemListValues
        }

    let partySize = random.Next(MinPartySize, MaxPartySize)
    List.map(fun _ -> generateGameUnit()) [1..partySize]

மேலே உள்ள துணுக்கில், 3 முதல் 12 யூனிட்கள் கொண்ட போலி பார்ட்டிக்கான ஃபிக்ஸ்ச்சர் இப்போது எங்களிடம் உள்ளது. பின்னர் நாம் ஒரு வணிகக் கடையை அமைக்க வேண்டும், அதில் இருந்து நாம் நுகர்வு பொருட்கள் (அதாவது ஒரு மருந்து), ஆயுதங்கள் (அதாவது ஒரு வாள்) & ஆயுதங்கள் (அதாவது ஒரு ஹெல்மெட்) வாங்க முடியும்.

முன்பு, நாங்கள் தேவைகளைப் பற்றி பேசினோம். இங்கே என்ன பயன்படுத்தலாம் என்று பார்ப்போம். ஒரு வாடிக்கையாளர் (கட்சி உறுப்பினரைப் படிக்கவும்), ஒரு கடைக்குள் நுழையும் போது, ​​ஒரு பொருளை வாங்குவதற்கு அவர்கள் மதிக்க வேண்டிய பல கடமைகள் உள்ளன:

  • குழு இருப்பு நிரம்பியதா?
  • குழு இருப்பு அதன் எடை வரம்பில் உள்ளதா?
  • குறிப்பிட்ட யூனிட் இன்னும் உபகரணங்களை வாங்க முடியுமா?
  • குறிப்பிட்ட யூனிட் இன்னும் நுகர்வு பொருட்களை வாங்க முடியுமா?

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

type PurchaseFromStore = (int16 * GameItem) -> Inventory -> GameUnit -> (Inventory * GameUnit)

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

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

let purchaseFromStore : PurchaseFromStore =
        fun itemAndQty inventory gameUnit ->
            let quantityInt = (fst itemAndQty) |> int
            let itemToBePurchased = (snd itemAndQty)

            if gameUnit.CanPurchaseEquipment |> not then
                (inventory, gameUnit)

            elif (quantityInt + gameUnit.Equipment.Length) < EquipmentSlotLimit then
                (inventory, gameUnit)

            elif (quantityInt |> float) * itemToBePurchased.Weight + inventory.CurrentWeight < inventory.MaxWeight then
                (inventory, gameUnit)

            else
                storeFunds <- storeFunds + (fst itemAndQty)

                let totalPurchaseOrder = itemToBePurchased.Price * quantityInt
                let addedWeight = itemToBePurchased.Weight * (quantityInt |> float)
                let gameUnit =
                    match itemToBePurchased with
                    | Consumable consummable ->
                        let storeItems = [1..quantityInt] |> List.map(fun _ -> consummable)

                        { gameUnit with Consummables = gameUnit.Consummables |> List.append storeItems }

                    | Equipement equipment ->
                        match equipment with 
                        | Weapon weapon ->
                            let storeItems = [1..quantityInt] |> List.map(fun _ -> Weapon weapon)

                            { gameUnit with Equipment = gameUnit.Equipment |> List.append storeItems }

                        | Armor armor ->
                            let storeItems = [1..quantityInt] |> List.map(fun _ -> Armor armor)

                            { gameUnit with Equipment = gameUnit.Equipment |> List.append storeItems }

                let inventory = {
                    inventory with 
                        Funds = inventory.Funds - (totalPurchaseOrder |> int16)
                        CurrentWeight = inventory.CurrentWeight + addedWeight
                }

                (inventory, gameUnit)

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

let gameFixture = {
    Party = unitPartyFixture
    Store = storeFixture
    PartyInventory = inventoryFixture
}

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

இறுதியான குறிப்புகள்

முழுக் கட்டுரையும் சீரற்ற சோதனை உள்ளீட்டைப் பயன்படுத்துவதிலும், உங்கள் சோதனைகளை விரைவாக உருவாக்க உதவும் ஒரு மாறாத சோதனை சாதனத்தை உருவாக்குவதிலும் கவனம் செலுத்துகிறது. ஆம், கோட்பேஸ் .NET மற்றும் குறிப்பாக F# இல் எழுதப்பட்டுள்ளது, ஆனால் இது பைதான், சி++, சி# அல்லது ரஸ்ட் மற்றும் ஜாவாஸ்கிரிப்ட் போன்ற எந்த வகையான டூரிங்-முழுமையான மொழிகளுக்கும் பொருந்தும்.

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

F# மற்றும்/அல்லது செயல்பாட்டு நிரலாக்கத்திற்கு புதியவர்கள், அடுத்த பகுதியில் பட்டியலிடப்பட்டுள்ள கடைசி 3 குறிப்புகளை விரைவாகப் பார்க்க உங்களை அழைக்கிறேன்!

உங்களிடம் கருத்துகள் அல்லது கேள்விகள் இருந்தால் தொடர்பு கொள்ள தயங்க வேண்டாம் 🙂

பயனுள்ள குறிப்புகள்

எனது தொழில்நுட்ப பயணத்தை நீங்கள் தொடரலாம் ட்விட்டர் & கிட்ஹப் மற்றும் பதிவு எனது வலைப்பதிவிற்கு.

அடுத்த முறை வரை,

கெவின் ஏ.

Leave a Comment