اڳ ڪڏهن به نه ٿيو، ۽ هتي اسان ٻيهر وڃون ٿا!
اسان جي ايندڙ منصوبي تي، اسان مستقبل ۾ مسئلن کان بچڻ لاءِ شروع کان ئي Liquibase استعمال ڪرڻ جو فيصلو ڪيو. جيئن ته اهو نڪتو، نه سڀئي نوجوان ٽيم ميمبر ڄاڻن ٿا ته اهو ڪيئن استعمال ڪجي. مون هڪ اندروني ورڪشاپ منعقد ڪئي، جنهن کان پوء مون هڪ مضمون ۾ تبديل ڪرڻ جو فيصلو ڪيو.
مضمون ۾ مفيد صلاحون ۽ ٽن واضح نقصن جو تفصيل شامل آھي جيڪي توھان ان ۾ پئجي سگھو ٿا جڏھن ڪم ڪرڻ سان لاڳاپيل ڊيٽابيس لڏپلاڻ جا اوزار، خاص طور تي Liquibase. جونيئر ۽ وچين سطحن تي جاوا ڊولپرز لاءِ ڊزائين ڪيل؛ وڌيڪ تجربيڪار ڊولپرز لاءِ اھو ٿي سگھي ٿو سود جي جوڙجڪ ۽ ورجائڻ لاءِ جيڪو گھڻو ڪري اڳي ئي ڄاتو وڃي ٿو.
Liquibase ۽ Flyway جاوا دنيا ۾ لاڳاپن جي جوڙجڪ جي ورزن ڪنٽرول مسئلن کي حل ڪرڻ لاء مکيه مقابلي واري ٽيڪنالاجيون آهن. پهرين هڪ مڪمل طور تي مفت آهي، عملي طور تي اهو اڪثر استعمال لاء چونڊيو ويو آهي، ڇو ته Liquibase اشاعت جي هيرو طور چونڊيو ويو آهي. تنهن هوندي، بيان ڪيل ڪجهه عمل شايد آفاقي هجن، توهان جي ايپليڪيشن جي فن تعمير تي منحصر آهي.
لاڳاپن جي جوڙجڪ جي لڏپلاڻ هڪ مجبور طريقو آهي جيڪو لاڳاپو ڊيٽا اسٽورن جي ڪمزور لچڪ سان معاملو ڪرڻ لاء. او او پي فيشن جي دور ۾، ڊيٽابيس سان ڪم ڪرڻ جي انداز جو مطلب اهو هو ته اسان هڪ ڀيرو اسڪيما کي بيان ڪنداسين ۽ ان کي ٻيهر هٿ نه ڪنداسين. پر حقيقت اها آهي ته شيون تبديل ٿينديون آهن، ۽ ٽيبل جي جوڙجڪ ۾ تبديليون اڪثر گهربل هونديون آهن. قدرتي طور، عمل پاڻ کي دردناڪ ۽ ناپسنديده ٿي سگهي ٿو.
مان توهان جي پروجيڪٽ ۾ لائبريري شامل ڪرڻ لاءِ ٽيڪنالاجي ۽ هدايتن جي وضاحت ۾ وڌيڪ نه ويندس؛ هن موضوع تي ڪافي ڪجهه مضمون لکيا ويا آهن:
ان کان سواء، اتي اڳ ۾ ئي هڪ بهترين مضمون هو مفيد ٽوٽڪا جي موضوع تي:
صلاحون
مان پنهنجا مشورا ۽ رايا شيئر ڪرڻ چاهيان ٿو، جيڪي لڏپلاڻ جي مسئلن کي حل ڪرڻ جي پسين، رت ۽ درد ذريعي پيدا ٿيا.
1. ڪم شروع ڪرڻ کان اڳ، توھان کي پاڻ کي بھترين عملن واري سيڪشن کان واقف ڪرڻ گھرجي Liquibase
سادي پر تمام ضروري شيون بيان ڪيون ويون آهن، جن جي بغير لائبريري استعمال ڪرڻ توهان جي زندگي کي پيچيده ڪري سگهي ٿي. مثال طور، تبديلين کي منظم ڪرڻ لاء هڪ غير منظم طريقي سان جلدي يا بعد ۾ مونجهارو ۽ ڀڄي لڏپلاڻ جو سبب بڻجندو. جيڪڏهن توهان هڪ ئي وقت ڊيٽابيس جي ڍانچي ۽ خدمت جي منطق ۾ باهمي طور تي منحصر تبديلين کي رول نه ڪيو، اتي هڪ وڏو امڪان آهي ته اهو لال ٽيسٽ يا خراب ماحول جي اڳواڻي ڪندو. اضافي طور تي، سرڪاري ويب سائيٽ تي Liquibase استعمال ڪرڻ لاءِ سفارشون شامل آهن رولبڪ اسڪرپٽ جي ترقي ۽ جانچ بابت مکيه لڏپلاڻ واري اسڪرپٽس سان گڏ. خير، مضمون ۾ لڏپلاڻ ۽ رول بيڪ ميڪانيزم جي حوالي سان ڪوڊ جا مثال آهن.
2. جيڪڏهن توهان لڏپلاڻ وارو اوزار استعمال ڪرڻ شروع ڪيو ٿا، ڊيٽابيس جي جوڙجڪ ۾ دستي سڌارن جي اجازت نه ڏيو
جيئن چوڻي آهي ته: ”هڪ ڀيرو پرسيل، هميشه پرسيل. جيڪڏهن توهان جي ايپليڪيشن جو بنياد Liquibase پاران منظم ٿيڻ شروع ٿئي ٿو، ڪنهن به دستي تبديلين کي فوري طور تي هڪ غير مطابقت واري حالت ڏانهن وٺي ويندي آهي، ۽ تبديلين ۾ اعتماد جي سطح صفر ٿي ويندي آهي. امڪاني خطرن ۾ شامل آهن ڪيترائي ڪلاڪ خرچ ٿيل ڊيٽابيس کي بحال ڪرڻ؛ بدترين حالت ۾، هڪ مئل سرور. جيڪڏهن توهان وٽ آهي ”پراڻو اسڪول“ ڊي بي اي آرڪيٽيڪٽ توهان جي ٽيم تي، صبر سان ۽ سوچي سمجهي هن کي ٻڌايو ته ڪيئن خراب شيون ٿينديون جيڪڏهن هو صرف هڪ مشروط SQL ڊولپر کان پنهنجي سمجھ مطابق ڊيٽابيس کي ايڊٽ ڪري.
3. جيڪڏھن تبديليءَ وارو سيٽ اڳي ئي مخزن ۾ پئجي ويو آھي، ترميم ڪرڻ کان پاسو ڪريو
جيڪڏهن ڪنهن ٻئي ڊولپر هڪ ڇڪيو ۽ هڪ تبديلي لاڳو ڪئي، جنهن کي بعد ۾ ايڊٽ ڪيو ويندو، هو ضرور توهان کي هڪ مهربان لفظ سان ياد ڪندو جڏهن هن کي ايپليڪيشن شروع ڪرڻ ۾ غلطي ملندي. جيڪڏهن تبديلين کي تبديل ڪندي ڪنهن به طرح ترقي ۾ لڪي وڃي ٿي، توهان کي هاٽ فڪسس جي پرچي سلپ جي پيروي ڪرڻي پوندي. مسئلو جو بنياد hash sum جي تبديلين جي تصديق تي مبني آهي - Liquibase جو بنيادي ميڪانيزم. تبديليءَ واري ڪوڊ کي تبديل ڪرڻ وقت، هيش جي رقم تبديل ٿي ويندي آهي. تبديلين کي تبديل ڪرڻ صرف ممڪن آهي جڏهن اهو ممڪن آهي ته سڄي ڊيٽابيس کي شروع ڪرڻ کان سواء ڊيٽا کي وڃائڻ کان سواء. انهي صورت ۾، SQL يا XML ڪوڊ کي ريفيڪٽر ڪري سگھي ٿو، ان جي ابتڙ، زندگي کي آسان بڻائي ۽ لڏپلاڻ کي وڌيڪ پڙهڻ لائق بڻائي سگھي ٿو. ھڪڙو مثال ھڪڙي صورتحال آھي جتي، ايپليڪيشن جي شروعات ۾، ماخذ ڊيٽابيس جي اسڪيما تي ٽيم جي اندر اتفاق ڪيو ويو.
4. جيڪڏهن ممڪن هجي ته ڊيٽابيس جي بيڪ اپ جي تصديق ڪريو
هتي، مان سمجهان ٿو، هر شيء واضح آهي. جيڪڏهن اوچتو لڏپلاڻ ناڪام ٿي وئي، هر شيء واپس ٿي سگهي ٿو. Liquibase وٽ تبديلين کي واپس آڻڻ لاءِ ھڪڙو اوزار آھي، پر رولبڪ اسڪرپٽ پڻ ڊولپر پاڻ لکيا آھن، ۽ انھن کي ساڳي امڪان سان مسئلو ٿي سگھي ٿو جيئن مکيه تبديلين جي اسڪرپٽ سان. هن جو مطلب آهي ته ان کي ڪنهن به صورت ۾ بيڪ اپ سان محفوظ ادا ڪرڻ لاء مفيد آهي.
5. استعمال ڪريو ثابت ٿيل ڊيٽابيس بيڪ اپ ترقي ۾، جيڪڏهن ممڪن هجي
جيڪڏهن اهو معاهدن ۽ رازداري سان تضاد نٿو رکي، ڊيٽابيس ۾ ڪو به ذاتي ڊيٽا نه آهي، ۽ اهو ٻه سج جيترو وزن نٿو رکي - ان کي لائيو لڏپلاڻ سرور تي استعمال ڪرڻ کان اڳ، توهان چيڪ ڪري سگهو ٿا ته اهو ڪيئن ڪم ڪندو ڊولپر جي مشين تي ۽ حساب ڪتاب لڏپلاڻ دوران امڪاني مسئلن جو تقريبا 100٪.
6. ٽيم تي ٻين ڊولپرز سان رابطو ڪريو
هڪ منظم ترقي واري عمل ۾، ٽيم تي هرڪو ڄاڻي ٿو جيڪو ڪير ڪري رهيو آهي. حقيقت ۾، اهو اڪثر نه هوندو آهي، تنهن ڪري، جيڪڏهن توهان پنهنجي ڪم جي حصي طور ڊيٽابيس جي جوڙجڪ ۾ تبديليون تيار ڪري رهيا آهيو، اهو مشورو آهي ته اضافي طور تي پوري ٽيم کي ان بابت مطلع ڪيو وڃي. جيڪڏهن ڪو ماڻهو متوازي ۾ تبديليون ڪري رهيو آهي، توهان کي احتياط سان منظم ڪرڻ گهرجي. اهو ڪم ختم ڪرڻ کان پوءِ ساٿين سان ڳالهائڻ جي قابل آهي، نه صرف شروعات ۾. تبديلين سان ڪيتريون ئي امڪاني مسئلا حل ڪري سگھجن ٿيون ڪوڊ جائزو اسٽيج تي.
7. سوچيو ته توهان ڇا ڪري رهيا آهيو!
اهو لڳي ٿو ته خود واضح مشورو جيڪو ڪنهن به صورتحال تي لاڳو ٿئي ٿو. بهرحال، ڪيترن ئي مسئلن کان بچي سگهجي ها جيڪڏهن ڊولپر هڪ ڀيرو ٻيهر تجزيو ڪري ها ته هو ڇا ڪري رهيو آهي ۽ اهو ڇا اثر انداز ڪري سگهي ٿو. لڏپلاڻ سان ڪم ڪرڻ هميشه اضافي ڌيان ۽ درستگي جي ضرورت آهي.
ارَ
اچو ته ھاڻي ڏسون انھن عام پيچرن کي جن ۾ توھان پئجي سگھوٿا جيڪڏھن توھان مٿي ڏنل مشوري تي عمل نه ڪيو، ۽ ڇا، بلڪل، توھان کي ڪرڻ گھرجي؟
صورتحال 1: ٻه ڊولپر هڪ ئي وقت نئين تبديليون شامل ڪرڻ جي ڪوشش ڪري رهيا آهن
Vasya ۽ Petya هڪ ٻئي جي باري ۾ ڄاڻڻ کان سواء، هڪ changeset ورجن 4 ٺاهڻ چاهيو ٿا. انهن ڊيٽابيس جي جوڙجڪ ۾ تبديليون ڪيون ۽ مختلف تبديلين واري فائلن سان ڇڪڻ جي درخواست جاري ڪئي. عمل جي هيٺين ميڪانيزم تجويز ڪيل آهي:
فيصلو ڪيئن ڪجي
- ڪنهن به طرح، ساٿين کي ان حڪم تي متفق ٿيڻ گهرجي جنهن ۾ انهن جي تبديلين کي وڃڻ گهرجي، مثال طور، پيٽين کي پهريان لاڳو ڪيو وڃي.
- ڪنهن کي ٻئي کي پاڻ ۾ شامل ڪرڻ گهرجي ۽ ورجن 5 سان واسيا جي تبديلين کي نشانو بڻائڻ گهرجي. اهو چيري پِڪ يا صاف مرج ذريعي ڪري سگهجي ٿو.
- تبديلين کان پوءِ، توھان کي ضرور جانچڻ گھرجي ته ڪيل عملن جي صحيحيت.
حقيقت ۾، Liquibase ميڪانيزم توهان کي اجازت ڏيندو ته توهان وٽ ٻه نسخو 4 تبديليون مخزن ۾، تنهنڪري توهان هر شيء کي ڇڏي سگهو ٿا جيئن آهي. اهو آهي، توهان وٽ صرف ٻه تبديليون هونديون نسخو 4 ۾ مختلف نالن سان. هن طريقي سان، اهو بعد ۾ ڊيٽابيس جي نسخن کي نيوڻ تمام ڏکيو ٿيندو.
ان کان سواء، Liquibase، hobbits جي گھر وانگر، ڪيترائي راز رکي ٿو. انهن مان هڪ آهي validCheckSum Key، جيڪو ورجن 1.7 ۾ ظاهر ٿيو ۽ توهان کي اجازت ڏئي ٿو هڪ صحيح هيش ويليو مقرر ڪرڻ لاءِ هڪ مخصوص تبديليءَ لاءِ، قطع نظر ته ڊيٽابيس ۾ ڇا محفوظ آهي. دستاويزي هيٺين چوي ٿو:
ھڪ چيڪسم شامل ڪريو جيڪو صحيح سمجھيو وڃي ھن تبديلي سيٽ لاءِ، ان کان سواءِ جيڪو ڊيٽابيس ۾ ذخيرو ٿيل آھي. بنيادي طور تي استعمال ڪيو ويندو آھي جڏھن توھان کي تبديل ڪرڻ جي ضرورت آھي تبديلي سيٽ ۽ توھان نٿا چاھيو ته غلطيون ڊيٽابيس تي اڇلايون وڃن جن تي اھو اڳ ۾ ئي ھليو ويو آھي (سفارش ٿيل عمل نه آھي)
ها، ها، اهو طريقو سفارش نه آهي. پر ڪڏهن ڪڏهن هڪ مضبوط روشني جادوگر پڻ اونداهي ٽيڪنالاجي کي ماهر ڪري ٿو
صورتحال 2: لڏپلاڻ جيڪا ڊيٽا تي منحصر آهي
اچو ته فرض ڪريون ته توهان کي لائيو سرورز مان ڊيٽابيس بيڪ اپ استعمال ڪرڻ جي صلاحيت نه آهي. پيٽيا هڪ تبديلي ٺاهي، ان کي مقامي طور تي آزمايو ۽، مڪمل اعتماد سان ته هو صحيح هو، ڊولپر ڏانهن ڇڪڻ جي درخواست ڪئي. صرف ان صورت ۾، منصوبي جي اڳواڻي واضح ڪئي ته ڇا پيٽيا ان کي چڪاس ڪيو، ۽ پوء ان کي شامل ڪيو. پر ڊولپمينٽ سرور تي تعیناتي ٿي وئي.
حقيقت ۾، اهو ممڪن آهي، ۽ ڪو به هن کان محفوظ ناهي. اهو ٿئي ٿو جيڪڏهن ٽيبل جي جوڙجڪ ۾ تبديليون ڪنهن به طرح ڊيٽابيس مان مخصوص ڊيٽا سان ڳنڍيل آهن. ظاهر آهي، جيڪڏهن پيٽيا جو ڊيٽابيس صرف ٽيسٽ ڊيٽا سان ڀريل آهي، ته پوءِ اهو شايد سڀني مسئلن جي ڪيسن کي ڍڪي نه سگهي. مثال طور، جڏهن هڪ ٽيبل کي حذف ڪيو وڃي، اهو ظاهر ٿئي ٿو ته فارين ڪي جي طرفان ٻين جدولن ۾ رڪارڊ موجود آهن جيڪي هڪ ڊليٽ ٿيل رڪارڊ سان لاڳاپيل آهن. يا جڏهن هڪ ڪالمن جي قسم کي تبديل ڪندي، اهو ظاهر ٿئي ٿو ته ڊيٽا جو 100٪ نئين قسم ۾ تبديل نٿو ڪري سگهجي.
فيصلو ڪيئن ڪجي
- لکو خاص اسڪرپٽ جيڪي هڪ ڀيرو لڏپلاڻ سان گڏ استعمال ڪيا ويندا ۽ ڊيٽا کي مناسب شڪل ۾ آڻيو. هي هڪ عام طريقو آهي ته ڊيٽا جي منتقلي جي مسئلي کي حل ڪرڻ لاءِ نئين ڍانچي کي لڏپلاڻ لاڳو ڪرڻ کان پوءِ، پر ڪجهه اهڙي ئي نموني اڳ لاڳو ڪري سگهجي ٿو، خاص ڪيسن ۾. اهو رستو، يقينا، هميشه دستياب ناهي، ڇو ته لائيو سرورز تي ڊيٽا کي تبديل ڪرڻ خطرناڪ ۽ اڃا به تباهي ٿي سگهي ٿو.
- ٻيو ڏکيو طريقو موجوده تبديلين کي تبديل ڪرڻ آهي. مشڪل اهو آهي ته سڀئي ڊيٽابيس جتي اهو اڳ ۾ ئي ان جي موجوده فارم ۾ لاڳو ڪيو ويو آهي بحال ڪرڻو پوندو. اهو بلڪل ممڪن آهي ته پوري پس منظر واري ٽيم کي مجبور ڪيو ويندو ته مقامي طور تي ڊيٽابيس کي شروع کان ٻاهر ڪڍو.
- ۽ سڀ کان وڌيڪ عالمگير طريقو اهو آهي ته مسئلي کي ڊيٽا سان گڏ ڊولپر جي ماحول ڏانهن منتقل ڪرڻ، ساڳئي صورتحال کي ٻيهر ٺاهڻ ۽ هڪ نئين تبديلي شامل ڪرڻ، ٽوٽل هڪ ڏانهن، جيڪو مسئلو کي ختم ڪري ڇڏيندو.
عام طور تي، وڌيڪ ڊيٽابيس پيداوار سرور ڊيٽابيس جي جوڙجڪ ۾ هڪجهڙائي آهي، گهٽ موقعو ته لڏپلاڻ سان مسئلا تمام گهڻو پري ويندا. ۽، يقينا، ان کان اڳ جو توهان مخزن ڏانهن تبديلي موڪلي، توهان کي ڪيترائي ڀيرا سوچڻ گهرجي ته ڇا اهو ڪجهه به ٽوڙيندو.
صورتحال 3. Liquibase پيداوار ۾ وڃڻ کان پوءِ استعمال ٿيڻ شروع ٿئي ٿو
فرض ڪريو ٽيم جي اڳواڻ پيٽيا کي چيو ته Liquibase منصوبي ۾ شامل ڪري، پر پروجيڪٽ اڳ ۾ ئي پيداوار ۾ آهي ۽ اتي موجود ڊيٽابيس جي جوڙجڪ آهي.
ان جي مطابق، مسئلو اهو آهي ته ڪنهن به نئين سرور يا ڊولپر مشينن تي، انهن جدولن کي شروع کان ٻيهر ٺاهڻ گهرجي، ۽ موجوده ماحول کي هڪ جهڙي حالت ۾ رهڻ گهرجي، نئين تبديلين کي قبول ڪرڻ لاء تيار آهي.
فيصلو ڪيئن ڪجي
اتي پڻ ڪيترائي طريقا آھن:
- پهريون ۽ سڀ کان وڌيڪ واضح آهي ته هڪ الڳ اسڪرپٽ هجڻ گهرجي جيڪو دستي طور تي لاڳو ڪيو وڃي جڏهن نئين ماحول کي شروع ڪيو وڃي.
- ٻيو گهٽ پڌرو آهي، هڪ Liquibase لڏپلاڻ آهي ته ٻئي Liquibase جي حوالي سان آهي، ۽ ان کي لاڳو. توهان هتي Liquibase جي حوالي سان وڌيڪ پڙهي سگهو ٿا: . عام طور تي، هي هڪ دلچسپ ميڪانيزم آهي جيڪو ڪاميابي سان استعمال ڪري سگهجي ٿو، مثال طور، جاچ لاء.
- ٽيون رستو ڪيترن ئي مرحلن تي مشتمل آهي. پهرين، موجوده جدولن لاء هڪ لڏپلاڻ پيدا ٿيڻ گهرجي. پوء ان کي لازمي طور تي ڪجهه ماحول تي لاڳو ڪيو وڃي ۽ اهڙيء طرح ان جي هش رقم حاصل ڪئي ويندي. اڳيون قدم اسان جي غير خالي سرور تي خالي Liquibase جدولن کي شروع ڪرڻ آهي، ۽ تبديلين جي استعمال جي تاريخ سان گڏ ٽيبل ۾، توهان دستي طور تي ڊيٽابيس ۾ موجود تبديلين سان "جيئن لاڳو ٿيل" تبديلين بابت رڪارڊ رکي سگهو ٿا. . اهڙيء طرح، هڪ موجوده سرور تي، تاريخ جي ڳڻپ شروع ٿيندي ورزن 2 کان، ۽ سڀئي نوان ماحول هڪجهڙائي سان هلندا.
صورتحال 4. لڏپلاڻ تمام وڏي ٿي وڃي ٿي ۽ مڪمل ٿيڻ جو وقت نه آهي
سروس ڊولپمينٽ جي شروعات ۾، ضابطي جي طور تي، Liquibase خارجي انحصار جي طور تي استعمال ڪيو ويندو آهي، ۽ سڀني لڏپلاڻ تي عمل ڪيو ويندو آهي جڏهن ايپليڪيشن شروع ٿئي ٿي. بهرحال، وقت سان گڏ، توهان هيٺ ڏنل ڪيسن تي ٿڪجي سگهو ٿا:
- لڏپلاڻ تمام وڏا ٿي ويندا آهن ۽ مڪمل ٿيڻ ۾ ڊگهو وقت وٺندو آهي.
- ورهايل ماحول ۾ لڏپلاڻ جي ضرورت آهي، مثال طور، ڪيترن ئي ڊيٽابيس سرور مثالن تي هڪ ئي وقت.
انهي صورت ۾، لڏپلاڻ کي تمام گهڻي عرصي تائين لاڳو ڪرڻ جي نتيجي ۾ وقت ختم ٿي ويندو جڏهن ايپليڪيشن شروع ٿيندي. اضافي طور تي، لڏپلاڻ لاڳو ڪرڻ هر ايپليڪيشن مثال لاءِ الڳ الڳ ٿي سگھي ٿو مختلف سرورن جي هم وقت سازي کان ٻاهر.
فيصلو ڪيئن ڪجي
اهڙين حالتن ۾، توهان جو منصوبو اڳ ۾ ئي وڏو آهي، شايد هڪ بالغ به، ۽ Liquibase هڪ الڳ خارجي اوزار طور ڪم ڪرڻ شروع ڪري ٿو. حقيقت اها آهي ته Liquibase هڪ لائبريري جي طور تي هڪ جار فائل ۾ مرتب ڪيو ويو آهي، ۽ هڪ پروجيڪٽ جي اندر يا آزاد طور تي انحصار طور ڪم ڪري سگهي ٿو.
اسٽينڊل موڊ ۾، توهان لڏپلاڻ جي عمل کي پنهنجي CI/CD ماحول ڏانهن يا توهان جي سسٽم جي منتظمين ۽ مقرري جي ماهرن جي مضبوط ڪلهن تي ڇڏي سگهو ٿا. هن کي ڪرڻ لاءِ توهان کي ضرورت پوندي Liquibase ڪمانڊ لائن . هن موڊ ۾، سڀني ضروري لڏپلاڻ کان پوء ايپليڪيشن کي لانچ ڪرڻ ممڪن آهي.
ٿڪل
حقيقت ۾، ڊيٽابيس جي لڏپلاڻ سان ڪم ڪرڻ دوران ڪيترائي وڌيڪ نقصان ٿي سگهن ٿا، ۽ انهن مان گھڻن کي تخليقي انداز جي ضرورت آهي. اهو سمجهڻ ضروري آهي ته جيڪڏهن توهان اوزار صحيح طريقي سان استعمال ڪيو، انهن مان اڪثر نقصان کان بچي سگهجي ٿو. خاص طور تي، مون کي سڀني فهرستن جي مسئلن سان معاملو ڪرڻو پيو مختلف شڪلن ۾، ۽ انهن مان ڪجهه منهنجي غلطين جو نتيجو هو. گهڻو ڪري اهو ٿئي ٿو، يقينا، غفلت جي ڪري، پر ڪڏهن ڪڏهن هن اوزار کي استعمال ڪرڻ جي مجرمانه ناڪامي جي ڪري.
جو ذريعو: www.habr.com