كد تميز

مقدمه

کدام درب کد شما را نشان می­دهد؟کدام کد نشان دهنده تیم یا شرکت شماست؟

چرا ما در آن اتاق هستیم؟آیا اینجا فقط یک کد نرمال را نشان میدهد یا جریانی از مشکلات وحشتناک مدتی بعد از زندگی کردن را؟آیا ما در وحشت اشکال زدایی می­کنیم و غوطه­ور می­شویم در کدی که فکر می­کنیم کار می­کند؟آیا مشتری ها ازدحام ها را ترک می­کنند و مدیران زیر گردن ما نفس می­کشند؟

چطور ما میتوانیم مطمعن بشویم پشت در سمت راست زمانی که کار سخت است؟جواب استاد کار دستی است.

اینجا دو بخش برای یادگیری کار دستی وجود دارد:دانش و کار.شما باید به دست بیاورید دانش اصولی،الگوها،شیوه­ها و اکتشاف­هایی که یک صنعت گر میداند.و شما باید آن دانش را منتقل کنید به انگشتانتان،چشم­هایتان با سخت کار کردن و تمرین کردن.

من میتوانم فیزیک سوار شدن بر دوچرخه را به شما یاد بدهم.در واقع ریاضیات کلاسیک سر راست است.جاذبه،اصطکاک،زاویه تکانه­ای و مرکز جرم میتوانند ثابت بشوند با کمتر از یک صفحه پر از معادلات.

با توجه به این فرمولها می توانم به شما ثابت کنم که دوچرخه سواری امری عملی است و تمام دانش نشان میدهد که لازم است تا کار کنید.و شما اولین باری که سوار آن دوچرخه میشوید پایین می­آیید.

کد زدن متفاوت نیست.ما میتوانیم پایین همه عبارات"احساس خوب" تمرین کد تمیز را بنویسیم و سپس به شما اعتماد کنیم که کار انجام دهید(به عبارت دیگر بگذارید هنگام سوار شدن بر دوچرخه بر زمین بیافتید) اما پس از آن چه نوع معلمان می توانند ما را بسازند و شما چه نوع دانشجویی ایجاد شدید.

خیر،این راهی نیست که کتاب براساس آن کارکند.یادگیری نوشتن کد تمیز کار سختی است.برای اینکار نیاز بیشتری است علاوه بر دانش اصول و الگوها.شما باید برای اینکار عرق کنید(سخت کارکنید).شما باید اینرا خودت تمرین کنی و ببینی که شکست میخوری.شما باید دیگران را ببینی که اینکار را انجام میدهند و شکست میخورند.شما باید لغزیدن انها را ببینید و ببینیند که چگونه دوباره گام هایشان را بر میدارند.شما باید عذاب انها بر روی تصمیماتشان و هزینه­ای که پرداخت میکنند بخاطر ان تصمیماتی که به روش اشتباه گرفته شد.آماده بشید برای کار سخت و در حالی که این کتاب را میخوانید.این یه کتاب در مورد احساس خوب نیست که شما بتونید اون رو توی هواپیما بخونید و قبل از اینکه فرود بیاد تمومش کنید.این کتاب به شما کار کردن و سخت کار کردن را یاد بدهد.شما چه نوع کاری را انجام خواهید داد؟شما مقدار زیادی کد را خواهید خواند.و شما را به چالش خواهد کشید برای فکر کردن در مورد انچه در مورد کد درست یا اشتباه است.شما اینرا از ما خواهید خواست که ماژول های جدا از هم بسازیم و سپس انها را دوباره کنار هم قرار بدهیم.این تلاش و زمان زیادی میخواهد ولی ما فکر میکنیم که ارزشش را خواهد داشت.

ما این کتاب را به سه بخش تقسیم کردیم.چند فصل اول اصول،الگوها،و تمرین کردن کد تمیز را برای شما توضیح خواهد داد.در این فصل کد کاملا کد وجود دارد و خواندن انها چالش برانگیز خواهد بود.انها شما برای امدن به بخش دوم اماده میکنند.اگر بعد از خواندن بخش اول کتاب را پایین گذاشتید(کتاب را نخواندید)،برای شما ارزوی موفقیت میکنم!!

قمست دوم کتاب کار سخت تر است.این شامل چند مورد مطالعه از پیچیدگی های روز افزون است.هر نمونه مطالعه یک تمرین برای تمیز کردن چند کد است که تبدیل شده اند از کدهایی که چندین مشکل در انها است به کد هایی که اشکالات کمی در انها است.جزییات در این بخش شدید است.شما باید بین لیست و روایت کد به عقب و جلو بر گردید.شما باید کدی را که با انها کار میکنیم تحلیل و درک کنید و استدلال خود را برای هرگونه تغییری که ایجاد میکنیم بیان کنید.زمان های کوتاه را کنار بگذارید.شما باید چند روز زمان بگذارید.

سومین بخش از کتاب باز پرداخت است. این یک فصل واحد است که شامل لیستی از اکتشافات است که در هنگام ایجاد مطالعات موردها جمع آوری شده است.همینطور که ما کد ها را تمییز میکنیم در نمونه های مطالعاتی ما دلایل خود را که کشف کردیم برای هر اقدامی ثبت کردیم.

ما سعی کردیم درک کنیم واکنش مان را به کدی که میخوانیم و انرا تغییر میدهیم و سخت کار کردیم که چرا ما احساس کردیم و انچه انجام دادیم دوباره انجام دهیم.نتیجه یک دانش بنیادی است که تفکر هنگام خواندن و نوشتن و تمیز کردن کد را توصیف میکند.این دانش مبنایی ارزش محدودی دارد اگر شما کار نکنید از چیزهایی که با دقت خواندید و از طریق نمونه های مطالعاتی قمت دوم این کتاب.

برای آن نمونه های مطالعاتی ما با دقت حاشیه نویسی کردیم که انها را تغییر دادیم با منابعی که ما را به جلو میبرد.این منابع رو به جلو در براکت های مربع مثل این ظاهر میشوند:[H22]. این به شما امکان می دهد محتوایی را که در آن تغییر اعمال شده و نوشته شده است ، مشاهده کنید!این خود اکتشافی نیست که با ارزش باشد.این یک ارتباط است بین ان اکتشافات و تصمیماتی که پیوسته میگیریم در حالی که در حال تمیز کردن کدهای نمومه­های مطالعاتی هستیم.

برای کمک به شما در رابطه با این روابط،ما یک مکانی برای ادرس مراجع در اخر کتاب قرار دادیم که نمایش میدهد شماره صفحاتی را که منابع را معرفی کردیم.شما میتوانید از استفاده کنید برای پیدا کردن هر کشفی که ما میکنیم.

اگر شما قمست های اول و سوم را خواندید و از نمونه های مطالعاتی عبور کردید،سپس شما هنوز میتوانید بخوانید کتاب "احساس خوب" در مورد نوشتن نرم افزار خوب.اما اگر شما زمان بگذارید بر روی کار روی نمونه های مطالعاتی و پیگیر گام های کوچک باشید و هر دقیقه تصمیم بگیرید و اگر شما خودتان را جای ما بگذارید و خودتان را مجبور کنید برای فکر کردن بر روی مسیر های مشابهی ما فکر کردیم شما فهم بسار زیادی از اصول ها،الگو ها ،تمرین ها و کشف ها پیدا میکنید.انها دیگر دانش خوب احساس نخواهند شد.باید انها را با قلب و روده و انگشت خود درک کنید.انها به همان روش بخشی از شما تبدیل خواهند شد که سوار شدن بر روی دو چرخه توسعه پیدا میکند شما استاد میشوید در چگونه سوار شدن روی آن.

تشکرها

از دو هنرمند متشکرم Jeniffer Kohnke و Angela Brooks. Jennifer مسئولیت دارد برای تصاویر خیره کننده و خلاق در ابتدای هر فصل و همچنین برای پرتره ها کنت بک ، بند کانینگهام ، بیارن استروستروپ ، ران جفری ، گرادی بوچ ، دیوتوماس ، مایکل پرها و خودم شرکت کردیم.

این صفحه عمدا خالی مانده است.

در پوشش

تصویر روی جلد [M104] است:ستاره کلاه.M104 در Virgo واقع شده درست در فاصله 30 میلیون سال نوری از ما. در هسته آن یک سیاه چاله فوق العاده با وزن حدود یک میلیارد توده خورشیدی است.ایا تصویر یادآور انفجار قدرتمند ماه کلینگون پرکسیس است؟من به وضوح صحنه ای را در Star Trek VI به یاد می آورم که یک حلقه استوایی از آوار را نشان می داد كه از آن انفجار دور می شدند.چون آن صحنه حلقه استوایی یک یک چیز مصنوعی و معمولی بود در انفجار فیلم­های تخیلی.حتی در نسخه های بعدی اولین فیلم جنگ ستارگان به انفجار Alderran اضافه شد.

چه چیزی باعث شده تا این حلقه در اطراف M104 شکل بگیرد؟چرا این یک برامدگی بزرگ مرکزی شبیه یک هسته کوچک و نورانی دارد؟به نظرم این یک سیاه چاله مرکزی است که حالش را از دست داده و وسط کهکشان سوراخ 30000 سال نوری را منفجر کرد.وای بر هر تمدنی که در مسیر ان اختلال کیهانی که رخ داده است قرار بگیرد.

سیاه چاله های فوق العاده ستارگان را برای نهار می بلعند،بخش قابل توجهی از جرم آنها را به انرژی تبدیل می کند. E = MC2 به اندازه کافی نیرو دارد ، اما وقتی M جرم ستاره ای است:پس مراقب باش! قبل از اینکه هیولا سیر بشود ، چند ستاره بی سر و پا در آن افتاده اند؟آیا می توان اندازه خلاء مرکزی را تصور کرد؟

تصویر M104 روی جلد ترکیبی است از تلسکوپ نوری مشهور هابل و و تصویر مادون قرمز اخیر از رصدخانه مدار Spitzer است. این مادون قرمز است،تصویری که به وضوح ماهیت حلقه را به ما نشان می دهد از کهکشان. در نور مرئی ما فقط می بینیم لبه جلوی حلقه را در تاریکی. برآمدگی مرکزی بقیه حلقه را مبهم می کند. اما در مادون قرمز ، ذرات داغ حلقه از طریق برآمدگی مرکزی می درخشد.ترکیب دو تصویر به نشان میدهد چیزی را که قبلا دیده نشده بود و یک دوزخ قبلا در ان فعال بوده است.

این صفحه عمدا خالی مانده است.

کد تمیز

شما این کتاب را به دو دلیل می خوانید. اول ، شما یک برنامه نویس هستید،دوم شما میخواهید یک برنامه نویس بهتر بشوید.خوب.ما به برنامه نویس های بهتری نیاز داریم.

این کتاب در مورد برنامه نویسی خوب است.این پر از کد است.ما کد را از بالا به پایین آن نگاه خواهیم کرد ، از بالای صفحه به پایین ، و از طریق آن از داخل به بیرون از هر جهتی به ان نگاه کنیم.تا زمانی که تمام شود.ما میخواهیم یک مقداری در مورد کد بدانیم.دیگه چی،ما میتوانیم تفاوت بین کد خوب و کد بد را بیان کنیم.ما میخواهیم بدانیم چطور یک کد خوب را بنویسیم.و میخواهیم بدانیم چطور یک کد بد را به یک کد خوب تبدیل کنیم.

