https://virgool.io/feed/@dndshmdr علاقه مند به برنامه نویسی اندروید, پایتون و هر چیزی که مربوط به کامپیوتر باشه. fa 2026-06-16 12:25:10 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@dndshmdr https://virgool.io/@dndshmdr/%D8%AC%D9%86%DA%AF-%D8%A8%D8%A7-%D8%AC%D8%A7%D9%88%D8%A7-%D8%A7%D8%B3%DA%A9%D8%B1%DB%8C%D9%BE%D8%AA-%D8%AA%D9%84%DA%AF%D8%B1%D8%A7%D9%81-%DA%86%DB%8C-%DB%B2-xmwo0wdxhk2x رسیدیم به بخش دوم که تلگراف چی مهربون میخواد به ما کمک کنه بهتر جاوا اسکریپت یاد بگیریم. اگر قسمت قبل رو ندیدید حتما حتما قبل از این بخش بخونید (مخصوصا اگر مبتدی هستید) چون چند تا متد مهم رو معرفی کردم (متد های split, map , trim , join) و در ضمن متدی نوشتیم که تقریبا نصف جواب این چالشه. خلاصه این پست در ادامه پست قبلی است. و البتهاین مسئله یک قسمت سوم رو هم داره که واقعا سخت میشه و میخوایم صفر و یک های مربوط به یه آدم مبتدی و ××بی نظم×× رو ترجمه کنیم. https://vrgl.ir/Pb3Fe یادآوری regexp:از regexp یا regex یا که مخفف regular expression هست برای پیدا کردن یک الگو در متن استفاده میکنیم. به این صورت که الگو رو به شکل تعدادی از کاراکتر های با معنی بین /.../ قرار میدیم و با استفاده از متد match دنبال این الگو ها میگردیم. این متد یک ارایه از قسمت هایی از متن که با الگو مطابقت داره رو برمیگردونه. اگه دوست دارید کامل تر باهاش اشنا بشید این منبع رو شدیدا توصیه میکنم.تعدادی از کاراکتر های با معنی که در این قسمت نیاز داریم:"+" : یعنی اگر یکی یا بیشتر از کاراکتر قبلش وجود داشت با regex مطابقت داره. مثلا /+x/ قسمت هایی از متن که در اون یک یا چند x پشت سر هم وجود داره رو انتخاب میکنه.'^' و '$': '^' اول خط و "$" آخر خط رو نشون میده. به این ترتیب که اگه دنبال یک الگو در اول متن باشیم از '^' و اگر دنبال یک الگو در اخر متن باشیم از '$' استفاده میکنیم. پس /+0^/ یعنی اگر اول متن یکی یا بیشتر "0" دیدی و /$+0/ یعنی اگر آخر خط یکی یا بیشتر '0' دیدی اون ها رو انتخاب کن یا به عبارتی این بخش ها با regex مطابق هستند. '|' : این کاراکتر وجود اختیار رو بیان میکنه. به طوری که هر کدوم از regex های چپ و راست اون منطبق شد همون رو اجرا میکنه. یه جور هایی یعنی " یا ".نکته: از آپشن g معنی global هم استفاده کردیم تا همه قسمت هایی که با regex سازگاری دارند رو انتخاب کنه. در غیر این صورت متد match اولین مطابقت رو انتخاب میکنه و فرایند جست و جو متوقف میشه.و چیز های ریگه که به مرور توضیح میدم...ساموئل مورس- مخترع تلگرافتلگراف برقی بر اساس دو سیم و یک دکمه کار میکنه، به طوری که وقتی دکمه فشار داده میشه، سیم ها به هم برخورد میکنند و این برخورد جریان الکتریکی ای ایجاد میکنه که از طریق کابل به سایر نقاط جهان منتقل میشه. در واقع چیزی که اون طرف دنیا دریافت میشه ترکیبی از صفر و یک هاست:1100110011001100000011000000111111001100111111001111110000000000000011001111110011111100111111000000110011001111110000001111110011001100000011یک ها مربوط به زمانیه که دکمه فشار داده شده و صفر ها مربوط به زمانیه که دکمه رها شده.مدت زمانی که این دکمه فشار داده میشه مشخص میکنه که نقطه است یا خط(دش). به این صورت که یک فشار کوتاه، نقطه ترجمه میشود و یک فشار طولانی، خط.برای فرستادن کد مورس از طریق تلگراف برقی قوانینی وجود داره :"نقطه" - فشردن دکمه به اندازه یک واحد است."خط" - فشردن دکمه به اندازه سه واحد است.توقف بین نقطه و خط ها در یک کاراکتر - یک واحد است.توقف بین کاراکتر های یک کلمه - سه واحد است.توقف بین دو کلمه - هفت واحد است.به این ترتیب میتونیم کد مورس رو از طریق صفر و یک ارسال کنیم. ولی چیزی که توی استاندارد مشخص نشده "واحد" یا "ضریب" است. برای یک فرد حرفه ای این واحد میتونه نیم ثانیه باشه و برای یک مبتدی که سرعتش کند تره میتونه یک ثانیه باشه. چالش اصلی ما برای حل این مسئله پیدا کردن واحده.پس باید دو تا تابع بسازیم. اول تابع (decodeBits(bits که اول واحد رو پیدا میکنه و صفر و یک ها رو به درستی به نقطه و خط تبدیل میکنه و string حاوی کد مورس رو تحویل میده.نکته ای که باید بهش توجه کنید اینه که اول و آخر هر پیام ممکنه تعدادی صفر پشت سر هم باشه که در معنای پیام تاثیر نداره و قبل از انجام هر کاری باید اونها رو حذف کرد.متد دوم که decodeMorse باشه رو توی قسمت قبل نوشتیم و کارش اینه که کد مورس رو به زبان ادمی زاد ترجمه کنه.بریم سراغ راه حل.این مسئله فرصت خیلی خوبی برای تمرین regular expressions هست. متد decodeBits به این صورت خواهد بود:function decodeBits(bits) { // Trim zeros const message = bits.replace(/^0+|0+$/g, &quot&quot).match(/0+|1+/g); // Find transmission rate const rate = Math.min(...message.map(x => x.length)); // Convert to morse code bits = bits .replace(new RegExp('(?:111){' + rate + '}(?:0{' + rate + '}|$)', 'g'), '-') .replace(new RegExp('1{' + rate + '}(?:0{' + rate + '}|$)', 'g'), '.') .replace(new RegExp('(?:000000){' + rate + '}', 'g'), ' ') .replace(new RegExp('(?:00){' + rate + '}', 'g'), ' ') return bits; }خط به خط اون رو بررسی میکنیم:const message = bits.replace(/^0+|0+$/g, &quot&quot).match(/0+|1+/g);اول صفر های اضافی رو حذف میکنیم. بعد با متد match صفر ها و یک های پشت سر هم رو به عنوان یک ارایه برمیگردونیم و توی message ذخیره میکنیم. محتوا message چیزی شبیه به این خواهد بود:['11', '111111', '0000', '1111', '00']const rate = Math.min(...message.map(x => x.length));اول با طول اعضا message یک ارایه ساختیم و بعد با متد Math.min کوتاه ترین اون رو انتخاب کردیم که واحد یا ضریب ما خواهد بود. در مورد این که چطور ضریب رو پیدا کردیم خودتون فکر کنید(انتظار ندارید که همه چیز رو من بگم. درسته؟)کاربرد '...' : از '...' کاربرد های زیادی دارد که مهم ترین آن کپی کردن اعضا یک ارایه دیگر است. به عنوان مثال اگر بخواهیم اعضا آرایه arr1 را در بین آرایه arr2 کپی کنیم:const arr1 = [2, 3, 5, 6, 7]; const arr2 = [1, ...arr1, 8, 9]; // arr2 => [1, 2, 3, 4, 5, 6, 7, 8, 9]; بقیه کاربرد های ... در اینجا توضیح داده شده.تنها نکته اینه که چرا از '...' قبل از message استفاده کردیم و چرا از خودش استفاده نکردیم؟ جواب اینه که اگر تنها از message استفاده میکردیم خروجی یک آرایه بود در صورتی که متد min ورودی آرایه نمیگیرد و باید تعدادی عنصر مجزا در ان قرار قیرد تا کوچکترین ان را انتخاب کند. با استفاده از ... با جای خود آرایه اعضا اون رو به متد min میدیم. bits = bits .replace(new RegExp('(?:111){' + rate + '}(?:0{' + rate + '}|$)', 'g'), '-') .replace(new RegExp('1{' + rate + '}(?:0{' + rate + '}|$)', 'g'), '.') .replace(new RegExp('(?:000000){' + rate + '}', 'g'), ' ') .replace(new RegExp('(?:00){' + rate + '}', 'g'), ' ') return bits;برای اینکه این رو بفهمیم اول باید درک بهتری از واحد به دست بیاریم. فرض کنید یک فرد حرفه ای حرف 'T'بخواد بنویسه. فرض کنیم این شکلی میشه:111 یعنی به اندازه سه واحد دکمه رو فشار دادهولی برای یک فرد مبتدی که نصف سرعت حرفه ای ها رو داره میشه:111111 میبینیم که تعداد یک ها دو برابر شد. پس واحد اینجا میشه ۲ چون دو برابر وقت برای تایپ یک کاراکتر استفاده شده و در نتیجه تعداد یک ها هم دو برابر شده. اگر بخواهیم با regexp این رو نشون بدیم میشه:/{ضریب}111/یادتون هست که بین {...} تعداد دقیق رخداد یک کاراکتر رو مشخص میکردیم. مثلا /{3}0/ یعنی 000.سوال مهم دوم اینه که چرا به جای فرم /.../ از شی RegExp استفاده کردیم؟جواب اینه که اگر از فرم /.../ استفاده میکردیم نمیتونستیم در اون از متغیر استفاده کنیم و همونطور که میبینید استفاده از متغیر rate برای حل این سوال ضروریه پس از شی RegExp استفاده کردیم. پارامتر اول regexp و پارامتر دوم آپشن ها هستند.بقیه ماجرا فقط regex هست و خودتون یکم بهش فکر کنید.این از نصف جواب. نصف بقیه جواب رو هم قبلا نوشتیم: متدی که کد مورس رو به زبان آدم ترجمه میکنه:decodeMorse = function(morseCode){ function decodeMorseLetter(letter) { return MORSE_CODE[letter]; } function decodeMorseWord(word) { return word.split(' ').map(decodeMorseLetter).join(''); } return morseCode.trim().split(' ').map(decodeMorseWord).join(' '); }این هم از این.تموم شد. امیدوارم استفاده کرده باشید و چیز های زیادی یاد گرفته باشید. این مسئله یک قسمت سوم رو هم داره که واقعا سخت میشه و میخوایم صفر و یک های مربوط به یه آدم مبتدی و ×بی نظم× رو ترجمه کنیم. منتظر باشید... Noah Noah Tue, 30 Jun 2020 11:29:07 +0430 https://virgool.io/@dndshmdr/%D8%AC%D9%86%DA%AF-%D8%A8%D8%A7-%D8%AC%D8%A7%D9%88%D8%A7-%D8%A7%D8%B3%DA%A9%D8%B1%DB%8C%D9%BE%D8%AA-%D8%AA%D9%84%DA%AF%D8%B1%D8%A7%D9%81-%DA%86%DB%8C-%DB%B1-eltqmhhowjyj تلگراف در زمان خودش انقلابی توی ارتباطات ایجاد کرد. مردم به راحتی میتونستند از فواصل خیلی دور برای هم پیام ارسال کنند. احتمالا توی فیلم ها دیدید که یه ادمی پشت یک دستگاه کوچک نشسته و یک دکمه رو فشار میده و یه صدای بیب بیب هم به گوش میرسه. این بیب بیب ها در واقع کد مورس هستند.کد مورس از دش(-) و نقطه(.) تشکیل شده. چیزی شبیه به این:morse code: .... . .-.. .-.. --- .-- --- .-. .-. . -.. که ترجمه اون میشه hello worldاز ترکیب دش و نقطه یک حرف به وجود میاد. مثلا .... یعنی H. حروف یک کلمه با یک اسپیس از هم جدا میشوند. مثلا .... که میشه H با یک اسپیس از . که میشه E جدا شده.دو کلمه با سه اسپیس از هم جدا میشوند. مثلا --- که یعنی O(اخرین حرف hello) با سه اسپیس از --. که میشه W جدا شده.کوچک یا بزرگی حروف در کد مورس مشخص نمیشه.دیروز برای تمرین جاوا اسکریپت توی codewars میگشتم که یه مسئله جالب پیدا کردم که سه مرحله از اسون به سخت داشت. چیزی که الان میخونید قسمت یک این مسئله است که امیدوارم خوشتون بیاد.کاری که قرار بکنیم اینه که یک کد مورس رو تحویل بگیریم و اون رو ترجمه کنیم. به نظر اسون میاد ولی من به عنوان یک مبتدی چند ساعتی درگیرش بودم.میدونم ازاین چیز ها تو اینترنت ریخته. جالبی این مسءله به چند قسمتی بودن اونه که هر بار سخت تر میشه. پس اگه راحت از پس این بر اومدید جوگیر نشید چون تو قسمت بعدی ذخایر فسفر مغذتون رو مورد هدف قرار دادم.بریم سراغ اصل ماجرایک تابع اسم decodeMorse مورد داریم که یک متن حاوی کد مورس رو میگیره و ترجمه اون کد رو باید تحویل بدیم.قیل از هرچیزی به ترجمه تک تک کد های مورس نیاز داریم: const MORSE_CODE = { &quot-----&quot: &quot0&quot, &quot.----&quot: &quot1&quot, &quot..---&quot: &quot2&quot, &quot...--&quot: &quot3&quot, &quot....-&quot: &quot4&quot, &quot.....&quot: &quot5&quot, &quot-....&quot: &quot6&quot, &quot--...&quot: &quot7&quot, &quot---..&quot: &quot8&quot, &quot----.&quot: &quot9&quot, &quot.-&quot: &quotA&quot, &quot-...&quot: &quotB&quot, &quot-.-.&quot: &quotC&quot, &quot-..&quot: &quotD&quot, &quot.&quot: &quotE&quot, &quot..-.&quot: &quotF&quot, &quot--.&quot: &quotG&quot, &quot....&quot: &quotH&quot, &quot..&quot: &quotI&quot, &quot.---&quot: &quotJ&quot, &quot-.-&quot: &quotK&quot, &quot.-..&quot: &quotL&quot, &quot--&quot: &quotM&quot, &quot-.&quot: &quotN&quot, &quot---&quot: &quotO&quot, &quot.--.&quot: &quotP&quot, &quot--.-&quot: &quotQ&quot, &quot.-.&quot: &quotR&quot, &quot...&quot: &quotS&quot, &quot-&quot: &quotT&quot, &quot..-&quot: &quotU&quot, &quot...-&quot: &quotV&quot, &quot.--&quot: &quotW&quot, &quot-..-&quot: &quotX&quot, &quot-.--&quot: &quotY&quot, &quot--..&quot: &quotZ&quot, &quot/&quot: &quot &quot, &quot-·-·--&quot: &quot!&quot, &quot.-.-.-&quot: &quot.&quot, &quot--··--&quot: &quot,&quot, &quot...---...&quot: &quotSOS&quot, &quot-.-.--&quot: &quot!&quot, &quot&quot: &quot &quot};خب گفتیم که یه متد داریم که یه string حاوی کد مورس میگیره و ترجمه رو برمیگردونه. ولی قبل از دیدش میخوام یکم در مورد متد هایی که استفاده کردم توضیح بدم که اگر مبتدی هستید درک بهتری داشته باشید.متد split： این متد با استفاده از پارامتری که میگیره یک string رو به یک array تبدیل میکنه. پارامتر مثل یک حایل عمل میکنه و هرجا اون کاراکتر دیده شد string رو قطع میکنه. مثلا اگر بخواهیم کلمات hello world رو از هم جدا کنیم：&quothello world&quot.split(&quot &quot); --> [&quothello&quot, &quotworld&quot]هرجا یک اسپیس (" ") وجود داشت از همونجا string رو جدا میکنه.متد map : وقتی بخوایم رو تک تک اعضای یک ارایه یه کار انجام بدیم از map استفاده میکنیم. این متد یه تابع به عنوان ورودی میگیره و روی تک تک اعضای ارایه این تابع رو اجرا میکنه و در نهایت یک ارایه جدید تحویل میده که حاصل اجرای اون تابع روی اعضای ارایه اصلیه.var numbers = [4, 9, 16, 25]; var x = numbers.map(Math.sqrt) document.getElementById(&quotdemo&quot) = x;مثلا اینجا با استفاده از Math.sqrt همه اعضا numbers رو به توان رو رسوندیم و اون رو توی ارایه جدید x ذخیره کردیم.متد trim: این متد اسپیس های اضافه اول و اخر string رو از بین میبره&quot hello word &quot.trim(); --> &quothello world&quotمتد join: این متد اعضای یک ارایه رو به هم میچسبونه و بینشون پارامتری که میگیره رو قرار میده[‘h‘,‘e‘,‘l‘,‘l‘,’o’].join(&quot&quot); --> &quothello&quot و اما اصل کار decodeMorse = function(morseCode){ function decodeMorseLetter(letter) { return MORSE_CODE[letter]; } function decodeMorseWord(word) { return word.split(' ').map(decodeMorseLetter).join(''); } return morseCode.trim().split(' ').map(decodeMorseWord).join(' '); }توضیح： درون تابع decodeMorse سه تابع تعریف کردیم：۱- decodeMorseLetter： کد مورس مربوط به یک حرف رو میگیره و خود حرف رو برمیگردونه۲- decodeMorseWord：کد موردمربوط به یک کلمه رو میگیره و تک تک کاراکتر هاش روبا متد decodeMorseLetter ترجمه میکنه و در نهایت با متد join اون هارو به هم چسبونه.اول اسپیس های اضافی کد مورس رو با trim برمیداریم. بعد با split کلمه هارو از هم جدا میکنیم(هر جا سه تا اسپیس پشت در هم بود) و متد رو روی همه کلمه ها اجرا میکنیم و در نهایت ترجمه که در واقع یک ارایه هست رو با متد join به هم میچسبونیم و اون رو تحویل میدیم .مثال：decodeMorse('.... . -.-- .--- ..- -.. .') //should return &quotHEY JUDE&quotاین تازه دستگرمی بود. مرحله بعد یکم سخت تر میشه. با تلگراف که نمیشه دش و نقطه فرستاد. باید این کار رو از طریق برق انجام بدیم. در نتیجه در واقعیت یک مشت صفر و یک داریم . باید این صفر و یک هارو به کد مورس تبدیل کنیم و بعد اونو ترجمه کنیم. https://vrgl.ir/0kwa2 Noah Noah Mon, 08 Jun 2020 13:10:10 +0430 https://virgool.io/@dndshmdr/%D8%A8%D8%A7%D9%84%D8%A7%D8%AE%D8%B1%D9%87-%D8%A8%D9%84%D8%A7%DA%A9%DA%86%DB%8C%D9%86-%DA%86%DB%8C%D9%87-%D8%AA%D9%88%D8%B6%DB%8C%D8%AD-%D8%A8%DB%8C%D8%AA-%DA%A9%D9%88%DB%8C%D9%86-%D8%A8%D8%AF%D9%88%D9%86-%DA%A9%D8%A7%D9%85%D9%BE%DB%8C%D9%88%D8%AA%D8%B1-rutr0nghje4o مطمئنم بیت کوین و بلاک چین به گوشتون خورده. بالاخره یکی از موضوعات محبوب این روز هاست. حتی کسانی که یک رمزارز را استخراج نکرده اند یا هنوز انرا درک نمیکنند, در مورد ان حرف میزنند. من بیشتر دوستان غیر کامپیوتری دارم تا کامپیوتری. اونها برای هفته ها پدر من را درآوردند تا این اصطلاحات نامفهوم را برایشان توضیح دهم! میدانم که هزاران نفر دیگر هم همچین حسی را دارند. در نتیجه وقت ان رسیده که چیزی بنویسم که به کمک ان همه تکه گم شده خود را پیدا کنند -- هدف این پست همین است. بلاکچین:چرا به چیزی اینقدر پیچیده نیاز داریم؟'برای هر مسئله پیچیده ای جوابی شفاف, ساده , و اشتباه وجود دارد' -- H.L.Menckenبرعکس اکثر مقاله ها, به جای اینکه اول آنرا تعریف کنیم, میخواهیم ببینیم بلاکچین چه مشکلاتی را حل میکند .فرض کنید دوستتان joe برای تعطیلات به مسافرت رفته و پول کم اورده. به شما زنگ میزنه و میگه "سلام داداش. یکم پول داری به من قرض بدی؟"ما هم که ساده میگیم " باشه joe جان . الان کارت به کارت میکنم"بعد به مسئول امور مشتریان در بانک تان زنگ میزنید و میگویید که هزار دلار به حساب joe کارت به کارت کند.اونم میگه " چشم قربان"بعد میره حساب شما رو بررسی میکنه که ایا هزار دلار موجودی دارید یا نه. از انجا که شما ادم پولداری هستید مشکلی نیست. بعد چیزی مثل این را در دفتر, ثبت میکند:برای سادگی فرض کنید این کار ها بدون کامپیوتر انجام میشود.بعد به joe زنگ میزنیم و میگیم" هزار دلار برات فرستادم. دفعه بعد که بری بانک میتونی ازش برداشت کنی "الان چه اتفاقی افتاد؟ شما و joe هر دو به بانک اعتماد کردید که پول شما را مدیریت کند. در واقع هیچ انتقال فیزیکی اسکناسی در کار نیست. تمام چیزی که نیاز دارید یک حساب در بانک است. به بیان دقیق تر, حسابی که نه شما و نه جمشید روی ان کنترلی ندارید.این مشکل سیستم کنونی است.برای رسمی کردن اعتماد بین خودمان به یک فرد ثالث (بانک)نیاز داریمسال هاست که برای اینکه به یکدیگر اعتماد کنیم به یک میانجی وابسته هستیم.ممکن است بپرسید："مشکل وابسته بودن به انها چیست؟"مشکل این است که تعداد آن یک است. اگر در جامعه هرج و مرج شود, تنها چیزی که لازمه این است که یک فرد/سازمان خراب بشه.عمدی یا ناخواسته.اگر تراکنش های حساب های شما اتفاقی اتش بگیرد چه؟اگر مدیر امور مشتریان اشتباها به جای یک میلیون , یک میلیون و نیم نوشته باشد چه؟اگر این کار را عمدی انجام دهد چه؟سال هاست تمام تخم مرغ هایمان را در یک سبد گذاشته ایم و آنرا هم در یک جای دیگر[نه پیش خودمان]ایا یک سیستم میتواند وجود داشته باشد که در ان بدون نیاز به بانک بتوان پول منتقل کرد؟جواب این است که باید بیشتر تمرکز کنیم و یک سوال دقیق تر از خودمان بپرسیم(بالاخره سوال های بهتر به جواب های بهتر منجر میشوند)چند ثانیه فکر کنید. معنی انتقال پول چیست؟ فقط یک تراکنش که د دفتر ثبت شده است. سوال بهتر این است：ایا راهی هست که بین خودمان یک دفتر داشته باشیم به جای اینکه یک نفر دیگر این کار را برای ما انجام دهد.حالا این سوالی است که ارزش پاسخ دادن دارد. و همانطور که احتمالا حدس زده اید بلاک چین جواب این سوال است.روشی برای اینکه یک دفتر بین خودمان داشته باشیم, به جای اینکه به یک نفر دیگربرای این کار وابسته باشیم.هنوز با من هستید؟ خوبه. حالا که در ذهنتان سوال هایی ایجاد شده , یاد میگیریم که این دفتر همگانی چطور کار میکند.بله اما به بگو چطور کار میکنداین روش نیازمند تعداد کافی از افرادی است که نمیخواهند به یک شخص ثالث وابسته باشند. بعد این گروه میتوانند یک دفتر را بین خود نگه دارند.منطقی به نظر میرسد که در صورتی که این کار ادامه پیدا کند مقداری بیت کوین به دست اورید. اگر تعداد کافی از میردم مثل هم فکر کنند این به یک پیشگویی اجتناب ناپذیر تبدیل خواهد شد. ساتوشی ناکوموتوچقدر کافی است؟ حداقل سه تا. برای مثال, فرض میکنیم که ده نفر وجود دارند که میخواهند بانک ها یا هر شخص ثالثی را ترک کنند. طی یک توافق متقابل, انها همیشه از حساب های یکدیگر اطلاع دارند __ بدون دانستن هویت انها۱. یک پوشه خالیبرای شروع همه یک پوشه خالی همراه خود دارند. همینطور که پیش میرویم همه این ده نفر شروع به اضافه کردن صفحاتی به پوشه خود میکنند. و این مجموعه صفحات یک دفتر را تشکیل میدهند که معاملات را ثبت میکند.۲.وقتی یک معامله میشود.در این شبکه همه با یک برگه کاغذ و خودکار در دست نشسته اند. همه اماده هستند که هر تبادلی در سیستم رخ میدهد را یادداشت کنندحالا اگر #2 بخواهد ده دلار به #10 ارسال کند.برای انجام تبادل, #2 داد میزنه و به همه میگه："من میخوام ده دلار به #9 بفرستم. پس لطفا همه ان را یادداشت کنید"همه چک میکنند که ایا #2 موجودی کافی ( ده دلار) برای انتقال به #9دارد یا نه. اگر داشت, همه این انتقال را روی کاغد هایشان مینویسند.انتقال تکمیل شد!۳. مبادلات ادامه پیدا میکندبا گذشت زمان, بقیه هم به انتقال پول به دیگران نیاز پیدا میکنند. هروقت بخواهند یک انتقال انجام دهند, انرا به بقیه اعلام میکنند.به محض اینکه یک نفر این اعلان(ها) را بشنود, انرا روی کاغذ مینویسد.این روند ادامه دارد تا وقتی که کاغذ همه پر شود. فرض کنید هر صفحه برای ده تبادل فضا داشته باشد. دقیقا بعد از دهمین تبادل کاغذ همه پر میشود.حالا وقت ان است که کاغذ را در پوشه بگذاریم و یک برگه دیگر برداریم و مراحل ۱و ۲ را تکرار کنیم.۴. کنار گذاشتن برگهقبل از اینکه برگه را در پوشه بگذاریم, باید انرا با یک شناسه منحصر به فرد که همه انرا قبول دارند پلمپ کنیم. با پلمپ کردن آن, مطمئن میشویم که بعد از اینکه انرا در پوشه قرار دادیم کسی نمیتواند تغییری در ان ایجاد کند __ نه امروز نه فردا نه حتی یک سال دیگر. وقتی رفت توی پوشه تا ابد در پوشه باقی می ماند __ مهر و موم شده. به علاوه, اگر همه به پلمپ اعتماد داشته باشند, به محتوای برگه هم اعتماد دارند. و این پلمپ کردن برگه رمز این روش است.اوایل , شخص ثالث/میانجی ها این اطمینان را به ما می دادند که هر چیزی که ثبت میکنند قابل تغییر نخواهد بود. به جای ان ,در سیستم توزیع شده و غیر متمرکزی مثل ما, پلمپ اعتماد ایجاد میکند.چه جالب! حالا چطور برگه ها را پلمپ میکنیم؟قبل از اینکه بدانیم چطور می توانیم برگه را پلمپ کنیم ، به طور کلی خواهیم دانست که این مهر و موم چگونه کار می کند. و پیش شرط لازم ، یادگیری در مورد چیزی است که دوست دارم آنرا صدا کنم ...ماشین جادویییک ماشین را تصور کنید که با دیوار های ضخیم احاطه شده است. اگر یک جعبه که حاوی یک چیز است را از چپ وارد ماشین کنیم, یک جعبه که حاوی یک چیز دیگر است را تف میکند!اسم این ماشین Hash Function است ولی ما خیلی نمیخوایم تخصصی باشیم. پس با همون ماشین جادویی ادامه میدیم.فرض کنید عدد ۴ رو از چپ وارد ماشین جادویی میکنیم, متوجه میشیم که کلمه ‘ dcbea’ رو تف کرد!چطور عدد ۴ روبه این عبارت تبدیل کرد؟ کسی نمیدونه. به علاوه, این یک فرایند برگشت ناپذیر است. اگر کلمه ‘dcbea’ را به عنوان ورودی به ان بدهیم غیر ممکنه که بفهمیم ورودی چه بوده. ولی هر وقت عدد ۴ را وارد کنیم , قطعا عبارت ‘dcbea’ خارج خواهد شد.بیایید یک عدد دیگر به ان بدهیم. ۲۶ چطوره؟اینبار 94c8e گرفتیم. چه جالب . پس این عبارت عدد هم میتونه داشته باشه.اگر حالا از شما این سوال را بپرسم چطور:آیا می توانید به من بگویید که از سمت چپ دستگاه چه باید وارد کنم به گونه ای که عبارتی را دریافت کنم که با سه صفر شروع می شود؟ به عنوان مثال ، 000ab یا 00098 یا 000fa یا هر چیزی مثل این.چند لحظه به سوال فکر کنید.من به شما گفتم که ویژگی ماشین این است که وقتی خروجی را به ان بدهیم نمیتوانیم بفهمیم که ورودی ان چه بوده. پس چطور میتوانیم به این سوال جواب دهیم؟یک روش به ذهنم رسید. چطوره همه عدد های جهان را یکی یکی به دستگاه بدهیم تا وقتی که عبارت خروجی با سه صفر شروع شود.خوشبین باشید, بعد از چندین هزار تلاش, بالاخره به خروجی مورد نظر میرسیم.محاسبه ورودی با توجه به خروجی بسیار دشوار بود. اما در عین حال ، بررسی اینکه آیا ورودی پیش بینی شده خروجی مورد انتظار را تولید می کند ، بسیار ساده خواهد بود. یادتان باشد که دستگاه هر بار همان عبارت را برای یک عدد خاص تولید می کند.فکر میکنید اگر یک عدد مثل 72533 را به شما بدهم جواب دادن به این سوال چقدر سخت است： آیا این عدد هنگام وارد شدن به ماشین کلمه ای را می دهد که با سه صفر شروع می شود؟تنها کاری که باید انجام دهید این است که شماره را به دستگاه بدهید و ببینید که در سمت راست آن چه چیزی را بدست آورده اید. خودشه. مهمترین ویژگی این ماشین ها این است که - "با توجه به یک خروجی ، محاسبه ورودی بسیار دشوار است ، اما اگر ورودی و خروجی را داشته باشیم ، می توان بررسی کرد که ورودی به خروجی منجر می شود یا نه."چطور از این ماشین برای پلمپ صفحه استفاده کنیم؟ما از ماشین جادویی برای تولید پلمپ برگه استفاده میکنیم.مثل همیشه با یک موقعیت خیالی شروع میکنیم.فرض کنید دو تا جعبه به شما داده ام. اولین جعfه محتوی عدد 20893 است. بعد از شما میپرسم ：ایا میتوانید عددی را حدس بزنید که وقتی با عدد درون جعبه اول جمع و وارد ماشین شود, عبارتی را تولید کند که به سه صفر شروع شود؟این مثل موقعیت قبل است. یاد گرفتیم که تنها راه پیدا کردن همچین عددی, این است که همه اعداد جهان را آزمایش کنیم.پس از چند هزار تلاش ، ما به عددی میرسیم ، مثلا 21191 ، که با اضافه شدن به 20893 (یعنی 21191 + 20893 = 42084) و ورود به ماشین ، عبارتی را تولید میکند که با شرایط ما هم خوانی دارد.در چنین حالتی ، این شماره ، 21191, پلمپ شماره 20893 می شود. فرض کنید صفحه ای وجود دارد که دارای شماره 20893 است که روی آن نوشته شده است. برای پلمپ آن صفحه (یعنی هیچ کس نمی تواند محتوای آن را تغییر دهد) ، یک نشان با شناسه "21191" را روی آن قرار می دهیم. به محض اینکه شناسه پلمپ (یعنی 21191) در صفحه قرار گرفت ، صفحه مهر و موم می شود.شناسه پلمپ "proof of work- اثبات کار" نامیده می شود ، بدین معنی که این شماره اثبات تلاش برای محاسبه آن است. برای اهداف ما "شناسه پلمپ" مناسب تر است.اگر کسی می خواهد بررسی کند که صفحه تغییر کرده است، تمام کاری که باید انجام دهد این است که محتوای صفحه را با شناسه پلمپ جمع کند و وارد ماشین جادویی کند. اگر ماشین یک عبارت که با سه صفر شروع میشود را تولید کند محتویات دست نخورده هستند. اگر کلمه ای که ارائه می شود شرایط ما را برآورده نمی کند ، می توانیم صفحه را دور بیندازیم زیرا محتویات آن دستکاری شده است.ما از یک مکانیزم پلمپ مشابه برای مهر و موم کردن تمام صفحات خود و در نهایت قرار دادن آنها در پوشه های مربوطه استفاده خواهیم کرد.سرانجام ، پلمپ برگه ...برای پلمپ صفحه خود که شامل تبادلات شبکه است، باید عددی را پیدا کنیم که وقتی با لیست معاملات جنع شود و وارد دستگاه شود ، عبارتی راتولید کند که با سه صفر شروع می شود.توجه: من از عبارت "عبارت شروع شده با سه صفر " فقط به عنوان مثال استفاده كرده ام. این نشان می دهد که hashing function چگونه کار می کند. چالش های واقعی بسیار پیچیده تر از این است.هنگامی که این شماره پس از گذر زمان و برق در دستگاه محاسبه می شود ، صفحه با آن شماره(شناسه) پلمپ می شود. اگر شخصی سعی کند محتوای صفحه را تغییر دهد ، شناسه پلمپ به هر کسی این امکان را می دهد که صحت برگه را تأیید کند.حالا که در مورد پلمپ کردن برگه میدانیم ، به زمانی باز می گردیم که نوشتن تبادل دهم در صفحه را تمام کرده بودیم و برای نوشتن اطلاعات بیشتر به فضا نیاز داشتیم.به محض اینکه همه برای نوشتن معاملات بیشتر از صفحه خارج شدند ،محاسبه شناسه پلمپ را شروع می میکنند تا در پوشه قرار بگیرد. همه افراد در شبکه محاسبه را انجام می دهند. اولین نفر در شبکه که شناسه پلمپ را فهمید آن را به بقیه اعلام می کند.بلافاصله با شنیدن شناسه پلمپ ، همه تأیید می کنند که آیا خروجی مورد نظر را میدهد یانه. اگر اینطور بود، همه صفحات خود را با این شناسه پلمپ میکنند در پوشه های خود قرار می دهند.اما اگر برای کسی ، مثلاً #7 ، شناسه پلمپ که اعلام شده بود، خروجی لازم را تولید نکند چه؟ چنین مواردی غیر عادی نیست. دلایل احتمالی این امر می تواند موارد زیر باشد:ممکن است معامله هایی را که در شبکه اعلام شده بود را اشتباه شنیده باشدممکن است معامله هایی را که در شبکه اعلام شده بود را اشتباه نوشته باشدممکن است سعی کرده باشد هنگام نوشتن معاملات ، تقلب کند، به نفع خودش یا شخص دیگری در شبکه مهم نیست که دلیل آن چیست ، #7 تنها یک انتخاب دارد - صفحه خود را دور ریخته و آن را از شخص دیگری کپی کند تا او هم بتواند آن را در پوشه قرار دهد. مگر اینکه صفحه خود را در پوشه قرار ندهد ، نمی تواند نوشتن معاملات بیشتر را ادامه دهد ، بنابراین ، شبکه او را طرد میکند. اگر اکثریت با موافقت کنند، به شناسه پلمپ درست تبدیل می شود.پس چرا همه افراد وقتی می دانند که شخص دیگری آن را برای آنها محاسبه و اعلام می کند ، منابع خود را برای انجام محاسبه صرف می کند؟ چرا بیکار ننشسته و منتظر اعلام نمانیم؟سوال خوبی است. این جا است که مشوق ها وارد عمل میشوند می شوند. هر کس که بخشی از Blockchain است واجد شرایط دریافت پاداش است. اولین کسی که شناسه پلمپ را محاسبه کند, برای تلاش های خود پول مجانی پاداش می گیرد (مثلا هزینه برق و CPU صرف شده).تصور کنید ، اگر # 5 شناسه پلمپ یک برگه را محاسبه کند ، با مقداری پول رایگان تشویق می شود ، مثلاً 1 دلار پاداش می گیرد. به عبارت دیگر ، موجودی حساب # 5 افزایش می یابد, بدون اینکه از حساب بقیه چیزی کم شود.اینگونه بیت کوین به وجود آمد. این اولین ارزی بود که در یک Blockchain معامله شد. در عوض، برای اینکه مردم در شبکه تلاش کنند, بیت کوین اهدا میشود.هنگامی که افراد کافی بیت کوین دارند ، ارزش آن رشد می کند و باعث می شوند افراد دیگر تمایل به بیت کوین داشته باشند. ساخت بیت کوین ارزش آن را بیشتر میکند. حتی وقتی افراد بیشتری تمایل به بیت کوین پیدا کنند باز هم ارزش ان بیشتر میشود. و به همین ترتیب.پاداش ها باعث میشود مردم کار روی شبکه را ادامه دهند.و وقتی برگه ها را در پوشه قرار دادند, یک برگه دیگر برمیدارند و کل مراحل را دوباره تکرار میکنند.به برگه به عنوان یک بلوک از تبادلات و به پوشه به عنوان یک زنجیره از تبادلات نگاه کنید(Blockchain == زنجیره ای از بلوک ها یا همچین چیزی)هنوز یک چیز کوچک را به شما نگفتم.فرض کنید ۵ صفحه در پوشه قرار دارد. همه پلمپ شده با یک شناسه پلمپ. اگر من برگه دوم را بردارم و ان را به نفع خودم تغییر دهم چه؟ شناسه پلمپ این امکان را به بقیه میدهد که صحت ان را بررسی کنند. درسته؟ اگر یک شناسه پلمپ جدید برای تبادل دستکاری شده محاسبه کنم و برگه را با شناسه جدید پلمپ کنم چه؟برای حل این مشکل که یک نفر برگردد و یک صفحه را دستکاری کند, از جمله شناسه پلمپ, محاسبه شناسه پلمپ کمی پیچیدگی دارد.محافظت از تغییرات شناسه پلمپیادتان هست که گفتم : به شما دو جعبه میدهم. یکی برای ذخیره عدد 20893 و یک جعبه خالی برای شما که محاسبه کنید؟ در حقیقت, برای محاسبه شناسه پلمپ در بلاکچین, به جای رو جعبه , سه جعبه وجود دارد. دوتا که محتوی چیزی هستند و یکی برای اینکه محاسبه شود.و وقتی محتوا همه سه جعبه با هم جمع شدند و وارد ماشین شدند, پاسخی که از سمت راست خارج میشود باید شرط مورد نیاز را داشته باشد.میدانیم که یک جعبه لیست تبادل ها را دارد و جعبه دیگر شناسه پلمپ . جعبه سوم محتوی خروجی ماشین جادویی برای برگه قبلی است.با استفاده از این ترفند کوچک ، ما اطمینان حاصل کردیم که هر صفحه به صفحه قبلی خود وابسته است . بنابراین ، اگر شخصی مجبور به تغییر یک صفحه قدیمی باشد ، مجبور است محتویات و شناسه پلمپ همه صفحات را پس از آن تغییر دهد تا زنجیره سازگار باشد. اگر فردی از بین ده نفری که در ابتدا داشتیم ، سعی کند محتوای بلاکچین (پوشه حاوی صفحات دارای لیست معاملات) را دستکاری کند ، باید چندین صفحه را تنظیم کند و همچنین شناسه پلمپ جدیدی را برای همه ان صفحات محاسبه کند. ما می دانیم محاسبه شناسه پلمپ چقدر دشوار است. بنابراین ، یک فرد نامرد در شبکه نمی تواند 9 فرد صادق را مورد ضرب و شتم قرار دهد.اتفاقی که خواهد افتاد این است که، از صفحه ای که شخص نامرد سعی در دستکاری ان دارد ،باید یک زنجیره دیگر را در شبکه ایجاد کند ، اما این زنجیره هرگز نمی تواند با زنجیره اصلی دست و پنجه نرم کند - چون تلاش و سرعت یک نفر نمی تواند با تلاش و سرعن نه نفر رقابت کند. از این رو ،اینکه طولانی ترین زنجیره در یک شبکه ، زنجیره اصلی است تضمین شده است .بزرگترین زنجیره, زنجیره واقعی و اصلی استچه می شود اگر به جای یک نفر ، شش نفر پسر ناسپاس شوند؟ در این حالت پروتکل دهنشان را سرویس خواهد کرد. و به عنوان "حمله 51٪" شناخته می شود. اگر اکثریت افراد در شبکه تصمیم بگیرند که هرج و مرج ایجاد کنند و بقیه شبکه را دستکاری کنند ، پروتکل از هدف خود ناکام می ماند. و این تنها دلیلی است که بلاکچین فرو بپاشد. بدانید بعید است که این اتفاق بیفتد اما همه باید نقاط آسیب پذیر سیستم را بدانیم. این سیستم با فرض ساخته شده است که اکثریت جمعیت همیشه صادق هستند.و دوستان من ، این همه چیز درباره بلاکچین است. اگر تا به حال کسی را پیدا کرده اید که احساس عقب ماندگی میکند از حالا به بعد می دانید که او را به کجا ارجاع دهیداگر این پست را دوست داشتید انرا لایک کنید تا بقیه هم اون رو بخوانند. Noah Noah Tue, 12 May 2020 10:29:41 +0430 https://virgool.io/@dndshmdr/%D8%AA%D8%B1%D8%AC%D9%85%D9%87-%D9%81%D8%B5%D9%84-%D8%AF%D9%88%D9%85-clean-code-%D8%A7%D8%B3%D8%A7%D9%85%DB%8C-%D8%A8%D8%A7-%D9%85%D8%B9%D9%86%DB%8C-aelqqffftac7 چند هفته پیش پروژه ترجمه گروهی کتاب clean code رو کلید زدم و الان دو فصل از کتاب ترجمه شده. هر چند به خاطر تعداد کم مترجمان فعال این کار خیلی کند پیش میره ولی داریم سعی میکنیم که متوقف نشه. این پروژه روی گیتهاب گذاشته شده و اگر مایل بودید میتونید یک پاراگراف از کتاب رو ترجمه کنید.(صفحه گیت هاب). در ضمن این متن مستقیما از گیت هاب کپی شده و اگر جایی مشکلی داشت بهتره از همون گیتهاب مطالعه کنید. و همچنین اگر اشتباه تایپی یا املایی و یا حتی از نظر روان بودن ترجمه مشاهده کردید لطفا توی گیت هاب اونو اصلاح کنید.اگر از این پست راضی بودید لایک کنید تا افراد بیشتری جذب این پروژه بشن.این پروژه توسط افراد داوطلب اداره میشود. تو هم میتونی یکی از اونها باشیلطفا به ازای هر پاراگراف از این پست که برات مفید بوده, یک کلمه از فصل سه رو در گیتهاب ترجمه کنقبل از ادامه دادن حتما حتما فصل اول رو بخونید https://virgool.io/@dndshmdr/ترجمه-فصل-اول-clean-code-کد-تمیز-ax3amclpsdzi فصل دوم : اسامی با معنیاسم ها همه جای نرم افزار وجود دارند. ما متغیر ها، تابع ها، آرگومان ها، کلاس ها و پکیج هایمان را نام گذاری میکنیم. ما فایل های سورس و دایرکتوری هایی که آنها را شامل میشوند را نام گذاری میکنیم. ما حتی فایل های jar و war و ear را نامگذاری میکنیم. ما نامگذاری میکنیم، نامگذاری میکنیم و نامگذاری میکنیم. از آنجایی که این کار را خیلی زیاد انجام میدهیم ، بهتر است که آن را با شیوه درست دهیم. آنچه که در ادامه میخوانید،قوانینی ساده برای خلق اسم های خوب هستند.استفاده از اسم های بیان کننده منظور (Intention-Revealing Names)کاملا واضح است که اسم ها باید منظور شما را بازتاب دهند. چیزی که ما میخواهیم به شما بگوییم این است که ما در این قضیه کاملا جدی هستیم. انتخاب کردن اسم های خوب زمانبر است ولی زمان بیشتری از آنچه میگیرد را ذخیره میکند. پس به اسم هایتان توجه کنید و هر وقت اسم های بهتری یافتید، آنها را عوض کنید. هر کسی که کد شما را بخواند (شامل خودتان) از انجام این کار خوشحال میشود. اسم یک متغیر، تابع یا کلاس، باید به تمام سوال های بزرگ پاسخ دهد. اسم باید بگوید که چرا وجود دارد، چه میکند و چگونه استفاده میشود.اگر اسمی به کامنت نیاز داشته باشد،پس منظور خود را نمیرساند.int d; // elapsed time in daysاسم d در کد بالا هیچ منظوری را نمیرساند. این اسم احساس گذشت روز ها را ایجاد نمیکند. ما باید اسمی انتخاب کنیم که مشخص کند چه چیزی در حال اندازه گیری شدن است و واحد و مقیاس آن اندازه گیری چیست.int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays;انتخاب اسم هایی که منظور ما را القا میکند ، فهمیدن و تغییر دادن کد را راحت تر میکند. میتوانید بگویید کد زیر چه میکند؟Public List getThem() { List list1 = new ArrayList; For (int[] x : theList\) If (x[0] == 4) List1.add(x); Return list1;چرا گفتن کاری که این کد انجام میدهد سخت است؟ اینجا هیچ کد پیچیده ای وجود ندارد. فاصله ها و تورفتگی ها کاملا معقول هستند. در کل سه متغیر و دو ثابت استفاده شده است. اینجا هیچ کلاس عجیب یا متد پیچیده ای وجود ندارد، فقط یک لیست از آرایه ها وجود دارد. مشکل سادگی کد نیست ، صراحت کد است؛ میزان صریح بودن کد در بیان منظور خودش. صریح بودن کد نیازمند این است که ما بتوانیم به سوال های نظیر این ها پاسخ دهیم:چه چیز هایی در theList وجود دارد؟اهمیت عضو صفرم در theList چیست؟اهمیت مقدار 4 چیست؟چگونه از لیستی که برگشت داده میشود استفاده کنم؟جواب سوال ها در مثال قبل قابل تشخیص نیستند، ولی باید مشخص شوند. فرض کنید ما داریم روی یک بازی مین روبی کار میکنیم. ما میدانیم که صفحه بازی یک لیست از سلول هاست که با عنوان theList نمایش داده میشود. بیایید نام آن را به gameBoard تغییر دهیم. هر سلول در صفحه توسط یک آرایه ساده نشان داده میشود. همچنین این را میدانیم که مقدار صفرم ، وضعیت سلول است و اینکه وضعیت 4 یعنی "پرچم گذاری شده". بیایید با دادن اسم های این کانسپت ها کد را به شکل قابل توجهی بهبود دهیم:Public List getFlaggedCells() { List flaggedCells = new ArrayList(); For (int[] cell : gameBoard) If (cell[STATUS_VALUE] == FLAGGED) flaggedCells.add(cell); return flaggedCells; }دقت کنید که سادگی کد تغییری نکرده است و هنوز هم همان تعداد مقادیر ثابت و متغیر وجود دارد، دقیقا با همان تعداد تورفتگی و بیرون زدگی. ما میتوانیم پا را فراتر بگذاریم و به جای یک آرایه از اعداد ، یک کلاس ساده برای سلول ها بنویسیم.این کلاس میتواند یک تابع را شامل شود (که منظور خود را به درستی به نمایش میگذارد و آن را isFlagged می نامیم) که باعث میشود اعداد عجیب از کد حذف شوند:public List getFlaggedCells() { List flaggedCells = new ArrayList(); for (Cell cell : gameBoard) if (cell.isFlagged()) flaggedCells.add(cell); return flaggedCells; }با این تغییرات ساده، دیگر فهمیدن اینکه چه کاری در حال انجام است سخت نیست. این قدرت انتخاب کردن اسم های خوب است.خودداری از دادن اطلاعات اشتباهبرنامه نویس ها باید از به جا گذاشتن اطلاعات اشتباه که معنی کد را خراب میکنند خودداری کنند. ما باید از کلماتی که مفهوم آنها با منظور ما فاصله زیادی دارد دوری کنیم. برای مثال، کلمات hp ، aix و sco نام های ضعیفی برای متغیر ها هستند زیرا از اسامی یونیکس پلتفرم هستند. حتی اگر شما در حال نوشتن یک Hypotenuse هستید و hp مخفف خوبی برای آن به نظر میرسد، ممکن است اطلاعات ناسازگار در کد به جا بگذارید. هرگز به یک لیست از اکانت ها اسم accountList را ندهید زیرا آن واقعا یک لیست است ولی کلمه List به معنی چیزی است که به برنامه نویس ها اختصاص دارد. اگر یک کانتینر اکانت را نگهداری میکند، به این معنی نیست که یک List است، این ممکن است به اطلاعات غلط منجر شود. پس accountGroup یا bunchOfAccounts یا فقط accounts اسم های بهتری هستند.از استفاده از اسم هایی که تفاوت های کوچکی با هم دارند خودداری کنید. چه تضمینی وجود دارد که بعدا دو شی با نام های XYZControllerForEfficientHandlingOfStringsin و XYZControllerForEfficientStorageOfStrings با هم اشتباه گرفته نشوند؟ هر دو اسم شکل یکسانی دارند. در انتخاب اسم به تلفظ آن دقت کنید. استفاده از اسم با تلفظ اشتباه نوعی اطلاعات غلط است. به کمک محیط های مدرن جاوا ما میتوانیم از تکمیل شدن خودکار کد ها لذت ببریم. ما چند حرف تایپ میکنیم و دکمه ای را فشار میدهیم که لیستی از اسامی قابل استفاده برای تکمیل کلمه را به ما نشان میدهد.بسیار مفید است که نامهای بسیار مشابه به ترتیب حروف الفبا مرتب شوند.تفاوت ها را آشکار میکند.یک مثال از نام هایی که اطلاعات غلط میدهند، نام هایی هستند که از حروفی استفاده میکنند که شبیه حروف دیگر هستند. مثلا حرف I و L ، اگر به صورت I و l نوشته شوند،مطمئنا اشتباه گرفته میشوند. همچنین حرف lو1 نیز ممکن است اشتباه گرفته شوند.int a = l; if(0==1) a=01; else l = 01;شاید فکر کنید این اتفاق محال است ؛ اما ما کد هایی را بررسی کرده ایم که چنین مواردی در آنها به وفور وجود داشت. در وهله اول نویسنده پیشنهاد میکند که فونت متن را تغییر دهید که باعث آشکار شدن بهتر تفاوت ها میشود، اما این راه حل باید به توسعه دهندگان آینده به صورت شفاهی یا کتبی منتقل شود. بهترین راه حل یک تغییر نام ساده است.تفاوت های با معنی ایجاد کنیدبرنامه نویس ها با نوشتن کد های کامپایلر پسند برای خودشان مشکل ایجاد میکنند. برای مثال شما نمیتوانید از یک اسم در دو متغیر مختلف استفاده کنید،شما مجبورید یکی از اسم ها را کمی تغییر دهید. گاهی اوقات اینکار را با تغییر دادن املای کلمات انجام می دهید، در اینصورت ممکن است تصحیح خطاهای املایی باعث مشکل در کامپایل نرم افزار شود. افزودن اعداد یا حروف اضافه هرگز کافی نیست. اگر نام ها باید متفاوت باشند، پس معنی آنها نیز باید فرق کند.اسامی شامل سری اعداد (a1,a2,…,aN) با نام گذاری اصولی در تضاد هستند. این اسم ها اطلاعات غلط نمیدهند،چون اصلا اطلاعاتی نمیدهند و کاملا بی معنی هستند. اینها هیچ سرنخی از منظور شما به دیگران نمیدهند. به مثال نگاه کنید:Public static void copyChars(char a1[], char a2[] { For (int i=0; i<a1.length; i++) { A2\[[i] = a1[i]; } }این تابع خواناتر میشود، اگر از اسم های source و destination در ارگومنت ها استفاده کنیم.حروف اضافه(noise words) موارد بی معنی دیگری هستند. تصور کنید شما کلاسی به اسم Product دارید. اگر شما کلاس های دیگری با اسم های ProductInfo یا ProductData بسازید، شاید اسم های مختلفی انتخاب کرده باشید اما در معنای آنها تفاوتی وجود ندارد. کلمات Info و Data کلمات اضافه هستند، مثل a, an و the . دقت کنید که استفاده از این پیشوند ها مشکلی ندارد، مثلا شما میتوانید از a برای همه متغیر های محلی و از the برای همه ارگومنت های توابعتان استفاده کنید. در حقیقت مشکل از جایی شروع میشود که شما یک متغیر را theZork بنامید، فقط به این دلیل که متغیر دیگری به نام Zork دارید. حروف اضافه ،زائد هستند. کلمه Variabale هیچوقت نباید در اسم یک متغیر نمایان شود. واژه table نباید در اسم یک Table نشان داده شود. چرا فکر میکنید NameString بهتر از Name است؟ آیا ممکن است Name یک عدد اعشاری باشد؟اگر جواب بله است،پس شما کل قوانین را زیر سوال برده اید!فرض کنیدکلاسی به اسم Customer و کلاسی دیگر به اسم CustomerObject دارید.از اختلاف این دو اسم چه چیزی دستگیرتان میشود؟ کدام یک از این دو اسم ، بهتر میتواند تاریخچه پرداخت های یک مشتری را نشان دهد؟ در مثال های زیر استفاده مناسب از حروف اضافه را میبینید.getActiveAccount(); getActiveAccounts(); getActiveAccountInfo();برنامه نویس به راحتی میفهمد که کدام تابع را نیاز دارد.دقت کنید که حروف اضافه چه تغییری در اسم متغیر شما میدهند. تفاوت متغیر moneyAmount از money غیرقابل تشخیص است. تفاوت customerInfo از customer نیز همینطور.accountData از account و theMessage از message. اسامی قابل تشخیص باید تفاوت خود را به خواننده نشان دهند.از اسم های قابل تلفظ استفاده کنیدانسان ها در استفاده از کلمات ماهرند. قسمت های مشخصی از مغز ما به درک مفهوم کلمات اختصاص داده شده اند.مفهوم کلمات ارتباط مستقیمی با تلفظ آنها دارد. مغز ما کلمات را با توجه به تلفظ آنها درک میکند، نه نوشتار آنها. بنابراین، بهتر است از اسم های قابل تلفظ استفاده کنید. اگر نمیتوانید یک اسم را تلفظ کنید، نمیتوانید درباره آن بحث کنید،بدون اینکه مثل یک احمق صدا در بیاورید! "Well,over here on the bee cee arr three cee enn tee we have a pee ess zee kyew int, see?" میتوانید این متن را بخوانید؟ فهمیدید که این موضوع مهم است، چون برنامه نویسی یک فعالیت اجتماعی است. یک کمپانی در برنامه خود ، مفهومی به نام genymdhms دارد (generation date, year, month, day, hour, minute and second ). آنها برای اینکه این اسم را به خاطر بسپارند، قدم زنان میگویند "gen why emm dee aich emm ess". من عادت مسخره ای دارم که در آن هر چیزی را به همان شکلی که نوشته شده میخوانم،پس من شروع کردم به گفتن "gen-yah-mudda-hims." .بعدها این مفهوم توسط جمعی از طراحان و آنالیزور ها به همین اسم نامیده شد، و ما هنوز هم به درآوردن این صدای احمقانه ادامه میدهیم. از آنجایی که این برای ما مثل یک شوخی به حساب می آمد، برای ما بانمک بود. بانمک باشد یا نباشد، ما داریم اسم گذاری ضعیف را تحمل میکنیم. برنامه نویس های جدید ما نیازمند این هستند که این مفهوم را برایشان توضیح دهیم و آنها در مورد دلیل در آوردن این صداهای احمقانه به جای استفاده از قوانین صریح و کلمات بامعنای انگلیسی صحبت میکنند.مقایسه کنید:class DtaRcrd102 { private Date genymdhms; private Date modymdhms; private final String pszqint = “102”; /\* _... \*_/ }باclass Customer { private Date generationTimestamp; private Date modificationTimestamp; private final String recordId = &quot102&quot /\* _... \*_/ };مکالمه عاقلانه اکنون امکان پذیر است:“Hey, Mikey, take a look at this record! The generation timestamp is set to tommorrow’s date! How can that be?"از اسامی قابل جستجو استفاده کنیداسامی تک حرفی و ثابت های عددی این مشکل را دارند که در متن قابل پیداکردن نیستند.احتمالا پیدا کردن MAX_CLASSES_PER_STUDENT در یک متن راحت است، اما مثلا پیدا کردن عدد 7 در یک متن طولانی، سخت و زمان بر است. جستجو ها ممکن است اعداد دیگری را نیز برای شما پیدا کنند، مثل قسمت های عددی اسم فایل ها،ثابت های توابع دیگر و در عبارات گوناگونی که از اعداد با اهداف متفاوتی استفاده میکنند. وقتی یک عدد طولانی استفاده میکنید، ممکن است شخصی رقم هایی را سهوا جابجا کند و همزمان این عدد از جستجوی شما فرار میکند. برای مثال، حرف e ضعیف ترین حرف ممکن برای نامگذاری یک متغیر برای برنامه نویسی است که نیازمند جستجو کردن است. چون این حرف پرکاربردترین حرف در زبان انگلیسی است و در هر عبارتی یافت میشود و باعث میشود حین جستجو هر متنی را که در هر برنامه ای وجود دارد ببینید.در این راستا در هر کدی، نام های طولانی تر، بر نام های کوتاه تر برتری دارند و نام های قابل جستجو بر ثابت ها. به نظر من نام های تک حرفی تنها میتوانند به عنوان متغیر های محلی در متد های کوتاه استفاده شوند. طول یک نام باید با دامنه استفاده آن مطابقت داشته باشد. اگر ممکن است از یک متغیر در چندین محل از یک کد استفاده کنید، ضروری است که یک اسم جستجو-دوست (search- friendly)داشته باشید. یکبار دیگر مقایسه کنیدFor (int j=0; j<34; j++) { S+= (t[j]*4)5; }باint realDaysPerIdealDay = 3; cons tint WORK_DAYS_PER_WEEK = 5; int sum = 0; for (int j=0; j<NUMBER_OF_TASKS; j++) { int realTaskDays = taskEstimate[j] * realDaysPerIdealDay; int realTaskWeeks = (realdays WORK_DAYS_PER_WEEK); sum += realTaskWeeks; }به sum دقت کنید، این اسم کاملا مناسب نیست، اما حداقل قابل جستجو کردن است. نوشتن کد با این نامگذاری ها شاید کمی طولانی تر باشد ، اما این را هم در نظر داشته باشید که پیدا کردن WORK_DAYS_PER_WEEK راحت است زیرا فقط 5 بار از آن استفاده شده.از رمزگذاری خودداری کنیدما به اندازه کافی از رمزنگاری ها برای زیاد کردن دردسرمان استفاده میکنیم، لطفا آن را از چیزی که هست بیشتر نکنید.نام های رمزگذاری شده به سادگی قابل تلفظ نیستند و برای توسعه دهندگان جدید دردسر ایجاد میکنند،زیرا هر کارمند جدید باید زبان رمزنگاری شما را بیاموزد که خود باعث فشار روحی زیادی است.نمادگذاری مجارستانیدر روزهای قبل، وقتی ما روی زبان های name-length-challenged کار میکردیم،این امر را با پشیمانی و بخاطر ضرورت نقض کردیم. Fortran رمزگذاری را اجبار میکرد. نسخه های اولیه BASIC فقط یک حرف به اضافه یک رقم را مجاز میکرد. HungarianNotation (HN) این مرحله را به سطح کاملا جدیدی رساند.و HN در Windows C API بسیار مهم به حساب می آمد،هنگامی که همه چیز یک دسته صحیح یا یک نشانگر طولانی یا یک Voidpointer یا یکی از چندین نوع "رشته" (با کاربرد ها و ویژگی های مختلف) بود. کامپایلر نوع متغیر های ورودی را بررسی نمی کرد، بنابراین برنامه نویسان برای کمک به آن در به خاطر سپردن نوع داده ها نیاز به عصا داشتند.در زبان های مدرن سیستم های بسیار غنی تری داریم و کامپایلر ها می توانند به خاطر بیاورند که هر داده ای از چه نوع است.گذشته از این موضوع،گرایش به کلاسهای کوچکتر و عملکرد های کوتاه تر نیز وجود دارد تا افراد معمولا بتوانند نقطه ی اعلام هر متغیری که میخواهند را ببینند. برنامه نویسان جاوا نیازی به رمزگذاری ندارند.نوع اشیا مشخص است و محیط های ویرایش به گونه ای پیشرفت کرده اند که یک خطای نوع را قبل از اینکه بتوانید برنامه را کامپایل کنید،تشخیص میدهند.پیشوندهای متغیرشما دیگر نیازی به پیشوند m_ در متغیر های محلی(member variable) ندارید. کلاس ها و توابع شما باید به قدری کوچک باشند که نیازی به آنها نباشد و شما باید از یک محیط ویرایش استفاده کنید که اعضا را برجسته و یا رنگی و آنها را متمایز کند.public class Part { private String m_dsc; // The textual description void setName(String name) { M_dsc = name; } }public class Part { String description; void setDescription(String description) { this.description = description; } }علاوه بر این،افراد به سرعت یاد میگیرند که پیشوند ( یا پسوند) را نادیده بگیرند تا بخش بامعنای نام را ببینند. هرچه آن را بیشتر بخوانند، کمترthe را میبینند.در نهایت پیشوندها به صورت تصادفی دیده می شوند و نشانگر کد قدیمی تر هستند.واسط ها (interface) و پیاده سازی هااینها گاهی اوقات مورد خاصی برای رمزگذاری است. به عنوان مثال ، می گویند شما در حال ساخت یک ABSTRACT FACTORY برای ایجاد شکل ها هستید. این factory یک واسط خواهد بود و توسط یک کلاس concrete (کلاسی که همه متد ها را پیاده سازی کند) پیاده سازی خواهد شد. چه اسمی باید برای انها بگذاریم؟ IShapeFactions و ShapeFective؟ من ترجیح می دهم واسط را بدون آراستگی رها کنم .پیشوند i ، که در میان میراث(legacy) این روز ها معمول است ، در بهترین حالت حواس پرتی و در بدترین اطلاعات اضافی است. من نمی خواهم که کاربرانم بدانند که من interface خود را به آنها ارائه می کنم. من فقط می خواهم آنها بدانند که این یک shape factoryاست. بنابراین اگر من باید یا interface یا implementation را رمزگذاری کنم ، implementation را انتخاب می کنم. نام ان را ShapeFactoryImp ، یا حتی CShapeFective ناخوشایند بگذارید، رمزگذاری واسط ها ضروری است.از نگاشت ذهنی خودداری کنیدخوانندگان نباید مجبور باشند که نام انتخابی شما را در ذهنشان به نام دیگری که از قبل می شناسند ترجمه کنند. این مشکل معمولاً ناشی از انتخابی است که نه از دامنه اصطلاحات مسئله استفاده کرده است و نه از دامنه واژه های راه حل.این مشکل مربوط به نام متغیرهای تک حرفی است. مطمئناً یک دامنه نام برای شمارشگر حلقه ای که کوچک باشد و هیچ نام دیگری با آن به تناقض نرسد، i یا j یا k است (هرچند هیچگاه l نامگذاری نمی شود). دلیل این امر آن است که این نامهای تک حرفی از قدیم برای شمارشگر حلقه استفاده شده اند. با این وجود ، در بیشتر زمینه های دیگر ، یک نام تک حرفی انتخاب بدی است. این انتخاب تنها یک جایگزین است که خواننده باید در ذهن خود آن را به مفهومی واقعی نگاشت کند. دلیلی بدتر از اینکه a و b قبلاً استفاده شده بود برای استفاده از نام c نمی تواند وجود داشته باشد.به طور کلی برنامه نویسان افراد بسیار باهوشی هستند. افراد باهوش گاهی دوست دارند با نشان دادن توانایی های ذهنی خود ، هوشمندی خود را به معرض نمایش بگذارند. از این گذشته ، اگر با اطمینان بتوانید به یاد داشته باشید که r نسخه کوتاه شده از آدرس url با میزبان و شمای حذف شده است ، پس مشخصا باید بسیار باهوش باشید.یک تفاوت بین یک برنامه نویس هوشمند و یک برنامه نویس حرفه ای در این است که حرفه ای می فهمد که شفافیت پادشاه است. حرفه ای ها به خوبی از توانایی های خود برای نوشتن کدی که دیگران می توانند آن را درک کنند استفاده می کنند.نام کلاس هاکلاسها و اشیاء باید دارای نام یا عبارت اسمی مانند Customer ، WikiPage ، Account و AdressParser باشند. از کلماتی مانند Manager ، Processor ، Data یا Info برای نام کلاس خودداری کنید.نام کلاس نباید یک فعل باشد.نام متدهااسم متدها باید دارای فعل یا عبارت فعلی مانند postPayment ، DeletePage یا save باشند. Accessorها، mutator ها و predicate ها را باید با مقدار خودشان نامگذاری کرد و با در نظر گرفتن استانداردهای javabean، با پیشوندهای get، set و is نام گذاری کرد.String name = employee.getName(); customer.setName(&quotmike&quot) if (paychech.isPosted()) ...زمانی که متدهای سازنده(cunstructor) زیاد شوند، از factory method های static با نام هایی که متغیرها را توصیف کنند استفاده کنید. به عنوان مثال،Complex FulcrumPoint = Complex.FromRealNumber(23.0);به طوور کلی بهتر است از :Complex FulcrumPoint = new Complex(23.0);در نظر بگیرید که با private کردن متدهای سازنده مربوطه ، بر استفاده از آنها تاکید کنید.بانمک نباشیداگر نام ها خیلی هوشمندانه باشند ، فقط در ذهن افرادی که از نظر شوخ طبعی به نویسنده شبیه هستند، و فقط تا زمانی که این افراد این شوخی را به خاطر می آورند، ماندگار می شوند. آیا آنها می دانند تابعی به نام HolyHandGrenade قرار است چه کاری انجام دهد؟ مطمئنا ، بانمک است ، اما شاید در این حالت DeleteItems نام بهتری باشد. شفافیت را در برابر سرگرمی انتخاب کنید.بامزگی در کد اغلب به شکل محاوره یا زبان عامیانه ظاهر می شود. به عنوان مثال ، از نام whack به جای kill استفاده نکنید. از شوخی های خاص در یک فرهنگ مانند eatMyShors به جای abort استفاده نکنید.آن چیزی را بگویید که منظورتان است. منظورتان همان چیزی است که می گویید.برای هر مفهوم یک کلمه انتخاب کنیدیک کلمه را برای یک مفهوم مجزا انتخاب کنید و به آن بچسبید. به عنوان مثال ، fetch ، retrieve و get به عنوان نام متد های معادل در کلاسهای مختلف گیج کننده است. چگونه به یاد خواهید آورد که نام کدام متد در کدام کلاس ذکر شده است؟ متأسفانه ، شما اغلب باید به خاطر داشته باشید كه كدام شركت ، گروه یا فرد كتابخانه یا كلاس را نوشته است تا بتوانید به یاد آورید که كدام اصطلاح استفاده شده است. در غیر این صورت ، شما زمان بسیار زیادی را صرف مرور در header ها و نمونه کد های قبلی می کنید.محیطهای ویرایش مدرن مانند Eclipse و IntelliJ- سرنخهای حساس به متن(context-sensitive clues) مانند لیست متدهایی که می توانید در یک شی خاص فراخوانی کنید را فراهم می کنند. اما توجه داشته باشید که این لیست معمولاً comment هایی را که شما در مورد نام تابع و لیست پارامترهای خود نوشتید به شما نمی دهد. خوش شانس باشید، بتواند نام پارامترها را از توصیف توابع به شما ارائه دهد. اسامی توابع باید مستقل واضح باشند، و آنها باید سازگار باشند تا شما بتوانید متد صحیح را بدون جستجوهای اضافی انتخاب کنید.به همین ترتیب ، داشتن یک Controller و یک manager و یک driver در یک پایگاه کد گیج کننده است. تفاوت اساسی بین DeviceManager و ProtocolController چیست؟ چرا هر دو Controller نیستند یا هر دو manager نیستند؟ آیا آن دو واقعاً driver هستند؟ این نام ها باعث می شود که شما توقع دو شی که از نظر نوع و کلاس هایشان بسیار متفاوت هستند را داشته باشید.واژه نامه نامتناقض یک لطف بزرگ به برنامه نویسانی است که باید از کد شما استفاده کنند.با ایهام ننویسیداز استفاده از یک کلمه برای دو منظور مختلف خودداری کنید. استفاده از یک اصطلاح یکسان برای دو ایده متفاوت در اصل یک ایهام است.اگر از قانون "یک کلمه برای هر مفهوم" پیروی کنید ، می بینید که بسیاری از کلاس ها مثلا یک متد add دارند. تا زمانی که لیست پارامترها و مقادیر برگشتی در متدهای مختلف add معنایی معادل داشته باشند، همه چیز خوب است.اما ممکن است شخص تصمیم بگیرد از کلمه add وقتی که منظورش افزودن نیست استفاده کند و تنها بخواهد سازگاری ایجاد کند. بیایید بگوییم که ما کلاسهای زیادی داریم که در آنها با اضافه کردن یا ملحق کردن دو مقدار موجود، مقدار جدیدی ایجاد میشود. حال فرض کنیم ما در حال نوشتن یک کلاس هستیم که متدی در آن است که یک پارامتر را درون یک مجموعه می گذارد. آیا باید این متد را add بنامیم؟ ممکن است به این دلیل که متدهای add دیگری داریم، سازگار به نظر برسد، اما در این حالت، مفاهیم متفاوت هستند، بنابراین باید به جای آن از اسمی مانند insert یا append استفاده کنیم. نامیدن متد جدید به add ایهام ایجاد میکند.هدف ما ، به عنوان نویسنده ، این است که کدهای خود را تا جایی که میتوانیم قابل درک کنیم. ما می خواهیم کد ما به جای اینکه یک مطالعه عمیق و مفهومی باشد، سریع خوانده شود. ما می خواهیم از مدل رایج کتاب های کاغذی استفاده کنیم که به موجب آن نویسنده وظیفه دارد منظور خود را شفاف سازد و نه مدل دانشگاهی كه در آن محققان وظیفه دارند مفاهیم و معانی را از مقاله ها استخراج کنند.از دامنه واژگان مربوط به راه حل استفاده کنیدبه یاد داشته باشید افرادی که کد شما را می خوانند ، برنامه نویس هستند. بنابراین از اصطلاحات علوم کامپیوتر، نام الگوریتم ها، نام الگوها ، اصطلاحات ریاضی و موارد دیگر استفاده کنید. عاقلانه نیست که هر نام را از دامنه صورت مسئله انتخاب کنیم زیرا ما نمی خواهیم همکاران ما مجبور به فرار از مشتری ای باشند که چون هر مفهوم را با نام دیگری میشناسد، معنی هر کلمه را می پرسد.نام AccountVisitor برای یک برنامه نویس که با الگوی VISITOR آشنا است بسیار پر معنی است. چه برنامه نویسی نمی داند JobQueue چیست؟ موارد فنی بسیار زیادی وجود دارد که برنامه نویسان باید انجام دهند. انتخاب نام های فنی برای آن موارد معمولاً مناسب ترین روش است.از دامنه واژگان صورت مسئله استفاده کنیدوقتی "اصطلاح برنامه نویسی" برای کاری که انجام می دهید وجود ندارد ، از دامنه صورت مسئله برای انتخاب نام استفاده کنید. حداقل برنامه نویسی که کد شما را نگهداری میکند می تواند از یک متخصص دامنه سوال کند که منظور چیست.جدا کردن دامنه راه حل و صورت مسئله بخشی از کار یک برنامه نویس و طراح خوب است. کدی که ارتباط بیشتری با مفاهیم مربوط به صورت مسئله دارد باید دارای نامهایی باشد که از دامنه صورت مسئله گرفته شده است.ساختار های با معنی اضافه کنیدتنها چند نام وجود دارند که به خودی خود معنی دارند و اکثر نام ها به خودی خود بی معنی اند. درعوض، باید با قرار دادن آنها در کلاسها ، توابع یا مکانهای نامگذاری شده، خوانندتان را در جریان وضوع قرار دهید. وقتی همه موارد دیگر شکست بخورد ، ممکن است استفاده از پیشوند برای نام به عنوان آخرین راه حل اساسی مورد استفاده قرار گیرد. تصور کنید که متغیرهایی با اسامی firstName، lastName ، street ، houseNumber ، city ، state و zipcode دارید. آنها به طور واضح در کنار هم یک آدرس را تشکیل می دهند. اما اگر متغیر state را به تنهایی در یک تابع دیدید چه؟ آیا به طور خودکار استنباط می کنید که این متغیر بخشی از یک آدرس است؟ می توانید پیشوندهایی را به متن اضافه کنید: addrFirstName ، addrLastName ، addrState و غیره. حداقل خوانندگان خواهند فهمید که این متغیرها بخشی از یک ساختار بزرگتر هستند. البته یک راه حل بهتر ایجاد کلاس با نام Address است. سپس، حتی کامپایلر هم می داند که متغیرها متعلق به یک ساختار بزرگتر هستند. متد موجود در Listing 2-1 را در نظر بگیرید. آیا متغیرها به یک ساختار معنی دار تر نیاز دارند؟ نام تابع تنها بخشی از ساختار, و الگوریتم بقیه را ارائه میدهد. پس از خواندن این تابع ، می بینید که سه متغیر ، number، verb و pluralModifier بخشی از پیام "guess statistics" هستند. متأسفانه، مفهوم باید حدس زده شود. وقتی برای اولین بار به متد نگاه می کنید ، معنی متغیرها مبهم است.Listing 2-1 Variables with unclear context.private void printGuessStatistics(char candidate, int count) { String number; String verb; String pluralModifier; if (count == 0) { number = &quotno&quot verb = &quotare&quot pluralModifier = &quots&quot } else if (count == 1) { number = &quot1&quot verb = &quotis&quot pluralModifier = &quot&quot } else { number = Integer.toString(count); verb = &quotare&quot pluralModifier = &quots&quot } String guessMessage = String.format( &quotThere %s %s %s%s&quot, verb, number, candidate, pluralModifier ); print(guessMessage); }این تابع کمی طولانی است و از متغیرها در کل آن استفاده می شود. برای تقسیم تابع به قطعات کوچکتر باید یک کلاس GuessStatisticsMessage ایجاد کنیم و سه فیلد متغیر این کلاس را بسازیم. بدین ترتیب یک متن واضح را برای سه متغیر فراهم می کنیم. آنها به طور قطع بخشی از GuessStatisticsMessage هستند. بهبود زمینه همچنین به الگوریتم اجازه می دهد تا با شکستن شدن به توابع کوچکتر، بسیار تمیزتر شود.Listing 2-1 Variables with unclear context.private void printGuessStatistics(char candidate, int count) { String number; String verb; String pluralModifier; if (count == 0) { number = &quotno&quot verb = &quotare&quot pluralModifier = &quots&quot } else if (count == 1) { number = &quot1&quot verb = &quotis&quot pluralModifier = &quot&quot } else { number = Integer.toString(count); verb = &quotare&quot pluralModifier = &quots&quot } String guessMessage = String.format( &quotThere %s %s %s%s&quot, verb, number, candidate, pluralModifier ); print(guessMessage); }این تابع کمی طولانی است و از متغیرها در کل آن استفاده می شود. برای تقسیم تابع به قطعات کوچکتر باید یک کلاس GuessStatisticsMessage ایجاد کنیم و سه فیلد متغیر این کلاس را بسازیم. بدین ترتیب یک متن واضح را برای سه متغیر فراهم می کنیم. آنها به طور قطع بخشی از GuessStatisticsMessage هستند. بهبود زمینه همچنین به الگوریتم اجازه می دهد تا با شکستن شدن به توابع کوچکتر، بسیار تمیزتر شود.Listing 2-2 Variables have a context.public class GuessStatisticsMessage { private String number; private String verb; private String pluralModifier; public String make(char candidate, int count) { createPluralDependentMessageParts(count); return String.format( &quotThere %s %s %s%s&quot, verb, number, candidate, pluralModifier ); } private void createPluralDependentMessageParts(int count) { if (count == 0) { thereAreNoLetters(); } else if (count == 1) { thereIsOneLetter(); } else { thereAreManyLetters(count); } } private void thereAreManyLetters(int count) { number = Integer.toString(count); verb = &quotare&quot pluralModifier = &quots&quot } private void thereIsOneLetter() { number = &quot1&quot verb = &quotis&quot pluralModifier = &quot&quot } private void thereAreNoLetters() { number = &quotno&quot verb = &quotare&quot pluralModifier = &quots&quot } }Listing 2-1 Variables with unclear context.private void printGuessStatistics(char candidate, int count) { String number; String verb; String pluralModifier; if (count == 0) { number = &quotno&quot verb = &quotare&quot pluralModifier = &quots&quot } else if (count == 1) { number = &quot1&quot verb = &quotis&quot pluralModifier = &quot&quot } else { number = Integer.toString(count); verb = &quotare&quot pluralModifier = &quots&quot } String guessMessage = String.format( &quotThere %s %s %s%s&quot, verb, number, candidate, pluralModifier ); print(guessMessage); }این تابع کمی طولانی است و از متغیرها در کل آن استفاده می شود. برای تقسیم تابع به قطعات کوچکتر باید یک کلاس GuessStatisticsMessage ایجاد کنیم و سه فیلد متغیر این کلاس را بسازیم. بدین ترتیب یک متن واضح را برای سه متغیر فراهم می کنیم. آنها به طور قطع بخشی از GuessStatisticsMessage هستند. بهبود زمینه همچنین به الگوریتم اجازه می دهد تا با شکستن شدن به توابع کوچکتر، بسیار تمیزتر شود.Listing 2-2 Variables have a context.public class GuessStatisticsMessage { private String number; private String verb; private String pluralModifier; public String make(char candidate, int count) { createPluralDependentMessageParts(count); return String.format( &quotThere %s %s %s%s&quot, verb, number, candidate, pluralModifier ); } private void createPluralDependentMessageParts(int count) { if (count == 0) { thereAreNoLetters(); } else if (count == 1) { thereIsOneLetter(); } else { thereAreManyLetters(count); } } private void thereAreManyLetters(int count) { number = Integer.toString(count); verb = &quotare&quot pluralModifier = &quots&quot } private void thereIsOneLetter() { number = &quot1&quot verb = &quotis&quot pluralModifier = &quot&quot } private void thereAreNoLetters() { number = &quotno&quot verb = &quotare&quot pluralModifier = &quots&quot } } متن(context) بیخود اضافه نکنید در یک برنامه فرضی به نام “Gas Station Deluxe” ، این که هر کلاس با پیشوند GSD شروع شود ایده بدی است. صادقانه بگویم، شما با این کار در برابر ابزارهای خود می ایستید. G را تایپ می کنید و کلید تکمیل را فشار می دهید و با یک لیست بلند بالا از تمام کلاس های سیستم مواجه می شوید. این عاقلانه است؟ چرا راه کمک را برای IDE دشوار میکنید؟ به همین ترتیب ، بیایید بگوییم که شما یک کلاس به نام MailingAddress را در ماژول حسابداری GSD نوشته اید و نام آن را GSDAccountAddress گذاشتید. بعداً ، برای تماس با مشتری خود به یک آدرس پستی نیاز دارید. آیا از GSDAccountAddress استفاده می کنید؟ آیا این نام مناسب به نظر می رسد؟ 10 تا از 17 کاراکتر زائد یا بی ربط هستند. معمولا تا زمانی که نامهای کوتاهتر واضح باشند، از نامهای طولانی تر بهتر هستند. هیچ متنی بیشتر از آن چیزی که لازم است، به یک نام اضافه نکنید. نام های accountAddress و customerAddress نام های خوبی برای نمونه های کلاس Address هستند اما برای نام کلاس ها مناسب هستند. Address یک نام خوب برای یک کلاس است. اگر نیاز به تفکیک بین آدرس های MAC ، آدرس پورت ها و آدرس های وب داشته باشم ، ممکن است PostalAddress ، MAC و URI را در نظر بگیرم. نامهای به دست آمده دقیق تر هستند، و این، هدف همه نامگذاری ها است.سخن پایانیسخت ترین کار در انتخاب نام های خوب این است که به مهارت های توصیفی خوب و پیشینه فرهنگی مشترک نیاز دارد. این مسئله یک مسئله فنی، تجاری یا مدیریتی نیست بلکه یک موضوع آموزشی است. در نتیجه بسیاری از افراد یاد نمی گیرند که این کار را به درستی انجام دهند. مردم همچنین از ترس اینکه برخی از توسعه دهندگان دیگر مورد تخریب قرار گیرند، از تغییر نام چیزها می ترسند. ما این ترس را نداریم و وقتی اسم ها به چیز بهتری تغییر می کنند واقعاً سپاسگزاریم. بیشتر مواقع ما واقعا نام کلاس ها و متدها را به خاطر نمی آوریم. ما از ابزارهای مدرن برای کلنجار رفتن با جزئیاتی از این دست استفاده می کنیم تا بتوانیم تمرکز خود را بر این مسئله بگذاریم که آیا کد باید مانند پاراگراف ها و جملات خوانده شود، یا شبیه به جدول ها و ساختار داده ها (یک جمله همیشه بهترین راه برای نمایش داده ها نیست). احتمالاً وقتی چیزها را تغییر نام دهید، دقیقاً مانند هر بهبود دیگری در کد، افراد را شگفت زده خواهید کرد. اجازه ندهید که این مسئله شما را در مسیرتان متوقف کند. برخی از این قوانین را دنبال کنید و ببینید آیا خوانایی کد خود را بهبود می بخشید یا خیر. اگر کد شخص دیگری را نگهداری می کنید ، برای حل این مشکلات از ابزارهای refactoring استفاده کنید. در کوتاه مدت نتیجه را می بینید و درازمدت به افزایش بهبودها ادامه می دهد. Noah Noah Sun, 26 Apr 2020 08:45:50 +0430 https://virgool.io/@dndshmdr/%D8%AA%D8%B1%D8%AC%D9%85%D9%87-%D9%81%D8%B5%D9%84-%D8%A7%D9%88%D9%84-clean-code-%DA%A9%D8%AF-%D8%AA%D9%85%DB%8C%D8%B2-ax3amclpsdzi چند هفته پیش پروژه ترجمه گروهی کتاب clean code رو کلید زدم و الان دو فصل از کتاب ترجمه شده. هر چند به خاطر تعداد کم مترجمان فعال این کار خیلی کند پیش میره ولی داریم سعی میکنیم که متوقف نشه. این پروژه روی گیتهاب گذاشته شده و اگر مایل بودید میتونید یک پاراگراف از کتاب رو ترجمه کنید.(صفحه گیت هاب). در ضمن این متن مستقیما از گیت هاب کپی شده و اگر جایی مشکلی داشت بهتره از همون گیتهاب مطالعه کنید. و همچنین اگر اشتباه تایپی یا املایی و یا حتی از نظر روان بودن ترجمه مشاهده کردید لطفا توی گیت هاب اونو اصلاح کنید. اگر از این پست راضی بودید لایک کنید تا افراد بیشتری جذب این پروژه بشن.لطفا به ازای هر پاراگراف از این پست که برات مفید بوده, یک کلمه از فصل سه رو در گیتهاب ترجمه کن بعد از خواندن این فصل میتونید فصل دوم رو شروع کنید https://virgool.io/@dndshmdr/%D8%AA%D8%B1%D8%AC%D9%85%D9%87-%D9%81%D8%B5%D9%84-%D8%AF%D9%88%D9%85-clean-code-%D8%A7%D8%B3%D8%A7%D9%85%DB%8C-%D8%A8%D8%A7-%D9%85%D8%B9%D9%86%DB%8C-aelqqffftac7 فصل اول ： کد تمیزبه دو دلیل شما در حال خواندن این کتاب هستید: یک: شما یک برنامه نویسید. دو: می خواهید برنامه نویس بهتری شوید. خوب است. ما به برنامه نویس های بهتری نیاز داریم. این یک کتاب در مورد برنامه نویسی خوب است.این کتاب با کد پر شده است. ما به کد از جنبه های مختلفی نگاه خواهیم کرد. از دیدگاه بالا به آن نگاه میکنیم، از دیدگاه پایین، و از درون به بیرون آن را بررسی میکنیم. وقتی کار ما تمام شد، در مورد کد اطلاعات زیادی داریم. به علاوه، قادر خواهیم بود تفاوت میان کد خوب و کد بد را بیان کنیم. ما خواهیم دانست که چگونه یک کد خوب بنویسیم. و خواهیم دانست که چگونه یک کد بد را به یک کد خوب تبدیل کنیم.کد وجود خواهد داشتممکن است شخصی بگوید یک کتاب در مورد کد به نوعی مربوط به زمان های گذشته است. کد دیگر مسئله اصلی نیست. در عوض ما باید در مورد مدلها و نیازمندیها نگران باشیم. در واقع بعضی از افراد پیشنهاد کرده اند که ما به پایان دوران کدنویسی نزدیک هستیم. به زودی تمام کدها به جای نوشته شدن، تولید خواهند شد. برنامه نویسان دیگر مورد نیاز نخواهند بود زیرا تجار برنامه را از مشخصات تولید خواهند کرد. چرت است!ما هیچگاه از کدها خلاص نخواهیم شد، زیرا کد جزییات نیازمندی ها را نشان میدهد. در بعضی سطح ها آن جزییات نمی توانند نادیده گرفته شوند یا کلی نگری (abstract)شوند. آنها باید مشخص باشند. و مشخص کردن نیازمندی ها با چنان جزییاتی که یک ماشین بتواند آنها را اجرا کند برنامه نویسی است. چنین مشخصه ای کد است. من انتظار دارم که سطح انتزاع زبان ها به گسترش خود ادامه دهد. من همچنین انتظار دارم که تعداد زبان های مختص دامنه(domain-specifid- زبان هایی که برای محدوده خاصی از مسائل ساخته شده اند) رشد پیدا کند. این مسئله خوب است. اما باعث حذف کد نمی شود.در واقع تمام مشخصات نوشته شده در این زبان های سطح بالا و مختص دامنه، "کد" خواهند بود! این کد همچنان نیاز دارد که سختگیرانه، دقیق، و بسیار رسمی و جزیی باشد تا یک ماشین بتواند آن را بفهمد و اجرا کند. گروهی که فکر میکنند که یک روز کد میتواند ناپدید شود شبیه به ریاضی دانانی هستند که امید دارند یک روز یک تعریف یا فرمول ریاضی را کشف کنند که نیاز نداشته باشد که رسمی باشد. آنها امید دارند که یک روز راهی برای ساختن ماشینهایی کشف کنند که میتواند چیزی را که ما میخواهیم به جای چیزی که میگوییم انجام دهند. این ماشینها باید قادر باشند که آنقدر خوب ما را بفهمند که نیازمندیهای خاص و مبهم را به برنامه های کاملا قابل اجرا که با دقت آن نیازمندی ها را مرتفع میکنند، ترجمه کنند. این اتفاق هیچگاه نمی افتد. حتی انسان ها با تمام بینش و خلاقیتشان قادر به ساخت موفق سیستم ها از احساسات مبهم مشتریان نیستند.در واقع اگر نظم نیازمندیهای مشخصات چیزی به ما آموخته باشد، آن این است که نیازمندی های دقیق توصیف شده به اندازه کد رسمی هستند و می توانند به عنوان تست های قابل اجرایی از کد عمل کنند! به خاطر داشته باشید که کد زبانی است که در نهایت با آن نیازمندیها را بیان میکنیم. ممکن است ما زبانهایی بسازیم که به نیازمندی ها نزدیکتر باشند. ممکن است ما ابزارهایی بسازیم که به ما در براورده کردن و سرهمبندی این نیازمندیها با ساختارهای رسمی کمک کنند. اما ما هرگز دقت لازم را حذف نمیکنیم . پس کد وجود دارد.کد بداخیرا یک پیشگفتار از کتاب Implementation Patterns نوشته Kent Beck خوانده ام. او می گوید :"... این کتاب بر مبنای یک فرضیه ضعیف بنا شده است: این که کد خوب مهم است ..." یک فرضیه ضعیف؟ من مخالفم! من فکر میکنم آن فرضیه یکی از بیشمار فرضیه های گسترش یافته، مورد حمایت، و پربار در حرفه ماست(و فکر میکنم Kent این را می داند.) ما می دانیم که کد خوب مهم است زیرا ما زمان زیادی ناچار بودیم با نبود آن کنار بیاییم.من یک شرکت را میشناسم که در اواخر دهه 80 یک برنامه killer نوشته است. این برنامه خیلی معروف بود و تعداد زیادی از افراد حرفه ای آن را خریده و استفاده کردند. اما پس از آن، چرخه انتشار شروع به کش آمدن کرد. از یک انتشار تا انتشار بعدی باگها تعمیر نشدند. زمان بارگذاری افزایش یافت و crash افزایش یافت. من به خاطر دارم که یک روز من آن محصول را با ناامیدی پاک کردم و دیگر هیچگاه از آن استفاده نکردم. مدت کمی پس از آن، آن شرکت از صحنه تجارت خارج شد. دو دهه بعد من یکی از اولین کارکنان آن شرکت را دیدم و از او پرسیدم که چه اتفاقی افتاد. آن پاسخ، ترس های من را تایید کرد. آنها در عرضه محصول به بازار عجله کرده بودند و حجم عظیمی از کد را درست کرده بودند. هرچه آنها ویژگی های بیشتر و بیشتری اضافه کردند، کد بدتر و بدتر شد تا زمانی که دیگر آنها نتوانستند آن را مدیریت کنند.این کد بد بود که آن شرکت را نابود کرد. آیا تا کنون توسط یک کد بد به مشکل خورده اید؟ اگر شما یک برنامه نویس با هر سطح از تجربه باشید آنگاه شما در مواقع زیادی این مانع را احساس کردید.حتی یک نام برای آن داریم. ما آن را به سختی راه رفتن(wading) صدا میکنیم.ما در طول یک کد بد به سختی راه میرویم. ما در باتلاقی از خاربن های در هم تنیده و تله های مخفی تقلا میکنیم. ما برای یافتن مسیر، به امید چند اشاره، چند سر نخ از اینکه چه اتفاقی در شرف وقوع است تقلا میکنیم اما تمام چیزی که میبینیم کدهای بی معنی بیشتر و بیشتر است. قطعا شما با کدهای بد به مشکل برخورده اید. خب چرا آنها را نوشتید؟ می خواستید سریع پیش بروید؟ عجله داشتید؟احتمالا بله. احتمالا شما احساس کردید که زمان کافی برای انجام یک کار خوب ندارید؛ رئیس شما از شما عصبانی میشود اگر برای تمیز کردن کدتان زمان هدر دهید. احتمالا شما از کار کردن بر روی این برنامه خسته شده بودید و میخواستید تمام شود. یا شاید شما به کارهای ناتمام بقیه کارمندانی که به آنها قول داده بودید که کار را انجام می دهید نگاه کردید و متوجه شدید که نیاز دارید تا ماژولها را به یکدیگر بچسبانید تا بتوانید کارها را به مرحله بعد ببرید. همه ما این کارها را انجام دادیم. همه ما به ریخت و پاشی که درست کرده بودیم نگاه کردیم و سپس انجام آن را به روز دیگر موکول کردیم. همه ما آسودگی ناشی از کار کردن برنامه نامرتب خودمان را حس کردیم و تصمیم گرفتیم که انجام کار شلخته بهتر از هیچ کاری است. .همه ما گفتیم بعدا که برمیگردیم، آن را تمیز میکنیم. قطعا در آن روزها ما قانون LeBlanc را نمیشناختیم : بعدا یعنی هیچوقت.هزینه کلی مالک یک شلختگی بودناگر بیش از دو یا سه سال است که برنامه نویس بوده اید ، احتمالاً با کد کثیف شخص دیگری معطل مانده اید. میزان معطل بودن می تواند قابل توجه باشد. طی یک بازه زمانی یک یا دو ساله، تیم هایی که در ابتدای یک پروژه بسیار سریع در حال حرکت بودند ، خود را در حال حرکت با سرعت حلزونی می بینند. هر تغییری که در کد ایجاد کنند ، دو یا سه قسمت دیگر کد را خراب می کند. تغییر ندادن مهم است. هرگونه افزودن یا تغییر در سیستم مستلزم این است که گره خوردگی ها، پیچ و تاب ها و مشکلات "درک شوند" تا بتوانید تعداد بیشتری گره و پیچ و تاب اضافه کنید. با گذشت زمان شلختگی بسیار بزرگ و عمیق و بسیار بلند می شود ، به گونه ای که نمی توان آن ها را تمیز کرد. اصلاً راهی نیست. با ساخته شدن شلختگی، بهره‌وری تیم همچنان رو به کاهش می رود، و در نهایت به صفر نزدیک می شود. با کاهش بهره وری ، مدیریت تنها کاری که می تواند را انجام می دهد؛ آنها به امید افزایش بهره وری کارکنان بیشتری را به این پروژه اضافه می کنند. اما آن کارکنان جدید سیستم را نمی شناسند. آنها تفاوت بین تغییری را که منطبق با هدف طراحی انجام میشود و تغییری که هدف طراحی راناکارآمد می کند، نمی دانند. علاوه بر این ، آنها و هر کس دیگری که در تیم حضور دارند ، تحت فشارهای هولناکی برای افزایش بهره وری قرار دارند. بنابراین همه آنها بیشتر و بیشتر باعث شلختگی می شوند و باعث می شوند که بازدهی هر چه بیشتر به سمت صفر برسد. (شکل 1-1 را ببینید.)طراحی مجدد بزرگ در اسمانسرانجام تیم شورش می کند. آنها به مدیریت اطلاع می دهند که نمی توانند بر مبنای این کد نفرت انگیز محصولی را توسعه دهند. آنها خواستار طراحی مجدد هستند. مدیریت نمی خواهد که منابع را صرف طراحی مجدد پروژه کند ، اما آنها نمی توانند انکار کنند که بهره وری وحشتناک است. سرانجام آنها به خواسته های توسعه دهندگان تن می دهند و اجازه انجام طراحی مجدد بزرگ در اسمان را می دهند.یک تیم جدید قوی انتخاب شده است. همه دوست دارند در این تیم حضور داشته باشند زیرا این یک پروژه Greenfield است. آنها دوباره شروع به کار می کنند و چیزی زیبا را ایجاد می کنند. اما فقط بهترین ها و درخشان ترین ها برای تیم قوی انتخاب می شوند. همه افراد دیگر باید به حفظ سیستم فعلی ادامه دهند. اکنون دو تیم در رقابت هستند. تیم قوی باید سیستم جدیدی بسازد که هر آنچه را که سیستم قدیمی انجام می دهد انجام دهد. نه تنها این ، آنها باید با تغییراتی که به طور مداوم در سیستم قدیمی انجام می شود ، به روز باشند. مدیریت تا زمانی که سیستم جدید نتواند کارهایی را که سیستم قدیمی انجام می دهد، انجام دهد، سیستم جدید را جایگزین سیستم قدیمی نخواهد کرد. این رقابت می تواند برای مدت زمان طولانی ادامه یابد. من دیده ام که 10 سال طول کشید. و زمانی که این کار انجام شد، اعضای اصلی تیم قوی مدتها بود که از تیم رفته بودند ، و اعضای فعلی خواستار طراحی مجدد سیستم جدید هستند زیرا این سیستم بسیار شلخته است.اگر حتی یک بخش کوچک از داستانی را که تعریف کردم تجربه کرده اید ، پس می دانید که صرف وقت برای تمیز کردن کد خود صرفاً مقرون به صرفه نیست. این یک کار حرفه ای برای بقا است.نگرشآیا تا به حال آنقدر با شلختگی ها کلنجار رفته اید که کاری را که در طی چند ساعت می توانستید انجام دهید، هفته ها طول بکشد؟ آیا دیده اید که چیزی که میتواست با تغییر یک خط ایجاد شود ، در عوض در تغییر در صدها ماژول مختلف انجام شد؟ این علائم بسیار شایع است. چرا این اتفاق برای کد می افتد؟ چرا کد خوب خیلی سریع به کد بد تبدیل میشود؟ توضیحات زیادی برای آن داریم. ما شاکی هستیم که نیازمندی ها به گونه ای تغییر یافته که طرح اصلی را خنثی می کند. ما ناراحتیم که برنامه ها برای انجام درست کارها بسیار فشرده بودkn. ما در مورد مدیران احمق و مشتریان عجول و انواع بازاریابی های بی فایده و ضد عفونی کننده های تلفنی صحبت می کنیم. اما Dilbert عزیز ، مشکل در سرنوشت ما نیست ، بلکه در خودمان است. ما غیر حرفه ای هستیم.ممکن است پذیرش این حقیقت تلخ، مشکل باشد. چطور ممکن است این شلختگی تقصیر ما باشد؟در مورد نیازمندی ها چطور؟ در مورد برنامه چطور؟ در مورد مدیران احمق و انواع بی فایده بازاریابی چطور؟ آیا آنها مقصر نیستند؟ خیر. مدیران و بازاریابان برای دریافت اطلاعاتی که برای وعده ها و تعهدات لازم دارند ، به ما نگاه می کنند. و حتی وقتی آنها به ما نگاه نمی کنند ، ما نباید از گفتن آنچه که فکر می کنیم شرمنده باشیم. کاربران به ما نگاه می کنند تا تصدیق کنند که ما چگونه سیستم را با نیازمندی ها پر میکنیم. مدیران پروژه از ما انتظار دارند که به پیش برد برنامه کمک کنیم. ما عمیقا درگیر برنامه ریزی پروژه هستیم و مسئولیت هرگونه خرابی را به عهده میگیریم. به خصوص اگر این شکستها مربوط به کد بد باشند! "اما صبر کنید!" شما بگویید. "اگر آنچه را که مدیر من می گوید ، انجام ندهم ، اخراج می شوم." احتمالا نه. اکثر مدیران حقیقت را می خواهند ، حتی اگر چنین رفتار نکنند. اکثر مدیران کدهای خوبی می خواهند ، حتی وقتی در مورد برنامه وسواس دارند. آنها ممکن است با شور و شوق از برنامه ها و نیازمندی ها دفاع کنند؛ اما این کار آنهاست این وظیفه شماست که با اشتیاق برابر، از کد دفاع کنید. برای اینکه این مسئله برای شما جا بیفتد ، چه می شود اگر شما یک پزشک باشید و یک بیمار داشته باشید که به این دلیل که شستن دستها قبل از عمل جراحی زمان زیادی میبرد، خواستار جلوگیری از این کار احمقانه باشد ؟(هنگامی که برای اولین بار در سال 1847 توسط Ignaz Semmelweis به پزشکان توصیه شد دستهای خود را بشویند ، این توصیه به دلیل اینکه سر پزشکان خیلی شلوغ بود و وقت نداشتند میان ویزیت بیماران دستهای خود را بشویند رد شد.) به وضوح بیمار رئیس است. و با این وجود پزشک کاملاً باید از انجام عمل خودداری کند. چرا؟ زیرا پزشک بیشتر از بیمار از خطرات بیماری و عفونت اطلاع دارد. این که پزشک مطابق با خواست بیمار عمل کند (حتی اگر مجرمانه نباشد) غیرحرفه ای است . به همین ترتیب غیر حرفه ای است که برنامه نویسان به خواسته مدیرانی که ریسک ایجاد شلختگی ها را نمی فهمند تن در دهند.مسئله بغرنج اصلیبرنامه نویسان با مجموعه ای از مسائل پایه ای روبرو هستند. همه توسعه دهندگان با بیش از چند سال تجربه می دانند که شلختگی های قبلی آنها را کند می کند. و با این وجود همه توسعه دهندگان فشار ناشی از ایجاد شلختگی را احساس می کنند زیرا باید به ضرب الاجل برسند. به طور خلاصه ، آنها وقت لازم را برای حرکت سریع ندارند! حرفه ای ها می دانند که قسمت دوم این مسئله اشتباه است. شما با ایجاد شلختگی به ضرب الاجل نمیرسید. در واقع ، شلختگی فورا شما را کند می کند و شما را مجبور می کند که ضرب الاجل را از دست بدهید. تنها راه برای رسیدن به ضرب الاجل- تنها راه سریع پیشبرد کار- این است که همیشه کد را تا حد ممکن تمیز نگه دارید.هنر کد تمیز؟بیایید بگوییم شما معتقد هستید که کد کثیف مانع قابل توجهی است. بیایید بگوییم که شما می پذیرید که تنها راه پیشبرد سریع، تمیز نگه داشتن کدهایتان است. سپس باید از خود بپرسید: "چگونه می توانم کد تمیز بنویسم؟" اگر نمی دانید تمیز بودن کد چیست ، تلاشتان برای نوشتن کد تمیز خوب نیست! خبر بد این است که نوشتن کد تمیز بسیار شبیه به نقاشی کشیدن است. بیشتر ما می دانیم چه زمانی یک تصویر خوب یا بد نقاشی شده است. اما قدرت تشخیص هنر خوب از بد به معنای این نیست که بلدیم چگونه نقاشی کنیم. بنابراین قدرت تشخیص کد تمیز از کد کثیف به این معنی نیست که می دانیم چگونه می توان کد تمیز نوشت! نوشتن کد تمیز مستلزم استفاده منظم از تکنیک های ظریف بی شماری است که این تکنیک ها از طریق به کارگیری حس"پاکیزگی" بکار برده می شود. این "حس کردن کد" مهم است. برخی از ما با آن متولد می شویم. برخی از ما باید برای به دست آوردن آن بجنگیم. نه تنها این امکان را به ما می دهد که ببینیم آیا کد خوب است یا بد ، بلکه برای تبدیل کد بد به کد تمیز، استراتژی استفاده از قوانین مان را به ما نشان می دهد. به طور خلاصه ، یک برنامه نویس که کد تمیز می نویسد ، هنرمندی است که می تواند یک صفحه خالی بگیرد و از طریق یک سری دگرگونی ها آن را به یک سیستم با کدگذاری زیبا تغییر دهد.کد تمیز چیست؟احتمالاً به اندازه برنامه نویسها تعریف وجود دارد. بنابراین از برخی از برنامه نویسان بسیار شناخته شده و با تجربه پرسیدم که چه فکر می کنند. Bjarne Stroustrup مخترع زبان C++ و نویسنده The C++ Programming Language :من دوست دارم کد من زیبا و کارآمد باشد. منطق باید سر راست باشد تا پنهان کردن باگ ها دشوار باشد ، وابستگی های حداقلی برای سهولت در نگهداری ،کنترل کامل خطا مطابق با یک استراتژی تکه به تکه و عملکرد نزدیک به بهینه، بگونه ای که مردم را وسوسه نکند تا کد را با بهینه سازی های غیر اصولی شلخته کنند. کد تمیز یک کار را به خوبی انجام می دهد. Bjarne از کلمه “ظریف” استفاده میکند. این کلمه کامل است! دیکشنری موجود در MacBook من این تعریف را برای این کلمه ارائه میدهد : از نظر ظاهری و رفتاری دلپذیر و برازنده و شیک است. کاملاً مبتکرانه و ساده. به کلمه "دلپذیر" دقت کنید. ظاهرا Bjarne فکر می کند که خواندن کد تمیز لذت بخش است. خواندن آن باید لبخند را به لبان شما بیاورد، هماگونه که یک جعبه موسیقی خوش ساخت و یا یک ماشین با طراحی زیبا باعث میشود لبخند بزنید Bjarne همچنین دو بار از واژه بازده استفاده می کند. شاید وقتی این کلمه از دهان مخترع C ++ خارج میشود، غافلگیر کننده نباشد. اما فکر می کنم چیزی فراتر از تمایل صرف برای سرعت وجود دارد. چرخه های تلف شده لذت بخش نیستند و ناخوشایند هستند و اکنون به کلماتی که Bjarne برای توصیف پیامد آن ناهنجاری استفاده می کند توجه داشته باشید. او از کلمه "وسوسه"استفاده می کند. در اینجا یک حقیقت عمیق وجود دارد. کد بد شلختگی را وسوسه میکند تا رشد کند! وقتی دیگران کد بد را تغییر می دهند ، متمایل به بدتر کردن آن هستند. Dave Thomas عملگرا و Andy Hunt این نکته را با یک روش متفاوت می گویند.آنها از استعاره پنجره های شکسته استفاده کرده اند. وقتی بنایی پنجره های شکسته های شکسته دارد اینظور به نظر می رسد که کسی به آن اهمیتی نمی دهد. بنابراین افراد دیگر هم از توجه به آن خودداری می کنند. آنها اجازه می دهند تا پنجره های بیشتری شکسته شود. سرانجام آنها به طور جدی آنها را می شکنند. آنها با گرافیتی نما را خراب می کنند و اجازه میدهند در آن جا زباله جمع شود.یک پنجره شکسته روند زوال را شروع می کند. Bjarne همچنین خاطرنشان می کند که رسیدگی به خطا باید کامل باشد. این مربوط به قانون توجه به جزییات می شود. کنترل خطای مختصر فقط یکی از راه هایی است که برنامه نویسان با استفاده از آن به تفصیل جزئیات می پردازند. نشت حافظه (Memory leaks) یکی دیگر از راهها و شرایط مسابقه(race condition) راه دیگر است. راه دیگر نامگذاری متناقض(Inconsistent naming) است. نتیجه اصلی این است که کد تمیز توجه زیادی به جزئیات دارد. Bjarne با این ادعا که کد تمیز یک کار را به خوبی انجام می دهد ، بحث را می بندد. تصادفی نیست که بسیاری از اصول طراحی نرم افزار وجود دارند که می توانند دلیل اصلی این توصیه ساده باشند.نویسندگان یکی پس از دیگری سعی در برقراری ارتباط با این اندیشه داشتند. کد بد بیش از حد خرابکاری می کند، تمایلات را زشت کرده و اهداف را مبهم می کند. کد تمیز متمرکز است. هر تابع، هر کلاس، هر ماژول یک نگرش تک ذهنیتی را که کاملاً دست نخورده و آلوده نشده باقی مانده است با جزئیات پیرامون خود در معرض نمایش قرار می دهدگردی بوچ Grady Booch ، نویسنده “Object Oriented analysis and Design with Applications” :کد تمیز ساده و سر راست است. کد تمیز مثل یک نثر خوب نوشته شده است. کد تمیز هرگز هدف طراح را مبهم نمی کند بلکه پر از انتزاعات واضح و خطوط کنترل سر راست است. Grady برخی از نکاتی را که Bjarne بیان می کند، عنوان میکند، اما او یک جنبه خوانایی را در نظر می گیرد. من خصوصاً این نظر او را که كد تمیز باید مانند نثر خوب نوشته شده باشد دوست دارم. دوباره به کتاب خوبی که مطالعه کرده اید فکر کنید. به یاد آورید که چگونه کلمات ناپدید شدند تا تصاویر جایگزین شوند! مثل تماشای فیلم. اینطور نیست؟ بهتر! شخصیت ها را دیدید ، صداها را شنیدید ، ترحم و طنز را تجربه کردید. خواندن کد تمیز هرگز شبیه به خواندن کتاب ارباب حلقه ها نخواهد بود. با این وجود استعاره ادبی بد نیست. مانند یک رمان خوب ، کد تمیز باید به وضوح تنش های موجود در مشکل را حل کند. باید آن تنش ها را به اوج خود برساند و سپس به خواننده بگوید که: "آها! اینه!" زیرا مشکلات و تنش ها در ظهور یک راه حل واضح برطرف می شود. .به نظر من استفاده grady از عبارت "انتزاع خشک(crisp abstraction)" به عنوان یک کلمه ضد و نقیض جذاب است! در نهایت، کلمه "خشک" تقریباً مترادف "واقع"3 است. فرهنگ لغت مک بوک من تعریف زیر از "خشک" را دارد: قاطعانه و سرنوشت ساز ، بدون تردید و جزئیات غیر ضروری. علیرغم این کنار هم گذاشتن معانی، کلمات دارای پیام قدرتمندی هستند. کد ما باید برخلاف حدس و گمان ها و واقعی باشد. کد باید فقط شامل چیزهای مهم و ضروری باشد. خوانندگان ما باید قاطعیت ما را درک کنند.آقای Dave Thomas، موسس OTI، پدرخوانده استراتژی Eclipse : کد تمیز میتواند بجز نویسنده اصلی آن، توسط یک توسعه دهنده دیگر نیز خوانده شود و بهبود یابد. این کد Unit test و Acceptance test دارد. این کد اسامی معنی دار دارد. کد تمیز به جای اینکه راههای زیادی برای انجام یک کار ارائه کند، یک راه برای انجام یک کار دارد. کد تمیز حداقل وابستگی ها ، که به طور واضح تعریف شده اند ، و یک API واضح و حداقلی را ارائه می دهد. کد باید دانا باشد زیرا بسته به زبان ، تمام اطلاعات لازم را نمی توان به طور مشخص و به تنهایی با کد بیان کرد. Dave بزرگ، تمایل Grady برای خوانایی را با پیچیدگی مهمی به اشتراک می گذارد. Dave ادعا می کند که کد تمیز باعث میشود بهبود آن برای سایر افراد آسان باشد. این ممکن است واضح به نظر برسد ، اما نمی تواند بیش از حد مورد تأکید قرار بگیرد. از این گذشته ، میان کدی که خواندن آن آسان است و کدی که تغییر آن آسان است تفاوت وجود دارد. Dave تمیز بودن کد را با تست ها پیوند می زند! ده سال پیش این امر باعث تعجب بسیار میشد. اما قوانین توسعه مبتنی بر تست(Test Driven Development) تأثیر عمیقی بر صنعت ما گذاشته و به یکی از اساسی ترین قوانین ما تبدیل شده است. حق با Dave است. کد ، بدون تست ، تمیز نیست. مهم نیست که چقدر زیبا باشد ، هر چقدر هم که قابل خواندن و در دسترس باشد ، اگر آزمایش نشده باشد ، کثیف است. Dave دو بار از کلمه حداقل استفاده می کند. ظاهراً منظور او در این تعریف کدهای کوچک است. در واقع ، از زمان پیدایش ادبیات نرم افزار تا کنون، این یک ترجمه رایج بوده است. کوچکتر بهتر است. Dave همچنین می گوید که کد باید دانا(Liteate) باشد. این یک اشاره ریز به ادبیات برنامه نویسی Knuth دارد. نتیجه کلی این است که کد باید به شکلی تهیه شود که برای انسانها خوانا باشدمیشل فیدرز MIcheal Feathers، نویسنده Working Effectively with Legacy Code :من می توانم تمام خصوصیاتی را که در کد تمیز به آن توجه می کنم ذکر کنم ، اما کیفیت فرا معماری وجود دارد که بر تمام آنان ارجح است. همیشه به نظر می رسد که کد تمیز توسط کسی نوشته شده است که به آن اهمیت داده است. هیچ چیز واضحی وجود ندارد که بتوانید انجام دهید تا کد بهتر شود. به همه این موارد توسط نویسنده کد فکر شده است و اگر سعی دارید پیشرفت ها را تصور کنید ، به جایی که هستید برمیگردید، جایی که از کد شخصی که برای شما باقی گذاشته تشکر میکنید - کدی که توسط کسی که عمیقاً به این مهارت اهمیت می دهد به جا گذاشته شده است. یک کلمه: اهمیت دادن. این کلمه واقعاً موضوع این کتاب است. شاید یک عنوان مناسب این باشد که چگونه به کد اهمیت دهیم. Micheal به مهمترین نکته اشاره کرد. کد تمیز کدی است که از آن مراقبت شده است. شخصی وقت خود را برای ساده و منظم نگه داشتن آن صرف کرده است. آنها توجه کافی به جزئیات داشته اند. آنها مراقبت کرده اند .رون جفری.Ron Jeffries ، نویسنده Extreme Programming Installed وExtreme Programming Adventures in C# : رون حرفه برنامه نویسی خود را در Fortran در فرماندهی هوایی استراتژیک آغاز کرد و تقریباً به هر زبان و تقریباً بر روی هر دستگاهی ، کدی را نوشت. این امر باعث شد که در مورد صحبت کردنش بسیار مراقب باشد: در سال های اخیر من قوانین کد ساده Beck را شروع و تقریباً به پایان رساندم. به ترتیب اولویت ، کد ساده:• تمام تست ها را اجرا می کند؛• بدون (کد اضافه)Duplicate است.• تمام ایده های طراحی موجود در سیستم را بیان می کند.• تعداد موجودیت هایی چون کلاسها ، متدها ، توابع و موارد مشابه را به حداقل می رساند.از این میان ، بیشتر روی Duplication تمرکز می کنم. وقتی همین کار بارها و بارها انجام شد ، این نشانگر این است که ایده ای در ذهن ما وجود دارد که به خوبی در کد نمایش داده نشده است. سعی می کنم بفهمم که چیست. سپس سعی می کنم این ایده را با وضوح بیشتری بیان کنم. برای من، بیانگر بودن شامل اسامی معنادار است ، و من احتمالاً چندین بار اسامی چیزها را قبل از تثبیت آنها، تغییر می دهم. با ابزار مدرن کدنویسی مانند Eclipse ، تغییر نام کاملا بدون هزینه است ، بنابراین تغییر دادن برای من مشکل ساز نخواهد بود. با این وجود بیان کد فراتر از نامها است. من همچنین به این موضوع نگاه می کنم که آیا یک شی یا متد بیش از یک کار را انجام می دهد یا نه. اگر یک شیء باشد ، احتمالاً باید به دو یا چند شیء تقسیم شود. اگر یک متد باشد ، من همیشه از refactoring Extract Method روی آن استفاده می کنم ، نتیجه اجرای این روش بر روی یک متد این است که چیزی که متد انجام میدهد را واضح تر بیان میکند، و برخی از زیرمتدها چگونگی انجام این کار را بیان میکنند. Duplication و صراحت ، برای رسیدن به چیزی که من آن را کد تمیز تلقی کنم، راه بسیار طولانی ای را طی می کنند و بهبود کد کثیف فقط با توجه به این دو مورد می تواند تفاوت بزرگی ایجاد کند. با این حال ، یک چیز دیگر وجود دارد که من از انجام آن آگاه هستم ، که توضیح آن کمی سخت تر است. بعد از سالها انجام این کار ، به نظر من همه برنامه ها با عناصر بسیار مشابهی ساخته شده اند. یک مثال "یافتن چیزها در یک مجموعه" است. چه بانک اطلاعاتی از سوابق کارمندان ، یا نقشه درهم ساز(Hash map)کلیدها و مقادیر ، و یا آرایه ای از بعضی از اقلام داشته باشیم ، ما اغلب خودمان را خواهان مورد خاصی از آن مجموعه میبینیم. در پی آگاهی از وقوع این اتفاق ، من اغلب پیاده سازی خاصی را در یک متد یا کلاس انتزاعی تر می پیچم. این به من چند مزیت جالب می دهد. من اکنون می توانم آن عملکرد را با چیزی ساده پیاده سازی کنم ، مثلا با یک هش مپ، اما از آنجایی که اکنون همه ارجاعات مربوط به آن جستجو را توسط انتزاع کوچکم تحت پوشش قرار دادم ، می توانم هر زمان که بخواهم ، پیاده سازی را تغییر دهم. من بعدا می توانم با حفظ توانایی خود برای تغییر، به سرعت پیش بروم. علاوه بر این، وقتی با چند روش نسبتا ساده می توانم همه چیزی که می خواهم را بیابم، مجموعه انتزاع اغلب توجه مرا به آنچه که "واقعاً" در جریان است ، جلب می کند و مرا از مسیر پیاده سازی مجموعه رفتارهای دلخواه منصرف می کند. Duplication کاهش یافته ، بیان واضح و ساخت انتزاعات ساده از ابتدا. این چیزی است که برای من کد تمیز می سازد.در اینجا ، در چند پاراگراف کوتاه ، Ron مطالب این کتاب را خلاصه کرده است.بدون Duplication ، یک چیز ، بیان ، تجریدهای کوچک. همه چیز آنجاست.و **Ward Cunningham مخترع ویکی، مخترع Fit، هم اختراع کننده eXtreme Programming. نیروی انگیزشی در پشت Design Pattern. رهبر فکری شی گرایی و Smalltalk. پدرخوانده همه کسانی که به کد اهمیت میدهند:**وقتی هر روالی(Routine) که میخوانید دقیقا همان چیزی است که انتظار دارید، شما می دانید که دارید روی کد تمیز کار می کنید. همچنین هنگامی که کد شبیه به زبانی که برای مشکل درست شده است ، می توانید آن را یک کد زیبا بنامید.جمله هایی مانند این ، خصوصیات Ward است. شما آن را خوانده اید ، سر خود را تکان داده اید ، و سپس به موضوع بعدی رفته اید. منطقی به نظر می رسد، بطور واضح این مسئله به سختی به عنوان یک مسئله عمیق و ژرف درنظر گرفته میشود. ممکن است فکر کنید تقریباً همان چیزی بود که انتظار داشتید. اما بیایید نگاه دقیق تری داشته باشیم. " . . تقریباً آنچه انتظار داشتید. " آخرین باری که ماژولی را دیدید که تقریباً همان چیزی بود که انتظار داشتید کی بود؟ آیا به احتمال زیاد ماژول هایی که به آنها نگاه می کنید گیج کننده ، پیچیده و درهم و برهم نیستند؟ این قانون اشتباه نیست؟ آیا شما عادت نکردید که تلاش برای گرفتن و نگه داشتن تارهای استدلال که از کل سیستم به دست می آیند و راه خود را در ماژولی که می خوانید درست میکنند، به هیچ انگارید؟ آخرین باری که یک کد را خواندید و سر خود را به شکلی که Ward گفته است تکان دادید، کی بود؟ Ward انتظار دارد که وقتی کد تمیز را می خوانید به هیچ وجه تعجب نکنید. در واقع ، شما حتی تلاش زیادی هم نمی کنید. شما آن را خواهید خواند ، و تقریباً همان چیزی است که انتظار دارید. این امر آشکار ، ساده و قانع کننده خواهد بود. هر ماژول مقدمات را برای مرحله بعد تنظیم می کند. هر کدام به شما می گوید که بعدی چگونه نوشته خواهد شد. برنامه هایی که آن چنان تمیز هستند، به گونه ای عمقی و خوب نوشته شده اند که حتی متوجه آن نمی شوید. طراح باعث می شود مانند همه طرح های استثنایی ، این مسئله به طرز مسخره ای ساده به نظر برسد.تفکر Ward در مورد زیبایی چطور؟ همه ما در برابر این واقعیت که زبانهای ما برای مشکلات ما طراحی نشده اند جبهه می گیریم. اما جمله Ward باری را بر دوش ما می گذارد. او می گوید که کد زیبا باعث می شود اینطور به نظر برسد که زبان برای این مشکل ایجاد شده است! بنابراین این مسئولیت ماست که زبان را ساده جلوه دهیم! طرفداران زبانها در همه جا هستند، هشیار باشید**!** این زبان نیست که برنامه ها را ساده جلوه دهد. این برنامه نویس است که باعث می شود زبان ساده به نظر برسد!مکتب فکری!در مورد من(عمو Bob) چی؟ من در مورد کد تمیز چه فکر میکنم؟ این کتاب با جزییات زیاد آنچه من و همفکرانم درباره کد تمیز فکر می کنیم را به شما خواهد گفت. ما آنچه که فکر میکنیم یک نام متغیر تمیز ، یک تابع تمیز ، یک کلاس تمیز و غیره را ایجاد می کند به شما خواهیم گفت. ما این عقاید را مطلق ارائه خواهیم کرد و از سختگیری خود عذرخواهی نمی کنیم. برای ما ، در این مرحله از حرفه مان ، آنها مطلق هستند. آنها مکتب فکری ما در مورد کد تمیز هستند. هنرمندان رزمی همه با بهترین هنر رزمی یا بهترین تکنیک در یک هنر رزمی موافق نیستند. اغلب استادان هنرهای رزمی مکتب خود را تشکیل می دهند و دانش آموزان را برای یادگیری دور خود جمع می کنند. بنابراین ما Gracie Jiu Jistu را می بینیم ، که توسط خانواده Gracie در برزیل تأسیس و تدریس شده است. ما Hakkoryu Jiu Jistu را می بینیم که توسط Okuyama Ryuho در توکیو تاسیس و تدریس شده است. ما Jeet Kune Do را می بینیم ، که توسط بروس لی در ایالات متحده تاسیس و تدریس شده است. هنرجویان این رویکردها، خود را در آموزه های بنیانگذار غرق می کنند. آنها خود را وقف این می كنند كه آنچه آن استاد خاص تدریس میکند را فارغ از چیزی که استاد دیگر تدریس میکند، بیاموزند. بعداً با رشد هنرجویان در هنر خود ، ممکن است دانش آموز استاد دیگری شوند تا بتوانند دانش و تمرین خود را گسترش دهند. عده ای سرانجام برای کشف مهارت های خود ، به کشف تکنیک های جدید و تأسیس مکتب خود می روند. هیچ یک از این مکاتب مختلف کاملاً درست نیستند. با وجود این ، در درون یک مکتب خاص به نظر می رسد که آموزه ها و فنون صحیح هستند.از این گذشته ، یک روش درست برای تمرین Hakkoryu Jiu Jitsu یا Jeet Kune Do وجود دارد. اما این حق در یک مکتب ، آموزه های یک مکتب متفاوت را باطل نمی کند. این کتاب را در مورد توصیفات مکتب اشیا آموزشی در کد تمیز1 در نظر بگیرید. تکنیک ها و آموزه های موجود روشی است که ما هنر خود را تمرین می کنیم. ما مایل هستیم ادعا کنیم که اگر این آموزه ها را رعایت کنید ، از مزایایی که ما از آنها لذت بردیم لذت خواهید برد و یاد می گیرید که کدی بنویسید که تمیز و حرفه ای باشد. اما این اشتباه را نکنید که فکر کنید که "حق" به طور مطلق با ما است.مکاتب و اساتید دیگری نیز وجود دارند که به همان اندازه که ما ادعا داریم، حرفه ای هستند. شایسته است که شما از آنها نیز بیاموزید. در واقع ، بسیاری از توصیه های این کتاب جنجال برانگیز است. احتمالاً با همه آنها موافق نخواهید بود. ممکن است با بعضی از آنها به شدت مخالف باشید. خوب است. ما نمی توانیم ادعای کمال اعتبار کنیم. از طرف دیگر ، توصیه های موجود در این کتاب مواردی است که ما طولانی و سخت در مورد آنها فکر کرده ایم. ما آنها را طی چندین دهه تجربه و آزمایش و خطای مکرر آموخته ایم. بنابراین چه موافق باشید یا مخالف باشید ، اگر به نقطه نظر ما احترام نگذارید و آن را نبینید شرم آور خواهد بود. ما نویسنده ایم فیلد @author در یک Javadoc به ما می گوید که ما کی هستیم. ما نویسنده هستیم و یک چیز در مورد نویسندگان وجود دارد و آن این است که آنها خواننده دارند. در واقع ، نویسندگان مسئول برقراری ارتباط خوب با خوانندگان خود هستند. دفعه بعد که شما یک خط از یک کد را نوشتید ، به یاد داشته باشید که شما نویسنده ای هستید که برای خوانندگانی که تلاش شما را قضاوت می کنند ، می نویسید. ممکن است بپرسید : یک کد واقعا چه مقدار خوانده میشود؟ تمام تلاش ما صرف نوشتن آن نمیشود؟ آیا تاکنون به یک جلسه ویرایش دوباره باز گشته اید؟ در دهه 80 و 90 ویرایشگرانی مانند Emacs داشتیم که هرگونه فشار به صفحه کلید را ردیابی می کردند. می توانید یک ساعت کار کنید و بعد از آن کلیه ویرایش های خود را مانند یک فیلم پر سرعت پخش کنید. وقتی این کار را کردم ، نتایج جالب توجه بود. هیچ یک از این مکاتب مختلف کاملاً درست نیستند. با وجود این ، در درون یک مکتب خاص به نظر می رسد که آموزه ها و فنون صحیح هستند.اکثریت قریب به اتفاق تجدید نظرها در مورد بخش پیمایش و هدایت به سایر ماژول ها بود! باب وارد ماژول می شود. او به تابعی که نیاز به تغییر دارد می رود او با توجه به گزینه های خود مکث می کند. اوه ، او در حال برگشتن به بالای ماژول برای بررسی مقدار اولیه داده شده به یک متغیر است. اکنون او دوباره به پایین برمیگردد و شروع به تایپ می کند. اوه ، او دارد آنچه را که تایپ کرده است پاک میکند! او دوباره آن را تایپ می کند. او دوباره آن را پاک می کند! او نیمی از چیز دیگری را تایپ می کند اما بعد آن را پاک می کند! او به تابع دیگری می رود که تابعی را که دارد تغییر می دهد را صدا میزند تا ببیند چگونه آن تابع صدا زده شده است. او دوباره به بالا برمیگردد و همان کدی را که تازه پاک کرده است تایپ می کند. مکث می کند. او دوباره آن کد را پاک می کند! وی پنجره دیگری را باز می کند و به یک زیر کلاس نگاه می کند. آیا این تابع دوبار نوشته شده است؟ . . . شما بی اراده کار می کنید. در واقع ، نسبت زمانی که صرف خواندن میکنید در مقابل زمانی که صرف نوشتن میکنید بیش از 10: 1 است. همیشه بخشی از تلاشمان برای نوشتن کد جدید ، برای خواندن کد قدیمی صرف میشود. از آنجا که این نسبت بسیار زیاد است ، می خواهیم خواندن کد آسان باشد ، حتی اگر این کار نوشتن را سخت تر کند. البته هیچ راهی برای نوشتن کد بدون خواندن آن وجود ندارد ، بنابراین آسان تر کردن خواندن در واقع نوشتن آن را آسان تر می کند. از این منطق گریزی وجود ندارد. اگر نمی توانید کدهای اطراف را بخوانید ، نمی توانید کد بنویسید. نوشتن کدی که می خواهید امروز بنویسید بسته به اینکه چقدر خواندن کد اطراف آن سخت یا آسان باشد، دشوار یا آسان خواهد بود. بنابراین اگر می خواهید سریع کار کنید ، اگر می خواهید به سرعت کار خود را به اتمام برسانید ، اگر می خواهید کد شما به راحتی نوشته شود ، خواندن آن را آسان کنید قانون پیشاهنگان پسر اینکه کد به خوبی نوشته شود کافی نیست. کد باید در طول زمان تمیز نگه داشته شود. با گذشت زمان ، همه ما شاهد پوسیدن و کاهش درجه ارزش کد هستیم. بنابراین ما باید نقش فعالی در جلوگیری از این تخریب داشته باشیم. پیشاهنگان پسر امریکا یک قانون ساده دارند که ما می توانیم از آن در حرفه خود استفاده کنیم. محل اردوگاه را تمیزتر از آنچه که به آن وارد شدید، ترک کنید2 اگر همه ما هنگام ورود به کد، كد خود را كمي تميزتر از زماني كه آن را رها کرده بوديم کنیم ، كد به سادگي نمي تواند پوسيده شود. پاکسازی لازم نیست چیز بزرگی باشد. بهتر کردن نام یک متغیر، شکستن یک تابع نسبتا بزرگ به توابع کوچکتر، از بین بردن یک تکثیر ، پاک کردن یک عبارت شرطی ترکیبی باعث تمیزتر شدن کد میشود. آیا می توانید کار کردن روی پروژه ای که کدش با گذشت زمان به آسانی بهتر شده است را تصور کنید؟آیا معتقدید که گزینه ای غیر از این حرفه ای است؟ در واقع ، آیا پیشرفت مداوم جز ذاتی حرفه ای بودن نیست؟ مقدمه و اصول از بسیاری جهات ، این کتاب "مقدمه" کتابی است که من در سال 2002 با عنوان توسعه نرم افزار چابک: اصول ، الگوهای و عملکردها نوشتم. کتاب PPP خود با اصول طراحی شی گرا و بسیاری از شیوه هایی که توسط توسعه دهندگان حرفه ای استفاده می شود درگیر است. اگر PPP را نخوانده اید ، ممکن است در آینده متوجه شوید که آن کتاب، داستانی که توسط این کتاب گفته شده را ادامه می دهد. اگر قبلاً آن را خوانده اید ، می توانید تکرار بسیاری از تفکرات آن کتاب در سطح کد را در این کتاب ببینید. در این کتاب اشاراتی پراکنده به اصول مختلف طراحی خواهید یافت. در میان این اصول اصل تک مسئولیت4 ، اصل بسته باز5 و اصل وارونگی وابستگی6 وجود دارد. این اصول به تفصیل در PPP شرح داده شده است نتیجه گیری کتابهای مربوط به هنر قول نمی دهند شما را به یک هنرمند تبدیل کنند. تمام کاری که آنها می توانند انجام دهند این است که برخی از ابزارها ، تکنیک ها و فرآیندهای فکری که سایر هنرمندان استفاده کرده اند را به شما ارائه می دهند. بنابراین این کتاب نیز نمی تواند قول دهد شما را به یک برنامه نویس خوب تبدیل کند. نمی تواند قول بدهد که به شما "درک کد" را بدهد. تمام کاری که می تواند انجام دهد این است که فرآیندهای فکری برنامه نویسان خوب و ترفندها ، تکنیکها و ابزارهایی را که از آنها استفاده می کنند به شما نشان دهد. درست مانند یک کتاب در زمینه هنر ، این کتاب پر از جزئیات خواهد بود. تعداد زیادی کد وجود دارد. هم کد خوب خواهید دید و هم کد بد. میبینید که کد بد را به کد خوب تبدیل می کنید. لیست های از اکتشاف7 ، قوانین و تکنیک ها را مشاهده خواهید کرد. مثال پشت مثال خواهید دید. پس از آن ، به شما بستگی دارد. شوخی قدیمی درباره ویولنیست کنسرت را که در راه رسیدن به یک اجرا گم شده بود را به یاد می آورید؟ او پیرمردی را در گوشه ای متوقف کرد و از او پرسید که چگونه به Carnegie Hall برسد. پیرمرد به ویولنیست و ویولون زیر بازویش نگاه کرد و گفت: "تمرین کن پسرم. تمرین کن!" Noah Noah Thu, 23 Apr 2020 15:29:35 +0430 https://virgool.io/@dndshmdr/%DA%86%D8%B7%D9%88%D8%B1-%D8%AF%D8%B1-%DA%A9%D9%85%D8%AA%D8%B1-%D8%A7%D8%B2-%DB%8C%DA%A9-%D8%B3%D8%A7%D8%B9%D8%AA-%D8%AA%D9%85%D8%A7%D9%85-%D8%B2%D9%86%D8%AF%DA%AF%DB%8C-%D8%AE%D9%88%D8%AF-%D8%B1%D8%A7-%D8%B1%D9%85%D8%B2%D9%86%DA%AF%D8%A7%D8%B1%DB%8C-%DA%A9%D9%86%DB%8C%D9%85-nudo6qv2jkvs "فقط پارانویا (ویکی پدیا)زنده مانده است." -- Andy Groveاندی گروو یک پناهنده مجارستانی بود که از کمونیسم فرار کرد ، در رشته مهندسی تحصیل کرد و در نهایت انقلاب رایانه شخصی را به عنوان مدیرعامل اینتل رهبری کرد. وی در اوایل سال جاری در دره سیلیکون پس از درگیری طولانی با بیماری پارکینسون درگذشت.هنگامی که یکی از قدرتمندترین افراد جهان ما را تشویق به پارانویا می کند ، شاید باید گوش کنیم.و گروو تنها شخصی قدرتمند نیست که احتیاط می کند. حتی مدیر FBI همه را تشویق می کند تا وب کم های خود را بپوشانند.اما شما از قانون پیروی می کنید. شما چه نگرانی دارید؟ همانطور که شعار برنامه نظارت بریتانیا به ما یادآوری می کند ، "اگر چیزی برای پنهان کردن ندارید ، هیچ چیزی برای ترس ندارید."خوب ، شهروندان مطیع قانون دلیلی برای ترس دارند. آنها دلایلی برای تأمین امنیت دستگاه ها ، پرونده های خود و ارتباط آنها با عزیزان دارند."اگر کسی شش سطر را که به دست صادق ترین مرد نوشته شده بود به من می داد ، من چیزی را در آنها پیدا می کردم تا او را به دار آویخته کنم." - Cardinal Richelieu در سال 1641در این مقاله به شما نشان خواهم داد که چگونه می توانید با اعمال رمزگذاری پیشرفته ، از خود محافظت کنید. امنیت عرفی برای همهمحظ اطلاع ، همه آنچه من در اینجا توصیه می کنم 100٪ رایگان و 100٪ قانونی هستند. اگر زحمت قفل کردن درهای خود را در شب به جان میخرید ، باید زحمت استفاده از رمزگذاری را هم به جان بخرید.بزن بریماول ، چند تا تعریف. وقتی من از اصطلاح "مهاجم" استفاده می کنم منظورم هرکسی است که سعی میکند به اطلاعات شما که به او اجازه دسترسی داده نشده است دسترسی پیدا کند - خواه یک هکر ، یک شرکت یا حتی دولت.و وقتی از اصطلاحات "خصوصی" یا "امن" استفاده می کنم ، منظورم منطقی است. واقعیت این است که - تا جایی که به انسان مربوط میشود ، هیچ سیستمی 100٪ خصوصی یا 100٪ امن نخواهد بود.وقتی تلفن ، رایانه ها و حساب های شما به اندازه کافی محافظت شوند ، محتویات آنها مثل "حبابی رمزگذاری شده" باقی می مانند و هیچ کس - صرف نظر از قدرتمند بودن آنها - نمیتواند به ان دسترسی داشته باشد.قدم #1: از تایید اعتبار تو مرحله ای در صندوق ورودی خود(ایمیل یا هرچی) استفاده کنیدصندوق ورودی شما کلید اسکلت زندگی شماست. اگر یک مهاجم آن را به خطر بیاندازد ، آنها نه تنها می توانند ایمیل های شما را بخوانند ، بلکه می توانند از آن برای تنظیم مجدد کلمه عبور خود برای تقریبا هر چیز دیگری استفاده کنند. این شامل حساب های رسانه های اجتماعی و حتی حساب های بانکی است.ساده ترین کاری که می توانید برای بهبود چشمگیر امنیت شخصی خود انجام دهید ، روشن کردن تأیید هویت دو مرحله ای در صندوق ورودی است.در اصل ، تأیید هویت دو مرحله ای لایه دوم از امنیت هنگام ورود به سیستم است. معمولاً شامل دریافت پیام متنی با یک کد ویژه هر وقت وارد حساب کاربری خود می شوید است.احراز هویت دو مرحله ای احتمال هک شدن صندوق پستی شما را به میزان قابل توجهی کاهش می دهد.اگر از Gmail استفاده می کنید ، باید احراز هویت دو مرحله ای را در اینجا فعال کنید.حالاجدامن همینجا منتظر میمانم تا برگردید.قدم #2: هارد درایو خود را رمزنگاری کنید.هم ویندوز و هم مک از رمزنگاری پشتیبانی میکنند.قدم #3: پسورد گوشی خود را فعال کنیدشناسایی اثر انگشت بهتر از هیچی است ، اما اغلب کافی نیست. دادگاه می تواند شما را مجبور به باز کردن قفل تلفن با اثر انگشت کند.همچنین ، شما نمی توانید اثر انگشت خود را بعد از اینکه یک مهاجم کنترل انرا به دست بگیرد ، تغییر دهید.یک مهاجم معمولاً قبل از اینکه تلفن شما کاملاً قفل شود ، 10 بار تلاش می کند. بنابراین اگر گذرواژه 4 رقمی شما یکی از این موارد معمول است ، آن را تغییر دهید.1234 99991111 33330000 55551212 66667777 11221004 13132000 88884444 43212222 20016969 1010نکته: اگر اصرار دارید به خاطر راحتی بتوانید شناسایی اثر انگشت را فعال کنید و اگر اتفاقا دستگیر شدید ، فوراً تلفن خود را خاموش کنید. وقتی مقامات تلفن شما را دوباره روشن می کنند ، آنها نمی توانند آن را بدون رمز عبور خود قفل کنند.مارک زاکربرگ از کلمه عبور "dadada" در حساب LinkedIn خود استفاده کرد. در اوایل سال جاری ، هنگامی که هکرها 117 میلیون ترکیب ایمیل و رمز عبور را منتشر کردند ، اون در بین آنها قرار بود. بعد هکرها توانستند از ایمیل و رمز عبور وی استفاده کنند تا به حساب های توییتر و پینترست وی دسترسی پیدا کنند.بنابراین بیش از یک مکان از همان رمز عبور استفاده نکنید.البته به یاد آوردن یک خروار رمز عبور مغز انیشتین میخواهد ، بنابراین از یک برنانه مدیریت رمز استفاده کنید.قدم #5: با Signal پیام های خصوصی بفرستید!سیگنال Signal یک سرویس پیام رسان محبوب است که از Electronic Frontier Foundation (ویکی پدیا) نمره کامل کسب کرده است. شما می توانید تمام کارهایی را که به طور معمول از طریق پیام های متنی انجام می دهید ، مانند ارسال پیام های گروهی و ارسال عکس و فیلم در سیگنال انجام دهید. به جز اینکه همه چیز رمزگذاری شده است.سیگنال رایگان ، منبع باز و در فروشگاه های برنامه های iOS و Android در دسترس است. توانستم در کمتر از 5 دقیقه آنرا تنظیم کرده و پیام ایمن را با دوستان و خانواده شروع کنم.مرحله اول ：نصب سیگنالمرحله دوم： دوستانتان را به نصب سیگنال دعوت کنید.مرحله سوم： پیام ارسال کنیدتبریک میگم - حالا می توانید با دوستان و خانواده خود در مورد هر آنچه می خواهید صحبت کنید ، و جاسوسی کردن مکالمات شما برای هر کسی غیرممکن خواهد بود.همچنین می توانید از Signal برای برقراری تماس تلفنی ایمن استفاده کنید.قدم #6: حالت ناشناس مرورگر شما اونقدر ها هم خصوصی نیستحتی اگر از "حالت ناشناس" Chrome یا "مرور خصوصی" فایرفاکس استفاده کنید ، طرفهای زیر همچنان می توانند فعالیت شبکه شما را تحت تأثیر قرار دهند:ارائه دهندگان خدمات اینترنتیسرپرستان سیستم مسئول شبکه در مدرسه ، محل کار یا هر مکان آنلاین شویدگوگل یا هر کسی که مرورگر شما را ساخته استاینترنت اکسپلورر ، سافاری ، اپرا و مرورگرهای دیگر خصوصی نیستند.اگر می خواهید یک مرور خصوصی داشته باشید (هیچ سیستمی نمی تواند 100٪ امن باشد) ، باید از Tor استفاده کنید.قدم #7: جست و جو خصوصی با Torتور مخفف "The Onion Router" است که اشاره ای به لایه های پیاز مانند برای پوشش فعالیت شبکه می کند. این نرم افزار رایگان ، متن باز و استفاده از ان راحت است.مرحله اول： دانلود Orbot مرحله دوم： دانلود Orfox browserمرحله سوم ： باز کردن Orbotمرحله چهارم ： باز کردن Orfoxمرحله پنجم：امتحان کنید که کار میکندبرای تأیید صحت کار ، به check.torproject.org مراجعه کنید. تبریک می گویم - اکنون می توانید با آرامش از اینترنت استفاده کنید که ردیابی شما برای هر کسی بسیار دشوار خواهد بود.قدم #8: جست و جو خصوصیاگر Tor به اندازه کافی مناسب شما نیست ، می توانید حداقل با استفاده از DuckDuckGo ، موتور جستجو ای که شما را ردیابی نمیکند ، به صورت خصوصی جستجو کنید.مرورگر DuckDuckGo مثل گوگل هزاران مهندس ندارد که روی ان کار کنند ، اما میانبری برای دستیابی به جستجوهای رمزگذاری شده Google دارد. شما فقط باید جستجوی خود را با! google پیشوند کنید.این بود هشت قدم برای حفظ حریم خصوصی. همچنین از من بخوانید： https://virgool.io/@dndshmdr/%D8%A8%DB%8C%D8%A7%DB%8C%D9%86-%DA%A9%D8%AA%D8%A7%D8%A8-clean-code-%D8%B1%D8%A7-%D8%A8%D8%A7-%D9%87%D9%85-%D8%AA%D8%B1%D8%AC%D9%85%D9%87-%DA%A9%D9%86%DB%8C%D9%85-%D8%AF%D8%B1%DB%8C%D8%A7%D9%81%D8%AA-%D8%AF%D9%88-%D9%81%D8%B5%D9%84-%D8%A7%D9%88%D9%84-spgsghy2vg36 منبع： free code camp Noah Noah Mon, 20 Apr 2020 08:41:32 +0430 https://virgool.io/@dndshmdr/%DB%B9-%D8%AF%D8%B3%D8%AA%D9%88%D8%B1-%D8%AC%D8%A7%D8%AF%D9%88%DB%8C%DB%8C-%D9%BE%D8%A7%DB%8C%D8%AA%D9%88%D9%86-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A7%D9%81%D8%B2%D8%A7%DB%8C%D8%B4-%D8%A8%D9%87%D8%B1%D9%87-%D9%88%D8%B1%DB%8C-vee6hbpxcwsj پایتون نه تنها همه کاره ترین زبان بلکه انعطاف پذیر ترین زبان در ترکیب ویژگی های مختلف هم هست. دستور یا کامند های جادویی هم یکی از ویژگی های جدید پایتونه.دستور های جادویی دقیقا چی هستند؟ دستور های جادویی که توسط هسته ipython اراعه شدن و به پایتون معمولی اضافه شده اند.این دستور های جادویی معمولا با پیشوند % مشخص میشونداین دستورات جادویی میانبر هایی هستند که برای حل مساعل معمولی به وجود امده اند.دو نوع دستور جادویی وجود دارد. انهایی که پیشوند % دارند و انهایی که پیشوند%% دارند.پیشوند % نشون میده که این دستور روی یک خط اجرا میشود و پیشوند %% اجازه میده که این دستور روی یک سلول(بلوک) اجرا بشهدر ادامه لیستی از دستورات جادویی و پیاده سازی انها در محیط jupyter notebook اورده شده است.اجرا کردن فایل خارجیهمون طور که داریم در محیط ژوپیتر کار میکنیم میخوایم که یک فایل خارجی رو اجرا کنیم .فایلی به اسم myCode.py داریم که دستورات بالا را اجرا میکند.با دستور run% فایل myCode.py اجرا میشه. اگر این فایل در جای دیگری بود باید مسیر یا path اون رو هم ذکر کنیم. خودتون میدونید که . مثلا C:/myfolder/myCode.py.با %run میتونیم یک jupyter notebooks خارجی رو هم اجرا کنیم.زمان اجرا کدایا تا حالا فکر کردید یک سلول از کد شما چقدر زمان میبره تا اجرا بشه؟دستور جادویی time زمان اجرا یک بلوک از کد شما رو محاسبه میکنه.از انجا که ما با یک سلول کد سر و کار داریم از پیشوند %% قبل از time استفاده میکنیم.سلول بالا یک حلقه داره که یه کاری رو انجام میده. time%% زمان لازم برای اجرا این حلقه رو محاسبه میکنه.کپی کردن محتوا فایل خارجیبعضی وقت ها نیاز داریم محتوایک سلول رو در یک فایل خارجی ذخیره کنیم.به جای کپی کردن همه چیز و ایجاد یک فایل جدید میتونیم با دستورwritefile مستقیما محتوا سلول رو در اون فایل جایگزین یا overwrite کنیم.دقت کنید که %% رو باید قبل از دستوری که به محتوا یک فایل اشاره میکنه قرار بدیم وقتی فایلی به اسم myCode.py وجود داشته باشد عبارت"Overwriting myCode.py" نمایش داده میشود که میگه : محتوا این سلول در فایل myCode.py جایگزین یا overwrite میشه.نمایش محتوا فایل خارجیگاهی اوقات نیاز داریم که محتوا یک فایل خارجی رو در کد مون کپی کنیم. به جای فرایند زمانبر پیدا کردن , باز کردن و کپی کردن محتوا مورد نیاز میتوانیم از دستو pycat% استفاده کنیم.این همه محتوا فایل myCode.py رو نمایش میده. میشه گفت این دستور برعکس دستور writefile% عمل میکنه.محکم بنشینید . هوز چند تا دستور جادوی دیگه داریم.لیست همه متغیر هااین دستور جادویی لیست همه متغیر های تعریف شده در کل notebook رو نمایش میدهد.فرض کنید سه تا متغیر داریم. a = &quothello&quot b = &quotGood Morning&quot c = 1با دستور who% میتونیم لیست همه متغیر های تعریف شده رو ببینیم.البته میتونیم لیست نوع خاصی از متغیر ها رو هم ببینیم. نوع متغیر باید بعد از دستور نوشته شود.اشتراک گذاری متغیر بین notebook هااین دستور جادویی اجازه میده که متغیر ها رو بین jupyter notebook های مختلف به اشتراک بگذاریم. با دستور store% باید متغیر اصلی رو مشخص کنیم. حالا میتونیم از notebook دیگه از این متغیر استفاده کنیم.اجرا html scriptدستور html%% اجازه میده که در یک سلول کد html بنویسیم. اون سلول الان مثل یک ادیتور html عمل میکنه.کد زیر یک جدول ساده رو با html نشون میده.%%html <html> <body> <table> <tr> <th>Name</th> <th>Country</th> <th>Age</th> </tr> <tr> <td>Sid</td> <td>India</td> <td>22</td> </tr> <tr> <td>Dave</td> <td>UK</td> <td>28</td> </tr> </table> </body> </html>نکته : میتونید کد های جاوااسکریپت رو هم با دستور جادویی js%% اجرا کنید. مثل دستور جادویی htmlنمایش نمودار های Matplotlibدستور جادویی %matplotlib inline یکی از محبوب ترین هاست. این دستور به Jupyter notebook اجازه میده که نمودار های matplotlib در این محیط نمایش داده بشه.import random import matplotlib.pyplot as plt %matplotlib inlineکتابخانه هایی که لازم داریم رو import کردیم.حالا دو تا لیست از نقطه های رندوم رو ایجاد میکنیم.a = [] b = [] for i in range(10): a.append(random.randint(0,10)) b.append(random.randint(0,10))حالا نمودار پراکندگی نقاط رو میکشیم.plt.scatter(a,b)دستور جادویی %matplotlib inline اجازه میده که نمودار رو در محیط notebook ببینیم.اطلاعات شی هادستور جادویی pinfo% اطلاعاتی در مورد یک شی که بهش پاس شده رو نمایش میده. مثل متد object?.در ادامه من یک a که یک String است رو به این دستور پاس کردم تا اطلاعات اش رو ببینم.a = &quotThe World Makes Sense!&quot %pinfo aخروجی این دستور همه اطلاعات موجود این String رو نمایش میدهد.به کمک دستور lsmagic% میتونید همه دستور های جاویی رو ببینید.%lsmagicاین بود ۹ دستور جادویی برتر که کمک میکنه بهره وری رو افزایش بدید و برای خودتون زمان بخرید.منبع: Mediumدر پروژه ترجمه گروهی کتاب clean code مشارکت کنید https://virgool.io/@dndshmdr/بیاین-کتاب-clean-code-را-با-هم-ترجمه-کنیم-دریافت-دو-فصل-اول-spgsghy2vg36 Noah Noah Sat, 18 Apr 2020 12:13:02 +0430 https://virgool.io/@dndshmdr/%D8%A8%DB%8C%D8%A7%DB%8C%D9%86-%DA%A9%D8%AA%D8%A7%D8%A8-clean-code-%D8%B1%D8%A7-%D8%A8%D8%A7-%D9%87%D9%85-%D8%AA%D8%B1%D8%AC%D9%85%D9%87-%DA%A9%D9%86%DB%8C%D9%85-%D8%AF%D8%B1%DB%8C%D8%A7%D9%81%D8%AA-%D8%AF%D9%88-%D9%81%D8%B5%D9%84-%D8%A7%D9%88%D9%84-spgsghy2vg36 چند وقت پیش یه پروژه ای رو شروع کردم که کتاب clean code رو ترجمه کنیم و رایگان منتشر کنیم. یه عده ای هم اومدند , حالا بعضی ها به دلایلی رفتند . به هر حال بعد از یک ماه که زمان خیلی زیادیه دو فصل اول ترجمه شده و اخر مقاله لینک هاش رو میذارم ولی لطفا بقیه پست رو هم بخونید.چرا این کار باید انجام بشه:جنبه فرهنگی:همون طور که میدونیم ایرانی ها توی کار های گروهی یکم ضعیفتر از جا های دیگه هستند یا حداقل من اینطور فکر میکنم. مخصوصا کار های داوطلبانه گروهی . شنیدم که یه جنبشی شروع شد که فونت فارسی بسازیم و کلی پول جمع شد و اخرش به جایی نرسید. بیاین یک بار هم که شده این رویه کنسل شدن اینجور پروژه ها رو بشکنیم و یه ردی از خودمون برای ایندگان به جا بذاریم.جنبه اقتصادی: تنها ترجمه این کتاب با قیمت ۱۲۰ هزار تومن به فروش میرسه. من اصلا نمیگم که قیمت به صرفه نیست ولی قبول کنیم خیلی ها توانایی پرداخت همین مبلغ رو هم ندارن. ترجمه رایگان این کتاب میتونه یک دلگرمی براشون باشه یا صرفا یک سرگرمی مفید رایگان در اختیارشون بذاره.جنبه سرگرمی: تو این روز ها هیچ چیز بهتر از یک سرگرمی مفید نیست و این پروژه هم فرصت خوندن یکی از بهترین کتاب های برنامه نویسی جهان رو به شما میده و هم یک سرگرمی خیلی خوبه.دلایل مخالفت با این کاراز همون اول خیلی ها با این کار مخالف بودند که با کمال احترام باهاشون مخالفم.این کتاب قبلا ترجمه شده و با ترجمه دوباره اون حقوق مترجمان رو زیر پا گذاشتیماگه قرار باشه که یک کتاب فقط یک بار ترجمه بشه که دیگه رقابتی به وجود نمیاد و کیفیت افت میکنه. این کار به نظرم اصلا با حقوق مترجمان محترم این کتاب منافاتی نداره ضمن اینکه ترجمه این دوستان هم رایگان نیست.چرا این کتاب وقتی قبلا ترجمه شدهبله این کتاب ترجمه شده ولی با قیمت ۱۲۰ هزار تومن به فروش میرسه. انصافا برای یک کتاب ۵۰۰ صفحه ای و اونم نسخه چاپی قیمت مناسبیه ولی تو این شرایط فعلی و مخصوصا این شرایط کرونایی خیلی ها توانایی پرداخت همین مبلغ رو هم ندارن. حالا بگذریم از بعضی ها که کتاب رو با قیمت پایین تر داشتند. احتمالا از یه جای خاصی پیدا کردند ولی در اینترنت فقط همین ترجمه وجود داره.اما دلیل اصلی انتخاب این کتاب محبوبیت اونه. همه برنامه نویس ها حداقل اسم این کتاب رو شنیدن. اگر ما با یک کتاب کمتر شناخته شده شروع میکردیم قطعا همین چند نفر هم جذب این کار نمیشدند.دوست داری کمک کنی؟اصلا کار سختی نیست . با ترجمه یک خط هم میتونید به پیشرفت این پروژه کمک کنید. بخش های ترجمه نشده به صورت انگلیسی در گیت هاب گذاشته شده. کافیه این بخش ها رو با ترجمه خودتون عوض کنید . به همین راحتی.یا میتونید بخش های ترجمه شده رو بازبینی و اصلاح کنیداگر قصد لایک کردن داری به جاش یک پاراگراف از کتاب رو ترجمه کنگیت هاب مابا ایمیل noahopentranslate@gmail.com هم میتونید با من در ارتباط باشید Noah Noah Wed, 15 Apr 2020 15:04:12 +0430 https://virgool.io/coderlife/%D8%AA%D8%B1%D8%AC%D9%85%D9%87-%D8%AF%D9%88-%D9%81%D8%B5%D9%84-%D8%A7%D9%88%D9%84-clean-code-%DB%8C%DA%A9-%D8%B3%D8%B1%DA%AF%D8%B1%D9%85%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%A7%DB%8C%D9%86-%D8%B1%D9%88%D8%B2-%D9%87%D8%A7-osgwrnnmfm4n چند وقت پیش یه پروژه ای رو شروع کردم که کتاب clean code رو ترجمه کنیم و رایگان منتشر کنیم. یه عده ای هم اومدند , حالا بعضی ها به دلایلی رفتند . به هر حال بعد از یک ماه که زمان خیلی زیادیه دو فصل اول ترجمه شده و اخر مقاله لینک هاش رو میذارم ولی لطفا بقیه پست رو هم بخونید.چرا این کار باید انجام بشه:جنبه فرهنگی:همون طور که میدونیم ایرانی ها توی کار های گروهی یکم ضعیفتر از جا های دیگه هستند یا حداقل من اینطور فکر میکنم. مخصوصا کار های داوطلبانه گروهی . شنیدم که یه جنبشی شروع شد که فونت فارسی بسازیم و کلی پول جمع شد و اخرش به جایی نرسید. بیاین یک بار هم که شده این رویه کنسل شدن اینجور پروژه ها رو بشکنیم و یه ردی از خودمون برای ایندگان به جا بذاریم.جنبه اقتصادی: تنها ترجمه این کتاب با قیمت ۱۲۰ هزار تومن به فروش میرسه. من اصلا نمیگم که قیمت به صرفه نیست ولی قبول کنیم خیلی ها توانایی پرداخت همین مبلغ رو هم ندارن. ترجمه رایگان این کتاب میتونه یک دلگرمی براشون باشه یا صرفا یک سرگرمی مفید رایگان در اختیارشون بذاره.جنبه سرگرمی: تو این روز ها هیچ چیز بهتر از یک سرگرمی مفید نیست و این پروژه هم فرصت خوندن یکی از بهترین کتاب های برنامه نویسی جهان رو به شما میده و هم یک سرگرمی خیلی خوبه.دلایل مخالفت با این کاراز همون اول خیلی ها با این کار مخالف بودند که با کمال احترام باهاشون مخالفم. این کتاب قبلا ترجمه شده و با ترجمه دوباره اون حقوق مترجمان رو زیر پا گذاشتیماگه قرار باشه که یک کتاب فقط یک بار ترجمه بشه که دیگه رقابتی به وجود نمیاد و کیفیت افت میکنه. این کار به نظرم اصلا با حقوق مترجمان محترم این کتاب منافاتی نداره ضمن اینکه ترجمه این دوستان هم رایگان نیست.چرا این کتاب وقتی قبلا ترجمه شدهبله این کتاب ترجمه شده ولی با قیمت ۱۲۰ هزار تومن به فروش میرسه. انصافا برای یک کتاب ۵۰۰ صفحه ای و اونم نسخه چاپی قیمت مناسبیه ولی تو این شرایط فعلی و مخصوصا این شرایط کرونایی خیلی ها توانایی پرداخت همین مبلغ رو هم ندارن. حالا بگذریم از بعضی ها که کتاب رو با قیمت پایین تر داشتند. احتمالا از یه جای خاصی پیدا کردند ولی در اینترنت فقط همین ترجمه وجود داره.اما دلیل اصلی انتخاب این کتاب محبوبیت اونه. همه برنامه نویس ها حداقل اسم این کتاب رو شنیدن. اگر ما با یک کتاب کمتر شناخته شده شروع میکردیم قطعا همین چند نفر هم جذب این کار نمیشدند. دوست داری کمک کنی؟اصلا کار سختی نیست . با ترجمه یک خط هم میتونید به پیشرفت این پروژه کمک کنید. بخش های ترجمه نشده به صورت انگلیسی در گیت هاب گذاشته شده. کافیه این بخش ها رو با ترجمه خودتون عوض کنید . به همین راحتی.یا میتونید بخش های ترجمه شده رو بازبینی و اصلاح کنیداگر قصد لایک کردن داری به جاش یک پاراگراف از کتاب رو ترجمه کنگیت هاب مابا ایمیل noahopentranslate@gmail.com هم میتونید با من در ارتباط باشید Noah Noah Sat, 11 Apr 2020 20:29:09 +0430 https://virgool.io/@dndshmdr/%D8%AE%D8%AF%D8%A7%D8%AD%D8%A7%D9%81%D8%B8-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7-pobn6zac4yal این پست ترجمه Goodbye, Object Oriented Programming در مدیومه که همین الان 158000 لایک خورده. پس فکر میکنم ارزش چند بار خوندن رو داره. به نظر من ترجمه این جور مقاله ها یکم سخته چون همه اصطلاحات برنامه نویسی انگلیسی هستند و اصل مقاله هم انگلیسیه و یه جورایی با هم دیگه هماهنگ هستند. به خاطر همین مجبور شدم یکم مقاله رو تغییر و خلاصه کنم که منظور رو بهتر برسونم- امیدوارم. ولی اصل قضیه هیچ تغییری نکرده. لذت ببرید...من چند دهه است که با زبان های شی گرا برنامه نویسی می کنم. اولین زبان شی گرایی که استفاده کردم C ++ و سپس Smalltalk و در آخر .NET و Java بود.خیلی مشتاق بودم که از مزایای وراثت ، محصورسازی و چند ریختی استفاده می کردم. سه ستون شی گرایی.مشتاق بودم وعده "قابلیت استفاده مجدد "را بدست آورم و از دانش کسانی که پیش از من در این منظره جدید و جالب بوده اند استفاده کنم.نمی توانم هیجانم را هنگام فکرکردن به شبیه سازی دنیای واقعی در کلاس ها توصیف کنم و انتظار داشتم همه چیز درست پیش برود.بیشتر از این نمیتوانستم اشتباه کنم!وراثت, سقوط اولین ستون در نگاه اول ، به نظر می رسد که وراثت بزرگترین مزیت الگو شی گرا است. به نظر می رسد که تمام مثال های ساده گرایانه از سلسله مراتب shape که به عنوان مثال جلو تازه وارد ها رژه میروند ، منطقی هستند.و‘استفاده مجدد’ کلمه روز است. نه ... سال و شاید همیشه .من همه این ها را قورت دادم و با بینش تازه خود به جهان حمله کردم!مشکل جنگل, میمون, موزبا ایمان در قلبم و مشکلاتی برای حل ، شروع کردم به ساخت سلسله مراتب کلاس و نوشتن کد. و همه با جهان هماهنگ بود.هرگز آن روز را فراموش نخواهم کرد که من با ارث بردن از یک کلاس ، آماده استفاده از وعده ‘’استفاده مجدد ‘’ شدم. این لحظه ای بود که هنوز منتظر ان هستم .یک پروژه جدید گرفتم و به آن کلاس که در پروژه قبلی ایجاد کرده بودم برگشتم .مشکلی نیست . دوباره استفاده کنید تا نجات پیدا کنید. تنها کاری که باید انجام دهم این است که آن کلاس را از پروژه دیگر بگیرم و از آن استفاده کنم.خوب ... در واقع ... نه فقط آن کلاس. ما به کلاس پدر هم احتیاج داریم. اما ... اما اینصبر کنید ... صبر کنید ... به نظر می رسد ما به پدر پدر نیز احتیاج داریم ... و بعد ... ما به همه والدین احتیاج داریم. باشه ... باشه ... من این کار رو میکنم مشکلی نیست.یک نقل قول عالی توسط جو آرمسترانگ ، خالق ارلانگ وجود دارد:مشکل زبانهای شی گرا این است که آنها این همه محیط ضمنی را با خود حمل میکنند. شما یک موز می خواستید اما آنچه شما گرفتید یک میمون, موز و کل جنگل بودراه حل جنگل, میمون ,موزمن می‌توانم این مشکل را با ایجاد نکردن سلسله‌مراتب های عمیق حل کنم.اما اگر وراثت کلید استفاده مجدد باشد ، مطمئناً هر محدودیتی که در آن مکانیزم قرار خواهم داد ، مزایای استفاده مجدد را محدود می کند. درسته؟درست.نگهدار و واگذار کن (Contain and Delegate- اگر معادل مناسب تری بلدید بهم بگید).بعداً درباره این مورد صحبت خواهم کرد.مسئله لوزیدیر یا زود ، مشکل زیر زشتی خودشو نشون میده و بسته به زبان ، مشکلی حل نشدنی است.اکثر زبانهای شی گرا از این امر پشتیبانی نمی کنند ، حتی اگر به نظر می رسد منطقی باشد. پشتیبانی از این امر در زبانهای شی گرا چقدر دشوار است؟خوب ، شبه کد زیر را تصور کنید:Class PoweredDevice { } Class Scanner inherits from PoweredDevice { function start() { } } Class Printer inherits from PoweredDevice { function start() { } } Class Copier inherits from Scanner, Printer { }توجه کنید که هم کلاس Scanner و هم کلاس Printer تابعی به نام start را پیاده سازی میکنند.بنابراین کلاس Copier کدام تابع start را به ارث می برد؟ Scanner یا Printer؟ هر دو نمی توانند باشند.راه حل لوزیراه حل ساده است. این کار را نکنید.بله درست است. اکثر زبانهای شی گرا به شما اجازه نمی دهند این کار را انجام دهید.اما ، اما ... اگر مجبور شدم این را مدل را پیاده سازی کنم چه؟ پس استفاده مجدد چی شد؟ شما باید نگه دارید و واگذار کنید.Class PoweredDevice { } Class Scanner inherits from PoweredDevice { function start() { } } Class Printer inherits from PoweredDevice { function start() { } } Class Copier { Scanner scanner Printer printer function start() { printer.start() } }توجه کنید که کلاس Copier اکنون نمونه ای از Printer و Scanner را دارد. این پیاده سازی تابع start را به کلاس Printer واگذار می کند. این می تواند به راحتی به Scanner واگذار شود.این مشکل شکاف دیگری در ستون وراثت است.مشکل کلاس شکنندهبنابراین من سلسله مراتب خود را کم عمق می کنم و آنها را چرخه ای نگه می دارم. هیچ لوزی وجود ندارد .و همه با جهان سازگار هستند. تا اینکه...یک روز کد من کار می کند و روز دیگر کار نمیکند . ولی... من که کد را تغییر ندادم.خوب ، شاید یک باگ باشد ... اما صبر کنید ... چیزی تغییر نکرده ... مشکل از کد من نیست. معلومه تغییر از کلاسی که از ان ارث بری کرده ام بوده.چطور ممکنه تغییر در کلاس پایه(base) کد من را خراب کند ؟؟اینجوریاس ...کلاس پایه زیر را تصور کنید (با جاوا نوشته شده ، اما اگر جاوا بلد نیستید هم فهم ان باید آسان باشد):import java.util.ArrayList; public class Array { private ArrayList<Object> a = new ArrayList<Object>(); public void add(Object element) { a.add(element); } public void addAll(Object elements[]) { for (int i = 0; i < elements.length; ++i) a.add(elements[i]); // this line is going to be changed } }**مهم**: خط کد کامنت شده را به خاطر بسپارید. این خط بعداً تغییر خواهد کرد که باعث خراب شدن اوضاع خواهد شد.این کلاس دارای دو تابع در رابط کاربری خود است start و addAll. تابع add یک عنصر واحد اضافه می کند و addAll () با فراخوانی تابع add ، چندین عنصر را اضافه می کند.و اینجا کلاس مشتق شده است:public class ArrayCount extends Array { private int count = 0; @Override public void add(Object element) { super.add(element); ++count; } @Override public void addAll(Object elements[]) { super.addAll(elements); count += elements.length; } }کلاس ArrayCount کلاسی خاص از کلاس اصلی Array است. تنها تفاوت رفتاری این است که ArrayCount تعداد عناصر را نگه می دارد(در متغیر count).بیایید با جزئیات به هر دو کلاس نگاه کنیم.تابع Array.add عنصری را به ArrayList محلی اضافه می کند.تابع Array.addAll ارایه ArrayList محلی را برای افزودن هر عنصر فراخوانی می کند.تابع ArrayCount.add , تابع add کلاس پدر خود را فراخوانی میکند و مقدار count را افزایش میدهد.تابع ArrayCount.addAll , تابع addAll کلاس پدر خود را فراخوانی میکند و با توجه به تعداد عناصر ان مقدار count را افزایش میدهد.و همه خوب کار می کنندحالا خط کد کامنت شده در کلاس پایه به شرح زیر تغییر می کند:public void addAll(Object elements[]) { for (int i = 0; i < elements.length; ++i) add(elements[i]); // this line was changed }و هنوز همه تست ها را پاس میکند.اما کلاس پدر به کلاس مشتق شده توجهی ندارد.حالا ArrayCount.addAll متد addAll کلاس پدر خود را فراخوانی میکند. که خودش متد add را که به صورت داخلی توسط کلاس مشتق شده override شده را فراخوانی میکند.این باعث میشد که مقدار count هر بار که متد add فراخوانی میشود افزایش یابد و وقتی متد addAll کلاس مشتق شده فراخوانی میشود دوباره افزایش یابد.دو بار حساب شدهاگر این میتواند اتفاق بیفتد ,و اتفاق بیفتد ، نویسنده کلاس Derived باید نحوه پیاده سازی کلاس پایهBase را بداند. و آنها باید از هر تغییری در کلاس پایه مطلع شوند زیرا این امر می تواند کلاس مشتق آنها را به روش های غیرقابل پیش بینی تغییر دهد.اوه! این شکاف بزرگ برای همیشه ثبات ستون ارزشمند وراثت را تهدید می کند.راه حل کلاس شکننده یک بار دیگر نگه دارید و واگذار کنید. با استفاده از نگه داشتن و واگذار کردن، از برنامه نویسی White Box به برنامه نویسی Black Box می رویم. در برنامه نویسی White Box باید به اجرای کلاس پایه توجه کنیم. در برنامه نویسی Black Box ، می توانیم پیاده سازی کلاس پایه را کاملاً نادیده بگیریم زیرا نمی توانیم با override کردن یکی از متد های آن ، کد را به کلاس پایه تزریق کنیم. ما فقط باید خود را نگران واسط-interface کنیم.این روند نگران کننده است ... قرار بود وراثت برای "استفاده مجدد" یک برد بزرگ باشد. زبانهای شیء گرا ، نگه داشتن و واگذار کردن را به راحتی انجام نمی دهند. اینها طراحی شده اند تا وراثت را ساده کنند. اگر مثل من هستید ، شروع به تعجب در مورد این موضوع وراثت می کنید. اما مهمتر از این ، این باید اعتماد شما را نسبت به قدرت طبقه بندی از طریق سلسله مراتب متزلزل کند.مسئله سلسله مراتب هر وقت در یک شرکت جدید شروع به کار می کنم ، وقتی مکانی را برای قرار دادن اسناد شرکتم ایجاد می کنم با این مشکل دست و پنجه نرم می کنم. کتابچه راهنمای کارمندان. آیا پوشه ای به نام Document ایجاد می کنم و سپس یک پوشه به نام Company در آن ایجاد می کنم؟ یا آیا من یک پوشه به نام Company ایجاد می کنم و سپس یک پوشه به نام Document را در آن ایجاد می کنم؟ هر دو کار می کنند. اما کدام درست است؟ کدام بهتر است؟مایده سلسله مراتب طبقه بندی شده این بود که کلاسهای پایه (والدین) وجود داشتند که عمومی تر بودند و کلاسهای مشتق شده (فرزندان) نسخه های خاص تر آن کلاسها بودند. و وقتی در زنجیره وراثت پایین میرویم خاص تر هم میشود. (سلسله مراتب shape را در بالا مشاهده کنید) اما اگر پدر و فرزند می توانند خودسرانه خود را تغییر دهند ، پس به وضوح چیزی در مورد این مدل اشتباه است.راه حل سلسله مراتبچیزی که که درست نیست اینه که ...سلسله مراتب طبقه بندی شده کار نمیکندپس سلسله مراتب به چه دردی میخورد؟شامل بودن( دارا بودن - محتوی) - containmentاگر به دنیای واقعی نگاه کنید ، سلسله مراتب محتوی (یا مالکیت انحصاری) را در همه جا مشاهده خواهید کرد. آنچه شما پیدا نخواهید کرد سلسله مراتب طبقه بندی شده است. بگذار کمی به آن فکر کنم. الگو شی گرایی مبتنی بر جهان واقعی بود. اما از یک مدل ناقص استفاده می کند . سلسله مراتب طبقه بندی شده، هیچ شباهتی به دنیای واقعی ندارند. اما دنیای واقعی مملو از سلسله مراتب های محتوی است. یک نمونه عالی از یک سلسله مراتب محتوی جورابهای شما است. آنها در یک کشو جوراب قرار دارند که کشو در کمد شما است و کمد در اتاق خواب شما قرار دارد که اتاق خواب هم در خانه شما قرار دارد و غیره.فولدر های هارد دیسک شما نمونه دیگری از سلسله مراتب های محتوی هستند. آنها حاوی فایل هستند. پس چگونه طبقه بندی می کنیم؟ خوب ، اگر به اسناد شرکت فکر می کنید ، اهمیتی ندارد که آنها را کجا قرار میدهم. می توانم آنها را در پوشه Documents یا پوشه ای بنام Stuff قرار دهم.من انها را با برچسب(تگ خودمون) دسته بندی میکنم.Document Company Handbookتگ ها ترتیب یا سلسله مراتب خاصی ندارند.(این مشکل لوزی را هم حل میکند)تک ها با واسط-interface ها مشابه هستند زیرا می توانید انواع مختلفی از Document داشته باشید. اما با وجود ترک های زیاد ، به نظر می رسد ستون وراثت سقوط کرده است. خداحافظ ، وراثتمحصور سازی - Encapsulation , سقوط دومین ستوندر نگاه اول ، به نظر می رسد محصور سازی دومین مزیت بزرگ برنامه نویسی شی گرا است. متغیرهایی که وضعیت شی را توصیف میکنند(فیلد ها)از دسترسی خارجی محافظت می شوند ، یعنی آنها در شی محصور شده اند. دیگر لازم نیست که نگران متغیرهای جهانی(global) باشیم که خدا میداند چه کسانی به ان دسترسی دارند.محصور سازی امنیت متغیرهای شما را تضمین میکند. این چیز محصور سازی باور نکردنیه !! زنده باد محصور سازی ... تا اینکه ...مشکل ارجاع - Referenceبرای کارآیی ، اشیاء به واسطه ارجاع- Reference شان در دسترس توابع قرار میگیرد نه مقدارشان. این بدان معنی است که توابع یک شی نمیگیرند ، بلکه یک ارجاع یا اشاره گر را به شی را میگیرند. اگر ارجاع یک شی به یک سازنده شی- Object Constructor پاس شود , سازنده می تواند ارجاع شی را در یک متغیر خصوصی-private قرار دهد که توسط محصور سازی محافظت می شود.اما شی پاس شده در امان نیستچرا نه؟چون قطعه کد های دیگر یک ارجاع به شی را دارند.مثلا کد های درون سازنده. ایا حتما باید یک ارجاع از شی داشته باشیم وگرنه نمیتوانیم انرا به سازنده پاس کنیم؟راه حل ارجاعسازنده باید انها در شی کلون کند. و نه یک کلون کم عمق بلکه یک کلون عمیق . یعنی هر شی پاس شده و شی های درون انها و غیره .برای بهره وری بیش از حد زیاده.و این یک مشکل است. همه اشیاء نمی توانند کلون شوند. برخی از منابع سیستم عامل در ارتباط با آنها ، کلون کردن را در بهترین حالت یا در بدترین حالت غیر ممکن است.و هر زبان شی گرا اصلی این مشکل را دارد.خداحافظ ، محصور سازی.چند ریختی, سقوط سومین ستونچند ریختی بد نیست اما برای دستیابی به ان حتما نیاز به یک زبان شی گرا نداریم.واسط-interface ها این را به شما می دهند. بدون خرت و پرت های شی گرایی.و با واسط ها ، محدودیتی برای تعداد رفتارهای مختلف که می توانید با هم مخلوط کنید وجود ندارد.بنابراین بدون هیچ گونه آزار و اذیت ، ما با چند ریختی شی گرا خداحافظی می کنیم و به چند ریختی مبتنی بر واسط سلام میکنیم.قول های شکسته شدهخوب ، شی گرایی مطمئناً در روزهای اولیه وعده های زیادی داده است. و این وعده ها هنوز به برنامه نویسان ساده لوح که در کلاسهای درس نشسته اند ، وبلاگ ها را می خوانند و دوره های آنلاین را می گذرانند ، داده می شود.برای درک اینکه چطور شی گرایی به من دروغ گفت ، سالها طول کشید. من هم بسیار چشم بسته و بی تجربه اعتماد داشتم.خداحافظ ، برنامه نویسی شی گرا.حالا چیکار کنیم؟سلام ، برنامه نویسی functional. کار با شما در طول چند سال گذشته بسیار خوب بوده است.فقط می دانید ، من هیچ یک از وعده های شما را ارزش نمیدانم. من باید آن را ببینم تا آن را باور کنم.اگر این مقاله را دوست داشتید ، لایک کنید تا افراد دیگر ان را در ویرگول مشاهده کنند.پادکستشماره ۲۲پادکست رادیو بوت که توسط اقای سمیر رحمانی تهیه شده در مورد تفاوت زبان های شی گرا و فانکشنال صحبت میکنه. شنیدن اش رو به همه توصیه میکنم . خود اقای رحمانی هم اشاراتی به این مقاله دارند.مطالعه های اینده https://virgool.io/@dndshmdr/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7-%D9%81%D8%A7%D8%AC%D8%B9%D9%87-%D9%85%DB%8C%D9%84%DB%8C%D8%A7%D8%B1%D8%AF-%D8%AF%D9%84%D8%A7%D8%B1%DB%8C-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-oat4sazhuzac منبع： Medium Noah Noah Tue, 07 Apr 2020 15:10:32 +0430 https://virgool.io/@dndshmdr/%DA%86%D8%B7%D9%88%D8%B1-%D8%A8%D8%A7-%D8%AA%D8%B1%D9%85%DB%8C%D9%86%D8%A7%D9%84-%D9%84%DB%8C%D9%86%D9%88%DA%A9%D8%B3-%D9%85%D9%88%D8%B3%DB%8C%D9%82%DB%8C-%D9%BE%D8%AE%D8%B4-%DA%A9%D9%86%DB%8C%D9%85-o7trobe36xfu ترمینال چیز عجیبیه.اول با ترس میری سمتش ولی هرچی بیشتر باهاش اشنا میشی بیشتر دوست داری باهاش کار کنی. تا جایی که دوست داری همه کار هاتو با ترمینال انجام بدی. ولی محیط ترمینال بیش از خشکه. یه چیزی لازم داریم که حال و هوامونو یکم عوض کنه. چی بهتر موسیقی.بله. میتونید از ترمینال موسیقی پخش کنید و یک موزیک پلیر کامل داشته باشید. ابزار های مختلفی برای این کار هست ولی من از "cmus" استفاده میکنم. برای دیدن جادو اماده هستید ؟ کمربنداتونو محکم ببندید...نصببرای نصب cmus خیلی راحت دستور زیر رو تو ترمینالتون کپی کنید.اگه توی اوبونتو, دبیان , مینت و امسال اونها هستید：sudo apt-get install cmusاگه توی فدورا و CentOs و... هستید：yum install cmusشروعهر وقت به موسیقی نیاز داشتید کافیه فقط 'cmus' رو توی ترمینال بنویسید و اینتر بزنید. به صفحه ای منتقل میشید که پلی لیست شخصیتون رو نشون میده：برای اینکه اهنگی رو به این پلی لیست اضافه کنید کلید '5' رو فشار بدید تا به محیط فایل منیجر هدایت بشید. چیزی مثل این： حالا با فلش های روی کیبورد و اینتر و Backspace توی اون میگردید . هر پوشه یا فایلی رو که میخواهید به پلی لیست اضافه بشه،کافیه بعد از اینکه انتخابش کردید و به اصطلاح هایلایت شد کلید 'a' رو بزنید. Cmus ادعا میکنه که این تغییرات خودکار ذخیره میشن ولی محض احتیاط ‘save:’ رو هم بنویسید و اینتر بزنید.وقتی با استفاده از کلید ‘2 ’ به محیط پلی لیست برگردید میبینید که اهنگ هایی که انتخاب کردید اضافه شده. با فلش های بالا و پایین روی کیبورد یکی رو انتخاب کنید و اینتر رو بفشارید. اولین لحظه ای که با ترمینال یک اهنگ رو پخش میکنید خیلی حس فوق العاده ای داره و یکم حس هکری میاد سراغ ادم：)چطور پخش اهنگ رو کنترل کنیم؟با کلید 'c' اونو متوقف / اجرا کنید.با کلید های '>' و '<' یک دقیقه جلو و عقب برید.با فلش های چپ و راست ده ثانیه جلو و عقب برید.با کلید ‘z’ اهنگ قبلی وبا کلید 'b' اهنگ بعدی رو پخش کنید.چطور اهنگ بعدی رو مشخص کنیم؟امکانات خوبی برای اینکه مشخص کنیم بعد از تموم شدن یک اهنگ کدوم پخش بشه وجود داره. وضعیت این رو میتونید در گوشه پایین و راست صفحه ببینید. دو تا حرف پشت سر هم وجود داره که با "|" از هم جدا شده.اولین حرف میگه کدوف مجموعه از اهنگ ها رو داریم پخش میکنیم.با کلید'm' اپشن های مختلف اونو ببینید. معمولا تو وضعیت 'all of library' به معنای تمام پلی لیست فعلی هست. حرف سمت راستش که با "|" از اولی جدا شده مشخص میکنه بعد از تموم شدن اهنگ فعلی یا اهنگ های پلی لیست چیکار کنه. چهار تا وضعیت داره که این دوتا مهم تره：اگر C به معنای continue بود بعد از تموم شدن هر اهنگ اهنگ بعدی رو شروع میکنه. اگر فعال نبود بعد از اتمام هر اهنگ متوقف میشه.اینو میتونید با shift-C فعال کنید.اگر R به معنا repeat بود بعد از تموم شده پلی لیست از اول شروع میکنه. با کلید r میتونید این رو فعال کنید.این برنامه امکانات خیلی زیادی داره که اگه دوست دارید باهاشون انشا بشید شما رو به داکیومنت هاش هدایت میکنم.تموم شد. امیدوارم لذت برده باشید. ترمینال خیلی چیز باحلیه . ازش نترسید. تجربه کوتاهی از مرورگر ترمینالی هم دارم که شاید به اشتراک گذاشتم. Noah Noah Fri, 03 Apr 2020 07:12:18 +0430 https://virgool.io/@dndshmdr/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7-%D9%81%D8%A7%D8%AC%D8%B9%D9%87-%D9%85%DB%8C%D9%84%DB%8C%D8%A7%D8%B1%D8%AF-%D8%AF%D9%84%D8%A7%D8%B1%DB%8C-%D9%82%D8%B3%D9%85%D8%AA-%D9%87%D9%81%D8%AA%D9%85%D9%BE%D8%A7%DB%8C%D8%A7%D9%86%DB%8C-gk3acjpclq6v این پست ترجمه بخشی از مقاله "Object-Oriented Programming — The Trillion Dollar Disaster" از Medium است. مقاله اصلی خیلی طولانی بود . به همین خاطر مجبور شدم ان را به چند بخش تقسیم کنم.اگر قسمت های قبل را نخوانده اید , خواندن این بخش را متوقف کنید و از قسمت اول بخوانید تا اصل ماجرا را بفهمید.قسمت اول - مقدمهقسمت دوم - OOP به جای چیز های درست به کار میرودقسمت سوم - من متاسفم که اصطلاح اشیا را ابداع کردم!قسمت چهارم - OOP ربطی به دنیای واقعی ندارد!قسمت پنجم - قلمرو اشیاقسمت ششم - چسب زخم الگو های طراحیفرو ریختن چهار ستون OOPچهار ستون OOP عبارت اند از : انتزاع-Abstraction و وراثت و محصور سازی-Encapsulation و چند ریختی-Polymorphism.بیایید یکی یکی ببینیم واقعاً چه هستندوراثتمن فکر می کنم عدم قابلیت استفاده مجدد در زبانهای شی گرا و جود دارد، نه در زبانهای فانکشنال. مشکل زبانهای شی گرا این است که آنها کلی محیط ضمنی را با خود حمل میکنند. شما یک موز می خواستید اما آنچه شما گرفتید یک گوریل موز و کل جنگل بود. ---- Joe Armstrong خالق ارلانگوراثت OOP هیچ ارتباطی با دنیای واقعی ندارد. وراثت ، در حقیقت ، یک روش پایین دستی برای دستیابی به قابلیت استفاده مجدد از کد است. برخی از زبانهای برنامه نویسی مدرن به طور کلی از وراثت پشتیبانی نمیکنند.وراثت چند مشکل دارد:كدی را وارد كنید كه كلاس شما حتی نیازی به آن نداشته باشد (مسئله موز و جنگل). داشتن بخش هایی از کلاس شما که در جایی دیگر تعریف شده است ، تحلیل آن را دشوار می کند ، مخصوصاً با وجود چندین سطح وراثت. در اکثر زبانهای برنامه نویسی ، وراثت چندگانه حتی ممکن نیست. این بیشتر وراثت را به عنوان مکانیسم اشتراک کد ، بی فایده می کند.چند ریختی OOP چند ریختی عالی است ، به ما این امکان را می دهد که رفتار برنامه را در زمان اجرا تغییر دهیم. با این حال ، این یک مفهوم بسیار مقدماتی در برنامه نویسی است. من نمی دانم که چرا OOP اینقدر به چند ریختی توجه می کند. چند ریختی OOP کار را انجام می دهد اما بار دیگر منجر به عمل دستکاری ذهنی می شود(در قسمت های قبل توضیح داده شده). این امر باعث می شود كه كد به طور قابل توجهی پیچیده تر شود و استدلال در مورد متد واقعی كه مورد استفاده قرار می گیرد واقعاً سخت می شود.از طرف دیگر برنامه نویسی functional به ما این امکان را می دهد که به شکلی ظریف تر به همان چند ریختی دست یابیم ... به سادگی با ک استفاده از متدی که رفتار دلخواه ما در زمان اجرا را مشخص میکند. چه چیزی می تواند ساده تر از این باشد؟ نیازی به تعریف دسته ای از متد مجازی و اضافی بارگذاری شده در چندین فایل (و واسط) نیست.محصور سازی همانطور که قبلاً بحث کردیم ، محصور کردن اسب تروجان OOP است. این در واقع یک وضعیت قابل تغییر عمومی(جهانی- global) قابل تغییر است و باعث می شود کد ناامن به نظر بی خطر برسد. کد ناامن ستونی است که برنامه نویسان OOP در کار روزانه خود به آن تکیه میکنند ...انتزاع انتزاع در OOP تلاش می کند با پنهان کردن جزئیات غیرضروری از برنامه نویس ، با پیچیدگی ها مقابله کند. از لحاظ تئوریک ، این امکان را برای توسعه دهنده فراهم می کند که بدون نیاز به فکر کردن در مورد پیچیدگی پنهان شده ، کد را تحلیل کند.من نمی دانم چه بگویم ... یک کلمه جالب برای یک مفهوم ساده. در زبانهای رویه ای / functional ما می توانیم به سادگی جزئیات اجرا (همون پیچیدگی هایی که باید مخفی شود) را در یک فایل همسایه مخفی کنیم. نیازی نیست که این عمل پایه ای را "انتزاع" بنامیم.چرا OOP بر صنعت حاکم است؟پاسخ ساده است ، نژاد بیگانه ای از خزندگان با NSA (و روسها) توطئه كرده اند تا ما برنامه نویسان را تا حد مرگ شکنجه کنند...اما به طور جدی ، جاوا احتمالاً پاسخ مورد نظراست.جاوا نگران کننده ترین چیزی است که از زمان MS-DOS (ویکی پدیا)برای کامپیوتر اتفاق افتاده است. --- الن کی - خالق OOPجاوا ساده بودهنگامی که اولین بار در سال 1995 معرفی شد ، جاوا در مقایسه با گزینه های دیگر یک زبان برنامه نویسی بسیار ساده بود . در آن زمان ، موانع زیادی برای ورود به نوشتن برنامه های دسک تاپ بود. توسعه برنامه های دسک تاپ شامل نوشتن API های سطح پایین win32 در C است ، و توسعه دهندگان نیز مجبور بودند که خود را با مدیریت حافظه دستی نگران کنند. جایگزین دیگر ویژوال بیسیک بود ، اما احتمالاً بسیاری نمی خواستند خود را در اکوسیستم مایکروسافت قفل کنند.هنگامی که جاوا معرفی شد ، برای بسیاری از برنامه نویسان واضح بود چونکه رایگان بود ، و می توانست در تمام سیستم عامل ها مورد استفاده قرار گیرد. مواردی مانند جمع آوری زباله های داخلی ، API هایی با نام دوستانه (در مقایسه با API های رمزنگاری win32) ، مکان های نام مناسب و سینتکس آشنای C مانند جاوا را قابل دسترسی تر می کند.برنامه نویسی GUI نیز رایج تر شد و به نظر می رسید که کامپوننت های مختلف UI به خوبی با کلاس ها سازگار شده اند. تکمیل خودکار متد در IDE همچنین باعث شد تا مردم ادعا کنند که API های OOP ساده تر هستند.شاید جاوا اینقدر بد نمی بود اگر برنامه نویسان را به استفاده از OOP مجبور نمیکرد. همه چیز در مورد جاوا بسیار خوب به نظر می رسید. جمع آوری زباله ، قابلیت حمل و نقل ، ویژگی های دست زدن به استثناء ، که سایر زبان های برنامه نویسی اصلی فاقد آن بودند ، در سال 1995 واقعاً عالی بودند ، سی شارپ از راه میرسددر ابتدا ، مایکروسافت به شدت به جاوا تکیه کرده بود. هنگامی که همه چیز بدتر شد (و پس از یک نزاع حقوقی طولانی با Sun Microsystems بر سر صدور مجوز جاوا) ، مایکروسافت تصمیم گرفت روی نسخه ای شخصی از جاوا سرمایه گذاری کند. این زمانی است که C # 1.0 به دنیا آمد. C # به عنوان یک زبان همیشه به عنوان "جاوا بهتر" تصور می شد. با این حال ، یک مشکل بزرگ وجود دارد - این همان زبان OOP با همان نقص ها بود ، که در زیر یک سینتکس کمی بهبود یافته پنهان شده بودند.مایکروسافت سرمایه گذاری زیادی در اکوسیستم .NET خود انجام داده است ، که شامل ابزارهای توسعه دهنده خوبی نیز می باشد. سالهاست که ویژوال استودیو احتمالاً یکی از بهترین IDE های موجود بوده است. این به نوبه خود منجر به تصویب گسترده چارچوب .NET ، به ویژه در شرکت شده است.اخیراً مایکروسافت با هل دادن TypeScript خود سرمایه گذاری زیادی در اکوسیستم مرورگر انجام داده است. TypeScript بسیار عالی است زیرا می تواند جاوا اسکریپت خالص را کامپایل کند و مواردی مانند بررسی نوع استاتیک را اضافه می کند. انچه در ان جالب نیست این است که از پشتیبانی مناسب برای ایجاد برنامه های فانکشنال برخوردار نیست - هیچ ساختار داده غیرقابل تغییری ساخته شده نشده ، ترکیب متد وجود ندارد و عدم تطبیق الگوی مناسب. TypeScript اول OOP است ، و بیشتر C # برای مرورگر ها است. Anders Hejlsberg حتی مسئول طراحی هر دو C # و TypeScript بود.زبان های فانکشنالاز سوی دیگر ، زبانهای functional هرگز توسط کسی به اندازه مایکروسافت پشتیبانی نشده اند. F # حساب حساب نمیشود زیرا سرمایه گذاری ناچیزی پشت ان بود. توسعه زبانهای functional بیشتر جامعه محور است. این احتمالاً تفاوت محبوبیت بین زبانهای OOP و FP را توضیح می دهد.زمان حرکت کردن است؟اکنون می دانیم که OOP تجربه ای است که شکست خورده است. وقت حرکت است. زمان آن رسیده است که ما به عنوان یک جامعه بپذیریم که این ایده ما را ناکام کرده است و باید از آن ترک کنیم. --- Lawrence Krubnerچرا ما از چیزی استفاده می کنیم که اساساً یک راه کم اهمیت برای سازماندهی برنامه ها است؟ آیا این جاهلیت آشکار است؟ من شک دارم ، افرادی که در مهندسی نرم افزار کار می کنند احمق نیستند. آیا با استفاده از اصطلاحات فانتزی OOP مانند "الگوهای طراحی" ، "انتزاع" ، "محصور سازی" ، "چند ریختی" و "تفکیک واسط-interface segregation" ، میخواهیم بین همسالانمان "هوشمند" به نظر برسیم؟ احتمالا نه.من فکر می‌کنم که استفاده از چیزی که چندین دهه است از آن استفاده کرده‌ایم، ادامه پیدا کند. اکثر مردم هرگز واقعا یک برنامه‌نویسی functional را امتحان نکرده اند. آن‌هایی که مثل من (مثل خودم) امتحان کرده اند هرگز نمی‌توانند به نوشتن کد OOP برگردند.هنری فورد یک جمله معروف دارد: "اگر من از مردم میپرسیدم چه چیزی میخواهند ، آنها سریع می گفتند اسب". در دنیای نرم افزار ، بیشتر افراد احتمالاً "زبان OOP بهتر" می خواهند. مردم به راحتی می توانند مشکلی را که دارند (بدست اوردن کد سازماندهی شده و ساده تر) توصیف کنند ، اما بهترین راه حل نیست.گزینه های روی میز چیست؟هشدار اسپویل: برنامه نویسی functional.اگر اصطلاحاتی از قبیل functor ها و monad ها شما را کمی ناراحت می کند ، پس تنها نیستید! برنامه نویسی کاربردی چندان ترسناک نبود اگر نام های شهودی بیشتری به برخی از مفاهیم آن داده شده بود. Functor؟ خیلی ساده,‌چیزی است که با یک متد میشود ان را توصیف کرد ,مثلا list.map. موناد-Monad؟ به سادگی محاسباتی که می توان زنجیره ای کرد!امتحان کردن برنامه نویسی functional شما را به یک توسعه دهنده بهتر تبدیل می کند. سرانجام به جای این که بیشتر وقت خود را صرف فکر کردن در مورد انتزاع و الگوهای طراحی کنید ، زمان را صرف نوشتن کد واقعی برای حل مشکلات در دنیای واقعی را خواهید کرد.ممکن است شما متوجه این موضوع نشوید ، اما در حال حاضر یک برنامه نویس functional هستید. آیا در کار روزانه خود از توابع استفاده می کنید؟ آره؟ سپس شما در حال حاضر یک برنامه نویس functional هستید! فقط باید یاد بگیرید که چگونه می توانید از این توابع بهترین استفاده را ببرید.دو زبان functional عالی با منحنی یادگیری بسیار ملایم Elixir و Elm هستند. آنها به توسعه دهنده روی چیزی که مهم تر است تمرکز کنند -- نوشتن نرم افزار قابل اعتماد در حالی که تمام پیچیدگی هایی را که زبانهای کاربردی سنتی تر دارند از بین ببرد.گزینه های دیگر چیست؟ آیا شرکت شما قبلاً از C # استفاده می کرد؟ سعی کنید F # را امتحان کنید - یک زبان کاربردی شگفت انگیز است ، و قابلیت همکاری عالی با کد NET موجود را فراهم می کند. استفاده از جاوا؟ سپس استفاده از Scala یا Clojure هر دو گزینه خوب هستند. از JavaScript استفاده می کنید؟ با راهنمایی و پوشش صحیح ، جاوا اسکریپت می تواند یک زبان functional خوب باشد.مدافعان OOPمن انتظار نوعی عکس العمل از مدافعان OOP دارم. آنها خواهند گفت كه این مقاله مملو از غلط است. برخی حتی ممکن است شروع به نام بردن اسم کنند. آنها حتی ممکن است من را یک توسعه دهنده "جوان" بنامند که هیچ تجربه OOP در دنیای واقعی ندارد. ممکن است برخی بگویند فرضیات من اشتباه است و مثال های آن بلا استفاده است.آنها حق نظر خود را دارند. با این حال ، استدلال های آنها در دفاع از OOP معمولاً بسیار ضعیف است. طعنه آمیز است که احتمالاً اکثر آنها هرگز واقعا با زبان functional برنامه نویسی نکرده اند. اگر کسی که واقعاً هر دو را امتحان نکرده باشد ، چگونه می تواند بین دو چیز مقایسه کند؟ چنین مقایسه هایی مفید نیستند.قانون Demeter خیلی هم مفید نیست - هیچ کاری برای پرداختن به مسئله عدم قطعیت نمی کند ، وضعیت تغییر پذیر هنوز هم وضعیت تغییر پذیر است ، مهم نیست که چگونه به آن حالت دسترسی پیدا کرده یا تغییر پیدا کند. a.total () خیلی بهتر از a.getB().getC().total()نیست؟.قانون Domain-Driven Design؟ این یک روش طراحی مفید است ، و کمی به کاهش پیچیدگی کمک می کند. با این حال ، هنوز هیچ کاری برای پرداختن به مسئله اساسی وضعیت مشترک قابل تغییر پذیر نمی کند.فقط یک ابزار در جعبه ابزار...من اغلب می شنوم که مردم می گویند OOP فقط یکی دیگر از ابزارهای جعبه ابزار است. بله ، به همان اندازه یک ابزار در جعبه ابزار است زیرا اسب ها و ماشین ها هر دو وسیله حمل و نقل هستند ... از اینها که بگذریم ، همه آنها به همان هدف خدمت می کنند ، درست است؟ چرا وقتی می توانیم سوار اسب های قدیمی خوب شویم ، از اتومبیل استفاده می کنیم؟تاریخ دوباره تکرار میشوداین در واقع چیزی را به من یادآوری می کند. در آغاز قرن بیستم ، اتومبیل ها شروع به جایگزینی اسب ها کردند. در سال 1900 در نیویورک تنها چند اتومبیل در جاده ها وجود داشت ، مردم از اسب ها برای حمل و نقل استفاده می کردند. در سال 1917 ، دیگر اسب در جاده ها باقی نماند. صنعت عظیمی حول حمل و نقل با حمل اسب قرار داشت. مشاغل زیادی پیرامون مواردی مانند تمیز کردن کود ایجاد شده بود.و مردم در برابر تغییر مقاومت کردند. آنها اتومبیل ها را یکی دیگر از "مد" خواندند که در نهایت می گذرد.هر چه باشد، اسب ها قرن ها در اینجا بوده اند! برخی حتی از دولت خواستند كه مداخله كند.یعنی چه؟ صنعت نرم افزار تقریبا OOP محور است. میلیون ها نفر در OOP آموزش دیده اند ، و میلیون ها شرکت در کد خود از OOP استفاده می کنند. البته آنها سعی خواهند کرد هر چیزی را که تهدید کننده نان و کره آنها است ، بی اعتبار کنند! این فقط عقل سلیم است.ما به وضوح می بینیم که تاریخ در حال تکرار است - در قرن بیستم این اتومبیل ها در مقابل اسب ها بودند ، در قرن بیست و یکم این برنامه نویسی شیء گرا در مقابل functional است.مطالعه های آینده https://virgool.io/@dndshmdr/خداحافظ-برنامه-نویسی-شی-گرا-pobn6zac4yal بالاخره این مقاله تمام شد. تمام تلاشم رو کردم که ترجمه خوبی اراعه بدم . اما حتما اشکالاتی وجود دارد که امیدوارم بهم بگید تا بتونم اونو اصلاح و ترجمه تر و تمیزی رو تحویل ایندگان بدم. Noah Noah Thu, 02 Apr 2020 21:58:18 +0430 https://virgool.io/@dndshmdr/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7-%D9%81%D8%A7%D8%AC%D8%B9%D9%87-%D9%85%DB%8C%D9%84%DB%8C%D8%A7%D8%B1%D8%AF-%D8%AF%D9%84%D8%A7%D8%B1%DB%8C-%D9%82%D8%B3%D9%85%D8%AA-%D8%B4%D8%B4%D9%85-d1eif7lgovgr این پست ترجمه بخشی از مقاله "Object-Oriented Programming — The Trillion Dollar Disaster" از Medium است. مقاله اصلی خیلی طولانی بود . به همین خاطر مجبور شدم ان را به چند بخش تقسیم کنم.اگر قسمت های قبل را نخوانده اید , خواندن این بخش را متوقف کنید و از قسمت اول بخوانید تا اصل ماجرا را بفهمید.قسمت اول - مقدمهقسمت دوم - OOP به جای چیز های درست به کار میرودقسمت سوم - من متاسفم که اصطلاح اشیا را ابداع کردم!قسمت چهارم - OOP ربطی به دنیای واقعی ندارد!قسمت پنجم - قلمرو اشیاریفکتورینگ - refactoring refactoring یکی از قسمت های مهم کار های روزانه برنامه نویسان است. از قضا ، کد OOP به سختی قابل ریفکتور است. refactoring قرار بود پیچیدگی را کمتر و کد را قابل اعتماد تر کند. در مقابل ، کد OOP ریفکتور شده بطور قابل توجهی پیچیده تر می شود - برای قابل تست کردن کد ، باید از تزریق وابستگی استفاده کنیم و واسط-interface ای برای کلاس ریفکتور شده ایجاد کنیم. حتی ، ریفکتور کردن کد OOP بدون ابزار اختصاصی مانند Resharper بسیار سخت است.این کد ها را داریم:قبل از ریفکتور کردن:بعد از ریفکتور کردن:در مثال ساده بالا ، تعداد خطوط فقط برای استخراج یک متد بیش از دو برابر شده است. چرا ریفکتور کردن پیچیدگی بیشتری ایجاد می کند ، در حالی که کد در درجه اول به منظور کاهش پیچیدگی ریفکتور میشود ؟این مورد را با یک ریفکتور مشابه در کد غیر OOP در JavaScript مقایسه کنید:قبل از ریفکتور:بعد از ریفکتور:کد به معنای واقعی کلمه یکسان باقی مانده است - ما فقط متد isValidInput را به فایلی دیگر منتقل کردیم و برای وارد کردن آن متد یک خط اضافه کردیم. ما همچنین به منظور قابلیت تست _isValidInput به امضای تابع اضافه کردیم.این یک مثال ساده است ، اما در عمل پیچیدگی بصورت نمایی با بزرگتر شدن کد بیشتر می شود.و این همه چیز نیست. ریفکتور کردن کد OOP بسیار خطرناک است. نمودارهای وابستگی پیچیده و وضعیت های پراکنده در سراسر کد OOP ، مغز انسان را قادر نمی سازد که همه مسائل بالقوه را در نظر بگیرد.چسب زخموقتی چیزی کار نمیکند چه کار میکنیم؟ این ساده است ، ما فقط دو گزینه داریم - آن را دور بیندازید یا سعی کنید آن را اصلاح کنید. OOP چیزی است که به راحتی قابل دور ریختن نیست ، میلیون ها توسعه دهنده در OOP آموزش می بینند. و میلیون ها سازمان در سراسر جهان از OOP استفاده می کنند.احتمالاً اکنون می بینید که OOP واقعاً کار نمی کند ، کد ما را پیچیده و غیر قابل اعتماد می کند. و شما تنها نیستید! مردم چندین دهه است که تلاش می کنند تا مشکلات موجود در کد OOP را حل کنند ، سخت فکر می کنند.که نتیجه آن تولید بی شمار الگو طراحی شده است.الگو های طراحیبرنامه نویسی شی گرا مجموعه ای از دستورالعمل ها را ارائه می دهد که از نظر تئوری باید به توسعه دهندگان اجازه دهد سیستم های بزرگتر و بزرگتر را بصورت تدریجی بسازند: اصل SOLID ، تزریق وابستگی ، الگوهای طراحی و سایر موارد.متأسفانه الگوهای طراحی چیزی جز چسب زخم نیستند. آنها فقط برای رفع کاستی های OOP وجود دارند. تعداد بی شمار کتاب در این زمینه نوشته شده است. آنها خیلی بد نیستند ، درصورتی که مسئولیت ورود پیچیدگی عظیم به کد های ما را برعهده نگرفته باشند.کارخانه مشکلدر حقیقت ، نوشتن کد شیء گرا و خوب ، غیرممکن است. در یک طرف ماجرا ، یک کد OOP داریم که نا سازگار است و به نظر نمی رسد که مطابق استاندارد باشد. در طرف دیگر ماجرا ، ما یک برجی از کدهای بیش از حد مهندسی و یک دسته از انتزاعات نادرست داریمک که یکی در بالای دیگری ساخته شده است. الگوهای طراحی در ساخت چنین برج هایی از انتزاعات بسیار مفید هستند.به زودی ، اضافه کردن قابلیت های جدید و حتی حس کردن همه پیچیدگی ها ، سخت تر و سخت تر می شود. کد مملو از مواردی مانند SimpleBeanFactoryAwareAspectInstanceFective ، AbstractInterceptorDrivenBeanDefinitionDecorator ، TransactionAwarePersistenceManagerFactoryProxyorRequestProcessorFactoryFective خواهد بود.با تلاش برای فهم برج انتزاعات که خود توسعه دهندگان ایجاد کرده اند ، نیروس مغز گرانبها را هدر می دهیم. عدم وجود ساختار در بسیاری موارد بهتر از داشتن ساختار بد (اگر از من بپرسید) است.این داستان در قسمت بعد به پایان خواهد رسید... https://virgool.io/@dndshmdr/برنامه-نویسی-شی-گرا-فاجعه-میلیارد-دلاری-قسمت-هفتمپایانی-gk3acjpclq6v Noah Noah Tue, 31 Mar 2020 22:07:35 +0430 https://virgool.io/@dndshmdr/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7-%D9%81%D8%A7%D8%AC%D8%B9%D9%87-%D9%85%DB%8C%D9%84%DB%8C%D8%A7%D8%B1%D8%AF-%D8%AF%D9%84%D8%A7%D8%B1%DB%8C-%D9%82%D8%B3%D9%85%D8%AA-%D9%BE%D9%86%D8%AC%D9%85-rxkl6n48xjqa این پست ترجمه بخشی از مقاله "Object-Oriented Programming — The Trillion Dollar Disaster" از Medium است. مقاله اصلی خیلی طولانی بود . به همین خاطر مجبور شدم ان را به چند بخش تقسیم کنم.اگر قسمت های قبل را نخوانده اید , خواندن این بخش را متوقف کنید و از قسمت اول بخوانید تا اصل ماجرا را بفهمید.قسمت اول - مقدمهقسمت دوم - OOP به جای چیز های درست به کار میرودقسمت سوم - من متاسفم که اصطلاح اشیا را ابداع کردم!قسمت چهارم - OOP ربطی به دنیای واقعی ندارد!قلمرو اشیااشیاء ,توابع و ساختار داده ها را در واحدهای غیر قابل تفکیک در کنار هم جمع میکنند. من فکر می کنم این یک خطای اساسی است زیرا توابع و ساختار داده ها کاملا به دنیا های متفاوتی تعلق دارند. --— Joe Armstrong خالق زبان ارلانگاشیاء هسته اصلی OOP هستند. یک محدودیت اساسی OOP این است که همه چیز را به اشیا سوق می دهد. و همه چیز را نباید بر پایه اشیا مدل سازی کرد. توابع نباید بر اساس اشیاء مدل شوند. چرا ما باید کلاسMultiplier (ضرب) را ایجاد کنیم وقتی همه آنچه که نیاز داریم یک تابع است که دو عدد را ضرب کند؟ به سادگی یک تابع Multiply داشته باشید ، بگذارید داده ها(data) داده و توابع توابع باشند!در زبان های غیر OOP ، انجام کارهای مهم مانند ذخیره داده ها در یک فایل ساده است .یک مثال واقعی, خواهش میکنم!برگردیم به مثال نقاش(در قسمت سه) ، نقاش صاحب یک PaintingFactory (کارخانه نقاشی!)است. او یک BrushManager اختصاصی ، ColorManager ، یک CanvasManager و یک MonaLisaProvider را ایجاد کرده است. زامبی دوست خوب او از BrainConsumingStrategy استفاده می کند. این اشیاء به نوبه خود متد های زیر را تعریف می کنند: CreatPainting ، FindBrush ، PickColor ، CallMonaLisa و ConsumeBrainz.البته ، این حماقت آشکار است ، و هرگز نمی توانست در دنیای واقعی اتفاق بیفتد. چقدر پیچیدگی غیر ضروری برای ترسیم یک نقاشی ایجاد شده است؟ وقتی توابع میتوانند مستقل از یک شی وجود داشته باشند , دیگر نیازی به ایجاد مفاهیم عجیب و غریب (کلاس ها)برای نگه داشتن متد ها نیست.تست واحد - Unit Testingتست خودکار بخش مهمی از فرآیند توسعه است و در جلوگیری از regressions فوق العاده کمک می کند (یعنی اشکالات موجود در کد موجود). تست واحد نقش مهمی در روند تست خودکار بازی می کند.برخی ممکن است مخالف باشند ، اما تست واحد کد OOP بسیار سخت است. تست واحد فرضیه آزمایش جداگانه چیز ها را اراعه میکند و برای اینکه یک متد قابل تست باشد:به یک کلاس مجزا وابسته باشد.یک واسط(interface) برای کلاس ایجاد شده ساخته شده باشد.یک فیلد برای نگهداری کلاس جدید ایجاد شده باشدبرای "تزریق وابستگی" از یک چارچوب برای تزریق وابستگی استفاده کنید.چقدر باید پیچیدگی بیشتری ایجاد شود تا یک تکه کد قابل تست کردن باشد؟ چقدر زمان صرف شده است تا برخی از کدها قابل تست باشند؟پ.ن: ، ما همچنین باید یک کلاس کامل را مقداردهی(instantiate) کنیم تا بتوانیم یک متد واحد را آزمایش کنیم.به لطف OOP ، نوشتن تست برای کد موروثی(ویکی پدیا) حتی سخت تر است - تقریبا غیرممکن است. شرکتهای زیادی پیرامون مسئله آزمایش کد موروثی ایجاد شده اند.کد اضافی - Boilerplate codeکد اضافی احتمالاً بزرگترین متخلف در رابطه با نسبت سیگنال به نویز است. کد اضافی "نویز" است که برای کامپایل برنامه لازم است. برای نوشتن کد اضافی وقت نیاز دارید و باعث می شود که کد به دلیل نویز اضافه شده ، خوانایی کمتری داشته باشد.در حالی که "program to an interface, not to an implementation" روش پیشنهادی در OOP است ، هر چیزی نباید به یک واسط تبدیل شود. ما تنها باید به منظور قابلیت تست کردن از واسط ها در همه کد استفاده کنیم. ما همچنین احتمالاً باید از تزریق وابستگی استفاده کنیم ، که باعث پیچیدگی های غیر ضروری می شود.تست کردن متد های خصوصی- privateبعضی ها می گویند که متد های خصوصی نباید تست شوند ... من تمایل ندارم که مخالف باشم ، تست واحد به یک دلیل "واحد" نامیده می شود - واحدهای کوچک کد را در انزوا آزمایش کنید. اما آزمایش متد های خصوصی در OOP تقریبا غیرممکن است. ما نباید فقط به خاطر تست پذیری ، متد های خصوصی را ایجاد کنیم.برای دستیابی به قابلیت تست متدهای خصوصی ، معمولاً آنها باید روی یک شی جداگانه انجام شوند. این به نوبه خود ، پیچیدگی و کد اضافی تولید میکند.این داستان حالا حالا ها ادامه دارد ... https://virgool.io/@dndshmdr/برنامه-نویسی-شی-گرا-فاجعه-میلیارد-دلاری-قسمت-ششم-d1eif7lgovgr Noah Noah Sun, 29 Mar 2020 09:41:36 +0430 https://virgool.io/@dndshmdr/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7-%D9%81%D8%A7%D8%AC%D8%B9%D9%87-%D9%85%DB%8C%D9%84%DB%8C%D8%A7%D8%B1%D8%AF-%D8%AF%D9%84%D8%A7%D8%B1%DB%8C-%D9%82%D8%B3%D9%85%D8%AA-%DA%86%D9%87%D8%A7%D8%B1%D9%85-sttkruwvaa2e این پست ترجمه بخشی از مقاله "Object-Oriented Programming — The Trillion Dollar Disaster" از Medium است. مقاله اصلی خیلی طولانی بود . به همین خاطر مجبور شدم ان را به چند بخش تقسیم کنم.اگر قسمت های قبل را نخوانده اید , خواندن این بخش را متوقف کنید و از قسمت اول بخوانید تا اصل ماجرا را بفهمید.قسمت اول - مقدمهقسمت دوم - OOP به جای چیز های درست به کار میرودقسمت سوم - من متاسفم که اصطلاح اشیا را ابداع کردم!اسب تروجان محصور سازی-Encapsulation اسب تروجان یا تروآ یک مجسمه چوبی تو خالی است که یونانی های باستان برای فریب دشمن از استفاده کرده اند. (ویکی پدیا)به ما گفته شده است كه Encapsulation یكی از بزرگترین مزایای OOP است. قرار بود از وضعیت داخلی شی در برابر دسترسی خارجی محافظت کند. با این وجود یک مشکل کوچک وجود دارد. کار نمی کند.محصور سازی-Encapsulation اسب تروجان OOP است. ایده انتشار وضعیت تغییر پذیر را با امن نشان دادن ان می فروشد.محصور سازی اجازه می دهد(و حتی تشویق میکند) کد ناامن در کد ما مخفیانه زندگی کند و باعث میشود کد ما از درون بپوسد.مشکل وضعیت عمومی(جهانی) - The global state problemبه ما گفته شده است كه وضعیت عمومی ریشه همه شرها است. باید به هر قیمتی از ان جلوگیری کرد. آنچه که هرگز به ما گفته نشده این است که در حقیقت, encapsulation خودش یک وضعیت عمومی است.برای کارآمدتر کردن کد ، اشیاء نه با مقدار خود بلکه با ارجاع-reference به آنها منتقل می شوند. اینجاست که "تزریق وابستگی-dependency injection" ضایع میشود.بگذارید توضیح بدهم. هر وقت یک شیء را در OOP ایجاد می کنیم ، به وابستگی آن به سازنده-constructor اشاره می کنیم. سازنده ها هم وضعیت درونی خود را دارند. این شیء تازه ایجاد شده با خوشحالی منابع خود را به ان وابستگی(constructor), وابسته میکند و خوشحال است که به هر شکلی که بخواهد میتواند وضعیت داخلی سازنده را اصلاح کند. و همچنین این ارجاع را به موارد دیگری که ممکن است از ان استفاده کند منتقل میکند.این یک نمودار پیچیده از اشیاء مشترک ایجاد می کند که در آخر وضعیت یکدیگر را تغییر میدهند. این به نوبه خود ، باعث ایجاد مشکلات عظیمی می شود زیرا نمی توان دید که چه عواملی باعث تغییر وضعیت برنامه شده است. ممکن است روزها در تلاش برای دیباگ کردن چنین تغییر وضعیت هایی تلف شود. اگر خوش شانس باشید و با همروندی-concurrency سر و کار نداشته باشید(بعدا در این مورد بیشتر حرف میزنم).متد ها و ویژگی ها-Propertiesمتد ها و ویژگی ها که امکان دسترسی به یک فیلد را به ما میدهند بهتر از تغییر مستقیم ان فیلد نیستند.فرقی نمی کند وضعیت یک شی با استفاده از یک فیلد خاص یا متد تغییر کند - نتیجه همان است: تغییر وضعیت.مشکل مدل سازی دنیای واقعیبرخی افراد می گویند OOP سعی می کند دنیای واقعی را شبیه سازی کند. این درست نیست - OOP هیچ ارتباطی با دنیای واقعی ندارد. تلاش برای مدل سازی برنامه ها با استفاده از اشیاء ، یکی از بزرگترین اشتباهات OOP است.دنیای واقعی سلسله مراتبی نیستبرنامه نویسی شی گرا تلاش می کند تا همه چیز را به عنوان سلسله مراتب اشیاء مدل سازی کند. متأسفانه ، در دنیای واقعی اشیا اینطور کار نمیکنند. اشیاء در دنیای واقعی با استفاده از پیام ها با یکدیگر در تعامل هستند اما اکثراً مستقل از یکدیگر هستند.وراثت در دنیای واقعیوراثت در OOP از دنیای واقعی الگوبرداری نمیکند. شیء پدر در دنیای واقعی قادر به تغییر رفتارشی فرزند در زمان اجرا نیست. حتی اگر شما DNA خود را از والدین خود به ارث ببرید ، آنها قادر به تغییر در DNA شما مطابق میل خود نیستند. شما "رفتارها" را از والدین به ارث نمی برید ، شما رفتارهای خودتان را توسعه می دهید. و شما قادر به "غلبه-override" بر رفتارهای والدین خود نیستید.دنیای واقعی متد نداردآیا تکه کاغذی که روی ان می نویسید متد "نوشتن" دارد؟ نه! شما یک کاغذ خالی دارید، یک قلم بر میدارید و متنی را می نویسید. شما به عنوان یک فرد متد "نوشتن" ندارید -- شما تصمیم می گیرید که متن را بر اساس رویدادهای خارجی یا افکار داخلی خود بنویسید.این داستان لعنتی همچنان ادامه دارد... https://virgool.io/@dndshmdr/برنامه-نویسی-شی-گرا-فاجعه-میلیارد-دلاری-قسمت-پنجم-rxkl6n48xjqa Noah Noah Sat, 28 Mar 2020 19:53:59 +0430 https://virgool.io/@dndshmdr/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7-%D9%81%D8%A7%D8%AC%D8%B9%D9%87-%D9%85%DB%8C%D9%84%DB%8C%D8%A7%D8%B1%D8%AF-%D8%AF%D9%84%D8%A7%D8%B1%DB%8C-%D9%82%D8%B3%D9%85%D8%AA-%D8%B3%D9%88%D9%85-zr0xcjyaatfb این پست ترجمه بخشی از مقاله "Object-Oriented Programming — The Trillion Dollar Disaster" از Medium است. مقاله اصلی خیلی طولانی بود . به همین خاطر مجبور شدم ان را به چند بخش تقسیم کنم.قسمت اول - مقدمهقسمت دوم- OOP به جای چیزهای درست به کار میرودشاید بهتر باشد قبل از شروع این بخش اطلاعاتی مختصری در مورد state و functional programmingو programming paradigm داشته باشید. منابع زیر میتواند مفید باشد و لازمه که بگم اصلا از اسم بزرگ مباحث نترسید . موضوع ساده تر از این حرف هاست.-برنامه نویسی شی گرا - Master the JavaScript Interview: What is Functional Programming? -- با اینکه این مقاله در مورد جاوا اسکریپته ولی خوندنش به شدت توصیه میشه.-الگو برنامه نویسی - What exactly is a programming paradigm?- وضعیت-State (computer science) - ویکی پدیا -- مخصوصا بخش program state*** مطمعن باشید وقت گذاشتن روی مقاله ارزشش را دارد.اگر با دقت و حوصله خوانده شود در های جدیدی به رویمان باز میشود.حداقل برای من اینطور بود.ما کلا OOP را اشتباه گرفته ایممن متاسفم که اصطلاح "اشیا" را مدت ها پیش ایجاد کردم چون باعث میشود مردم روی ایده کوچکتر تمرکز کنند. ایده بزرگ پیامرسان است. -- الن کی Alan Kay مخترع OOPمعمولا ارلانگ-Erlang به عنوان یک زبان شی گرا شناخته نمیشود. اما احتمالا Erlang تنها زبان شی گرا واقعی موجود است. بله, البته, Smalltalk نیز به عنوان یک زبان شی گرا شناخته میشود -- با این حال کاربرد گسترده ای ندارد. هم Smalltalk و هم Erlang از OOP ای که توسط مخترع آن، آلن کی در نظر گرفته شده‌بود، استفاده می‌کنند.پیام رسانیالن کی اصطلاح "برنامه نویسی شی گرا" را در سال 1960 ابداع کرد. او پیش زمینه ای در زیست شناسی داشت و تلاش میکرد برنامه های کامپیوتری را همان طور که سلول های زنده با هم ارتباط برقرار میکنند , شکل دهد.ایده بزرگ الن کی این بود که برنامه های کامپیوتری مستقل (سلول ها), با ارسال پیام به یکدیگر با هم ارتباط برقرار کنند. وضعیت برنامه های مستقل هرگز نباید به جهان بیرون منتشر شود(محصور سازی - encapsulation)همینه . OOP هیچوقت قصد نداشت چیز هایی مثل وراثت, چند ریختی, کلمه "new" و بی شمار الگو طراحی داشته باشد.برنامه نویسی شی گرا در خالص ترین حالتارلانگ OOP در خالص ترین شکل است.بر خلاف بیشتر زبان های اصلی, روی ایده اصلی OOP تمرکز میکند -- پیام رسانی. در Erlang اشیا با فرستادن پیام های تغییر ناپذیر با هم ارتباط برقرار میکنند.آیا اثباتی وجود دارد که پیام های تغییر ناپذیر بهتر از ارتباط متد هاست ؟بله, Erlang شاید مورد اعتماد ترین زبان در جهان باشد. ارلانگ به بیشتر زیرساخت های ارتباطی جهان(از جمله اینترنت) نیرو میبخشد. بعضی از سیستم های نوشته شده با ارلانگ اطمینان پذیری 99.9999999% داردند (درست میخوانید -- ۹۹ درصد).پیچیدگی کدبا زبان های برنامه نویسی تاثیر گرفته از OOP , نرم افزار های کامپیوتری طولانی تر, ناخواناتر, غیر تشریحی تر و سخت تر برای نگهداری و تغییر میشوند --- Richard Mansfieldمهمترین جنبه توسعه نرم افزار, پایین نگه داشتن پیچیدگی کد است. هیچ کدام از قابلیت های فانتزی مهم نیست اگر کد غیرقابل نگهداری نباشد. حتی پاس کردن ۱۰۰٪ تست ها هم ارزشی ندارد اگر کد پیچیده و غیر قابل نگهداری باشد.چه چیزی کد را پیچیده میکند؟ موارد زیادی را باید در نظر گرفت اما به نظر من عوامل اصلی این ها هستند:اشتراک وضعیت تغییرپذیر, انزوا نادرست و نسبت سیگنال به نویز کم (با کمی جست و جو در مورد اینها میتوانید اطلاعات بدست اورید که موضوع بحث ما نیست). همه اینها در OOP رواج دارد.مشکلات وضعیتوضعیت(یا حالت یا state) چیست؟ به بیان ساده, وضعیت هرگونه اطلاعات موقت ذخیره شده در حافظه است. مثل متغیر ها یا فیلد/properties در OOP. برنامه نویسی مطلق (از جمله OOP), محاسبات را از طریق وضعیت برنامه و تغییرات وضعیت توضیح میدهد. برنامه نویسی اعلانی(functional) به جای ان نتایج مورد نظر را توصیف میکند و تغییرات وضعیت را صراحتا مشخص نمیکندوضعیت تغییر پذیر --عمل دستکاری ذهنمن فکر میکنم برنامه های شی گرا با ساختن نمودار های بزرگ اشیا تغییر پذیر برای کاهش پیچیدگی تقلا میکنند. میدانید, سعی در درک و یادآوری در ذهن خود دارید که هنگام فراخوانی یک متد چه اتفاقی رخ میدهد و عوارض جانبی ان چیست. --Rich Hickey خالق زبان Clojureوضعیت به خودی خود کاملا بی ضرر است. با این حال وضعیت تغییر پذیر یک مشکل بزرگ است. مخصوصا اگر انتشار یافته باشد. وضعیت تغییر پذیر دقیقا چیست؟ هر وضعیتی که قابلیت تغییر داشته باشد. مثل متغیر ها و فیلد ها در OOP.یک مثال واقعی, خواهش میکنم!شما یک کاغذ سفید دارید, یادداشتی روی ان مینویسید و در نهایت همان تکه کاغذ اما با وضعیت (یادداشت) متفاوت را دارید. شما به طور موثری وضعیت کاغذ را تغییر داده اید. این امر در دنیای واقعی کاملاً خوب است زیرا احتمالاً هیچ کس دیگری به آن کاغذ اهمیت نمی دهد. مگر اینکه این تکه کاغذ نقاشی اصلی مونا لیزا باشد.محدودیت های ذهن انسانوضعیت تغییر پذیر چنین مشکل بزرگی است؟ مغز انسان قدرتمندترین ماشین در جهان شناخته شده است.با این حال ، مغز ما در کار با وضعیت واقعاً بد است زیرا ما فقط می توانیم حدود 5 مورد را در یک زمان در حافظه خود نگه داریم. بسیار راحت تر است که اگر در مورد کاری که یک قطعه کد انجام میدهد فکرکنید , نه اینکه چه متغیر هایی را در کد تغییر میدهد.برنامه نویسی به وضعیت تغییر پذیر یک عمل دستکاری ذهن است. متاسفانه این دستکاری ذهنی وضعیت تغییر پذیر در همه جای OOP وجود دارد. تنها دلیل برای وجود متد هایی برای یک شی ,تغییر دادن همان شی است.برنامه نویسی شی گرا مشکل سازماندهی کد را با پراکندگی وضعیت حتی بدتر میکند. سپس وضعیت پراکنده به طور آشکارانه بین اشیاء مختلف به اشتراک گذاشته می شود.یک مثال واقعی , خواهش میکنم!بیایید برای چند ثانیه فراموش کنیم بزرگ شده ایم, و تلاش کنیم یک کامیون لگو با حال درست کنیم.با این حال ، یک مشکل وجود دارد - تمام قطعات کامیون شما به طور تصادفی با قطعات سایر اسباب بازی های لگو مخلوط می شوند.و آنها را در 50 جعبه مختلف ، دوباره به طور تصادفی قرار داده اند. و شما اجازه ندارید قطعات کامیون را در کنار هم جمع کنید. باید قسمت های مختلف کامیون را در قسمت ذهن خود نگه دارید و فقط می توانید آنها را یکی به یکی بیرون بیاورید.بله ، در نهایت آن کامیون را مونتاژ خواهید کرد ، اما چقدر طول خواهد کشید؟ارتباط این با برنامه نویسی چیست؟در برنامه نویسی functional معمولا وضعیت ایزوله است. همیشه میدانید یک وضعیت از کجا می آید. وضعیت هرگز بین تابع های شما پراکنده نمیشود. در OOP هر شی وضعیت خود را دارد, هنگام ساخت برنامه , باید وضعیت همه اشیا ای که با انها کار میکنید را بدانید.برای اسانتر کردن زندگی بهتر است کد ,معاملات خیلی کمی با وضعیت داشته باشد. بگذارید قسمتهای اصلی برنامه شما خالص باشد.وضعیت منتشر شده اشکاراوضعیت قابل تغییر در دنیای واقعی تقریباً هرگز مشکلی به وجود نمی اورد ، زیرا همه چیز خصوصی نگه داشته می شود و هرگز مشترک نیست.این یعنی "انزوا مناسب" . نقاشی را تصور کنید که در حال کشیدن نقاشی بعدی مونا لیزا است. او به تنهایی روی نقاشی کار می کند ، به پایان میرساند و سپس شاهکار خود را به میلیون ها نفر میفروشد.حالا ، او با این همه پول حوصله اش سر میرود و تصمیم می گیرد کار متفاوتی انجام دهد. او فکر می کند برگزاری مهمانی نقاشی ایده خوبی خواهد بود. او دوستانش ، جن ، تقی ، پلیس و زامبی را دعوت می کند تا به او کمک کنند. کار گروهی! همه آنها همزمان شروع به کشیدن نقاشی روی یک بوم میکنند. البته هیچ چیز خوبی از آن بیرون نمی آید - نقاشی یک فاجعه کامل است!انتشار وضعیت تغییر ناپذیر در جهان واقعی مفهومی ندارد. این دقیقاً اتفاقی است که در برنامه های OOP رخ می دهد - وضعیت آشکارا بین اشیاء مختلف به اشتراک گذاشته می شود ، و آنها به هر شکلی که مناسب می بینند ، آن را ارتقا و تغییر می دهند. این به نوبه خود ، به دلیل رشد کد استدلال در مورد برنامه را سخت تر و سخت تر می کند.مساعل مربوط به همزمانیبا وجود انتشار وضعیت بی قاعده در OOP , موازی کردن ان کد غیر ممکن میشود. مکانیسم های پیچیده ای برای رفع این مشکل اختراع شده است. Thread locking, mutex و مکانیسم های دیگری اختراع شده است. البته ، چنین رویکردهای پیچیده اشکالات خاص خود را دارد - deadlock ها ، عدم سازگاری ، دیباگ کردن کد های چند نخی بسیار سخت و زمانگیر است. من حتی در مورد افزایش پیچیدگی ناشی از استفاده از مکانیزم های همزمانی صحبت نمی کنم.همه وضعیت ها شر نیستندهمه وضعیت ها شر هستند؟ نه وضعیت الن کی احتمالا بد نیست. تغییر وضعیت ها اگر به طور صحیح ایزوله شده باشد احتمالا خوب است.داشتن اشیاء تغییر ناپذیر برای انتقال داده خیلی هم خوب است. نکته اینجا"تغییر ناپذیر" است. از چنین اشیا ای برای انتقال داده ها بین توابع استفاده می شود.با این حال ,‌ چنین اشیایی ممکن است متد ها و ویژگی ها (properties) در OOP را کاملا زائد کند. وقتی متد ها و ویژگی های یک شی نمیتواند تغییر کند پس کاربرد انها چیست؟تغییر پذیری در OOP طبیعی(ذاتی) استبعضی ها ممکن است استدلال کنند که تغییر وضعیت در OOP یک انتخاب است نه یک اجبار. این استدلال مشکلاتی دارد. این یک انتخاب در طراحی نیست, تقریبا تنها گزینه است. بله میتوان در جاوا و C#اشیا تغییر ناپذیر را به متد ها منتقل کرد.اما این به ندرت انجام می شود زیرا بسیاری از برنامه نویسان به صورت پیش فرض در حال تغییر داده ها هستند. حتی اگر توسعه دهندگان بخواهند از تغییر ناپذیری در برنامه شی گرا شان درست استفاده کنند, زبان ها مکانیسم داخلی ای برای تغییر ناپذیری و استفاده موثر از تغییر ناپذیری فراهم نکرده اند.بله ، ما می توانیم اطمینان حاصل کنیم که اشیاء فقط با ارسال پیام های غیرقابل تغییر ارتباط برقرار می کنند و هرگز هیچ مرجعی (references)را منتقل نمی کنند (که بندرت انجام می شود). چنین برنامه هایی قابل اعتماد تر از OOP اصلی هستند. با این حال ، پس از دریافت پیام ، اشیاء هنوز هم باید حالت خود را تغییر دهند. پیام یک اثر جانبی دارد و تنها هدف آن ایجاد تغییرات است.پیام ها اگر نتوانند وضعیت اشیاء دیگر را تغییر دهند ،بی فایده هستند.این غیر ممکن است که از OOP استفاده کنیم و وضعیت تغییر نکند.این داستان ادامه دارد... https://virgool.io/@dndshmdr/برنامه-نویسی-شی-گرا-فاجعه-میلیارد-دلاری-قسمت-چهارم-sttkruwvaa2e Noah Noah Fri, 27 Mar 2020 21:06:09 +0430 https://virgool.io/@dndshmdr/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7-%D9%81%D8%A7%D8%AC%D8%B9%D9%87-%D9%85%DB%8C%D9%84%DB%8C%D8%A7%D8%B1%D8%AF-%D8%AF%D9%84%D8%A7%D8%B1%DB%8C-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-lsjsuu4mm6mb این پست ترجمه بخشی از مقاله "Object-Oriented Programming — The Trillion Dollar Disaster" از Medium است. مقاله اصلی خیلی طولانی بود . به همین خاطر مجبور شدم ان را به چند بخش تقسیم کنم.اگر قسمت اول(مقدمه) را نخوانده اید چیزی را از دست نداده اید ولی چیز های خوبی در ان روشن میشود.TLDR -- Too Long; Didn’t Readبرنامه های شی گرا به عنوان جایگزین چیز های درست به کار میرود... Edsger W. Dijkstraبرنامه نویسی شی گرا با یک هدف در ذهن خلق شد - کنترل پیچیدگی کد های رویه ای(procedural).به عبارت دیگر, قرار بود سازماندهی کد را بهتر کند. هیچ دلیل و شواهدی وجود ندارد که برنامه نویسی شی گرا بهتر از برنامه نویسی رویه ای ساده است. حقیقت تلخ این است که OOP از انجام تنها وظیفه اش (که برای ان ایجاد شده) ناکام مانده است. روی کاغذ خوب به نظر می آید -- ما سلسله مراتبی تمیز از حیوانات, سگ ها و انسان ها و ... داریم. با این حال وقتی پیچیدگی برنامه شروع به افزایش میکند شکست میخورد. به جای کاهش پیچیدگی, وضعیت ناپایدار را بی پروا تشویش میکند و با الگو های طراحی بیشمارش پیچیدگی اضافه تولید میکند. OOP کار های معمولی توسعه مانند refactoring و testing را بی دلیل سخت میکند.شاید بعضی ها با من مخالف باشند , اما حقیقت این است که OOP مدرن در java و C# احتمالا هیچوقت طراحی نشده اند. هیچوقت از یک موسسه تحقیقاتی معتبر منتشر نشده اند. جبر لامبدا(ویکی پدیا) یک پایه علمی کامل از برنامه نویسی functional اراعه میدهد. OOP هیچ تطابقی با ان ندارد.برنامه نویسی شی گرا ظاهرا در کوتاه مدت معصوم است . ولی عواقب طولانی مدت OOP چست؟ OOP یک بمب ساعتی است, منتظر انفجار میماند تا کد به اندازه کافی بزرگ شود.برنامه نویسی شی گرا برای ‌ذهن ما طبیعی نیست, فرایند فکری ما روی "انجام" کار ها متمرکز است -- صحبت کردن با دوستان , خوردن پیتزا. مغز ما برای انجام کار ها تکامل یافته , نه سازمان دادن جهان در سلسله مراتب های پیچیده از کلاس ها مجرد.برنامه نویسی شی گرا غیرقطعی است-- برخلاف برنامه نویسی functional , تضمینی وجود ندارد که به ازای ورودی ها یکسان خروجی های مشابه بگیریم. این , استدلال در مورد برنامه را خیلی سخت میکند. به عنوان یک مثال ساده : خروجی ۲+۲ یا calculator.Add(2, 2) معمولا برابر چهار است, اما گاهی اوقاط ممکن است سه , پنج یا حتی ۱۰۰۱ باشد. وابستگی های (dependencies) شی calculator ممکن است نتیجه محاسبه را به شکل محسوس اما عمیقی تغییر دهد .نیاز به چهارچوب انعطاف پذیربرنامه نویسان خوب کد خوب مینویسند و برنامه نویسان بد کد بد مینویسند, الگو برنامه نویسی اهمیتی ندارد. با این حال, الگو برنامه نویسی بد , ممکن است برنامه نویس بد را مجبور به ایجاد خسارات زیاد کند. البته, این شما نیستید, تاوقتی که این مقاله را میخوانید و تلاش میکنید که یاد بگیرید. برنامه نویسان بد هرگز برای یادگیری وقت ندارند, آنها فقط مثل دیوانه ها چند دکمه تصادفی را فشار میدهند. چه بخواهید چه نخواهید, شما با برنامه نویسان بد کار خواهید کرد, بعضی از انها خیلی خیلی بد هستند. و , متاسفانه, OOP محدودیت های لازم برای جلوگیری از برنامه نویسان بد به ایجاد خسارت های زیاد را ندارد.فکر نمیکنم برنامه نویس بدی باشم, اما بدون یک چهارچوب قوی که کارم را روی ان بنا کنم نمیتوانم کد خوب بنویسم. بله , چهارچوب هایی وجود دارد که خود را با مشکلات خیلی خاص نگران میکنند( مثل Angular or ASP.Net) .من در مورد چهارچوب های برنامه نویسی صحبت نمیکنم. من در مورد تعریف فرهنگ لغت از چهارچوب حرف میزنم:"یک ساختار حمایتی ضروری و اساسی" -- چهارچوب هایی که خود را با چیز هایی مفهومی تر مثل "سازماندهی کد" و "مقابله با پیچیدگی کد" نگران میکنند.گرچه برنامه نویسی شی گرا و functional هر دو الگوی برنامه نویسی هستند ، هر دو چارچوب بسیار سطح بالایی هم هستند.محدود کردن انتخاب هاسی ++ یک زبان [شی گرا] وحشتناک است... و محدود کردن پروژه تان به C به این معناست که مردم با "مدل -- object model" های احمقانه گیج نمیشوند . -- لینوس توروالدز , خالق لینوکسلینوس توروالدز به طور گسترده ای با انتقاد های ازادش از C++ و OOP شناخته میشود. چیزی که او ۱۰۰٪ درمورد ان درست میگفت , محدود کردن برنامه نویسان در انتخاب هایی که میتوانند بکنند است. در حقیقت هرچه انتخاب های برنامه نویس کمتر باشد , برنامه انعصاف پذیر تر میشود. در نقل و قول بالا , لینوس توروالدرز به شدت به داشتن یک چهارچوب خوب برای بنا کردن کدمان بر اساس ان پیشنهاد میکند.خیلی ها با محدودیت سرعت در جاده ها مخالف هستند, اما انها برای جلوگیری از تصادف و مرگ ضروری هستند. به همین ترتیب ، یک چارچوب خوب برنامه نویسی باید سازوکارهایی را فراهم کند که مانع از انجام کارهای احمقانه شود.یک چهارچوب خوب برنامه نویسی به ما کمک میکند کد قابل اعتماد بنویسیم. در درجه اول , باید با فراهم کردن چیز های زیر , به کم کردن پیچیدگی کمک کند.ماژولار بودن و قابلیت استفاده مجدد -- Modularity and reusabilityانزوا مناسب -- Proper state isolationنسبت سیگنال به نویز بالا -- High signal-to-noise ratio متاسفانه ,‌ OOP ابزار ها و انتخاب های زیادی را در اختیار برنامه نویس قرار میدهد, بدون اینکه نوع درست محدودیت را تحمیل کند. با اینکه OOP قول پرداختن به modularity و بهبود قابلیت استفاده مجدد (reusability) را داده , اما نتوانسته به وعده های خود عمل کند( بعدا در مورد این بیشتر صحبت میکنم). کد OOP انتشار وضعیت ناپایدار را تشویق میکند , که بار ها و بار ها ثابت شده که ناامن است. OOP معمولا مقدار زیادی کد تکراری و بیهوده نیاز دارد (boilerplate code).برنامه نویسی functional برنامه نویسی functional دقیقا چیست؟ عده ای فکر میکنند یک الگو برنامه نویسی بسیار پیچیده است که فقط در دانشگاه ها کاربرد دارد و برای "دنیای واقعی" مناسب نیست. این از حقیقت دور نیست!!بله . برنامه نویسی functional یک اساس ریاضی قوی دارد که ریشه ها ی ان به حساب لامبدا برمیگردد.(lambda calculus) . با این حال , بیشتر ایده هایش به عنوان پاسخی بر ضعف های زبان های برنامه نویسی اصلی ظهور میکند. توابع مفاهیم اصلی برنامه نویسی functional هستند. وقتی درست استفاده شوند , توابع سطحی از modularity و reusability را به وجود می اورد که هرگز در OOP مشاهده نشده. حتی دارای الگو های طراحی ای است که به مشکلات nullability میپردازد و روشی برتر برای رسیدگی به خطا ها اراعه میکند.چیزی که برنامه نویسی functional در ان واقعا خوب عمل میکند این است که به ما کمک میکند نرم افزار قابل اعتماد بنویسیم. نیاز به دیباگ کردن به طور کامل از بین میرود. بله, نیازی نیست قدم به قدم روی کد پیش بروید و متغیر ها را چک کنید! شخصا مدت زیادی است که دیباگر را لمس نکرده ام.بهترین قسمت ؟ اگر میدانید چطور از توابع استفاده کنید شما یک برنامه نویس functional هستید. فقط باید یاد بگیرید که چطور بهترین استفاده را از توابع کنید.من برنامه نویسی functional را موعظه نمیکنم, حتی اهمیت نمیدهم که از کدام الگو برنامه نویسی استفاده میکنید.من فقط تلاش میکنم مکانیسم هایی که برنامه نویسی functional برای رفع مشکلات ذاتی OOP اراعه میکند را به شما انتقال دهم. https://virgool.io/@dndshmdr/برنامه-نویسی-شی-گرا-فاجعه-میلیارد-دلاری-قسمت-سوم-zr0xcjyaatfb Noah Noah Thu, 26 Mar 2020 10:56:32 +0430 https://virgool.io/@dndshmdr/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7-%D9%81%D8%A7%D8%AC%D8%B9%D9%87-%D9%85%DB%8C%D9%84%DB%8C%D8%A7%D8%B1%D8%AF-%D8%AF%D9%84%D8%A7%D8%B1%DB%8C-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84-oat4sazhuzac این پست ترجمه بخشی از مقاله "Object-Oriented Programming — The Trillion Dollar Disaster" از Medium است. مقاله اصلی خیلی طولانی بود . به همین خاطر مجبور شدم ان را به چند بخش تقسیم کنم.برنامه نویسی شی گرا به عنوان جواهر تاج دانش کامپیوتر شناخته میشود. راه حل نهایی برای سازماندهی کد. پایان همه مشکلات ما. تنها راه درست برای نوشتن یک برنامه. توسط یک خدای برنامه نویسی به ما عطا شد.اینطور نیست. مردم شروع به تسلیم شدن زیر بار انتزاعات و گراف های پیچیده اشیا تغییر پذیر کرده اند. زمان گرانبها و قدرت مغز به جای اینکه صرف حل کردن مساعل واقعی شود , صرف ''انتزاعات - abstractions" و "الگو های طراحی - design patterns" میشود.بسیاری از مردم از جمله مهندسان نرم افزار انتقاداتی به برنامه نویسی شی گرا دارند. به جهنم, حتی مخترع OOP هم یکی از منتقدان شناخته شده OOP مدرن است.هدف نهایی هر توسعه دهنده نرم افزار باید نوشتن کد قابل اعتماد باشد. هیچ چیز دیگری اهمیت ندارد اگر کد حاوی باگ و غیر قابل اعتماد باشد. و بهترین راه برای نوشتن کد قابل اعتماد چیست؟ سادگی. سادگی متضاد پیچیدگی است. بنابراین در درجه اول مسعولیت ما به عنوان یک توسعه دهنده نرم افزار باید کاستن پیچیدگی باشد.سلب مسعولیت!من صادق هستم , من طرفدار شی گرایی نیستم. البته این مقاله قرار است از ان طرفداری کند. به هر حال دلایل خوبی برای دوست نداشتن OOP دارم.همچنین درک میکنم که انتقاد از OOP موضوع حساسی است -- شاید به خیلی از خوانندگان توهین کنم. به هر حال کاری که فکر میکنم درست است را انجام میدهم.هدف من توهین نیست , بلکه بالا بردن اگاهی در مورد اشکالاتی است که OOP معرفی میکند. من از OOP الن کی (Alan Kay) انتقاد نمیکنم -- او نابغه است. آرزو دارم OOP همانطور که او طراحی کرده بود پیاده می شد. من به رویکرد مدرن Java/C# در مورد OOP انتقاد دارم.من فکر میکنم درست نیست که OOP به عنوان یک استاندارد بالفعل سازماندهی کد از دید خیلی از مردم شناخته شود - از جمله کسانی که خیلی senior هستند. همچنین غیر قابل قبول است که خیلی از زبان های اصلی, به غیر از OOP راه دیگری برای سازماندهی کد پیشنهاد نکنند.لعنتی, من هنگام کار روی پروژه های OOP خیلی با خودم میجنگم. و حتی سرنخی ندارم که چرا باید اینقدر تلاش کنم. شاید به اندازه کافی خوب نبودم. باید چند تا الگو طراحی دیگه یاد میگرفتم(شاید). و در نهایت کاملا سوختم!این پست خلاصه ای از سفر ده ساله دست اول من از برنامه نویسی شی گرا به برنامه نویسی Functional است. متاسفانه مهم نیست چقدر تلاش کنم, دیگر نمیتوانم کاربردی برای OOP پیدا کنم. شخصا پروژه های OOP ای را دیده ام که شکست خورده اند چون برای نگهداری بیش از حد پیچیده شده بودند. قسمت دوم : https://virgool.io/@dndshmdr/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%B4%DB%8C-%DA%AF%D8%B1%D8%A7-%D9%81%D8%A7%D8%AC%D8%B9%D9%87-%D9%85%DB%8C%D9%84%DB%8C%D8%A7%D8%B1%D8%AF-%D8%AF%D9%84%D8%A7%D8%B1%DB%8C-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-lsjsuu4mm6mb Noah Noah Wed, 25 Mar 2020 13:41:58 +0430 https://virgool.io/@dndshmdr/%D8%A2%D9%85%D9%88%D8%B2%D8%B4-view-binding-%D8%AF%D8%B1-%D8%A7%D9%86%D8%AF%D8%B1%D9%88%DB%8C%D8%AF-%D8%A8%D8%A7%DB%8C-%D8%A8%D8%A7%DB%8C-findviewbyid-utlysoozmzxb با خودمون که تعارف نداریم . برنامه نویس ها ادم های تنبلی هستند. نه به این معنا که حوصله ندارن اشغال هارو ببرن دم در(که این طور هم هست) بلکه به این معنا که دوست ندارن زیاد از کد های تکراری ایستفاده کنند. این یکی از اصول برنامه نویسیه. در اندروید هر وقت میخواهیم از یک view استفاده کنیم مجبوریم اول با متدfindViewById اون رو پیدا کنیم. اما گوگل توی کنفرانس I/O اخیر ویژگی رو معرفی کرد که مارو از شر این ها راحت میکنه. اسمش هست : view binding. این رو با bata binding اشتباه نگیرید . میشه گفت view binding اومده تا استفاده از data binding رو برای استفاده های خاص اسون کنه. کاربرد اصلیش بی نیاز کردن ما از findViewById است.البته تا اونجا که من میدونم در کاتلین هم ویژگی های مشابهی وجود داره که جایگزین بهتری برایfindViewById است ولی این موضوع بحث ما نیست. برای اینکه از این ویژگی استفاده کنید باید اندروید استودیو ۳٫۶ به بالا رو نصب کنید و حتما gradle رو اپدیت کنید.اول برید توی فایل gradle.build مربوط به ماژول app و این خط هارو اضافه کنید.وقتی پروژه سینک شد باید به ازای هر لایه(layout), یک کلاس ایجاد شده باشد. اسم این کلاس از اسم لایه که به هم چسبیده شده(با قاعده camel case) و کلمه Binding در انتها اون تشکیل شده. به این کلاس binding class گفته میشه.فرض کنید یک لایه به اسم result_profile داریم:اسم binding class اون لایه میشه ResultProfileBinding که دو تا فیلد داره: یکTextView به اسم name و یک Button به اسم button . و ImageView چون آی دی نداره پس فیلدی هم ازش نیست.در این کلاس از هر view ای که آی دی داشته باشد یک ارجاع وجود داره. انگار اندروید همه view ها رو برامون پیدا کرده و ما فقط باید ازش استفاده کنیم. اما استفاده از اون هم قوانین خودشو داره.در ضمن در این کلاس یک متد استاتیک به نام getRoot هم وجود داره که root element( یا rootView) اون لایه رو برمیگردونه( تگی که بقیه تگ ها در اون قرار میگیره . در مثال بالا LinearLayout).استفاده از view binding در اکتیویتی:برای اینکه یک شی از binding class ایجاد کنیم و از اون توی اکتیویتی استفاده کنیم مراحل زیر را دنبال کنید.متد استاتیک inflate را روی binding class مورد نظر اجرا کنید تا یک شی از اون binding class در اختیارتون قرار بگیره.یک شی از root element یا rootView (که در بالا بهش اشاره شد) رو از طریق متد getRoot بگیرید.اون شی رو به متد setContentView بدید.الان میتونید از این شی در اکتیویتی استفاده کنید.استفاده از view binding در فرگمنت:برای اینکه یک شی از binding class ایجاد کنیم و از اون توی فرگمنت استفاده کنیم مراحل زیر را دنبال کنید.متد استاتیک inflate را روی binding class مورد نظر اجرا کنید تا یک شی از اون binding class در اختیارتون قرار بگیره.یک شی از root element یا rootView (که در بالا بهش اشاره شد) رو از طریق متد getRoot بگیرید.اون شی رو به عنوان مقدار برگشتی onCreateView قرار بدید.مزایا استفاده از view binding در برابر findViewById:ایمنی در برابر null بودن: با استفاده از view binding یک ارجاع به همه view ایجاد میشه و خطر اشتباه بودن آی دی و null pointer exception از بین میره.فیلد هایی که در binding class ایجاد میشه از جنس همون چیزی هستند که توی فایل xml وجود داره. مثلا یک Button در لایه, به صورت یک شی Button در binding class وجود داره. پس خطر class cast exception از بین میره.این بود مقدمات view binding . امیدوارم مفید واقع بشه. سعی کردم کامل باشه. خیلی جاها مجبور شدم از کلمات انگلیسی استفاده کنم چون نتونستم معادل مناسبی براش پیدا کنم.جدیدا توی هر پستی که میزارم یه تبلیغی از پروژه ای که تازه شروع کردم میکنم:)تصمیم گرفتیم که کتاب clean code رو خودمون ترجمه کنیم و برای استفاده عموم منتشر کنیم. فصل اول کتاب ترجمه شده و میتونید اونو توی گیت هاب ما ببینید و اگر دوست داشتید کمک کنید پست زیر برای شما مفید خواهد بود. لازم نیست کل وقت تونو بذارید . یک صفحه هم خوبه. https://virgool.io/@dndshmdr/%D8%A8%DB%8C%D8%A7%DB%8C%D9%86-%DA%A9%D8%AA%D8%A7%D8%A8-clean-code-%D8%B1%D8%A7-%D8%A8%D8%A7-%D9%87%D9%85-%D8%AA%D8%B1%D8%AC%D9%85%D9%87-%DA%A9%D9%86%DB%8C%D9%85-nzjvkcf2sckr Noah Noah Tue, 24 Mar 2020 21:13:31 +0430 https://virgool.io/@dndshmdr/%D8%B1%D8%A7%D9%87%D9%86%D9%85%D8%A7%DB%8C%DB%8C%D9%85-%DA%A9%D9%86%DB%8C%D8%AF%EF%BC%9A%D8%A7%D8%AF%D8%A7%D9%85%D9%87-%D8%AF%D8%A7%D8%AF%D9%86-%D8%A7%D9%86%D8%AF%D8%B1%D9%88%DB%8C%D8%AF-%D8%A8%D8%A7-%D8%B2%D8%A8%D8%A7%D9%86-%D9%87%D8%A7%DB%8C-%D9%86%DB%8C%D8%AA%DB%8C%D9%88-%DB%8C%D8%A7-%D8%B4%D8%B1%D9%88%D8%B9-flutter-xkt1xjja7cbs یه مدتیه افتادم تو نخ اندروید. با جاوا شروع کردم و الان هم اشنایی کلی با کاتلین دارم ولی هنوز دارم با جاوا مینویسم.تا الان هم خوب پیش رفتم ولی به نظرم کارم یکم کند داره پیش میره. الان با اکثر مفاهیم اندروید اشنایی دارم و دارم تازه data binding یاد میگیرم و پروژه های شخصی میسازم و این جور چیزا.از اون جایی که هدف نهایی من کار کردن به صورت فریلنسریه(یا تولید محتوا اموزشی . زیاد به شرکت ها علاقه ندارم ولی شاید مجبور شدم) میخام سرعت کارمو بالا ببرم. تو اینترنت یه سرچی کردم و با فلاتر اشناشدم. ظاهرا سرعت یادگیریش خیلی زیاده و امکاناتی داره که کمک میکنه سریعتر برنامه نویسی کنیم.قبلا شده که یه چیزی رو تا جا های خوب رفتم ولی ولش کردم و چسبیدم به یه چیز دیگه و در نهایت در هیچکدوم چیزی نشدم：)دنبال یه راهنمایی اساسی میگردم که تصمیم بگیرم همینطور ادامه بدم یا ولش کنم و فلاترو شروع کنم. یا شاید هم همزمان با هم.چیز هایی که دوست دارم بدونم：وضعیت شغلی فلاتر در برابر نیتیو(منظورم زبان جاوا و کاتلینه) مخصوصا بازار فریلنسریشرایط جوری پیش میره که اگر کلا برم تو کار فلاتر پشیمون نشم؟احساس کندی کردن یادگیری با جاوا و کاتلین طبیعیه یا من یه چیزیم هست؟یادگیری به صورت همزمان مشکلی تو کارم وارد میکنه؟شاید بهتر باشه بیشتر در مورد سطح اندرویدم بگم： با liveData و ViewModel و dataBinding و Room اینجور چیزای جدید اشنایی کامل دارم. و تقریبا با بیشتر view ها کار کردم. ولی هیچوقت تو یه پروژه بزرگ از همشون استفاده نکردم. و یکی از مشکلات اساسی من کار کردن با API ها یا مثلا provider هاست.اگر تجربه ای در این زمینه دارید به کمکتون نیاز دارم. Noah Noah Sat, 21 Mar 2020 16:14:07 +0430