https://virgool.io/feed/@hossein_no1 برنامه نویس اندروید٬ عاشق یادگیری و کشته مرده سبک موسیقی راک fa 2026-06-10 13:00:00 https://files.virgool.io/upload/users/205390/avatar/qxFqR0.jpeg?height=120&width=120 https://virgool.io/@hossein_no1 https://virgool.io/@hossein_no1/04-%D9%81%D8%B5%D9%84-%D8%AF%D9%88%D9%85-%D9%86%D8%A7%D9%85-%DA%AF%D8%B0%D8%A7%D8%B1%DB%8C-%DA%86%DA%A9%DB%8C%D8%AF%D9%87-%DA%A9%D8%AF%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AA%D9%85%DB%8C%D8%B2clean-code-%D8%A7%D8%AB%D8%B1%DB%8C-%D9%81%D8%A7%D8%AE%D8%B1-%D8%A7%D8%B2-%D8%B9%D9%85%D9%88-%D8%A8%D8%A7%D8%A8-gscebz04tv78 03- چرایی و تعریف کد تمیزسلام?توی رشته پست‌های قبلی راجب کدتمیز، چرایی نوشتن و اهمیت دادن به این موضوع، نظر بقیه برنامه‌نویسان درباره‌ی این موضوع و... صحبت کردیم(لینک پست قبلی بالای همین صفحه هست?) و فهمیدیم که عموباب میگه کدتمیز یعنی رعایت کردن کلی تکنیک ریز و کلی نکته که به جزئیات اشاره داره.حالا توی این فصل میخوایم اولین نکته رو بررسی کنیم.نام‌گذاریاز اونجایی که نام ها و نام‌گذاری همیشه وجود دارند و ما همیشه در کد با آنها برخورد میکنیم، پس خیلی طبیعی است که به روش و اصول نام‌گذاری درست دقت کنیم و آنها را در کد هایمان به کار ببندیم.در ادامه چند قانون ساده برای ایجاد یک نام خوب رو بررسی میکنیم و به اختصار هرکدوم رو توضیح میدیم:چند قانون ساده برای ایجاد یک نام خوب و بامعنی:از نام های آگاهانه استفاده کنیداجتناب از اطلاعات غلطایجاد تمایز بین نام ها با معنی‌دار کردناستفاده از نام های قابل تلفظاز نام های قابل جستجو استفاده کنیداجتناب از کدگذارینشانه‌گذاری مجارستانیاجزای پیشوندیاجتناب از نقشه برداری های ذهنینحوه نام‌گذاری کلاس هانحوه نام‌گذاری متد هانام ها را دقیق انتخاب کنیدیک کلمه را برای یک مفهوم انتخاب کنیدتشابه نسازیداز نام دامنه به عنوان راه حل استفاده کنیداز نام دامنه مسئله مورد نظر استفاده کنیدمحتوای معنی دار اضافه کنیدساختار بدون دلیل اضافه نکنیدنام‌ها باید بیانگر نیت ما باشند و این موضوع را باید جدی بگیریم. درسته که انتخاب نام های خوب زمان‌بر است، اما در آینده زمان بیشتری به نسبت وقتی که برای انتخاب نام‌ها صرف میکنیم برای ما ذخیره میشود. پس باید حواسمان به نام‌های انتخابی باشد و زمانی که نام‌های بهتری پیدا کردیم آنها را تغییر دهیم.نام یک متغیر، تابع و یا یک کلاس باید به تمام سوالات بزرگ پاسخ بدهد. این نام باید به ما بگویید که چرا چنین چیزی وجود دارد، چه کاری انجام میدهد و چگونه باید از آن استفاده کرد. اگر یک نام نیاز به کامنت و توضیحات داشته باشد پس این نام به خوبی قصد و هدف را نشان نمیدهد.اجتناب از اطلاعات غلطبرنامه‌نویسان باید از دادن سرنخ‌های غلطی که مفهوم کد را پنهان میکند، اجتناب کنند. باید از نوشتن کلماتی که معنای معتبر اونها، به جای معنای مورد نظر ما درک میشن اجتناب کنیم. به عنوان مثال برای ارجاع دادن به گروه حساب‌ها، از accountList استفاده نکنیم چون در برنامه نویسی کلمه list دارای معنا و مفهوم خاصی است و بجاش میتونیم از اسم‌های accountGroup, bunchOfAccounts یا accounts استفاده کنیم.باید مراقب نام‌هایی باشیم که تفاوت خیلی کمی باهم دارند تا موقع استفاده به اشتباه نیفتیم. در محیط‌های کدنویسی امروزی که بسیار مدرن هستند و هنگام تایپ قسمتی از اسم، بقیه آنرا به ما پیشنهاد میدهد، این مشکل خودش رو به وضوح نشون میده که نام‌هایی که تشابه زیادی باهم دارند و براساس حروف الفبا مرتب شده‌اند، برنامه‌نویس را موقع استفاده در شک می اندازند.ایجاد تمایز با معنی‌دار کردنبرنامه‌نویسان زمانی که کد را فقط برای راضی نگه داشتن کامپایلرها و مترجمان می‌نویسند، برای خودشان مشکل ایجاد میکنند. برای مثال چون شما نمی‌توانید از نام‌های یکسان برای نوع‌های مختلف در دامنه یکسان استفاده کنید، ممکن است که وسوسه شوید یکی از نام‌ها را به دلخواه تغییر دهید.اینکه شماره‌های سری اضافه کنیم(مثلا a1وa2) یا از کلمات نویز(مثل: the,a,an,of,...) برای متمایز کردن نام‌ها استفاده کنیم و حتی کامپایلر از شما خطا نگیرد کافی نیست. این موارد باید از نظر مفهوم نیز متفاوت باشند.استفاده از نام‌های قابل تلفظانسان‌ها در تلفظ کلمات خوب عمل میکنند. بخش مهمی از مغز ما به مفهوم کلمات اختصاص داده شده است و کلمات به وسیله‌ی تعریفشان قابل تلفظ هستند. این یک ضعف است که از بخش بزرگی از مغزمان که در زبان گفتاری پیشرفت کرده است استفاده نکنیم. پس نام‌های خود را قابل تلفظ کنید. به عنوان مثال نام متغیر genymdhms برای نگه داشتن مقدار generation date, year, month, day, hour, minute, second ، از لحاظ تلفظی مشکل دارد.از نام‌های قابل جستجو استفاده کنیدنام‌های تک حرفی و ثابت‌های عددی مشکل خاصی دارند. زیرا پیدا کردن آن‌ها در متن کاری بسیار مشکل است. پیدا کردن رشته MAX_CLASSES_PER_STUDENT در متن بسیار راحتر از پیدا کردن ۷ است!نتیجه این کار به طور همزمان، هم سبب ایجاد مشکل میشود و هم از جستجو برنامه‌نویس در برنامه جلوگیری میکند. به همین ترتیب برای برنامه‌نویسی که ممکن است نیاز به جستجو داشته باشد انتخاب نام e برای یک متغیر، یک انتخاب ضعیف و غیرحرفه‌ای است. ترجیح شخصی من این است که از نام‌های تک حرفی فقط و فقط به عنوان متغیرهای محلی درون تابع‌های کوچک استفاده شود.اجتناب از کدگزاریبه اندازه کافی روش های کدگزاری وجود دارد و نیازی نیست تعداد بیشتری را به کار خودمان اضافه کنیم. نوع کدگزاری یا محدوده اطلاعات در نام‌ها صرفا یک بار اضافی به کدگشایی اضافه میکند. منطقی به نظر نمی‌آید که برنامه‌نویس دیگری را مجبور کنیم که علاوه بر یادگیری کدهای مربوط به کار خود، عملیات کدگشایی را برای کدهای ما نیز یادبگیرد.نشانه‌گذاری مجارستاننشانه‌گذاری مجارستانی(یک نوع نشانه‌گذاری قدیمی است که نوع متغیر، در نام متغیر به صورت مختصر آورده میشود) در قدیم کاربردهای خواستی داشته است و به برنامه‌نویس در تشخیص نوع متغییر، کلاس یا ... قبل از کامپایل کد کمک میکرد. اما امروزه با وجودIDE های پیشرفته و زبان‌های سطح بالا با قابلیت وابستگی اشیایٔ به نوع، این نشانه‌گذاری اضافه‌کاری محسوب میشه و با پایین آمدن قابلیت خوانایی کد، بیشتر کار را سخت میکند.اجزای پیشوندیشما نیازی ندارید که متغیرها را با پیشوند مثلا m_ نامگذاری کنید. کلاس‌ها و توابع باید به اندازه کافی کوچک باشند که شما نیاز به انجام چنین کاری نداشته باشید. علاوه بر این برنامه‌نویسان سریع یادمیگیرند که پیشوند یا پسوند را نادیده بگیرند تا بخش معنادار نام را ببینند و در نهایت پیشوندها نامریٔی میشوند و یادآور کدهای قدیمی تر میشوند.اجتناب از نقشه برداری ذهنینام‌هایی که شما انتخاب میکنید، نباید ذهن خواننده را به سمت نام‌هایی که از قبل میشناخته است هدایت کند. مثلا در یک حلقه شمارنده معمولا ممکن است از i یا j یا k استفاده شود، اگرچه دامنه کوچک است و هیچ نام دیگری با آن تشابه ندارد. این به این علت است که نام‌های تک حرفی برای نام‌گذاری حلقه‌ها یک روش سنتی است. با این حال در اکثر زمینه‌های دیگر نام‌های تک حرفی، انتخاب ضعیفی بشمار می‌آیند.یک تفاوت بین برنامه‌نویس هوشمند و برنامه‌نویس حرفه‌ای این است که برنامه‌نویس حرفه‌ای میداند که وضوح (Clarity) همه‌ چیز است. حرفه‌ای ها از قدرت خود بهره میگیرند و کدی ارایٔه میدهند که دیگران قادر به درک آن باشند.نام کلاس‌هاکلاس‌ها و اشیا باید نام یا نام‌های اسمی، مانند Customer یا Account داشته باشند. نام یک کلاس نباید فعل باشد.نام متدهانام متدها باید فعل یا یک اصطلاح فعلی باشد مانند postPayment یا deletePage باشد.نام‌ها را دقیق انتخاب کنیدنام‌هایی را انتخاب کنید که به وضوح درگیری ذهنی بیشتری ایجاد می‌کنند. سادگی در کد اغلب به شکل گفتارها یا به صورت عامیانه ظاهر می‌شود. به عنوان مثال از whack به معنای kill برای متد استفاده نکنید. چیزی که دقیقا مدنظرتان است را بگویید.یک کلمه را برای یک مفهوم استفاده کنیداز یک کلمه برای یک مفهوم انتزاعی استفاده کنید و با آن تا آخر کنار بیایید. به عنوان مثال این گیج کننده است که fetch،retrieve و get را به عنوان روش‌های معادل در کلاس‌های مختلف در نظر بگیریم.تشابه نسازیداز یک کلمه یکسان برای استفاده در دو هدف مختلف اجتناب کنید. استفاده از یک اصطلاح یکسان برای دو ایده متفاوت اساسا باعث تشابه می‌شود. اگر از قانون‌ «هرکلمه به ازای هر مفهوم» استفاده کنید، می‌توانید کلاس‌های موجود را به پایان برسانید.از نام دامنه به عنوان راه‌حل استفاده کنیدبه یاد داشته باشید کسانی که کد شما را می‌خوانند برنامه‌نویس خواهد بود. بنابراین پیش بروید و از قوانین علوم کامپیوتر، نام الگوریتم‌ها، قوانین ریاضی و ... استفاده کنید.از نام دامنه مسئله مورد نظر استفاده کنیدزمانی که دیگر از نام دامنه به دلیل تکراری شدن نمیتوان در نام‌گذاری‌ها استفاده کرد، باید از نام دامنه مسئله مورد نظر استفاده کنید. حداقل برنامه‌نویسی که کد شما را نگه‌داری میکند، میتواند معانی را از متخصص دامنه بپرسد.محتوای معنی‌دار اضافه کنیدنام‌های کمی وجود دارند که معنی‌دار هستند، در عوض شما باید نام‌هایی را در متن برای خواننده خود قرار دهید که این کار از طریق نام‌گذاری کلاس‌ها توابع یا فضاهای نام انجام می‌شود. وقتی هیچ راه دیگری ندارید، پیشوند نام ممکن است به عنوان آخرین راه‌حل لازم باشد. البته راه‌حل بهتر این است که کلاسی برای مفهوم موردنظر ایجاد کنید تا حتی کامپایلر هم متوجه شود که این مفاهیم متعلق به یک مفهوم بزرگتر می‌باشد.ساختار بدون دلیل اضافه نکنیدقسمت‌های اضافی به نام اضافه نکنید مخصوصا پیشوندهایی بلا استفاده! در یک برنامه فرضی با نام «Gas station deluxe» یک ایده بد این است که هر کلاس را با GSD پیشوند کنید. صادقانه به شما بگوییم که شما در حال کار در برابر ابزار خود هستید. شما G را تایپ میکنید و با لیست پیشنهادی طولانی از IDE خود روبرو میشوید. آیا این عاقلانه است؟نام‌های کوتاه‌تر به طور کلی بهتر از بقیه هستند. تا زمانی که نام‌ها واضح‌اند، هیچ نامی به نام‌هایتان اضافه نکنید.خلاصهسخترین چیز در مورد انتخاب نام‌های خوب، این است که نیاز به یک مهارت توصیفی خوب و یک پس‌زمینه فرهنگی مشترک دارد. این یک مسئله تدریسی است نه یک مسئله فنی، مدیریتی، یاتجارتی. به عنوان یک نتیجه بسیاری از مردم یادنگرفته‌اند که اینکار را خوب انجام دهند. این فصل به این موضوع تأکید دارد و نکته‌ها و تکنیک‌هایی را بیان میکند که با رعایت آن‌ها میتوان گفت این قسمت از تمیز نویسی کد را با موفقیت پشت سر گذاشته‌اید.تا قسمت بعدی خدانگه‌دار حسین پناهنده حسین پناهنده Fri, 14 Jan 2022 23:34:25 +0330 https://virgool.io/@hossein_no1/03-%D9%81%D8%B5%D9%84-%D8%A7%D9%88%D9%84-%DA%86%D8%B1%D8%A7%DB%8C%DB%8C-%D9%88-%D8%AA%D8%B9%D8%B1%DB%8C%D9%81-%DA%A9%D8%AF-%D8%AA%D9%85%DB%8C%D8%B2-%DA%86%DA%A9%DB%8C%D8%AF%D9%87-%DA%A9%D8%AF%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AA%D9%85%DB%8C%D8%B2clean-code-%D8%A7%D8%AB%D8%B1%DB%8C-%D9%81%D8%A7%D8%AE%D8%B1-%D8%A7%D8%B2-%D8%B9%D9%85%D9%88-%D8%A8%D8%A7%D8%A8-rqvytkoxrpfj ۰۱- پیشگفتار۰۲- مقدمه‌ی کتاب کدنویسی تمیزسلام✋توی قسمت قبلی راجع‌ به اینکه چرا اصلا باید به تمیز بودن کدمون اهمیت بدیم اشاره کردیم و دلیل‌های اونو بررسی کردیم، و علاوه بر اون خود کتاب رو معرفی کردیم و توضیح دادیم که این کتاب چه قسمت‌هایی داره و اصلا چجوری باید کتاب رو بخونیم!(لینک قسمت‌های قبلی بالای همین پست هست)حالا می‌‌خوایم به عنوان اولین قسمت اصلی یا اولین فصل خوده کتاب به این موضوع بپردازیم که چرا باید کدتمیز بنویسیم و بابت‌اش مجبور باشیم این کتاب رو مطالعه کنیم و اینکه کد تمیز یعنی چی و بزرگان برنامه‌نویسی به چی کدی میگن "کد تمیز".چرا باید کد تمیز بنویسیم و بابت‌اش این کتاب رو بخونیم؟به طور خیلی خلاصه ما به دو دلیل قراره خودمون رو قانع کنیم که کد تمیز بنویسیم:اول اینکه ما برنامه‌نویسیمدوم اینکه تمایل داریم برنامه‌نویس بهتری بشیم(دنیا به برنامه‌نویس‌های بهتری نیاز داره)هدف اصلی این کتاب اینه که ما به برنامه‌نویس‌های بهتری تبدیل بشیم، علاوه بر اون توی طول کتاب ما به کد ها از زاویه‌های بیرونی و با دیدگاه بالاتری نگاه میکنیم که همین امر باعث میشه تفاوت بین کد خوب و بد رو متوجه بشیم و قادر باشیم کد بد رو به کد خوب تبدیل کنیم.کد وجود خواهد داشت!شاید جالب باشه که بدونین بعضی‌ها هستند که فکر میکنن کد نوشتن روند رو به منسوخ شدن داره و اکثر برنامه نویسان شغل خودشون رو از دست میدن و کلا کد بجای نوشته شدن باید براساس نیاز هامون تولید بشه، پس خوندن این نوع کتاب‌ها معنی نداره!حرف پوچ و بی اساسیه چون،‌ کد جزئیات نیازمندی هارو بیان میکنه. بعضی از مواقع این جزئیات قابل حذف و خلاصه شدن نیست بلکه دقیقا باید مشخص بشن، و برنامه‌نویسی یعنی توصیف کردن نیازمندی ها با جزئیاتی که یک ماشین بتواند آنهارا اجرا کند. چیزی که قابل پیشبینی است اینه که سطح انتزاع زبان‌ها رو به افزایشه و تعداد زبان‌های مربوط به یک دامنه رو به رشده، اما کد هیچوقت حذف نمیشه به دلیل اینکه حتی با وجود سطح بالا بودن زبان‌ها در آینده باز هم تنها راه توصیف نیازمندی ها از طریق کد صورت میگیره.به یاد داشته باشید که کد در واقع زبانی است که ما درنهایت نیازمندی‌ها را با استفاده از آن بیان میکنیم. ممکن است زبان‌هایی تولید بشن که به زبان توصیف نیازمندی‌ها نزدیک‌تر اند یا ابزارهایی ایجاد بشن که توی تجزیه کردن و سرهم کردن نیازمندی‌ها به ساختارها رسمی به ما کمک میکنن. ولی هیچوقت دقت لازم حذف نمیشه. پس در نتیجه کد همیشه وجود داره.کد بدخوب حالا که به این نتیجه رسیدیم که هیچ‌وقت قرار نیست از دست کد خلاص بشیم، میریم مرحله بعد، یعنی درک کد خوب و عواقب استفاده از کد بد.مثال‌های زیادی وجود داره از عواقب استفاده از کد بد، مثلا در دهه‌ی ۸۰ یک شرکت نرم‌افزاری برنامه‌ای درست کرد که در آغاز راه با استقبال زیادی روبه‌رو شد، اما بعد از مدتی چرخه‌های انتشار‌اش شروع به طولانی‌تر شدن کرد و باگ‌ها از یک نسخه به نسخه بعدی اصلاح نشده باقی میموندن. بعد از مدتی محصول با شکست روبه‌رو شد و شرکت تولید کننده از چرخه‌ی بازار خارج شد که علت اون کد های بد بود.همه‌ی ما با هر سطح از دانش در برنامه‌نویسی، بارها با کد بد مواجه شده‌ایم. سوال اینجاست که، اگر یک کد بد جلوی انجام کار مقاومت میکنه، پس چرا اونو بنویسیم؟جواب : باورهای اشتباه ما از کد بد.هزینه‌ی کلی داشتن کد بهم‌ریختهکد بد باعث ایجاد به‌‌هم ریختگی و اتلاف وقت در طولانی مدت میشه. کد بد باعث میشه روند روبه رشد تبدیل به روند حلزونی بشه.یعنی با جلو رفتن و بیشتر شدن ابعاد پروژه، به هم ریختگی‌ها و وابستگی‌ها هم بیشتر میشه و در کل باعث میشه که سرعت بهبود پروژه رو به کاهش باشه.همزمان با ایجاد به‌هم‌ ریختگی‌ها، بهره‌وری تیم رو به کاهش میره. با کاهش بهره‌وری، مدیریت تصمیم میگیره که افراد جدید به تیم فنی اضافه کنه به امید افزایش بهره‌وری. ولی افراد جدید هماهنگ به طراحی سیستم نیستند. اونا فرق بین تغییری که مطابق با اهداف تعیین شده با تغییراتی که برخلاف اهداف تعیین شده رو نمیدونن. در نتیجه تحت فشار کاهش بهره‌وری، اونها هم شروع به تولید به‌هم ریختگی میکنن.طراحی دوبارهبالاخره کاسه صبر تیم توسعه لبریز میشه و به مدیریت اعلام میکنن که باید طراحی دوباره(Refactor) اتفاق بیفته!مدیریت از یک طرف علاقه‌ای به خرج منابع دوباره برای طراحی نداره و از طرف دیگه هم میزان بهره‌وری فعلی‌اش هم سود جذابی بهش نمیده. در نتیجه انتخاب دیگه‌ای نداره و مجبور به اجرای، طراحی دوباره میشه.طراحی دوباره که توسط تیم توسعه حرفه‌ای انجام میشه زمان بر و پر هزینه‌ی و بعضی وقت‌ها تا ۱۰ سال هم طول میکشه!!نتیجه‌ای که از این داستان میشه گرفت اینه که: صرف زمان برای تمیز نگه داشتن کد نه تنها مقرون به صرفه‌اس، بلکه یک مسئله مهم برای بقایٔ حرفه‌ایه.روش برخورد حرفه‌ایاولین نکته برای برخورد حرفه‌ای، مسئولیت پذیری و چرخاندن انگشت اتهام به سمت خودمان است!شاید ما از مشتریان،مدیران،بازاریاب‌ها و دیگر اعضای تیم راجع به مسائلی مثل زمان‌بندی، تغییر نیازها حین طراحی و ... برای ایجاد کد بد بهانه داشته باشیم، ولی این مهمه که ما خودمون رو برای اون مقصر بدونیم نه کس دیگه‌ای رو.بازاریاب‌ها برای اطلاعات مورد نظرشون برای تعهد دادن، به ما نگاه میکنن.کاربران برای اعتبارسنجی محصول مطابق با نیازهاشون، به ما نگاه میکنن.همچنین مدیران برای زمان بندی‌هاشون.پس ما توی برنامه‌ریزی پروژه عمیقا شریک جرم هستیم و در مسئولیت هر شکستی سهیم هستیم، بخصوص اگه شکست‌ها ناشی از کد بد باشه.پزشک جراحی رو درنظر بگیرین که قبل از عمل باید دست‌هاشو بشوره. طبیعیه که بیمار برای جلوگیری از اتلاف وقت بهش بگه که این کار احمقانه رو کنار بزاره و سریع‌تر بیاد برای جراحی. مطمئنا دکتر باید با اینکار مخالفت کنه چون بهتر از هرکس دیگه‌ای از عفونت و بیماری آگاهه. موافق دکتر با بیمار نه تنها غیرحرفه‌ایه بلکه جنایتکارانه هم هست. پس برای برنامه‌نویسان هم کوتاه آمدن دربرابر خواسته‌ی مدیران که خطر بهم‌ریختگی را نمیدانند، غیر حرفه‌ای است.هنر کد تمیزحالا که به این باور رسیدیم که بهم‌ریختگی یک مانع مهم است،حالا که میدونیم تنها راه سریع بودن، تمیز نگه داشتن کده، پس حالا به اینجا رسیدیم که بفهمیم چجوری باید کد تمیز بنویسیم.اگه ندونیم معنی کد تمیز چیه، تلاش برای نوشتن کد تمیز نتیجه خوبی نداره.کد مثله نقاشی میمونه، یعنی اینکه ما اگه قادر باشیم کد خوب یا نقاشی خوب رو از کد بد یا نقاشی بد تشخیص بدیم، به این معنی نیست که ما میتونیم کد خوب رو تولید کنیم.نوشتن کد تمیز نیازمند رعایت هزاران تکنیک کوچیکه که از طریق اعمال فهم تمیز بودن دقیق به دست میاد.این "حس کردن کد" کلیدیه. بعضی ها از بچگی دارن‌اش، بعضی ها باید کسب‌اش کنن. این حس نه تنها به ما اجازه میده که فرق بین کد خوب رو با بد بفهمیم، بلکه بهمون استراتژی تبدیل کد بد به خوب رو هم نشون میده.یک برنامه‌نویس بدون حس کردن کد میتونه به یک ماژول بهم‌ریخته نگاه کنه و تشخیص بده که کد ها بد طراحی شدن ولی هیچ ایده‌ای برای تبدیل‌اش به کد خوب نداره. یک برنامه‌نویس دیگه هم که کد رو میفهمه میتونه به یک ماژول نگاه کنه و انتخاب ها و تغییرات به ذهن‌اش برسه.خلاصه اینکه برنامه‌نویسی که کد تمیز رو مینویسه یک هنرمنده که میتونه با استفاده از یک سری از تبدیلات یک صفحه خالی رو به یک سیستم کدنویسی شده زیبا تبدیل کنه.کد تمیز چیست؟شاید به اندازه برنامه نویسان برای این مفهوم تعریف وجود داشته باشه، پس میریم که نظر چندتا از برنامه نویسان بزرگ و باتجربه رو بخونیم:Bjarne stroustrup خالق C++-من دوست دارم کدهایم زیبا و کارا باشند. منطق باید سرراست باشد و وابستگی ها در حداقل ممکن باشد تا نگهداری از کد آسان شود. رسیدگی به خطاها باید براساس یک استراتژی گام به گام تکمیل شود، کارایی باید به سمت بهینگی باشد تا افراد برای بهینه‌سازی غیراصولی، به بهم ریخته کردن کد وسوسه نشوند. کد تمیز یک کار را خوب انجام میدهد.Grady booch نویسنده کتاب تحلیل و طراحی شیٔ گرایی-کد تمیز ساده و مستقیم است. کد تمیز مثل یک نثر خوب نوشته شده است. کد تمیز هیچوقت نیاز یک طراح را مبهم نمیکند و در عوض سرشار از انتزاع پر شور و روند کنترلی واضح و مستقیم است.Dave thomas موسس OTI-کد تمیز قابلیت خوانده شدن و بهبود داده شدن توسط توسعه دهنده‌ی دیگری غیر از توسعه دهنده اصلی کد را دارد. به این منظور تست‌های پذیرش و تست‌های واحد وجود دارد. نام‌های بامعنایی دارد. یک راه به جای چند راه برای انجام یک کار فراهم میکند. حداقل وابستگی را شامل میشود، واضح‌ترین و کمترین API را فراهم میکند و دارای کامنت مفید است.میشل فیدرز نویسنده کتاب Legacy code-کد تمیز همیشه مانند این است که توسط فردی نوشته شده است که به آن اهمیت میدهد. در نتیجه شما نمی‌توانید کار مشخصی برای بهتر شدن کد انجام دهید.Ron jeffries نویسنده کتاب سی شارپ پیشرفته-کدی تمیز است که این قوانین را به ترتیب رعایت کند:-تمام تست‌ها اجرا شده باشد-شامل تکرار نباشد-تمام ایده‌های طراحی موجود در سیستم را بیان کند-تعداد موجودیت‌ها مثل کلاس‌ها، متد‌ها،توابع و غیره در آن به حداقل رسیده‌اندWard cunningham مخترع wiki,fit,..-وقتی هر روتینی که میخوانید به اندازه‌ای که انتظار دارید به نظر خوب می‌آید، شما میدانید که درحال کار کردن بر روی یک کد تمیز هستید. وقتی کد، شبیه زبانی هست که برای حل مسأله ساخته شده است، می‌توانید آنرا کد زیبا بنامید.Robert C.martin نویسنده کتاب کدتمیز-عمو باب به عنوان نویسنده‌ی این کتاب، باور و اعتقاد خودشو از "کد تمیز" با ریز جزئیات(نحوه نام‌گذاری متغییر ها، توابع تمیز، کلاس‌تمیز و غیره) خواهد گفت و بابت اعتقادش هم عذرخواهی نخواهد کرد! چون به نظرش توی این نقطه از راهش، این اعتقاد قطعی و مسلم‌اش هست. درست مثل تکنیک‌های مبارزه که هیچ رزمی‌کاری در مورد بهترین روش مبارزه یا تکنیک مبارزه‌ای توافق نداره. معمولا اساتید مکتب فکری خودشون رو دارن و برای خودشون شاگرد جمع میکنن و اصولا فعالیت در یک سبک مبارزه به معنی نقض سبک‌های دیگه نیست.عمو باب ادعای بهترین بودن را ندارد ولی در عوض ادعای اینو داره که اگه ما از این روش‌ها پیروی کنیم، از فوایدی بهره‌مند میشیم که اون شده.نتیجه‌گیریکتاب‌های هنری قول نمی‌دهند که از شما یک هنرمند بسازن، در عوض هدف اونها ارئه‌ی ابزار‌ها، فرآیندها و روش‌های‌ فکری است که سایر هنرمندان استفاده میکنند. بنابراین این کتاب هم قول نمیده که از ما برنامه‌نویس خوب بسازه. نمیتونه به ما قول بده که کد خوب رو حس و درک‌اش کنیم در عوض نشان دهنده‌ی فرآیند فکری برنامه‌نویسان خوب و فوت‌و‌فن‌ها و روش‌‌ها و ابزارهایی که اونها استفاده میکنن.درست مثل یک کتاب در مورد هنر، این کتاب سرشار از جزئیات است، و ما روش تبدیل شدن کد بد به خوب رو میبینیم و بعد از اون نوبت خود ماست تا این روش‌هارو پیاده سازی کنیم?و تمام...تا قسمت بعدی خدانگهدار✋04-فصل دوم: نام‌گذاری حسین پناهنده حسین پناهنده Sat, 25 Dec 2021 16:13:25 +0330 https://virgool.io/@hossein_no1/02-%D9%85%D9%82%D8%AF%D9%85%D9%87-%DA%A9%D8%AA%D8%A7%D8%A8-%DA%86%DA%A9%DB%8C%D8%AF%D9%87-%DA%A9%D8%AF%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AA%D9%85%DB%8C%D8%B2clean-code-%D8%A7%D8%AB%D8%B1%DB%8C-%D9%81%D8%A7%D8%AE%D8%B1-%D8%A7%D8%B2-%D8%B9%D9%85%D9%88-%D8%A8%D8%A7%D8%A8-s7ebc57znihj . لینک پست قبلی(پیشگفتار)سلام?توی قسمت قبلی، من یک بیوگرافی کوچیک از خودم دادم و شروع کردم به توضیح هدفم از تولید این محتوا و اینکه مبدا شکل گیری هدفم از کجا بود و ...ولی از این قسمت به بعد سعی میکنم مطالب رو بیشتر متمرکز کنم روی محتوای کتاب و کمتر راجع به مسائل حاشیه‌ای صحبت کنم.قبل از شروع، می‌خوام یک تشکر از سایت www.zerobook.ir بابت انتشار کتاب به صورت ترجمه شده بکنم و اینکه بقیه کتاب های عمو باب(کدنویس تمیز و معماری تمیز) هم موجود داره و قابل خریداری است.ترجیح میدم خلاصه مقدمه کتاب رو با یک سوال شروع کنم:چرا باید به تمیزی کد اهمیت بدیم؟کل ماجرا به اونجایی برمیگرده که به این درک و فهم برسیم که، چیز های کوچک، کم اهمیت نیستند!همون‌جور که معمار معروف "لودویگ میس فن در روهه" میگه : خداوند در جزيیات نهفته است.فرض کنید دو نوع معمار ساختمان وجود داره: نوع اول شخصی آماتوره که هدف‌اش از ساختن یک آپارتمان فقط به اتمام رسوندن ماجرا و تموم کردن پروژه‌ است، و توجه‌ای به ظرافت ساخته‌ی خودش نداره و از کنار جزيیات به سادگی رد میشه، ولی شخص دوم که توی کار خودش حرفه‌ایه و آگاه به این موضوعه که کیفیت کل پروژه تحت‌الشعاع کیفیت تک‌تک اجزای کوچیکه اونه، از کنار انتخاب دستگیره‌های در اون آپارتمان هم به سادگی نمی‌گذره و ترجیح میده یا یک کاری با ظرافت تمام انجام بشه یا اصلا انجام نشه!پر واضحه که توی مثال بالا شخص دوم رو میشه هنرمند صدا زد و ارزش خروجی کار خیلی بالاتری نسب به شخص اول داره. از این مثال میشه این برداشت رو کرد که: موارد کوچیک مهم هستند.پس یکی از موارد حرفه‌ای بودن، توجه به نکات ریز و کوچیکه.البته توجه به جزيیات، بیشتر به عنوان اساس و پایه حرفه‌ای بودن شناخته میشه نه داشتن دیدگاه‌های عالی(کمال گرایی)، حالا چرا؟ به دو دلیل:اولا، تمرین‌های کوچیک باعث میشه که متخصصان مهارت و اطمینان لازم رو برای انجام کارهای بزرگ به دست بیارن.دوما، کوچیک‌ترین بینظمی در ساختمان مثله کاشی‌ای که یکمی کجه یا یک میز کثیف و نامرتب، کاملا جذابیت یک مکان بزرگ و مجلل رو از بین میبره. این همون مفهومی که کد تمیز بیان میکنه.در حالی که، معماری فقط یک استعاره برای توسعه نرم‌افزاره و مخصوصا برای بخشی از نرم‌افزار که محصولی اولیه رو ارایٔه میکنه، مثله اینه که یک معمار یک ساختمان تازه رو تحویل میده.در همین راستا یک "رویکرد کیفیت" در ژاپن توی سالهای ۱۹۵۱ با عنوان TMP روی صحنه اومد که تمرکز‌اش بیشتر روی نگهداری محصول بود نه تولید. خیلی جالبه که یکی از ستون‌های اصلی این رویکرد، یک مجموعه اصوله که به اصطلاح بهش 5S میگن و جلوتر بهش میرسیم.این اصول شامل ۵ مورده به شرح زیر:۱- Seiri: سازمان‌دهی کردن(یا همون مرتب کردن)۲-Seiton: مرتب بودن(یا همون سیستماتیک)۳-Seiso: تمیز کردن۴-Seiketsu: استاندارد عمل کردن۵-Shutsuke: منظبط بودنحالا شاید بگی اینایی که گفتی یعنی چی و چه ربطی به موضوع ما داره؟! آفرین، سوال خوبیه الان میگم.این دیدگاه‌های انتزاعی نسبت به تولید محصول(حالا هر محصولی، می خواد ماشین باشه، آپارتمان باشه یا اصلا یک قطعه موسیقی) خیلی واضح داره میگه روی جزییات محصول تمرکز کن.یعنی چی؟ یعنی کد باید از هر ۵ فیلتر بالا بگذره تا بشه بهش بگیم "کد تمیز".توی همون مثال معماری که زدیم، توجه کردن به انتخاب دستگیره در، داره مورد ۱ رو بیان میکنه دقیقا همون قدر که ما باید به انتخاب اسم متغییر هامون دقت کنیم. ما باید به انتخاب اسم متغییر هامون به اندازه اسم کودک تازه متولد شده‌مون اهمیت بدیم!مورد دیگه‌ای که توی مقدمه آورده شده اینه که، این کتاب مارو وادار میکنه تا چالش‌های خوندن دستورالعمل‌های خوبی رو ادامه بدیم که قبلا با بی‌تفاوتی از کنارشون رد میشدیم.متاسفانه، ما معمولا این نگرانی هارو به عنوان پایه‌های اصلی هنر برنامه‌نویسی نمیبینیم.ما یک زمان‌هایی دیگه کدنویسی نمیکنیم نه بخاطر اینکه دیگه کاری برای انجام نداریم، بخاطر اینکه تمرکز سیستم بیشتر روی ظاهر بیرونیه تا اون‌چیزی که ما ارایٔه میدیم.یکی دیگه از اهداف این کتاب اینه که این فرهنگ رو به وجود بیاره که، معماری یا برنامه‌نویسی یا مفاهیم سطح بالا دلیل کیفیت باشن نه تسلط روی ابزارها و روش‌های طراحی عالی و ...درحالی که بازنویسی(refactor) در تولید باعث ایجاد هزینه میشه، بازنگری(review) در طراحی منجر به ارزشه. این همون تفاوت بین مفاهیم سطح بالا با بقیه مفاهیمه که اشتباها معیار تایین کیفیت برای کد تمیزه.تمام این حرف‌ها گفته شد تا به این نتیجه برسیم که، جمله‌ی "راستگویی در مورد موارد کوچک، کم اهمیت نیست" نه تنها مارو به توجه به موارد کوچیک توصیه میکنه، بلکه به صادق بودن درمورد چیزهای کوچیک نیز دعوت میکنه. معنی این جمله توی کار ما اینه که: ما باید با کدمون صادق باشیم، با همکارامون در مورد وضعیت کدمون صادق باشیم، از همه مهم‌تر با خودمون درباره کدی که نوشتیم صادق باشیم.شاید این ذهنیت اشتباه برامون به وجود بیاد که این موارد نگرانی‌های بیش از اندازه‌اس، ولی باید در نظر داشته باشیم که هیچ معماری و کدنویسی تمیزی بر کمال‌گرایی اصرار نداره، فقط به صداقت و انجام بهترین کاری که می‌تونیم انجام بدیم تاکید داره.معرفی کتابدوتا اتاق رو در نظر بگیرید که توی هر دوی اونا داره فرآیند کد ریویو انجام میشه; یک واحد اندازه گیری کیفیت کد وجود داره به اسم WTF/minute، یعنی تعداد وات د فاک گفتن در یک دقیقه زمانیکه داریم کد رو بازبینی میکنیم((((((:حالا یک اتاق تعداد وا د فاک‌هاش زیاده یکی کم.آیا با دلهره، مشغول اشکال زدایی کدهامون هستیم؟آیا به کدهایی خیره شدیم که فکر میکردیم کار میکنه؟آیا مشتری ها شما رو تحت فشار گذاشتن؟آیا مدیر ها همیشه مزاحم شما میشن؟چطور وقتی دچار مشکل میشیم، مطمیٔن بشیم که توی کدوم اتاق هستیم؟ جواب: استاد شدن.دو بخش برای یادگیری استاد شدن وجود داره: دانش و به کارگیری اون.ما باید دانش اصول، الگوها، شیوه‌ها و ... یک استاد کار رو به دست بیاریم و بعد از طریق سخت کار کردن و تمرین کردن اون دانش رو توی خودمون به وجود بیاریم.یک مثال برای درک این مسیٔله: ما میتونیم اصول فیزیکی دوچرخه سواری رو یاد بگیریم و با توجه به این فرمول‌ها به این نتیجه برسیم که دوچرخه‌سواری امکان پذیره و تمام دانش مربوط بهش رو هم کسب کنیم. ولی با این حساب باز هم برای اولین بار که می‌خوایم سوار بشیم، باز هم از روی اون میوفتیم زمین(: کدنویسی از این قاعده مستثنی نیست.هدف این کتاب هم دقیقا همینه، درسته که به ما اصول درست کدنویسی رو یاد میده ولی این تازه نصف راهه، نصف دیگه‌اش مربوط میشه به تمرین‌های سخت و به اصطلاح همون زمین خوردن از روی دوچرخه و دوباره تلاش کردن.نکته‌ای که به صورت واضح ذکر شده اینه که: این کتاب از اون دسته کتاب‌های"حس بهتر" نیست که شما میتونین توی یک سفر هوایی قبل از رسیدن به زمین بخونین، این کتاب شمارو مجبور میکنه که سخت تمرین کنین.این کتاب به سه قسمت تقسیم شده:. چند فصل اول کتاب که اصول،‌ الگو ها و شیوه‌ی نوشتن کد تمیز رو توصیف میکنه. این قسمت مارو برای قسمت دوم آماده میکنه..این قسمت نسبت به قسمت قبلی سختره، چون شامل بررسی وضعیت‌هایی خواهد بود که پیچیدگی اونها همیشه درحال افزایشه..سومین قسمت این کتاب، شامل نتیجه نهایی کار میشه.اگر که قسمت های یک و سه رو خوندین و از قسمت دو چشم‌پوشی کردین یا حتی به صورت روزنامه‌وار فقط مطالعه کردین، بهتره که خودتون و بقیه رو گول نزنین و این واقعیت رو قبول کنین که شما فقط یک کتاب"حس خوب"(استعاره از کتاب هایی که مطالعه‌شون جنبه تفریحی دار) رو درباره‌ی نحوه‌ی نوشتن نرم‌افزار خوب خوندین.نتیجه‌گیری نهایی: تنها زمانی این کتاب روی ما اثر میزاره که، وقت خودمون رو صرف کار کردن روی مطالعات موردیش کنیم و به دنبال هرگام کوچیک و تصمیم گیری در هر دقیقه‌اش خودمون رو به جای نویسنده قرار بدیم و سعی کنیم که خودمون رو مجبور کنیم به فکر کردن توی همون مسیرهایی که نویسنده فکر کرده، اونجایه که ما به فهم عمیق‌تری از اصول، الگوها، شیوه‌ها و اکتشافات میرسیم.وقتی که ما به دوچرخه‌سواری مسلط شویم، دوچرخه‌سواری جزيی از ما خواهد شد.خوب این قسمت از کتاب که بخش مقدمه و معرفی کتاب بود هم تموم شد.از قسمت بعدی وارد بخش اصلی کتاب میشیم که تازه شروع ماجراست((:منتظر قسمت بعدی باش، راستی لینک قسمت قبل رو هم بالای همین پست گزاشتم، اگه این پست رو به عنوان اولین پست از سری خلاصه نویسی‌های کتاب کدنویسی تمیز می‌خونی بهتره که از اولین پست شروع کنی.خدا نگهدار.✋03-فصل اول: چرایی و تعریف کد تمیز حسین پناهنده حسین پناهنده Thu, 16 Dec 2021 22:56:35 +0330 https://virgool.io/@hossein_no1/%DB%B0%DB%B1-%D9%BE%DB%8C%D8%B4%DA%AF%D9%81%D8%AA%D8%A7%D8%B1-%DA%86%DA%A9%DB%8C%D8%AF%D9%87-%DA%A9%D8%AF%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AA%D9%85%DB%8C%D8%B2clean-code-%D8%A7%D8%AB%D8%B1%DB%8C-%D9%81%D8%A7%D8%AE%D8%B1-%D8%A7%D8%B2-%D8%B9%D9%85%D9%88-%D8%A8%D8%A7%D8%A8-qfhuzn7uwlna سلام✋من حسین پناهنده‌ام، یک جوون عاشق برنامه نویسی و فن پرو‌پاقرص گوگل?پس طبیعیه که توسعه دهنده اندروید باشم...فعالیت برنامه نویسی من(نه چندان تخصصی) از دوران هنرستان شروع شد و با زبان قدرتمند و انعطاف پذیر سی شارپ، که خوشبختانه و از نظر من زبان عالی برای شروع برنامه نویس و ورود به دنیای کدنویسیه; بگذریم، بعد از اون با تحقیق و جست و جو و پیشنهاده بعضی از دوستان که دستی بر کد داشتن به زبان جاوا گرویدم(: و شروع به کدنویسی حرفه‌ایم از همون جا (سال ۹۶) بود.بعد از گزروندن یک دوره آماتوری توی یک موسسه گمنام بالاخره فرصتی پیش اومد تا برم سمت چیزی که دوست دارم یعنی اندروید.علت انتخاب اندروید برای من حداقل توی اون سال ها دو دلیل داشت:۱- همون‌جور که گفتم عاشق گوگل و محصولاتش بودم و هستم و خواهم بود۲- رسالت و هدف من از توسعه نرم‌افزار، جذب کاربر و ساخت محصولی‌ایه که کاربر رو ذوب خودش کنه و بتونه نیاز هاشو برطرف کنه(سازندگی)، و از اونجایی که سهم اندروید توی تعداد کاربر بیشتر از بقیه پلتفرم هاست(حداقل در ایران) پس چی بهتر از این دیگه(:خوب دیگه بیوگرافی بسته، میریم سراغ دلیل ایجاد این پست.چند وقتیه که توی یک شرکت برنامه نویسی دانش‌بنیان با کلی ایده خفن و آینده‌ای درخشان مشغول به کار شدم که شروع به کار من توی این شرکت مصادف شد با شروع دوره‌های رشد شخصی خودم در دنیای تخصصی‌ام به صورت حرفه‌ای(چقدر پیچیده گفتم‌اش?)با ورود من به این شرکت و با پیشنهاد و پافشاری خودم بالاخره تونستیم، تیم بیزینس رو راضی کنیم تا دوره‌های رشد شخصی برای خودم و بقیه افراد گروه بزاریم(البته قبل از من هم این ایده رو داشتن، ولی همزمان با ورود من این فرصت به وجود اومد تا به جای تولید فیچر ها و اپدیت های فورس یک فکری به حال بدهی فنی هم بکنیم...)خلاصه، با یک صحبت کوتاه و پیشنهاد اسکرام مستر شرکت، برنامه این شد که کتاب کدنویسی تمیز(Clean code) یا به قول من قرآن برنامه نویس ها از عمو باب عزیز رو تهیه کنیم و یک برنامه برای خوندن و عمیق شدن توی این محتوای سنگین رو طراحی کنیم.بعد از تفکرات فراوان به این نتیجه رسیدیم که، بهترین بازدهی در درک مطالب کتاب = بیشترین تعامل و بحث و اظهار نظر افراد گروه درباره اونه.پس تصمیم گرفتیم که در طول دوره هر اسپرینت(اسپرینت یک بازده زمانی در شیوه اسکرام است) یک فصل از کتاب رو همه مطالعه کنیم و در آخر هر اسپرینت یک جلسه اجلاس سران رو تشکیل بدیم و راجب به موضوعات اون فصل بحث و نتیجه‌گیری کنیم.از اونجایی که من علاقه‌ به "نوشتن" و "خلاصه برداری" دارم، این مسؤلیت رو قبول کردم که یک قدم از بقیه جلوتر باشم و بعد از مطالعه هر صفحه، خلاصه اونو کنارش بنویسم تا بچه های گروه، هم با خوندن مطالب، محتوا رو درک کنن همم با خوندن خلاصه نویسی من بتونن راحت تر اطلاعات رو هضم کنن.خوب از اونجایی که قبلا هم گفته بود، من آدم "کاربر دوستی" هستم(: (دهخدا تو گور لرزید)و بعد از این پیشنهادم این فکر به سرم زد که چرا خلاصه نویسی من محدود به ۱۰ نفر بشه؟؟؟ چرا اونو منتشر نکنم تا علاقه‌مندهای دیگه‌ به این موضوع هم بتونن استفاده کنن؟!؟ واقعا چرا؟؟و این دلیلی بود که تا الان این همه مطلب نامربوط به عنوان رو خوندی و رسیدی به اینجا?خوب دیگه خیلی هم بیربط حرف نزدم، بالاخره برای هر موضوعی یک مقدمه و پیشگفتار باید نوشته بشه تا خواننده از اول نخ مطلب رو بگیره و تا آخرش بره.نتیجه‌گیری نهایی: هدف از ساخت این پست و رشته پست‌های بعد از این، انتشار خلاصه کتاب کدنویسی تمیز از دیدگاه خودم و خروجی مناظره یک تیم حرفه‌ای روی هر کدوم از قسمت هاشه تا بقیه هم بخونن و ازش لذت ببرن.وتمام✋منتظر اولین قسمت از کتاب باشید...خدانگهدار.مقدمه و معرفی کتاب حسین پناهنده حسین پناهنده Wed, 15 Dec 2021 21:52:09 +0330