انجا کد خواهد بود

ممکن است کسی استدلال کند که یک کتاب در مورد کد به نوعی عقب مانده است - این کد دیگر مسئله طولانی نیست: که باید نگران مدلها و الزامات دیگری بجای آن باشیم. در واقع برخی پیشنهاد کرده اند که ما به پایان کد نزدیک هستیم.

به زودی همه کد ها به جای نوشته شدن تولید می شوند.دیگر به سادگی به این برنامه نویسان نیازی نخواهند داشت زیرا افراد تجاری برنامه هایی را با توجه به مشخصات از قبل تولید میکنند.

مزخرفه!ما هرگز از دست کد رها نمیشویم،زیرا کد جزییات درخواست های مورد نیاز را به ما نشان میدهند.در بعضی موارد نمیتوان جزییات را نادیده گرفت یا بیخیال شد،انها باید مشخص شوند.مشخص کردن درخواست با جزییات که ماشین بتواند انرا اجرا کند برنامه نویسی است.چنین مشخصاتی کد است. انتظار دارم سطح انتزاعی زبانهای برنامه نویسی ما همچنان در حال افزایش باشد. همچنین انتظار دارم که تعداد زبانهای دامنه ای خاص به رشد خود ادامه دهند.این چیز خوبی خواهد بود.ولی کد را حذف نمیکند. در واقع ، تمام مشخصات نوشته شده در این سطح بالاتر و خاص با دامنه کد خواهد بود! هنوز هم باید سختگیرانه ، دقیق و آنقدر رسمی و باجزییات باشد تا یک دستگاه بتواند آن را بفهمد و

اجرای آنرا اجرا کند.

افرادی که فکر می کنند یک روز کد از بین می رود مانند ریاضی دانانی هستند که یک روز امیدوارند یک فرمول ریاضی را کشف کنند که لازم نیست روی ان فکر کنند. آنها امیدوار هستند که ما روزی راهی برای ایجاد ماشینهایی کشف کنیم که بتوانند کاری را که می خواهیم انجام دهیم تا آنچه که می گوییم انجام دهند. این دستگاه ها باید بتوانند ما را به خوبی درک کنند که بتوانند نیازهای مبهم را به برنامه هایی کاملاً اجرایی تبدیل کنند که دقیقاً آن نیازها را برآورده سازند.

این هرگز اتفاق نخواهد افتاد. حتی انسان ها با تمام شهود و خلاقیت خود نتوانسته اند از احساسات مبهم مشتریان خود سیستم های موفقی بسازند. در واقع ، اگر رشته مشخصات درخواست ها چیزی را به ما آموخته باشد ، این است که درخواست های مشخص شده به اندازه کد رسمی هستند و می توانند به عنوان تست های اجرایی آن کد عمل کنند!

در واقع کد چیزی است که ما در نهایت درخواست هایمان را بیان میکنیم یا مینویسیم. ممکن است زبانهایی ایجاد کنیم که به درخواست های ما نزدیکتر باشند. ممکن است ما ابزاری ایجاد کنیم که به ما کمک کند آن دسته از درخواست ها را در ساختارهای رسمی تبدیل کنیم. اما ما هرگز دقت لازم را از بین نمی بریم ، بنابراین همیشه کد وجود خواهد داشت.

کد بد

من اخیرا مقدمه ای در کتاب Kent Beck’s در مورد ساختار های پیاده سازی خواندم.او میگوید این کتاب بر اساس یک فرضیه ضعیف ساخته شده است:که کد خوب دارای اهمیت است.

فرضیه ضعیف؟من مخالفم. من فکر می کنم که این فرضیه یکی از قوی ترین ، پشتیبان و پربارترین فرضیه های موجود در کاردستی ما است (و فکر می کنم کنت آن را می داند).بدانید کد های خوب مهم هستند زیرا مجبوریم با فقدان انها برای مدت طولانی کنار باییم.

من ميدانم يكي از شركت ها در اواخر دهه 80 يك برنامه مخرب نوشت. بسیار محبوب بود و تعداد زیادی ازمتخصصان آن را خریداری و استفاده کردند. اما پس از آن چرخه انتشار شروع به گسترش کرد.اشكالات در نسخه جديد تر تعمير نميشدند.زمان بار برنامه بيشتر شد و برنامه بيشتر كرش ميكرد. یاد روزی می افتم که محصول را با ناامیدی خاموش کردم و هرگز دوباره ازش استفاده نكردم.ان شركت زمان كوتاهي بعد از ان از تجارت خارج شد. دو دهه بعد با یکی از کارمندان اولیه آن شرکت آشنا شدم و از او پرسیدم چه اتفاقی افتاده است.جواب او ترس هاي مرا تاييد كرد.انها عجله كردند در عرضه برنامه به بازار و حجم زيادي از كد هاي كثيف در ان بود. هرچه اضافه كردن ویژگی ها بیشتر و بیشتر می شدند ، کد بدتر و بدتر می شد تا اینکه دیگر نتوانستند آن را مدیریت کنند.اين كد بد بود كه شركت را خراب كرد.

ايا تا به حال به طور قابل ملاحضه اي از نوشتن كد بد جلوگيري كرده ايد.اگر شما برنامه نويس با هر تجربه اي هستيد حتما بارها اين مانع را احساس كرده ايد. در واقع ، ما یک نام برای آن داریم. ما آن را Wading می نامیم.

ما از کد بد عبور می کنیم. از میان بوته‌های درهم‌پیچیده و دام‌های پنهانی گذشتیم. ما در تلاش برای یافتن راه خود هستیم ، به امید برخی از سرنوشت ،مدرك ها از آنچه اتفاق می افتد. اما تنها چیزی که می بینیم کد بی معنی بیشتر است.اين يكي از دليل هايي است كه شما را از نوشتن كد بد مانع شده. بنابراین پس چرا آن را نوشتید؟آیا شما سعی می کنید به سرعت پیش بروید؟شما عجله داشتيد؟احتمالا همينطور است. شاید احساس کردید که وقت کافی برای انجام یک کار خوب ندارید. رئیس شما از اینکه زمان را برای تمیز کردن كد استفاده کنید عصبانی خواهد شد. شاید شما فقط از کار کردن روی این برنامه خسته شده اید و می خواستید این کار تمام شود. یا شاید هم به اون موضوع هاي جمع شده که قول داده بودی انجام بدی نگاه کردی و متوجه شدی که باید این ماژول رو با هم به هم بزنی تا بتونی حرکت کنی . همه ما این کار را انجام داده ایم و تجربه كرده ايم. همه ما به افتضاحی که درست کردیم نگاه کردیم و بعد تصمیم گرفتیم که درست كردن آن را برای یک روز دیگر بگذاریم . همه ما احساس آسودگی كرديم که برنامه آشفته ما کار می‌کند و تصمیم‌گیری می‌کند که یک آشفتگی کاری بهتر از هیچی است .

همه ما گفتیم که بعداً برمی گردیم و بعداً آن را تمیز می کنیم. البته ، در آن روزها ما قانون LeBlanc را نمی دانستیم: بعداً هرگز برابر با الان نیست.

كل هزينه داشتن يك سربار

اگر شما بيشتر از دو يا سه سال است كه برنامه نويس هستيد، احتمالا ً به طور قابل‌توجهی کد نامرتب شما کاهش پیدا کرده‌ است. اگر شما بيشتر از دو يا سه سال است كه برنامه نويس هستيد،احتمالا با كدهاي اشفته سرعتت كم شده است. میزان کاهش سرعت می‌تواند قابل‌توجه باشد. طی یک یا دو سال ، تیم هایی که در ابتدای یک پروژه بسیار سریع در حال حرکت بودند ، می توانند خود را با سرعت حلزون در حال حرکت مقايسه کنند. هر تغییری که به کد می‌دهند دو یا سه بخش دیگر کد را می‌شکند . هیچ تغییری جزئی نیست. هر نوع افزودن یا تغییر به سیستم نیازمند این است که گره‌های درهم ، پیچيده ، و گره‌ها قابل‌درک باشند به گونه‌ای که پیچ و گره‌های دیگر را بتوان اضافه کرد. با گذشت زمان هرج و مرج به قدری بزرگ و عمیق و آنقدر عمیق است که نمی‌توانند آن را پاک کنند .هيچ راهي براي انها نيست. همانطور که این آشفتگی شکل می‌گیرد ، بهره‌وری تیم کاهش ميابد، به طور مجانبی نزدیک به صفر مي رسد. همانطور که بهره‌وری کاهش می‌یابد، مدیریت تنها چیزی که می‌تواند انجام می‌دهد ؛ اين است كه به امید افزایش بهره‌وری کارکنان بیشتری را به پروژه اضافه كنند . اما این که کارکنان جدید در طراحی سیستم خبره نیستند. آن‌ها تفاوت بین تغییری را نمی‌دانند که با نیت طراحی مطابقت می‌کند و تغییری که قصد طراحی را خنثی می‌کند . علاوه بر این ، آن‌ها و هر کس دیگری در تیم تحت فشار وحشتناکی برای افزایش بهره‌وری هستند . بنابراین همه آن‌ها بیش از پیش در معرض آشفتگي قرار می‌گیرند ، و بهره‌وری را بیشتر به سمت صفر سوق می‌دهند.

طراحي مجدد در آسمان

سرانجام تیم سركش . آن‌ها به مدیریت اطلاع می‌دهند که نمی‌توانند به توسعه در این قانون نفرت‌انگیز ادامه دهند . آن‌ها خواستار طراحی مجدد هستند. مدیریت نمی‌خواهد منابع را صرف طراحی مجدد کامل پروژه کند ، اما آن‌ها نمی‌توانند انکار کنند که بهره‌وری بسیار وحشتناک است (مخصوصا در اين ساختار). سرانجام به تقاضاهای سازندگان سر خم میكنند و به طراحی مجدد بزرگ در آسمان اجازه می‌دهند. یک تیم جدید ببر انتخاب می‌شود . همه می‌خواهند در این تیم حضور داشته باشند چون پروژه كامل و درست است . آن‌ها شروع به کار می‌کنند و یک چیز واقعا ً زیبا ایجاد می‌کنند . اما بهترین و درخشان‌ترین آن‌ها برای تیم ببر انتخاب می‌شوند . هر کس دیگری باید به حفظ سیستم کنونی ادامه دهد . اکنون دو تیم در یک مسابقه هستند . تیم ببر باید یک سیستم جدید بسازد که هر کاری که سیستم قدیمی انجام می‌دهد را انجام دهد . نه تنها آن ، بلکه باید تغییراتی را که به طور مداوم به سیستم قدیمی تبدیل می‌شوند ، حفظ کنند . مدیریت تا زمانی که سیستم جدید بتواند همه کارهایی که سیستم قدیمی انجام می‌دهد را انجام دهد ، سیستم قدیمی را جایگزین نخواهد کرد . این مسابقه برای مدتی طولانی می‌تواند ادامه پیدا کند . ۱۰ سال طول می‌کشه . و تا زمانی که این کار در حال انجام باشد ، اعضای اصلی تیم ببرها خیلی وقت پیش رفته‌اند و جلو زده اند و اعضای فعلی درخواست کرده‌اند که سیستم جدید دوباره طراحی شود چون این خیلی اشفته است . اگر شما حتی یک قسمت کوچک از داستانی که گفتم را تجربه کرده‌اید ، می‌دانید که زمان خرج کردن برای تمیز نگه داشتن کد شما تنها مقرون‌به‌صرفه نیست ؛ این یک مساله زنده ماندن حرفه‌ای است.

