https://virgool.ir/feed/@NimaShirinzadehDeveloperfa2026-11-11 07:41:45https://files.virgool.ir/upload/users/2012/avatar/yHplnn.pnghttps://virgool.ir/@NimaShirinzadehhttps://virgool.ir/@NimaShirinzadeh/clean-code-بخش-سوم-owpf1yesn4k1امروز قصد داریم در مورد بخش سوم clean code صحبت کنیم. این بخش به شخصه بخش مورد علاقه من هستش. چون سعی کردم فلسفه و روشی رو که تو این بخش توضیح داده شده رو روی کدی بشدت شلوغ و نامرتب اجرا کنم و نتیجه رو هم دیدم همه چی به مراتب تمیز تر و خوانا تر شده بود و و ضریب تکرار کد خیلی پایین اومد بود. و هر بار که فرصتی پیدا می کنم سعی می کنم اون کد و تمیز تر کنم. به طور خلاصه استفاده از دستور العمل های این بخش به من خیلی کمک کرد.در ادامه این بخش رو بررسی می کنیم.Functionsدر سال های ابتدایی معرفی شدن برنامه نویسی، سیستم ها از روتین ها و زیر روتین ها (routines and subroutines)، برنامه ها و زیر برنامه ها (programs, subprograms) و تابع ها (function) تشکیل شده بودند. در زبان های برنامه نویسی امروزی این فاکشن ها هستن که هنوز با قدرت جایگاه خود را حفظ کرده اند. و از مهم ترین ارکان یک سیستم محسوب می شوند. حتما با این مشکل مواجه شده اید که یک فاکشن به قدری بزرگ شده باشه که عملا امکان اعمال تغییرات رو سخت یا ناممکن کرده باشد. و این معمولا اولین مشکلی است که همه برنامه نویس ها با ان مواجه می شوند. فاکشن های بزرگ که خوانایی کد رو کم می کنند و در اینده امکان درک کد را خیلی مشکل می کنند. در ادامه چند نکته و روش و راه حل رو باهم بررسی می کنیم.small!کتاب اینطوری شروع می شه که:اولین قانون برای فانکشن ها این است که باید خیلی کوچک باشند و دومین قانون این که باید از این هم کوچک تر باشند. توجیهی برای این ادعای خود ندارم. و هیچ تحقیق و مرجعی به منظور ارجاع و اثبات این که فانکشن های کوچک بهترند ندارم ولی من به مدت 40 سال فاکشن با اندازه های مختلف نوشته ام. از فاکشن های با حدود 3000 خط کد تا فاکشن هایی با 20 خط کد. و این تجربه به من اموخت که تست و اشکال یابی در فانکشن های کوچک خیلی راحت و سریع تر است.اگر بخواهیم اندازه فانکشن رو به صورت کمی بسنجیم هر فانکشن باید در ابعاد یک صفحه نمایش بگنجند اما با توجه به ویژگی های محیط های برنامه نویسی امروزی و امکان تغییر فونت و اندازه فونت این معیار، معیار دقیقی نیست. اما برای بهتر کردن این معیار هر فانکشن باید کمتر از 20 خط باشد. بر اساس نمونه کدهای Kent Beck بهترین فانکشن‌ها فانکشن‌های 3 الی 4 خطی هستن که این نشانگر دقت و مهارت بالای برنامه نویس است.نکته-Blocks and Indenting: بر اساس توضیحات قبلی بهتر است درون عبارات کنترلی مانند (if,while) تک خطی باشد. بنابراین بهتر است از فانکشن ها استفاده کرد. و همین طور نباید سطوح تو در تو بیشتر از یک یا دو سطح باشند. فانکشن نباید به اندازه ای بزرگ باشد که تمام سطوح تو در تو را در بر بگیرد.Do One Thingفانکشن ها باید یک عمل را انجام بدهند. ان ها باید ان را به خوبی انجام دهند. و فقط ان را انجام دهند.تلاش برای کوچک بودن فانکشن از چند کاره بودن ان جلوگیری می کند و تلاش برای ساخت فانکشن با یک وظیفه به کوچک بودن ان کمک می کند. به نوعی این دو قانون برای یک دیگر نقش کاتالیزور رو دارند. مفهوم ساده ی مطرح شده که مشخص می کند فانکشن فقط به یک وظیفه عمل می کند این است که اگر ما بتوانیم از یک فانکشن یک فانکشن دیگر با نامی جدید که مفهومی مشابه با فانکشن قبلی نداشته باشد استخراج کنیم بنابراین عملا فانکشن قبلی ما تک وظیفه‌ای نبوده بنابراین باید فانکشن را به فانکشن های کوچک تر بشکنیم.مفهوم دقیق تری که مطرح شده، کدها در زیر فانشکن با نام معین باید در یک سطح انتزاع (abstraction) قرار داشته باشند. برای متوجه شدن دقیق تر این مفهوم به نمونه کد زیر (Listing 3-2) توجه کنید. برخی از این کد از بالاترین سطح انتزاع (مانند getHtml)، برخی در سطح میانی (مانند String pagePathName = PathParser) و برخی در پایین ترین سطح انتزاع قرار دارند (مانند ()append.) تشکیل شده است.Listing 3-2 public static String renderPageWithSetupsAndTeardowns( PageData pageData, boolean isSuite) throws Exception { boolean isTestPage = pageData.hasAttribute("Test"); if (isTestPage) { WikiPage testPage = pageData.getWikiPage(); StringBuffer newPageContent = new StringBuffer(); includeSetupPages(testPage, newPageContent, isSuite); newPageContent.append(pageData.getContent()); includeTeardownPages(testPage, newPageContent, isSuite); pageData.setContent(newPageContent.toString()); } return pageData.getHtml(); }خواندن کدی با ترکیبی از سطوح انتزاع، گیج کننده است و باعث می‌شود تشخیص عمکرد اصلی برای خواننده دشوار شود.Reading Code from Top to Bottom: The Stepdown Ruleدر ادامه برای بررسی تک وظیفه ای بودن متدی ارائه شده است که به (TO paragraph) معروف است. طبق این متد از بالا ترین انتزاع شروع می‌کنیم تا به پایین ترین انتزاع برسیم و باید توجه کنیم در هر انتزاع باید کد‌های همان انتزاع را قرار دهیم. به نمونه زیر توجه کنید که مربوط به کد های بالاست (Listing 3-2). هر انتزاع با کلمه کلید TO شروع شده هر بخش از انتزاع (هر بخش برار متن بین دو ویرگول)که نیاز به سطح بعدی داشته باشد در ادامه مانند دستور العمل امده است که هم مشخص کننده انتزاع بعدی است و هم به دلیل شروع با کلمه کلیدی TO خود به عنوان یک انتزاع و فانکشن در نظر گرفته شده است. استفاده از این متد کمکی زیادی به ما می کند تا حرفه ای تر شویم.To include the setups and teardowns, we include setups, then we include the test page content, and then we include the teardowns.To include the setups, we include the suite setup if this is a suite, then we include the regular setup.To include the suite setup, we search the parent hierarchy for the “SuiteSetUp” page and add an include statement with the path of that page.To search the parent. . .نکته-Use Descriptive Names: همان طور که قبلا گفته شد انتخاب نام مناسب از اهمیت بالایی برخوردار است. هر قدر که توابع ما کوچک تر باشند و بر روی یک وظیفه متمرکز باشند انتخاب اسم مناسب (descriptive name) برای ما اسان تر می شود.نکته: اسم طولانی ولی توصیف کننده عملکرد فانکشن از یک اسم کوتاه و مبهم و حتی از کامنت گذاری هم مهم تر و بهتر است.Function Argumentsتعداد ورودی های یک فانکشن نیز از اهمیت بالایی برخوردار است. بهترین تعداد ورودی برای هر فانکشن صفر است. اما دستیابی به این عدد همیشه امکان پذیر نیست. از انجایی که وجود ورودی برای یک فانکشن پیچیدگی ادارکی ان را افزایش می دهد بنابراین وجود بیش از 3 ورودی برای توابع قابل قبول نیست و در صورت وجود چنین توابعی باید ریفکتور صورت گیرد. وجود ورودی برای فانکشن ها نه تنها اشنایی با عملکرد فانکشن های را سخت می کند بلکه در هنگام تست هم باید ترکیبات ورودی ها مورد تست قرار گیرد. که معمولا فانکشن های بیش از 2 ورودی فرایند تست سختی دارند.زمانی که یک فانکشن بیش از دو یا سه ورودی داشت با دو دیدگاه در صورت امکان می توان تعداد ورودی های ان را کاهش داد:بعضی از ورودی ها را بتوان درون یک کلاس قرار داد مانند مثال که x و y در کلاس center جمع شده اند.Circle makeCircle(double x, double y, double radius); Circle makeCircle(Point center, double radius);برای بعضی از ورود‌ها با یک ترتیب خاص یک اتفاق خاص می افتد که در این صورت می توان از یک List یا Object به جای تمام ان ورود ها استفاده کرد.String.format("%s worked %.2f hours.", name, hours); String.format("%s worked %.2f hours.",List or Object);Command Query Separation (مثال خاص و پر کاربرد)این عنوان اندکی مبهم و در نگاه اول ممکن است مقصود رو منتقل نکند.ولی چیست؟ یک فانکشن باید در یک زمان یا کاری انجام دهد یا جوابی تولید کند. انجام هر دو کار در یک زمان برای یک فانکشن درست نیست. اما منظور چیست با یک مثال ببینیم.public boolean set(String attribute, String value);فرض کنید فانکشنی داریم که مقداری برای نام کاربری قرار می دهد و در صورت موفقیت true و در صورت عدم موفقیت false را باز‌می گرداند. و باعث استفاده های عجیبی مانند مثال زیر شود.if (set("username", "unclebob"))...از دیدگاه خواننده برداشت های متفاوتی از عبارت بالا انجام می‌شود. ایا مقدار نام کاربری را بررسی می کند که قبلا unclebob قرار داده شده بود؟ یا بررسی می کند که مقدار نام کاربری به درستی unclebob قرار داده شود؟همانطور که مشخص است فهمیدن عملکرد امکان پذیر نیست. یک راه حل انتخاب setAndCheckIfExists به عنوان نام فانکشن است که خوانایی شرط را کم می کند و راه حل دوم جدا سازی شرط(query) از عملیات (command) است که کد به صورت زیر تغییر پیدا می کند.if (attributeExists("username")) { setAttribute("username", "unclebob"); ... }که به این ترتیب هر فانکشن یک عملکرد خاص را انجام می دهد.Don’t Repeat Yourself(Evils lay here)تکرار(duplication)، مشکلی که باعث به وجود امدن مشکلات زیادی در کد نویسی می شود به اصطلاح باعث باد کردن (bloat) کد می شود. با یک تغییر در الگوریتم و یا یک ویژگی از برنامه نیاز به اصلاح n بخش کد و نیاز به n بار کد نویسی است. Duplication may be the root of all evil in softwareتکرار، می تواند ریشه تمام مشکلات نرم افزاری باشد. به همین دلیل اصول و روش های (principles and practices) مختلفی برای کم کردن و جلوگیری از تکرار ارائه شده است. متد ها و روش هایی که باید هر برنامه نویسی بر حسب نیاز با ان ها اشنا شود و از ان ها هنگام کد نویسی استفاده کند. از جمله این متد ها:object-oriented programming ,Structured programming,Aspect Oriented Programming, Compo-nent Oriented Programmingتا اونجایی که می شد سعی کردم این بخش رو خلاصه و مفید کنم که حداقل دید کلی به خواننده بده امیدوارم تونسته باشم این کارو بکنم.مطمئنا مفهوم مطرح شده توی بخش رو تو اکثر بخش های کداتون دیدین جایی وجود نداره که شما فانکشن نبینین و این تعدد استفاده نیاز داره تا ما بدونیم چطوری و کجا ازشون استفاده کنیم تا بتونیم خوب کد بنویسیم. البته این بخش یه اشاره هایی ام به مفهوم شی گرایی داره شاید تو نوشته من خیلی این اشاره مشخص نباشه ولی در نهایت خیلی از این مشکلات در فانکشن ها با شی گرایی قابل حل هست یکی از اصول مهمیه که باید بدونین سعی کنین یه مطالعه ای پیرامونش بکنین.نیما شیرین زادهنیما شیرین زادهMon, 16 Sep 2019 19:16:49 +0430https://virgool.ir/@NimaShirinzadeh/clean-code-بخش-دوم-i3dth5q3dincدر ادامه طبق روند کتاب جلو میریم. قرار توی این پست در مورد اولین نکته مهم که پایه و اساس یک فاکشن، یا کد، یا برنامه، یا هر متغیری هست صحبت کنیم. هدف این بخش کتاب این که کد هایی که شما می نویسین مثل خوندن یه روزنامه باشه(زمانی که روزنامه می خونین سرتون به سرعت روی خطوط حرکت می کنه) خود کتاب از واژه Quick Skim استفاده می کنه. تا به این ترتیب نه تنها خودتون در آینده از خوندن کداتون لذت ببرین، حتی بقیه ام خیلی راحت کداتونو بخون و هدف هر بخش از کد، فاکشن یا متغییر رو بفهمن.Meaningful Namesاز اینجا به بعد قصد داریم این دانش و آگاهی رو پیدا کنیم که نام های معنا دار چی هستن و چجوری باید نام های معنا دار انتخاب کرد و اصلا فرق بین نام معنا دار با نامه های نامناسب یا بی معنی چی هستش. و در نهایت با ایده کلی چگونگی انتخاب اسم اشنا بشیم. مطمئنا مفاهیم پیش رو بعد مدتی کد نویسی تا حدی توسط برنامه نویس رعایت میشه ولی ممکنه این رعایت کردن از نوع آگاهانه نباشه برای همین به بهترین شکل خودش اعمال نشه.Intention-Revealing Namesمهم ترین نکته در این بخش انتخاب اسامی است که مقصود خودشون رو نشون بدن. تقریبا این نکته پایه و اساس باقی نکات و مفاهیمی است که در ادامه می بینیم. نام یک متغیر، کلاس یا فانکشن باید بتونه دلیل وجودی، کاری که داره انجام میده، جا و نحوه ی استفاده شو توصیف کنه. در واقع جواب این سوال ها باید توی کد وجود داشته باشه بعنی اسامی و در انتزاع بالا تر خود کد باید بتونه خودش رو توصیف(کلمه ای که کتاب انتخاب کرده explicit بودنه) کنه.برای مثال d می تونه هرکدوم از متغیر های زیر باشه:int d; // elapsed time in days ----------------------------------------------- int elapsedTimeInDays; int daysSinceCreation; int daysSinceModification; int fileAgeInDays;نکته ای که وجود داره اگر مجبور بودید برای یک اسم کامنت بذارین تا مفهومش رو منتقل کنین (اسم می تونه در غالب فاکشن یا هر چیز دیگه باشه) اون اسم اصل نام گذاری معنادار و نقص کرده.Avoid Disinformationما همیشه حتی توی صحبت روزمره هم سعی می کنیم از الفاظی استفاده کنیم که مخاطب رو دچار سوء تفاهم نکن و مقصود مارو به درستی منتقل بکنن.در برنامه نویسی هم رعایت این نکته مهم چون می تونه باعث کج فهمی بشه ما می تونیم از اسمی مثل android استفاده کنیم ولی این ممکنه مفهوم درستی رو منتقل نکنه حتی زمانی که توی محیط اندرویدی باشید.مثال های دیگر: ممکنه accountList واقعا یک List نباشه مارو در تشخیص تایپ دچار اشتباه کنه ولی accountGroup یا BunchOfAccounts می تونه اسم بهتری باشه.اسامی که در کلماتشون تفاوت کمی وجود داره اسامی مناسبی نیستند. برای مثال پیدا کردن تفاوت بین این اسم XYZControllerForEfficientHandlingOfStrings و اسم مشابه دیگه که مثل این اسم XYZControllerForEfficientStorageOfStrings هست کار راحتی نیست.و هر مثالی از این دست مشکلات که به ذهن شما میرسه؟؟Make Meaningful Distinctionsما همیشه باید سعی کنیم تفاوتی هایی که ایجاد می کنیم، معنایی رو منتقل کنند در غیر اینصورت ما اصل معنا دار بودن رو نقض کردیم و تفاوتی که ایجاد کردیم کارایی و ارزش کد رو پایین میارن. برای مثال از نام klass به جای class استفاده کنیم و علاوه بر اینکه تفاوت ما معنادار نیست ممکنه ما دچار مشکلات کامپایلری هم بشیم.نکات مهم:استفاده از اعداد در کنار حروف مناسب نیستد و با اینکه تفاوت بین اسامی ایجاد کرده اند ولی تفاوت معنا دار نیست. مانند a1اسامی مثل Data یا Info و کلماتی مثل a، an و the نیز اسامی مناسبی برای ایجاد تفاوت نیستند. حالا اگه شما می تونین تفاوت بین این اسامی رو بگین :getActiveAccount();getActiveAccounts();getActiveAccountInfo();مشخصه که نمیشه با یقین تفاوت هاشون و ماهیتشون رو به زبون اورد.مثال بیشتر: moneyAmount, money - customerInfo, customer and so on...Use Pronounceable Names باتوجه به کار کرد مغز انسان، بخشی مهمی از مغز به کلمات اختصاص داده شده و هر کلمه دارای بار معنایی است. بنابراین استفاده از اسامی معنادار کمک می کنه تا کد ما داری خوانایی بیشتری باشه برای همین استفاده از اسامی معنا دار بهترین گزینه است و استفاده از اسامی معنا دار یعنی استفاده از اسامی قابل تلفظ.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 = "102";};Pick One Word per Conceptتا اینجا یاد گرفتیم که اسامی باید چه ویژگی هایی داشته باشن و چه ویژگی هایی نداشته باشن. مشخصه که با رعایت مفاهیم بالا تا حدی انتخاب اسامی مون بهتر میشه ولی بیاین یک سطح انتزاعمون رو بیاریم بالاتر، به کلماتی مثل get یا fetch دقت کنین. اگه تو کلاس های مختلف از هر کدوم استفاده کنیم زمانی که تعداد کلاس ها بره بالا ممکنه برای کسی دیگه ای که کد های مارو می بینه حتی بعد مدتی برای خودمون این انتخاب اسم گیج کننده بشه. بخصوص زمانی که هر کدوم از اونا بخوان یه کار متفاوت هم انجام بدن.بنابراین بهتره که برای انتخاب اسم برای یک موضوع و انتزاع هم دقت کنیم.برای مثال فانکشنی که در یک کلاس اطلاعات مربوط به اون کلاس رو بر می گردونه فقط با get نام گذاری بشه. نکته دیگه ای که توی این مفهوم وجود داره اینه که علاوه بر این که نباید از دو اسم برای یک انتزاع استفاده کرد همین طور نباید از یک اسم برای دو کار و انتزاع مختلف استفاده کرد برای مثال فکر کنین ما از اسم add برای ساخت یک مقدار جدید در تمام کلاس ها استفاده می کنیم و این یعنی ثبات (consistency) و ما هم به دنبال همین هستیم. و حالا یک کلاس جدید می سازیم که از فاکشن add به جای ساختن یک مقدار جدید، یک مقدار به مقدار قبلی در یک آرایه اضافه می کنیم ظاهرا همه چی درسته ولی باید بدونیم که در واقع ما عملیات insert یا append انجام دادیم پس باید تو این کلاس از append یا insert به عنوان اسم فانکشنمون استفاده کنیم. فکر می کنم تا حدی متوجه شده باشیم که چه اسامی باید انتخاب بشن و چجوری باید انتخاب بشن ولی چنتا نکته وجود داره که خوب گفته بشه:دقت کنید که استفاده از اسامی مناسب جست و جو در پروژه رو برای ما آسون می کنه بنابراین اسامی انتخاب کنین که یسری ویژگی های بالا رو داشته باشن یسری رو نداشته باشن و search-friendly باشن. اسمی مثل حرف e که جز حروف پر تکرار بد ترین انتخاب می تونه باشه.همین طور که هر متنی مخاطب داره مخاطب کد های ما برنامه نویس ها هستن. با همین استدلال برای انتخاب اسم ها می تونین دو استراتژی رودر نظر بگیرید: انتخاب اسم بر اساس راه حل (Use Solution Domain Names):اسم می تونه یک اصطلاح در علم کامپیوتر، اسم یک الگوریتم، یک اصطلاح ریاضی یا هر چیز مرتبط دیگه ای باشه. برنامه نویسی نداریم که ندونه JobQueue چه مفهومی داره. بنابراین بهترین استراتژی برای اتنخاب اسم، انتخاب بر اساس راه حل هستش.انتخاب اسم بر اساس مشکل (Use Problem Domain Names): راه دیگر انتخاب اسم بر اساس مشکلی هست که که حل می شه. تنها مشکل این استراتژی زمانی هست که شخص دیگه ای بخواد روی کد کار کنه بنابراین باید در مورد مشکل از شخصی که توی اون پروژه تجربه داشته سوال بپرسه.جدا کردن دامنه راه حل و مشکل بخشی از کار یک برنامه نویس یا طراح خوبه پس باید روش دقت بشه.نکته: زمانی که تمرکز یه کد بیشتر روی حل یک مشکل هست بهتره که اسم از دامنه مشکلات انتخاب بشه.درسته که رعایت نکات و مفاهیم بالا می تونه کمک کنه اما علاوه برا نکات بالا وجود یک مهارت توصیفی خوب در فرد و وجود یک پیشینه فرهنگی مشترک هم می تونه کمک زیادی کنه تا کد از خوانایی زیادی برخوردار باشه. که این مسائل بیشتر مربوط به مسائل آموزشی هستن تا مسائل تکنیکی کار. و در انتهای این بخش کتاب میگه "این قوانین رو پیروی کنین اگه خوانایی کدتون بیشتر نشد."با رعایت این مفاهیم ممکنه زمان بیشتری هنگام کد زدن از شما بگیره ولی با هزینه کردن این زمان هنگام کد زدن مسلمه در آینده در هنگام تغییرات یا استفاده دوباره از کد صرفه جویی میشه. البته تمام این نکات بدون تمرین عملی و تکرار عملا به درد نمی خورن و باید هنگام کد زدن بهشون فکر کنین، رعایتشون کنین، تو انتخاب اسامی دقت کنین اگر اسم بهتری انتخاب کردین برگردین و جایگزینش کنین. تو این بخش سعی کردم نکات مهم و بدرد بخور رو تا حد امکان منتقل کنم و در عین مفید بودن، خلاصه هم باشه. اگه نکته ای یا مشکلی یا پیشنهادی می بینین خوبه که درمیون بذارید تا بقیه ام استفاده کنن. تو مبحث های بعدی سعی می کنم مبحث های کاربردی و بدرد بخور دیگرو مطرح کنم تا روز به روز کدامون تمیز بشه. تو این پست نشد نقل قولی رو بیارم سعیمو می کنم تو پست های بعدی یه جایی برای نقل قول در نظر بگیرم.توئیتر من: Nima Shirinzadehنیما شیرین زادهنیما شیرین زادهSat, 10 Aug 2019 21:40:53 +0430https://virgool.ir/@NimaShirinzadeh/clean-code-بخش-اول-dgzw9ik0zusdسخن اولطی این سلسله پست ها قصد دارم مفاهیم ساده ولی مهمی رو که می تونه برنامه نویسی رو برای ما بیشتر از قبل جذاب بکنه و همین طور کمک کنه تا به یه برنامه نویس خوب شایدم به یه حرفه ای تبدیل بشیم رو مطرح بکنم.همه چیز از اونجایی شروع شد که وارد یه پروژه نسبتا بزرگ شده بودم و پیچیدگی و حجم کار بالا بود و البته مدیریت ضعیف، روز به روز که جلو می رفتیم می دیدم که داریم توی کد هامون غرق می شیم و نگهداری و بروزرسانی کد ها و اضافه کردن فیچر های جدید داشت روز به روز سخت تر می شد یکی از دلایل عمده ی این مشکل حضور دائمی ددلاین تو یک قدمی ما بود روزی رو سراغ ندارم که فرداش ددلاین نباشه (یکم مبالغه امیز ولی تقریبا درسته) و مشکلات ریز و درشت دیگه ای که جای مطرح کردنش نیست. خود این مشکل فرصت کافی فکر کردن و سازماندهی به کد هارو از برنامه نویسا گرفته بود.مشخص بود هرچی بیشتر جلو بریم بازدهی برنامه و برنامه نویس روز به روز کم تر میشه در نهایت به جایی می رسیم که نمیشه کاریش کرد یا باید همه چیو از صفر شروع کرد یا باید همه چیو ریخت دور یه روز که کلید واژه های مختلف و سرچ می کردم و داشتم فکر می کردم که چطوری باید خودمون و از باتلاقی که درست کردیم نجات بدیم و با این کار خود پروژه رو از سرنوشت شومی که در انتظارش نجات بدیم به کتابی بر خوردم که برای حل همین مشکل یعنی کمک به نگهداری و اعمال راحت تر تغییرات طراحی شده بود.کتاب عنوان ساده ای داشت Clean Code، همین که صفحات اولیه کتاب رو خوندم متوجه شدم که این دقیقا همون راه حلی بود که دنبالش بودم. نویسنده این کتاب Robert Cecil Martin معروف به uncle bob مدرس و مهندس نرم افزار امریکایی هستش که به عنوان یکی از نویسندگان Agile و همچین ارائه دهنده چندین اصل طراحی نرم فزار شناخته شده است.سخن اول کتابشما این کتاب را به دو دلیل می خونین دلیل اول اینکه برنامه نویس هستین دلیل دوم اینکه شما قصد دارید برنامه نویس بهتری بشید.خاطره ای کوتاه از کتابکمپانی رو در دهه 80 میشناختم که یک اپلیکیشن موفق طراحی کرده بود و محبوبیت زیادی کسب به دست اورده بود اما روز به روز زمان انتشار نسخه جدید اپلیکیشن طولانیتر می شد و نظم قبلا رو نداشت و باگ ها از نسخه ای به نسخه بعد از بین نرفته بودن و زمان لود اپ و کراش اپ بیشتر و بیشتر شده بود و بالاخره کمپانی مجبور شد ادامه کار روی اپلیکیشن متوقف کنه و دیگه هیچ وقت ازش استفاده نکرد.حدود 20 سال بعد من یکی از کارمندان قدیمی اون شرکت رو ملاقات کردم و در مورد دلیل این اتفاق ازش سوال کردم. جواب نظریه های منو تایید کرد. ما باید اپلیکشین رو هر چه زود تر به بازار ارائه می دادیم به همین دلیل کدها به شدت کثیف و ناخوانا بود. ما اسمی براش گذاشتیم و اون رو wading (توده های انباشه شده روی هم) صداش می کردیم. ما هرچه بیشر و بیشتر ویژگی اضافه می کردیم نگهداری و مدیریت کد ها سخت تر و سخت تر می شد. این کد نامناسب بود که کمپانی رو از بین برد.نمودار نسبت بازده به زمان بر اساس یک کد بدشاید الان فک کنین که مشکل مدیریت کمپانی بود که همه چی از بین رفته ولی دلیل اصلی خود برنامه نویس ها هستن چون مدیر،مشتری و بازار با توجه به اطلاعاتی که ما بهشون میدیم برنامه ریزی میکنن و جلو میرین و حتی اگر از ما برنامه ریزی نخوان هم ما باید مشکلات و اشتباهاتی مانند زمان بندی که تو کد تاثیر دارن و بهشون بگیم حتی اگه خوشون نیاد(یکم آرمانگرایانه است) و در نظر داشته باشیم که ما به عنوان برنامه نویس مسئولیم. و توجه داشته باشیم که تمیز کاری کد رو هیچ وقت به بعدا موکول نکنیم چون طبق قانون لبلانک بعدا === هرگز.در ادامه و در پست های بعدی نکات مهم و مباحث مختلف و مطرح میکنم که با رعایت ساده هر کدوم از اونا روز به روز می بینین که همه چی تمیز تر میشه و البته سعی میکنم نقل قول های مختلفی که توی کتاب در مورد کد تمیز اومده رو در خلال پست ها بعدی جا بدم خوندن اونام خالی از لطف نیست.نیما شیرین زادهنیما شیرین زادهSun, 04 Aug 2019 20:41:01 +0430