نگرش

آیا تا به حال از میان آن شلوغی که هفته‌ها طول می‌کشید تا کاری را که باید چند ساعت طول بکشد سپری کرده‌اید ؟ آیا دیدید که چه چیزی باید یک تغییر یک خطي باشد ، به جای آن در صدها ماژول های مختلف ان تغيير ایجاد شود ؟ این نشانه‌ها بسیار رایج هستند . چرا این اتفاق برای کد می‌افتد ؟ چرا کدي خوب به سرعت به کد بد تبدیل می‌شود ؟ ما توضیحات زیادی برای آن داریم . ما شکایت می‌کنیم که درخواست ها به روش‌هایی که طراحی اصلی را خنثی می‌کنند تغییر کرده‌است . برنامه‌هایی را که برای انجام کارها بسیار ضعيف بودند را تنظیم کردیم .ما درباره مدیران احمق و مشتریان متعصب و انواع بازاریابی بی‌فایده و ضد عفونی‌کننده‌های دست صحبت می‌کنیم . اما اقاي عزیز ، تقصیر ما نیست ، بلکه در خود ما است .ما غیر حرفه‌ای هستیم.این ممکن است یک قرص تلخ برای قورت دادن باشد . چطور ممکن بود این مساله تقصیر ما باشد ؟ شرایط مورد نیاز چیست ؟ برنامه چی ؟ در مورد مدیران احمق و انواع بازاریابی بی‌مصرف چه ؟ آن‌ها مقصر نیستند ؟نه ، مدیران و بازاریابان به دنبال اطلاعاتی هستند که آن‌ها باید به وعده‌ها و تعهدات عمل کنند ؛ و حتی وقتی به ما نگاه نمی‌کنند ، ما نباید از گفتن چیزهایی که فکر می‌کنیم خجالت بکشیم . کاربران به ما نگاه می‌کنند تا روشی را که درخواست ها در سیستم مناسب هستند را تایید کنند . مدیران پروژه به ما نگاه می‌کنند تا به کار در برنامه کمک کنند .

ما عمیقا ً در برنامه‌ریزی پروژه شریک هستیم و مسئولیت بزرگی برای هر شکست داریم , به خصوص اگر این شکست‌ها با کد بد انجام شود !

اما صبر کنید " شما می‌گویید " اگر من کاری را که مدیر من می‌گوید انجام ندهم ، اخراج خواهم شد .

بسیاری از مدیران حقیقت را می‌خواهند ، حتی اگر مانند آن عمل نکنند . بسیاری از مدیران کد خوبی می‌خواهند ، حتی زمانی که درگیر برنامه هستند . آن‌ها ممکن است از برنامه و درخواست هاي مورد علاقه خود دفاع کنند ؛ اما این کار آن‌ها است . این وظیفه شماست که از این قانون با شور و شوق برابر دفاع کنید . برای رانندگی این نقطه به خانه , اگر شما یک دکتر بودید و یک بیمار داشتید که از شما درخواست کرده بود تمام شستن دست‌های احمق خود را در آماده‌سازی برای جراحی متوقف کنید , چون زمان زیادی می‌برد ? واضح است که بیمار رئیس است و با این حال پزشک باید مطلقا ً با خواست او موافقت کند . چرا ? زیرا دکتر بیش از بیمار را در مورد خطرات بیماری و عفونت می‌داند . این غیر حرفه‌ای است ( هرگز حقوقي و قاننوني ) برای پزشک نیست که با بیمار مطابقت داشته باشد. بنابراین اين برای برنامه نویسان غیر حرفه‌ای است که به اراده مدیرانی که خطرات ایجاد اشفتگي را درک نمی‌کنند خم شوند .

معماي اوليه

برنامه نویسان با معمای ارزش‌های اساسی مواجه هستند . همه سازندگان با تجربه بیش از چند سال، می‌دانند که به آرامی آن‌ ارزش ها را کاهش می‌دهند . و با این حال همه سازندگان فشار را احساس می‌کنند تا برای رسیدن به مهلت‌های زمانی یکدیگر را به هم بریزند . خلاصه , آن‌ها وقت براي حركت سريع را ندارند ! متخصصان حقیقی می‌دانند که بخش دوم مشکل اشتباه است . شما با ایجاد این آشفتگی ، موعد مقرر را تعیین نخواهید کرد . در واقع ، این آشفتگی شما را به سرعت پایین خواهد برد و شما را مجبور خواهد کرد که مهلت را از دست بدهید . تنها راه ایجاد مهلت ، تنها راه رفتن سریع این است که كد را تا حد ممکن تمیز نگه دارید .

هنر کد تمیز؟

اجازه دهید بگوییم که شما باور دارید که کد آشفته یک مانع مهم است . اجازه دهید بگوییم که شما قبول می‌کنید که تنها راه رفتن سریع این است که کد خود را تمیز نگه دارید . پس باید از خودتان بپرسید : " چطور یک کد تمیز بنویسم ؟ اگر شما ندانید آن کد تمیز براي چیست , هیچ تلاشی برای نوشتن کد تميز فایده‌ای ندارد !

خبر بد این است که نوشتن کد تمیز بسیار شبیه نقاشی یک تصویر است . بسیاری از ما می‌دانیم که یک تصویر خوب یا بد نقاشی شده‌است . اما قادر بودن به تشخیص هنر خوب از بد به این معنا نیست که ما می‌دانیم چطور نقاشی کنیم . بنابراین قادر بودن به تشخیص کد تمیز از کد كثيف به این معنا نیست که ما می‌دانیم چگونه کد تمیز بنویسیم !

نوشتن کد تمیز نیاز به استفاده منظم از هزاران تکنیک کوچک به دارد که از طریق یک حس ساده از تمیزی به کار می‌رود.

بعضی از ما با آن به دنیا می‌آییم . برخی از ما باید برای بدست آوردن ان مبارزه کنیم . نه تنها به ما اجازه می‌دهد ببینیم آیا کد خوب است یا بد ، بلکه این استراتژی را به ما نشان می‌دهد که نظم و انضباط ما را برای تبدیل کد بد به کد تمیز به كا بريم.

یک برنامه‌نویس بدون " مفهوم كد " می‌تواند به یک ماژول آشفته نگاه کند و آشفتگی را تشخیص دهد اما هیچ ایده‌ای در مورد آن ندارد . یک برنامه‌نویس با " مفهوم كد " به یک ماژول آشفته نگاه خواهد کرد و گزینه‌ها و تغییرات را می‌بیند . " مفهوم كد " به این کمک خواهد کرد که برنامه‌نویس بهترین تغییر را انتخاب کرده و یا او را هدایت کند تا دنباله‌ای از رفتاری که تغییر شکل می‌دهد را ترسیم کند تا از اینجا به آنجا برسد .

به طور خلاصه ، یک برنامه‌نویس که یک کد تمیز می‌نویسد یک هنرمند است که می‌تواند یک صفحه نمایش خالی را از طریق یک سری تغییر شکل بدهد تا اینکه یک سیستم کدگذاری شود .

كد تميز چيست

احتمالا ً تعاریف بسیاری وجود دارد همانطور كه برنامه نویسان زيادي وجود دارد . بنابراین من از برخی از برنامه نویسان که به خوبی شناخته‌شده و با تجربه هستند پرسیدم که آن‌ها چه در اين مورد چه فکر می‌کنند .

Bjarne Stroustrup ، مخترع C + + و نویسنده زبان برنامه‌نویسی C + +

من از كدي خوشم می‌آید که ظریف و کارآمد باشد . منطق باید صریح باشد تا ايراد را برای اشكالات دشوار کند ، وابستگی‌های حداقل به حفظ آرامش ، کنترل خطا با توجه به یک استراتژی بيان شده است، و عملکرد نزدیک به بهینه است تا مردم را وسوسه نکند که این کدها را با بهینه‌سازی اصول اخلاقی به هم بریزد . کد تمیز یک چیز را به خوبی انجام می‌دهد .

Bjarne از کلمه شیک استفاده می‌کند . این یک کلمه است ! فرهنگ لغت من در مک بوک این تعاریف زیر را ارائه می‌کند : ظریف و شیک در ظاهر یا رفتار ; هوشمندانه و ساده . توجه داشته باشید که کلمه خوشایند است. ظاهرا ً فکر می‌کند که خواندن کد تمیز خوشایند است . خواندن باید باعث شود که شما به راه یک جعبه موسیقی خوب و یا ماشین خوب طراحی‌شده لبخند بزنید .

Bjarne همچنین دو بار به کارایی اشاره می‌کند . شاید این نباید ما را با صحبت از آمدن از مخترع C + + شگفت‌زده کند ؛ اما من فکر می‌کنم بیش از تمایل برای سرعت وجود دارد . چرخه‌های قاعدگی واقعی هستند ، اما آن‌ها خوشایند نیستند. و حالا به این کلمه توجه کنید . او از کلمه " وسوسه " استفاده می‌کند . " اینجا یک واقعیت عمیق وجود دارد . قوانین بد برای بزرگ شدن وسوسه میكنند. وقتی دیگران قانون بد را عوض می‌کنند, آن‌ها تمایل دارند اوضاع را بدتر کنند. دیو توماس و اندی هانت این را به طريق دیگری گفتند . آن‌ها از استعاره پنجره‌های شکسته استفاده می‌کردند . یک ساختمان با پنجره‌های شکسته به نظر هیچ‌کس با اهميت نيست . بنابراین افراد دیگر از ان مراقبت می‌کنند . اجازه می‌دهند پنجره‌های بیشتری شکسته شوند . در نهایت به طور پوبا آن‌ها را می‌شکنند . آن‌ها نما را با گرافیتی روشن می‌کنند و اجازه جمع‌آوری زباله را می‌دهند . یک پنجره شکسته روند رو به زوال را آغاز می‌کند.

Bjarne همچنین اشاره می‌کند که مديريت خطا باید کامل شود . این توجه به جزييات ميكند. خطای جابجایی اجباری تنها یک روش برای توجیه جزئیات خطاي برنامه نویسان است . نشت حافظه یکی دیگر از شرایط مسابقه است که هنوز هم مهم است .

ناسازگاري هنوز يكي از انها است. نتیجه این است که این کد تمیز توجه بیشتری را به جزئیات نشان می‌دهد.

Bjarne با این ادعا که کد تمیز کاری خوب انجام می‌دهد ,تمام حرف هايش بسته می‌شود . هیچ تصادفی نیست که اصول کلی طراحی نرم‌افزار وجود داشته باشد که بتوان آن را به این نصیحت ساده تبدیل کرد . نویسنده پس از تلاش نویسندگي سعی در برقراری ارتباط دارد . کد بد سعی دارد بیش از حد كار انجام دهد , هدف گیج و ابهام در هدف دارد . کد تمیز متمرکز شده‌ است . هر تابع , هر کلاس , یک نگرش با ذهنیت واحد را نشان می‌دهد که کاملا ً بدون آلودگی باقی می‌ماند و با جزئیات اطراف بدون آلودگی باقی می‌ماند .

گریدی - نویسنده تحلیل و طراحی شی‌گرا با کاربردهاي ان

کد تمیز ساده و صریح است . کد تمیز مانند نثری که به خوبی نوشته شده باشد . کد تمیز هیچ وقت قصد طراح را پنهان نمی‌کند بلکه کامل از انتزاعات شارپ و خطوط مستقیم قابل کنترل است. گریدی برخی از نقاط مشابه را در نظر می‌گیرد , اما دیدگاه قابل قبولی دارد . من ویژه او را دوست دارم که كد تميز باید مانند نثر خوب خوانده شود . به یک کتاب واقعا ً خوب فکر کنید که خوانده‌اید . به یاد داشته باشید که چگونه این کلمات با تصاویر ناپدید شدند ! مثل تماشای فیلم بود , نه ؟ بهتر است! شما شخصیت‌ها را می‌دیدید , صداهای رقت‌انگیز و شوخی را تجربه کردید . خواندن کد پاک هرگز شبیه خواندن ارباب حلقه‌ها نیست . باز هم استعاره ادبی آدم بدی نیست . همانند یک رمان خوب , کد تمیز باید تنش‌ها در مساله را به وضوح نشان دهد. آن باید این تنش‌ها را به اوج خود برساند و سپس به خواننده بگوید که آها ! البته از آنجا که مسائل و تنش‌ها در افشای یک راه‌حل مشخص حل شده‌اند .

من استفاده گرادی را از عبارت انتزاع واضح به عنوان تركيب متضاد جذاب می دانم! پس از همه ، کلمه ترد تقریباً مترادف بتن است. فرهنگ لغت مک بوک من تعریف زیر از واضح را دارد: کاملاً قاطع و از واقعیت ، بدون تردید یا جزئیات غیر ضروری. علیرغم این آمیزش ظاهراً معناي انها ، پیام قدرتمندی دارند. کد ما باید بر خلاف سفته بازی ، از واقعیت برخوردار باشد. آن باید فقط شامل آنچه که لازم است باشد. خوانندگان ما باید ما را درک کنند که قاطع بوده‌اند.

دیو توماس، بنیانگذار OTI ، پدر خوانده استراتژی کسوف

کد تمیز را می‌توان خوانده و توسط یک سازنده به غیر از مولف اصلی آن ارتقا داد . این دستگاه تست‌های واحد و پذیرش دارد . اسامی معنی‌داری دارد . این کار یک راه را به جای بسیاری از روش‌ها برای انجام یک کار فراهم می‌کند . آن وابستگی‌های حداقلی دارد ، که به طور واضح تعریف شده‌است ، و یک API شفاف و حداقلی را ارایه می‌دهد . کد باید با توجه به زبان ، با سواد باشد نه اينكه تمام اطلاعات لازم را می‌توان به طور شفاف در متن به طور واضح بیان کرد .

Big Dab تمایل گریدی به خوانایی را به اشتراک می‌گذارد ، اما با یک چرخش مهم . دیو ادعا می‌کند که این کد تمیز برای افراد دیگر آسان است تا آن را توسعه دهند. این ممکن است واضح به نظر برسد ، اما نمی‌تواند زياد مورد تاكيد باشد. پس از همه اینها ، فرق كد كه اسان خوانده ميشود اين است كه راحت تر تغيير ميكند.

Dav پاکیزگی را به تست‌ها پیوند می‌دهد ! ده سال پیش این کار باعث تعجب بسیاری می‌شد .

اما نظم توسعه محور بر صنعت ما تاثیر عمیقی می‌گذارد و یکی از اساسی‌ترین رشته‌های ما شده‌است . حق با Dav است . کد بدون آزمایش تمیز نیست . مهم نیست چقدر برازنده و قابل خواندن است , مهم نیست که چقدر خوانا و قابل تست است . دیو این کلمه را حداقل دو بار استفاده می‌کند . ظاهرا ً او به چیزی که کوچک است اشاره می‌کند ، به جای کد که بزرگ باشد . در واقع ، از زمان آغاز به کار ، این یک مانع رایج در سراسر ادبیات نرم‌افزار بوده‌است . کوچک‌تر بهتر است.

Dav همچنین می‌گوید که این کد باید با سواد باشد . این یک اشاره نرم به برنامه‌نویسی با سواد Knuth است.نتیجه این است که این کد باید به گونه‌ای تنظیم شود که توسط انسان‌ها قابل خواندن باشد .

Micheal Feathers ، نویسنده کار موثر با ارث بري در كد

من می‌توانم تمام ویژگی‌هایی را که در کد پاک به آن توجه می‌کنم را لیست کنم , اما یک کیفیت فراگیر وجود دارد که منجر به همه آن‌ها می‌شود . کد تمیز همیشه به نظر می‌رسد توسط کسی نوشته شده‌است که به ان اهميت می‌دهد .

هیچ چیز آشکاری وجود ندارد که شما بتوانید آن را بهتر کنید . همه این چیزها توسط نویسنده کد نوشته شده بودند , و اگر سعی کنید بهبودهایی را تصور کنید , و از كسي كه اين قانون ها را براي شما گذاشته و به صنعت و هنر اهميت ميدهد تشكر كنيد و به عقب باز گرديد.

یک کلمه : مراقب باشید. این موضوع واقعا ً موضوع این کتاب است . شاید زیرنویس مناسب چگونگی مراقبت از کدها باشد . مایکل به آن ضربه زد . کد پاک کدي است که از آن مراقبت شده‌است . کسی زمان را برای ساده و منظم نگه دارد .آن‌ها به جزئیات بیشتر توجه کرده‌اند . آن‌ها اهمیت داده‌اند .

ران جفریز , نویسنده برنامه‌نویسی افراطی و ماجراهای برنامه‌نویسی پيشرفته در C#

رون برنامه‌نویسی حرفه‌ای خود را از زبان فرترن در برنامه استراتژیک هوایی آغاز کرد و تقریبا ً در هر زبان و در هر ماشینی کد نوشته بود . با دقت گفته‌هایش را بررسی می‌کند.

در سال‌های اخیر , شروع و پایان دادن به قوانین ساده بک در اولویت هستند , کد ساده : تمامی تست‌ها را اجرا می‌کند; شامل تمامی ایده‌های طراحی که در سیستم هستند ; تعداد واحدهای تجاری مانند کلاس‌ها , روش‌ها , کارکردها و غیره را به حداقل می‌رساند. از اینها , من بیشتر روی تکرار تمرکز می‌کنم . وقتی یک مساله بارها و بارها انجام می‌شود , نشانه این است که ایده‌ای در ذهن ما وجود دارد که به خوبی در کد نمایش داده نمی‌شود . سعی می‌کنم بفهمم چیست . پس سعی می‌کنم این ایده را واضح‌تر بیان کنم. ايده در من شامل نام‌های معنی‌دار است , و احتمالا ً چندین بار نام همه چیز را قبل از اقامت من تغییر خواهد داد . با ابزارهای برنامه‌نویسی مدرن مانند eclipse , تغییر نام کاملا ً ارزان است , بنابراین به من اجازه تغییر نمی‌دهد .

با این حال ، Expressiveness فراتر از اسامی می‌رود . همچنین به این مساله نگاه می‌کنم که آیا یک هدف یا يك روش بیش از یک چیز را انجام می‌دهد . اگر یک شی است ، احتمالا ً باید به دو یا چند شی تقسیم شود . اگر یک روش باشد ، من همیشه از روش استخراج يا پالايش بر روی آن استفاده می‌کنم ، که منجر به یک روش کاملا ً مشخص می‌شود ، و برخی به ان ارسال كننده می‌گویند که این روش چگونه انجام می‌شود . تكثير و واضحي از من دور است به چیزی که من کد تمیز را در ان در نظر می‌گیرم ، و اصلاح کدي کثیف با این دو چیز در ذهن ، می‌تواند تفاوت بزرگی ایجاد کند. با این حال ، یک چیز دیگر وجود دارد که من از انجام دادن آن آگاه هستم ، که توضیح آن کمی سخت‌تر است. پس از سال‌ها انجام این کار ، به نظر من همه برنامه‌ها از عناصر بسیار مشابهی ساخته شده‌اند . یک مثال پیدا کردن چیزها در یک مجموعه ، چه ما یک پایگاه‌داده از سوابق کارمندان داریم ، یا یک نقشه درهم سازی از کلیدها و ارزش‌ها ، یا مجموعه‌ای از موارد از این قبیل ، ما اغلب در می‌یابیم که یک مورد خاص از این مجموعه می‌خواهیم . زمانی که این اتفاق می‌افتد ، اغلب اجرای خاص را در یک روش یا کلاس انتزاعی نشان می‌دهم . این به من چند مزیت جالب می‌دهد . من می‌توانم قابلیت را در حال حاضر با چیزی ساده ، مثلا ً یک نقشه درهم ساز ، اجرا کنم ، اما از آن زمان همه منابع به این جستجو با انتزاع کوچک من پوشانده شده‌اند ، من می‌توانم هر زمان که بخواهم اجرا را تغییر دهم . من می‌توانم به سرعت به جلو حرکت کنم ، در حالی که توانایی خود برای تغییر بعد را حفظ می‌کنم. علاوه بر این ، انتزاع جمع‌آوری اغلب مرا به چیزی که واقعا ً اتفاق می‌افتد و توجه من به ان است صدا ميكند ، و من را از دویدن در مسیر اجرای رفتار جمعي دلخواه نگه می‌دارد وقتی که تمام چیزی که واقعا ً نیاز دارم توسط چند روش ساده برای پیدا کردن چیزی است که من می‌خواهم .کاهش تکرار ، بیانگری بالا و ساخت اولیه انتزاعی ساده .این چیزی است که برای من قانون پاک می‌سازد .در اینجا , در چند پاراگراف کوتاه , Ron مطالب این کتاب را خلاصه کرده‌است . بدون تکرار , یک چیز , بیانگری , انتزاع کوچک . همه چیز آنجاست

Ward cunningham، مخترع ویکی ، مخترع Fit، مخترع برنامه نویسی exterm. نیروی انگیزه در پشت الگوهای طراحی.

Smaltalkو رهبر فکر .OO پدرخوانده همه کسانی که به کد اهمیت می دهند.

شما می‌دانید که در حال کار بر روی کد تمیز هستید ، زمانی که هر روتین که مطالعه می‌کنید تقریبا ً همان چیزی است که شما انتظار داشتید . شما می‌توانید آن را کد زیبا صدا کنید وقتی که کد هم چنین به نظر می‌رسد که زبان برنامه نويسي برای این مشکل ساخته شده‌است . اظهاراتی مانند این ویژگی حصار شده است .آن را بخوانید ، سرتان را تکان دهید، و سپس به موضوع بعدی بروید . خیلی منطقی به نظر می‌رسد ، خیلی واضح است که به سختی می‌تواند به عنوان چیزی عمیق ثبت شود . شما ممکن است فکر کنید که این تقریبا ً همان چیزی است که شما انتظار داشتید . اما اجازه بدهید دقیق‌تر نگاه کنیم .

تقریباً آنچه انتظار داشتید. آخرین باری که ماژول را دیدید تقریباً همان چیزی بود که انتظار داشتید؟ آیا به احتمال زیاد ماژول هایی که به آنها نگاه می کنید گیج کننده ، پیچیده ، درهم و برهم نیستند؟ آیا اين قاعده و قانون نادرست نیست؟ آیا شما عادت نکردید که در تلاش برای گرفتن و نگه داشتن مباحث استدلال که از کل سیستم دور می شود و راه خود را از طریق ماژولی که می خوانید بيابيد؟ کی آخرین باری بود که از طریق کد می خوانید و سر خود را به سر تکان می دادید به شکلی که ممکن است سرتان را به گفته Ward گره بزنید؟Wardانتظار دارد که وقتی یک کد تمیز می‌خوانید ، اصلا ً تعجب نخواهید کرد . در حقیقت ، شما حتی تلاش زیادی نخواهید کرد . تو آن را خواهی خواند ، و این همان چیزی است که تو انتظار داشتی . واضح است، ساده و قانع‌کننده است . هر ماژول ‌ها مرحله بعدی را تعیین می‌کنند . هر کدام از آن‌ها به شما می‌گوید که بعدی چگونه نوشته خواهد شد . برنامه‌هایی که تمیز هستند آنقدر به خوبی نوشته شده‌اند که حتی به آن توجه ندارید . طراح آن به طرز مسخره‌ای مثل همه طراحی‌های استثنایی ساده به نظر می‌رسد . و در مورد مفهوم زیبایی Wardچه ؟ همه ما مخالف این حقیقت بودیم که زبان ما برای مشکلات ما طراحی نشده است . اما بیانیه وارد مسئولیت را بر دوش ما می‌گذارد .او می‌گوید که این کد زیبا باعث می‌شود که زبان به نظر برسد که برای این مشکل ساخته شده‌است. بنابراین مسئولیت ما این است که زبان را ساده جلوه دهیم. افراد متعصب در همه جا ، مراقب باشید ! این زبانی نیست که برنامه‌ها را ساده جلوه می‌دهد . این یک برنامه‌نویس است که زبان را ساده می‌کند.

مكاتب فكري : من ( عمو باب ) چی ؟ کد پاک چیست ؟ این کتاب با جزئیات بدي به شما خواهد گفت که من و هم وطنان من در مورد قوانین پاک چه فکر می‌کنند . ما به شما خواهیم گفت که چیزی که فکر می‌کنیم یک نام متغیر تمیز است , یک تابع تمیز , یک کلاس تمیز , و ما این نظرات را به عنوان مطلق ارائه می‌کنیم , و ما از درخواست مان عذرخواهی نمی‌کنیم .در این نقطه در حرفه ما , آن‌ها مطلق هستند . آن‌ها مكتب ما در مورد قوانین پاک هستند .هنرمندان مارتیالیس در مورد بهترین هنرهای رزمی یا بهترین تکنیک در یک هنر رزمی اتفاق‌نظر ندارند . اغلب هنرمندان نظامی مدارس فکری خود را شکل خواهند داد و دانش آموزان را گرد هم خواهند آورد تا از آن‌ها درس بگیرند . پس ما گارسیا را می‌بینیم که توسط يك خانواده در برزیل تدریس و تدریس می‌شود . ما Hakkoryu Jiu را می‌بینیم که توسط Okuyama Ryuho در توکیو تاسیس و تدریس می‌شود . ما Jeet Kune را می‌بینیم که توسط بروس لی در آمریکا تاسیس و تدریس می‌شود .

دانش آموزان این رویکردها خود را در تعالیم موسس خود غوطه‌ور می‌کنند .

آن‌ها خودشان را وقف یادگیری چیزهایی می‌کنند که استاد ويژه انرا تدریس می‌کند و اغلب به استثنای هر معلم دیگری تدریس می‌کند . بعدها ، هنگامی که دانش آموزان در هنر خود رشد می‌کنند ، ممکن است به دانش آموزان یک استاد دیگر تبدیل شوند تا بتوانند دانش و عمل خود را وسعت بخشند .برخی در نهایت به اصلاح مهارت‌ها ، کشف تکنیک‌های جدید و تاسیس مدارس خود ادامه می‌دهند .هیچ کدام از این مدارس مختلف کاملا ً درست نیستند . با این حال ، در یک مدرسه خاص ، ما طوری رفتار می‌کنیم که انگار ان و تکنیک‌ها درست هستند . به هر حال ، یک روش درست برای تمرین جیو - جیتسو Jiu یا Jeet Kune وجود دارد . اما این درستی در مدرسه ، تعالیم یک مدرسه متفاوت را تایید نمی‌کند . این کتاب را به عنوان شرحی از مدرسه راهنمایی شی گرا در نظر بگیرید . تکنیک‌ها و تعالیم در داخل روشی هستند که ما هنر خود را تمرین می‌کنیم . ما می‌خواهیم ادعا کنیم که اگر از این آموزه‌های پیروی کنید ، از مزایایی که ما از آن بهره‌مند شده‌ایم بهره‌مند خواهید شد و شما یاد خواهید گرفت که کد نوشتاری را که تمیز و حرفه‌ای است بنویسید . اما اشتباه فکر نكنيد که ما به نوعی حق مطلق را داریم . مدارس دیگری هم وجود دارند و استادان دیگر هم به همان اندازه که ما ادعا می‌کنیم حرفه‌ای گری دارند . به شما کمک می‌کند که از آن‌ها نیز یاد بگیرید . در واقع ، بسیاری از توصیه‌ها در این کتاب بحث‌برانگیز هستند . احتمالا ً با همه آن‌ها موافق نیستید . ممکن است به شدت با برخی از آن‌ها مخالفت کنید . خوبه .ما نمی‌تونیم ادعا کنیم که قدرت نهایی رو داریم . از سوی دیگر ، توصیه‌های این کتاب چیزهایی هستند که ما در مورد آن فکر کرده‌ایم . ما آن‌ها را از طریق چندین دهه تجربه و آزمایش و خطا یاد گرفته‌ایم . پس فرقی نمی‌کند که شما موافق باشید و یا موافق باشید ، این شرم‌آور خواهد بود اگر شما دیدید و احترام بگذارید به نقطه‌نظر ما .

ما نويسندگان هستيم

فیلد نویسنده یک Javadoc به ما می‌گوید که چه کسی هستیم . ما authors . و یک چیز در مورد نویسندگان این است که آن‌ها خوانندگان دارند . در واقع ، نویسندگان مسیول برقراری ارتباط خوب با خوانندگان هستند . دفعه بعد که یک خط کد می‌نویسید ، به یاد داشته باشید که شما یک نویسنده هستید و برای خوانندگان می‌نویسید که تلاش شما را داوری خواهند کرد. ممکن است بپرسید : کد واقعا ً خوانده می‌شود ؟ آیا تلاش بیشتر برای نوشتن آن انجام نمی‌شود ؟

آیا تا به حال یک جلسه ویرایش را اجرا کرده‌اید ؟ در دهه ۸۰ و ۹۰ میلادی ما ويراستاران مثل Emacs داشتیم که هر keystroke را پی‌گیری می‌کرد . شما می‌توانید یک ساعت کار کنید و سپس کل جلسه ویرایش خود را مانند یک فیلم با سرعت بالا باز کنید . وقتی این کار را کردم ، نتایج بسیار جالب بودند .قسمت اعظم ماژول در حال حرکت دادن و مرور به بخش‌های دیگر بود !

باب وارد ماژول شد .

او طومارهای زیادی را به سمت تابع نیاز داشت .

مکث می‌کند و به انتخاب گزینه‌ها فکر می‌کند .

اوه ، او به بالای مدول می‌رود تا مقدار دهی یک متغیر را بررسی کند .

او شروع به نوشتن کرد و شروع به تایپ کردن کرد

او دارد آنچه را که تایپ می‌کند پاک می‌کند !

او دوباره این کار را انجام می‌دهد.

پاک می کنه!

او نیمی از چیز دیگر را تايپ ميكند ، اما آن را پاک می‌کند

او به سمت یک تابع دیگر رفت که تابع را فراخوانی می‌کند تا ببیند به چه چیزی گفته می‌شود .

او طومارهای زیادی را برداشت و همان کد را که پاک شده بود تایپ کرد .

مکث می‌کند .

باز هم آن كد را پاک می‌کند !

یک پنجره دیگر ظاهر ميشود و به یک زیر رده نگاه می‌کند . آیا این تابع رو به کاهش خواهد بود ؟

شما اجرايش می کنید. در واقع ، نسبت زمان صرف خواندن در مقابل نوشتن بیش از 10: 1 است.

ما به عنوان بخشی از تلاش برای نوشتن کد جدید ، دائماً در حال خواندن کد قدیمی هست.

از آنجا که این نسبت بسیار زیاد است ، می خواهیم خواندن کد آسان باشد ، حتی اگر این کار نوشتن را سخت تر کند. البته هیچ راهی برای نوشتن کد بدون خواندن آن وجود ندارد ، بنابراین خواندن آسان در واقع نوشتن آن را آسان تر می کند. از این منطق گریزی وجود ندارد. اگر نمی توانید کد اطراف را بخوانید ، نمی توانید کد بنویسید. کدی که می خواهید امروز بنویسید بسته به اینکه خواندن کد اطراف آن چقدر سخت یا آسان باشد نوشتن آن دشوار یا آسان خواهد بود. بنابراین اگر می خواهید به سرعت پیش بروید ، اگر می خواهید سریع کار خود را انجام دهید ، اگر می خواهید کد شما به راحتی نوشته شود ، خواندن آن را آسان کنید.

قانون اسكات

این برای نوشتن این کد به اندازه کافی کافی نیست . این کد باید در طول زمان تمیز نگه‌داشته شود . همه ما تا به حال كدي را دیده‌ایم و با عبور زمان تنزل پیدا می‌کنیم . بنابراین ما باید نقش فعالی در پیش‌گیری از این تخریب ایفا کنیم .پسران پیشاهنگ آمریکا یک قانون ساده دارند که ما می‌توانیم به حرفه خود اعمال کنیم .محل اردوگاه را تمیزتر از آنچه پیدا کردید بگذارید. اگر ما همه چیز را بررسی کنیم کد ما کمی تمیزتر از زمانی است که آن را بررسی کردیم ، این کدها نمی‌توانند فاسد شوند . تمیز کردن یک چیز بزرگ نیست . یک نام متغیر را برای بهتر شدن تغییر دهید ، یک عملکرد را بشکنید که کمی بزرگ است ، یک بیت از تکرار را حذف کرده، یک ترکیب را در صورت بیان تمیز کنید. آیا می توانید تصور کنید که با گذشت زمان ، روی پروژه ای کار می کنید که کد به سادگی بهتر شود؟ آیا معتقدید که هیچ گزینه دیگری حرفه ای است؟ در واقع ، آیا پیشرفت مداوم جزء ذاتی حرفه ای بودن نیست؟

اصول و قواعد

از بسیاری جهات ، این کتاب "مقدمه" کتابی است که من در سال 2002 با عنوان توسعه نرم افزار چابک: اصول ، الگوهای و عملکردها (PPP) نوشتم. کتاب PPP خود را با اصول طراحی شی گرا و بسیاری از شیوه هایی که توسط توسعه دهندگان حرفه ای استفاده می شود ، نگران می کند. اگر PPP را نخوانده اید ، ممکن است متوجه شوید که این داستان را که توسط این کتاب گفته شده است ادامه می دهد. اگر قبلاً آن را خوانده اید ، بسیاری از احساسات آن کتاب را که در این کد وجود دارد ، در سطح کد مشاهده خواهید کرد.

در این کتاب اشاراتی پراکنده به اصول مختلف طراحی خواهید یافت. اینها شامل اصل تك مسئولیتي SRP، اصل بسته باز OCPو اصل وارونگی وابستگی DVدر میان دیگر اصل ها است است. این اصول در عمق PPP شرح داده شده است.

نتيجه گيري

کتابهای مربوط به هنر قول نمی دهند شما را به یک هنرمند تبدیل کنند. تمام کاری که آنها می توانند انجام دهند این است که برخی از ابزارها ، تکنیک ها و فرآیندهای تفکر را که سایر هنرمندان استفاده کرده اند به شما ارائه می دهد. بنابراین این کتاب نیز نمی تواند قول دهد شما را به یک برنامه نویس خوب تبدیل کند. این نمی تواند قول بدهد که به شما "مفهوم کد" بدهد.

تمام کارهایی که می تواند انجام دهد این است که فرآیندهای فکری برنامه نویسان خوب و ترفندها ، تکنیکها و ابزارهایی را که آنها استفاده می کنند به شما نشان دهد. درست مانند یک کتاب در زمینه هنر ، این کتاب پر از جزئیات خواهد بود. تعداد زیادی کد وجود دارد کد خوبی و کد بدي را خواهید دید. کد بد را به کد خوب تبدیل می کنید. لیست های اکتشاف ، رشته ها و تکنیک ها را مشاهده خواهید کرد. بعد از اين مثال انرا می بینید پس از آن ، همه چيز به شما بستگی دارد.

شوخی قدیمی ویولن نواز کنسرت را که در مسیر ويولن خود از دست داده بود به خاطر بسپارید ؟ یک پیرمرد را در گوشه اتاق متوقف کرد و از او خواست به سالن کارنگی برود .

پیرمرد به ویولن نواز و ویولن زیر بغل نگاه کرد و گفت : تمرین کن پسر . تمرین !

این صفحه به عمدخالي گذاشته شده است

نام هاي معني دار

مقدمه

اسامی همه جا در نرم‌افزار وجود دارد . ما متغیرهای ما ، توابع ما ، استدلال‌های ما ، کلاس‌ها و بسته‌ها را نام می‌بریم . ما فایل‌های منبع و شاخه‌های حاوی آن‌ها را نام می‌بریم . پرونده‌های jar و پرونده‌های جنگ و پرونده‌های گوش را نام می‌بریم . نام و نام و نام...

چون ما خیلی از این کارها را انجام می‌دهیم ، بهتر است این کار را به خوبی انجام دهیم . در زیر برخی از قوانین ساده برای ایجاد نام‌های خوب آورده شده‌است .

استفاده از نام ها قصد را مشخص ميكند

به راحتی می توان گفت که اسامی باید قصد را آشکار کنند. آنچه می خواهیم شما را تحت تأثیر قرار دهد این است که ما در این باره جدی هستیم. انتخاب نام های خوب به زمان نیاز دارد اما بیشتر از زمان لازم صرفه جویی می کند.

بنابراین در هنگام یافتن نامهای بهتر مراقب نام خود باشید و آنها را تغییر دهید.اگر اين را انجام دهيد هر کس کد شما را بخواند (از جمله خود شما) خوشحال تر خواهید شد. نام یک متغیر ، عملکرد یا کلاس باید به تمام سوالات بزرگ پاسخ دهد. باید به شما بگوید که چرا وجود دارد ، چه کاری انجام می دهد و چگونه استفاده می شود. اگر یک نام نیاز به اظهار نظر داشته باشد ، آنگاه نام قصد خود را نشان نمی دهد.

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;

}

چرا سخت است بگویید این کد چیست؟ هیچ عبارات پیچیده ای وجود نداردفاصله و تورفتگی معقول است. فقط سه متغیر و دو ثابت ذکر شده است. حتی کلاس های فانتزی یا روش های چند شکل وجود ندارد ، فقط لیستی از آرایه ها (یا حداقل اينطور به نظر می رسد).

مشکل فقط سادگی کد نیست بلکه مفهوم کد (معنای سکه کردن یک عبارت) است: درجه ای که متن در خود کد صریح نیست. کد به طور ضمنی ایجاب می کند که ما پاسخ سؤالاتی از قبیل:

1. چه مواردی در لیست وجود دارد؟

2. اهمیت اشتراک صفر یک مورد در لیست چیست؟

3. اهمیت ارزش 4 چیست؟

4. چگونه می توانم از لیست برگردان شده استفاده کنم؟

پاسخ به این سوالات در نمونه کد وجود ندارد ، اما ممکن است باشد . بگویید که ما در یک بازی sweeper کار می‌کنیم . ما متوجه می‌شویم که این صفحه فهرستی از سلول‌ها به نام theList است . اجازه دهید نام آن را به gameboard تغییر دهیم . هر سلول روی تخته توسط یک آرایه ساده نشان داده شده است. علاوه بر این ، ما می توانیم که zerothsubscript مکان یک مقدار وضعیت است و مقدار وضعیت 4 به معنای "پرچم دار" است. فقط با دادن نام این مفاهیم می توانیم کد را به میزان قابل توجهی بهبود بخشیم:

توجه کنید که سادگی کد تغییر نکرده است. هنوز هم دقیقاً همان تعداد عملگرها و ثابت ها ، دقیقاً با همان تعداد سطح لانه ها همراه است. اما کد بسیار واضح تر شده است. ما می‌توانیم به جای استفاده از آرایه of ، یک کلاس ساده را برای سلول‌ها بنویسیم .این می‌تواند شامل یک تابع مقصد - آشکار ( فراخوانی سیستم ) برای پنهان کردن اعداد جادویی باشد . این کار منجر به نسخه جدیدی از تابع می‌شود :

با این تغییر نام های ساده ، درک این مسئله که این اتفاق می افتد دشوار نیست. این قدرت انتخاب نامهای خوب است.

از اطلاعات نادرست خودداری کنید

برنامه نویسان باید از گذاشتن سرنخ های دروغین که معنی کد را مبهم می کند ، خودداری کنند. ما باید از کلماتی که معانی درج شده با معنای مورد نظر ما متفاوت است ، بپرهیزیم. مثلا، aix و sco ممکن است نام متغیرهای ضعیفی باشند زیرا نام آنها در سیستم عامل های یونیکس موجود است. حتی اگر شما در حال کدگذاری یک hypotenuse هستید و hp مانند یک مخفف خوب به نظر می رسد ، می تواند اطلاعاتی ناسازگار باشد.

به گروه بندی حسابها به عنوان یک لیست اشاره نکنید ، مگر اینکه در واقع یک لیست باشد.

لیست کلمات به معنای چیزی خاص برای برنامه نویسان است. اگر کانتینر موجود در حساب ها یک لیست نباشد ، ممکن است منجر به نتیجه گیری نادرست شود. بنابراین حساب گروهی یا bunchOfAccounts یا فقط حساب های ساده بهتر از انها است. در استفاده از نام‌ها آگاه باشید . چقدر طول می‌کشد تا تفاوت ظریفی بین یک شکاف در یک ماژول تشخیص داده شود و , جایی که کمی دورتر و دورتر از آن است ؟ کلمات بسیار شبیه هم هستند .

یک مثال واقعاً افتضاح از نامهای گسست آور ، استفاده از L یا حروف بزرگ O به عنوان نام متغیرها ، به خصوص در ترکیب است. البته مسئله این است که آنها به ترتیب تقریباً کاملاً مانند ثابت یک و صفر به نظر می رسند. خواننده ممکن است این تدبیر را به کار اندازد ، اما ما کدها را بررسی کردیم که در آن‌ها چنین چیزهایی فراوان بودند . در یکی از موارد ، نویسنده کد با استفاده از فونت متفاوتی پیشنهاد داد تا تفاوت‌ها آشکار باشند ، یک راه‌حل که باید برای همه توسعه دهندگان آینده به عنوان سنت شفاهی یا در یک سند نوشته شده باشد . این مشکل با قطعیت و بدون ایجاد محصولات جدید کاری توسط یک نام ساده تسخیر شده‌است .

تمایزهای معنی‌دار ایجاد کنید

برنامه نویسان برای نوشتن کد فقط برای رضایت کامپایلر یا مترجم ، مشکلاتی را برای خود ایجاد می کنند. به عنوان مثال ، از آنجا که نمی توانید از یک نام استفاده کنید تا به دو چیز مختلف در یک دامنه اشاره کنید ، ممکن است شما وسوسه شويد که یک نام را به صورت دلخواه تغییر دهید. بعضی اوقات این کار با غلط املایی انجام می شود و به وضعیت شگفت آور منجر می شود. تصحیح خطاهای املایی منجر به عدم امکان تدوین دوباره می شود.

اضافه کردن يك سری شماره یا کلمات کافی نیست ، حتی اگر کامپایلر راضی باشد. اگر نام ها باید متفاوت باشند ، معني هاي انها هم بايد متفاوت باشد.

مزیت آن بخش عظیمی از مغزهای ما است که برای مقابله با زبان گفتار تکامل یافته است. بنابراین اسامی خود را معنا دار کنید. اگر نمی توانید آن را تلفظ کنید ، نمی توانید درباره آن بحث کنید بدون اینکه مثل یک احمق صدا کنید.اين مساله به اين دليل اهميت دارد كه برنامه نويسي يك فعاليت اجتماعي است. شرکتی که من می شناسم دارای ژانرمی است (تاریخ تولید ، سال ، ماه ، روز ، ساعت ، دقیقه و دوم) بنابراین آنها در اطراف خود گفتند "gen pse emm dee aich emm ess". من یک عادت آزار دهنده دارم که همه چیز را همانطور که نوشته شده است تلفظ کنم ، بنابراین شروع به گفتن "gen-yah-muddahims" کردم. بعداً این امر توسط بسیاری از طراحان و تحلیلگران خوانده می شد و ما هنوز احمقانه به نظر می رسیدیم. اما ما شوخی کردیم ، بنابراین سرگرم کننده بود. سرگرم کننده بود یا نه ،به هر حال ما تحمل نامگذاری ضعیف را داشتیم. توسعه دهندگان جدید مجبور بودند متغیرها را برای آنها توضیح دهند و سپس به جای استفاده از اصطلاحات مناسب انگلیسی ، درمورد آن صحبت کردند. مقایسه کنید.

اکنون گفتگوی هوشمند امکان پذیر است: سلام ، مايكي ، به این سابقه نگاهی بیندازید! جدول زمانی تولید به تاریخ فردا تنظیم شده است! چطور ممکنه؟

استفاده از نام هاي قابل جستجو

نام‌های حروف و ثابت‌های عددی یک مشکل ویژه دارند که پیدا کردن آن‌ها در سراسر بدن یک متن ساده نیست . ممکن است شخصی به راحتی از MAX_CLASSES_PER_STUDENTاستقبال کند ، اما شماره 7 می تواند مشکل ساز باشد. جستجوها ممکن است رقم را به عنوان بخشی از نام پرونده ها ، سایر تعریف های ثابت و در عبارات مختلف که مقدار با مقاصد مختلف استفاده می شود ، تبدیل کنند. یکنواخت است.بدتر است وقتی تعداد ثابت تعداد زیادی باشد و ممکن است شخصی رقم هایی را جابجا کند ، در نتیجه اشکالی ایجاد می کند و همزمان از جستجوی برنامه نویس فرار می کند. به همین ترتیب ، نام e گزینه ای ضعیف برای متغیرهایی است که ممکن است یک برنامه نویس جستجو کند. این رایج ترین نام در زبان انگلیسی است و احتمالاً در هر متن در هر برنامه نشان داده می شود. در این راستا ، نام های طولانی تر نام های کوتاه تری را به خود می گیرند و هر نام قابل جستجو از نظر کد ثابت است. ترجیح شخصی من این است که نامهای تک حرف تنها می توانند به عنوان متغیرهای محلی در روشهای کوتاه استفاده شوند. طول یک نام باید به اندازه دامنه آن مطابقت داشته باشد.

اگر ممکن است یک متغیر یا ثابت در چندین مکان در یک کد مشاهده شود یا از آن استفاده شود ، ضروری است که یک اسم دوستانه براي جستجو داشته باشید. بار دیگر خودتان مقایسه کنید

توجه داشته باشید که در بالا ، یک اسم به خصوص مفید نیست اما حداقل قابل جستجو است. کد نامگذاری شده عمدتاً عملکردی طولانی تر ایجاد می کند ، اما در نظر بگیرید که پیدا کردن WORK_DAYS_PER_WEEK آسانتر از پیدا کردن همه مکانهایی که 5 مورد استفاده قرار گرفته است و لیست را فقط در مواردی با معنای در نظر گرفته شده فیلتر ميكند.

از رمزگذاری جلوگیری کنید

ما باید رمزگذاری های کافی برای مقابله با آن داشته باشیم بدون اینکه بیشتر به بار ما اضافه شود. رمزگذاری نوع یا اطلاعات دامنه به نامها ، به سادگی بار اضافی از رمزگشایی را اضافه می کند. به نظر نمی رسد که لازم باشد که هر کارمند جدید علاوه بر یادگیری بدنه رمزگذاری (که معمولاً قابل توجه است) کد دیگری را که در آن کار می کند یاد بگیرد. "این یک زبان رمزگذار دیگر است." این یک فشار روانی غیر ضروری است هنگام تلاش برای حل مسئله. نام های رمزگذاری شده به ندرت قابل تلفظ هستند و از نوع نادرست آسان هستند.

نماد های مجاور

در قدیم ، هنگامی که ما به زبان های با چالش نام کار می کردیم ، این قانون را از ضرورت و با حسرت نقض می کردیم. Fortran با ساخت حرف اول ، کد را برای نوع مجبور کرد. نسخه های اولیه BASIC فقط یک نامه به اضافه یک رقم را مجاز می کرد. نشانه مجاری HN این مسئله را به سطح کاملاً جدیدی رساند.

شبکه حقانی در ویندوز c بسیار مهم تلقی می‌شد , زمانی که همه چیز یک دسته صحیح یا یک نشانگر طولانی یا یک نشانگر خالی یا یکی از چندین اجرای " رشته " بود . کامپایلر انواع آن روزها را بررسی نکرد , بنابراین برنامه نویسان به یک چوب زیر بغل نیاز داشتند تا به آن‌ها در یادآوری انواع آن کمک کنند .

در زبان‌های جديد ، ما سیستم‌های نوع بسیار غنی‌تر داریم ، و ها این نوع را به یاد می‌آورند و اعمال می‌کنند . علاوه بر این ، گرایشی به سمت کلاس‌های کوچک‌تر و کارکرده‌ای کوتاه‌تر وجود دارد به طوری که افراد معمولا ً می‌توانند نقطه اعلام هر متغیری که استفاده می‌کنند را ببینند .

برنامه نویسان جاوا نیاز به رمزگذاری از ان نوع ندارند . اشیا به فقط تایپ می‌شوند ، و محیط‌های ویرایش به گونه‌ای پیشرفت کرده‌اند که یک خطای نوع را قبل از اینکه بتوانید یک کامپایل را اجرا کنید ، تشخیص می‌دهند ! بنابراین این روزها شبکه حقانی و دیگر شکل‌های رمز گذاری نوع به سادگی مانع از بوجود امدن مشكل هستند .

آن‌ها تغییر نام یا نوع یک متغیر ، تابع ، یا کلاس را سخت‌تر می‌کنند . خواندن کد را سخت‌تر می‌کنند . و آن‌ها این احتمال را بوجود می‌آورند که سیستم کدگذاری خواننده را گمراه کند .

PhoneNumber phoneString;

// name not changed when type changed!

عضو هاي پيشوند

شما دیگر نیازی به پیشوند متغیرهای عضو با پیشوند _M ندارید. کلاس ها و کارکردهای شما باید به اندازه کافی کوچک باشد که به آن پيشوند ها نیازی نداشته باشید. و شما باید از یک محیط ویرایش استفاده کنید که اعضا را برجسته یا رنگ بندی کند تا آنها را مشخص کند.

علاوه بر این ، افراد به سرعت یاد می‌گیرند که پیشوند ( یا پسوند ) را نادیده بگیریم تا بخش معنی‌دار نام را ببینیم . هر چه بیشتر آن را بخوانیم ، کم‌تر انرا را می‌بینیم . در نهایت پیشوندها به صورت تصادفی دیده می‌شوند و نشانگر کد قدیمی‌تر ميشوند.

واسط‌ها و پیاده‌سازی

اینها بعضی اوقات یک مورد خاص از کدگذاری‌های موجود هستند . برای مثال ، بگویید که یک کارخانه ABSTRACT برای ایجاد اشکال بسازید . این کارخانه یک رابط خواهد بود و توسط یک کلاس بتونی به اجرا در خواهد آمد . آن‌ها را با چه نامي صدا ميزنيد؟ I shapeFactory و ShapeFactory ؟ من ترجیح می‌دهم که رابط را بدون هیچ اراستگي ترک کنم . که در میان میراث امروزی معمول است ، در بهترین حالت و در بدترین اطلاعات ، حواس پرتی است. من نمی‌خواهم که کاربران بدانند که من یک رابط را به آن‌ها می‌دهم . فقط می‌خواهم آن‌ها بدانند که این یک ShapeFactory است . پس اگر من باید رابط را رمز کنم یا پياده سازي کنم ، من پیاده‌سازی را انتخاب می‌کنم . تماس گرفتن با آن ، یا حتی پياده سازي نفرت‌انگیز ، بهتر است که رابط را کدگذاری کند.

از نقشه برداری ذهنی خودداری کنید

خوانندگان نباید به طور ذهنی نام خود را به نام‌های دیگری که آن‌ها می‌شناسند ، ترجمه کنند . این مشکل به طور کلی از یک انتخاب برای استفاده از شرایط حوزه مساله و یا شرایط حوزه راه‌حل حاصل می‌شود . این یک مشکل با نام‌های متغیر تک حرفي است . مسلما ً یک شمارنده حلقه‌ای ممکن است با نام i یا k یا k نامیده شود هرچند هرگز اين كار را نكنيد اگر دامنه آن بسیار کوچک باشد و هیچ نام دیگری نمی‌تواند با آن درگیر شود . این به این دلیل است که نام‌های single برای counters حلقه سنتي هستند .

با این حال ، در بسیاری زمینه‌های دیگر ، یک نام یک حرف یک انتخاب ضعیف است ؛ این تنها مکانی است که خواننده باید به طور ذهنی به مفهوم واقعی بپردازد . دلیل دیگری برای استفاده از نام c وجود ندارد تنها به این دلیل که a و b در حال حاضر برداشته شده‌اند . به طور کلی برنامه نویسان افراد بسیار باهوش هستند. افراد باهوش گاهی دوست دارند با نشان دادن توانایی های ذهنی خود ، هوشمندي خود را نشان دهند. از این گذشته ، اگر به طور قابل اطمینان بخاطر بسپارید که r نسخه پایین url با میزبان و طرح حذف شده است ، پس باید به بسیار باهوش باشید تا انرا بفهميد. یک تفاوت بین یک برنامه‌نویس باهوش و یک برنامه‌نویس حرفه‌ای این است که حرفه‌ای درک می‌کند که واضح بودن كد شبيه يك پادشاه است . متخصصان از قدرت خود برای کد خوب و نوشتن که دیگران می‌توانند آن را درک کنند استفاده می‌کنند .

نام كلاس ها

کلاس و اشیا باید اسم اسمی یا اسمی مثل مشتری ، WikiPage ، حساب ، و AddressParser داشته باشند . از کلماتی مانند مدیر ، پردازنده ، داده ، یا اطلاعات به نام یک کلاس اجتناب کنید . نام کلاس نباید يك فعل باشد.

نام متدها

متدها باید دارای اسم اصطلاحات فعل یا فعل مانند DeletePage,PostPayment ذخیره شده باشند.

دارندگان ذسترسي ، جهش دهنده ها و محموله ها را باید بر اساس ارزش خود نامگذاری کرد و با get، set و پیشوند براساس استاندارد javabean نوشته شوند.

string name = employee.getName();

customer.setName("mike");

if (paycheck.isPosted())...

هنگام بار کردن سازندگان , از متد هاي استاتیک Factory با نام‌هایی استفاده کنید که بحث‌ها را توصیف می‌کنند . برای مثال ,

Complex fulcrumPoint = Complex.FromRealNumber(23.0);

عالي نباش

اگر اسامي هوشنمدانه باشند،آنها فقط برای افرادی که احساس طنز نویسنده را به اشتراک می گذارند ، به یاد ماندنی می شوند ، و فقط تا زمانی که این افراد شوخی را به خاطر بسپارند اين اسامي به ياد ماندني هستند. آیا آنها می دانند عملکردی به نام HoluHandGrenadeقرار است چه کاری انجام دهد؟ مطمئناً ، اين عالي است ، اما شاید در این حالت DeleteItem نام بهتری باشد. مهم ترين ارزش سرگرمي وضوح ان است.

کوتاه بودن کد اغلب به شکل محاوره یا زبان عامیانه ظاهر می شود،به عنوان مثال ، از نام whack()به معنای کشتن استفاده نکنید.از شوخي هاي وابسته به فرهنگ لغت استفاده كنيد. eatMyShorts به معناي سقط كردن نيست.

بگو منظورت چیه . منظورت اینه که چی میگی.

برای هر مفهوم یک کلمه انتخاب کنید

یک کلمه را برای یک مفهوم انتزاعی انتخاب کنید و به آن بچسبید. به عنوان مثال ، واکشی ، بازیابی و به دست آوردن به عنوان روشهای معادل کلاسهای مختلف گیج کننده است. چگونه به یاد دارید که نام متد با کدام کلاس انجام می شود؟ متأسفانه ، شما اغلب باید به خاطر داشته باشید كه كدام شركت ، گروه یا فرد كتابخانه یا كلاس را برای یادآوری كدام اصطلاح استفاده كرده است. در غیر این صورت ، شما زمان بسیار زیادی را صرف مرور در سربرگ ها و نمونه کد های قبلی می کنید. محیطهای ویرایش مدرن مانند Eclipse و IntelliJ سرنخهای حساس به متن را فراهم می کنند ، مانند لیست روشهایی که می توانید با استفاده از آن در یک شی خاص قرار دهید. اما توجه داشته باشید که این لیست معمولاً نظری را که شما در مورد عملكرد نام و لیست پارامترهای خود نوشتید به شما نمی دهد.

خوش شانس هستید اگر نام پارامترها را از اعلان هاي متد ارائه دهد. اسامی تابع ها باید به تنهایی باشند ، و آنها باید سازگار باشند تا شما بتوانید با روش صحیح و بدون کاوش های اضافی را انتخاب کنید.

به همین ترتیب ، داشتن یک کنترلر و یک مدیر و یک راننده در همان پایه کد گیج کننده است. تفاوت اساسی بین DeviceManager و ProtocolController چیست؟ چرا هر دو کنترل کننده نیستند یا هر دو مدیر نیستند؟ آیا آنها هر دو راننده هستند؟این نام باعث می شود که دو شیء از نظر نوع بسیار متفاوت باشند و همچنین داشتن کلاس­های را مختلف انتظار داشته باشید.واژگان مداوم یک پیشرفت عالی برای برنامه نویسان است که باید از کد شما استفاده کنند.

كار نكن

از استفاده از همان کلمه به دو منظور خودداری کنید. استفاده از یک اصطلاح یکسان برای دو ایده متفاوت در اصل، یک کار مشترک است.

اگر از قانون "یک کلمه در هر مفهوم" پیروی کنید ، می توانید بسیاری از کلاس ها را که مثلاً یک روش افزودنی دارند ، به پایان برسانید. تا زمانی که پارامترها و مقادیر برگشتی روشهای مختلف افزودنی از نظر معنایی معادل باشند ،مفيد است.

با این حال , ممکن است تصمیم بگیرد کلمه " ثبات " را زمانی که او در واقع به یک چيزي مفهومي اضافه نمی‌کند , استفاده کنيد . اجازه دهید بگوییم ما کلاس‌هایی داریم که در آن‌ها اضافه یا الحاق دو مقدار موجود ارزش جدیدی ایجاد خواهد کرد . حال اجازه دهید بگوییم ما در حال نوشتن یک کلاس جدید هستیم که متدي دارد که پارامتری را در یک مجموعه قرار می‌دهد . آیا باید این متد را اضافه کنیم ؟ ممکن است ثابت به نظر برسد چون ما متدهاي اضافه دیگری داریم , اما در این مورد , معانی متفاوت هستند , بنابراین باید از نامی مانند الحاق یا الحاق استفاده کنیم . اضافه کردن متد جدید یک ايهام است . هدف ما ، به عنوان نویسنده ، ایجاد کدي است مه تا جایی که ممکن است آسان باشد . ما می‌خواهیم که کد ما یک نگاه سطحی سریع باشد ، نه یک مطالعه عمیق . ما می‌خواهیم از مدل شوميز مشهور استفاده کنیم که در آن نویسنده مسول درست کردن كد خودش و نه مدل دانشگاهی است که در آن وظیفه پژوهشگر است که معنای آن را از مقاله بیرون کند .

استفاده از نام های راه حل

به یاد داشته باشید افرادی که کد شما را می‌خوانند برنامه نویسان خواهند بود . بنابراین پیش بروید و از اصطلاحات علوم کامپیوتر CS ، نام‌های الگوریتم ، نام‌های الگو ، عبارات ریاضی و غیره استفاده کنید . عاقلانه نیست که هر نام را از حوزه مشکل بگیرید چون ما نمی‌خواهیم همکاران ما مجبور شوند به عقب و جلو بروند و از مشتری بپرسند که هر نام چه معنایی دارد وقتی که آن‌ها این مفهوم را با نام دیگر و معناي ديگري می‌شناسند . نام AccountVisitor به معنی سروکار داشتن با یک برنامه‌نویس است که با الگوی بيننده آشنا است . کدام برنامه نويس نمی‌دانست a چیست ؟ کارهاي بسیار فنی زیادی وجود دارندکه برنامه نویسان باید انجام دهند. انتخاب نام‌های تکنیکی برای آن چیزها معمولامناسب‌ترین است.

استفاده از نام دامنه مشکل

وقتی "برنامه نویس" برای کاری که انجام می دهید وجود ندارد ، از این نام استفاده کنید. حداقل برنامه نویس که کد شما را حفظ کرده است می تواند از یک متخصص دامنه سوال کند منظورش چیست؟جدا کردن مفاهیم حوزه و راه حل و مسئله بخشی از کار یک برنامه نویس و طراح خوب است. کدی که ارتباط بیشتری با مفاهیم دامنه مشکل دارد باید دارای نامهایی باشد که از حوزه مسئله گرفته شده است.

متن معنی دار اضافه کنید:چند نام وجود دارد که به خودی خود معنی دار است – ولي اکثر اینها اينطور نیستند. درعوض ، باید با قرار دادن آنها در کلاسها ، کارکردها یا مکانهای نامگذاری شده ، مفهوم خود را در متن قرار دهید. وقتی همه موارد دیگر شکست بخورد ، ممکن است پیشوند نام به عنوان آخرین راه حل ضروری باشد.

تصور کنید که شما متغیری به نام firstname ، lastName ، Street ، houseNumber ، city ، state ، و zipcode دارید . به طور کلی ، کاملا ً واضح است که آن‌ها یک آدرس را تشکیل می‌دهند . اما چه می‌شود اگر شما فقط متغیر حالت را تنها در یک روش به تنهایی مورد استفاده قرار دهید ؟ آیا شما به طور خودکار استنباط می‌کنید که اینها بخشی از یک آدرس است ؟

می‌توانید با استفاده از پیشوند مفهومی به متن اضافه کنید . حداقل خوانندگان متوجه خواهند شد که این متغیرها بخشی از یک ساختار بزرگ‌تر هستند . البته راه‌حل بهتری ایجاد کلاسی به نام آدرس است . سپس , حتی کامپایلر می‌داند که متغیرها به مفهوم بزرگ‌تر تعلق دارند.

روش را در لیست 2-1 در نظر بگیرید. آیا متغیرها به یک زمینه معنی دار تر نیاز دارند؟ نام تابع تنها بخشی از متن را ارائه می دهد. الگوریتم بقیه را فراهم می کند.

پس از خواندن این تابع ، می بینید که سه متغیر ، number ، verb و pluralModifier، بخشی از پیام "guess statistics" هستند. متأسفانه ، زمینه باید استنباط شود. وقتی برای اولین بار به روش نگاه می کنید ، معنی متغیرها مات است.

عملکرد کمی طولانی است و در کل از متغیرها استفاده می شود. برای تقسیم عملکرد در قطعات کوچکتر باید یک کلاس GuessStatisticsMessage ایجاد کنیم و سه فیلد متغیر این کلاس را بسازیم. این یک زمینه واضح برای سه متغیر فراهم می کند. آنها

به طور قطع بخشی از GuessStatisticsMessage هستند. بهبود زمینه همچنین اجازه می دهد تا با شکستن آن در بسیاری از توابع کوچکتر ، الگوریتم بسیار تمیزتر شود. (به لیست 2-2 مراجعه کنید.)

متن مورد علاقه خود را اضافه نکنید

متن مورد علاقه خود را اضافه نکنید

در یک برنامه فرضی به نام " Gas Station Deluxe" , ایده بدی برای پیشوند هر کلاس با gsd وجود دارد . صراحتا , شما با ابزار خود کار می‌کنید . کلید G را تایپ کرده و کلید تکمیل را فشار دهید و با لیست یک مایلي كه خيلي طولاني است از لحاظ كد در سیستم پاداش بگیرید . عاقلانه است ؟ چرا برات سخت تره که بهت کمک کنم؟

به همین ترتیب , می‌گویند که شما یک کلاس MailingAddress را در مدل حسابداری GSD اختراع کرده‌اید , و نام آن را GSDAccountAddress گذاشته‌اید . بعدا , شما به یک آدرس پستی برای درخواست تماس مشتری خود نیاز دارید . از GSDAccountAddress استفاده می‌کنید ؟ آیا این اسم درست به نظر می‌رسد ؟ ده تا از ۱۷ نویسه اضافی یا بی‌ربط هستند .

نام کوتاه‌تر به طور کلی بهتر از نام‌های بلندتر است ، تا زمانی که واضح باشند . هیچ زمینه بیشتری را به نامی که لازم است اضافه کنید.

اسامی accountAddress و custonerAddress نام‌های زیبایی برای نمونه‌های نشانی کلاس هستند اما ممکن است نام‌های ضعیف برای کلاس‌ها باشند . آدرس یک اسم خوب برای یک کلاس است . اگر لازم باشد بین آدرس‌های MAC ، آدرس‌های پورت و نشانی‌های اینترنتی تمایز ایجاد کنم ، ممکن است PostalAddress ، MAC و URL را در نظر بگیرم . نام‌های به‌دست‌آمده دقیق‌تر هستند ، که نقطه نظر تمام نامگذاری ها است .

كلمات پاياني

سخت‌ترین چیز در مورد انتخاب نام‌های خوب این است که به مهارت‌های توصیفی خوب و یک پس‌زمینه فرهنگی مشترک نیاز دارد . این یک مساله آموزشی به جای یک مساله فنی ، کسب‌وکار و یا مدیریتي است . در نتیجه افراد زیادی در این زمینه یاد نمی‌گیرند که این کار را به خوبی انجام دهند .

مردم همچنین از ترس اینکه برخی از توسعه دهندگان دیگر اعتراض کنند ، از تغییر نام چیزها می ترسند. ما این ترس را به اشتراک نمی گذاریم و متوجه می شویم که وقتی نام ها تغییر می کنند (برای بهترشدن) واقعاً از آنها سپاسگزاریم. بیشتر اوقات ما نام کلاس ها و روش ها را به خاطر نمی آوریم. ما از ابزارهای مدرن برای مقابله با جزئیاتی از این دست استفاده می کنیم تا بتوانیم بر این نکته تمرکز کنیم که آیا کد مانند پاراگراف ها و جملات خوانده می شود ، یا حداقل مانند جدول ها و ساختار داده ها (یک جمله همیشه بهترین راه نمایش داده ها نیست). احتمالاً وقتی تغییر نام دهید ، شخصی را شگفت زده خواهید کرد ، دقیقاً مانند هر بهبود کد دیگری. اجازه ندهید که شما را در آهنگهای متوقف کند.

برخی از این قوانین را دنبال کنید و ببینید که این قوانین را بهبود خواهید داد یا خیر . اگر می‌خواهید قانون شخص دیگری را حفظ کنید ، از ابزارهای Refactoring برای کمک به حل این مشکلات استفاده کنید . این هزينه در کوتاه‌مدت پرداخت خواهد شد و در دراز مدت ان هزينه به شما بر ميگردد.