معیار خوب بودن کدهای شما چیست ؟

[ایمان اختیاری]

سلام ....خیلی وقت بود می خواستم چنین بحثی رو مطرح کنم و دغده های فکریم رو بپرسم ..
از حدود سال 75 بود که به دنیای کامپیوتر وارد شدم .. و از همون اول هم شروع کردم به برنامه نویسی .. با کمودور 64 و برنامه نویسی QBasic ... یادمه چقدر جذبش شدم و تشنه برای یادگیری ...واسه همین شروع کردم به کتاب خریدن ... اون موقع ها مثه الان اینترنتی نبود و فیلم های آموزشی و MSDN و غیره و غیره . واسه همین هر چی پول که به دست می آوردم فقط کتاب برنامه نویسی می خریدم ..سعی می کردم هر زبانی رو حداقل یه بار تجربه کنم که بالاخره توی #C موندگار شدم و اینجا احساس راحتی می کنم . اما چیزی که باعث ناراحتی و آزارم شده اینه .. می گن وقتی زیاد بخونی تازه می فهمی که هیچی بلد نیستی .. شده الان من .. من الان برام سوال شده که معیار یک کد خوب ، یک برنامه ی خوب چی هست .. بیشتر البته روی کد منظورمه .. برای یه سوال که مربوط به ASP.Net بود گذارم افتاد به ویدئوهای آموزشی مایکروسافت . دیدم چرا اینا انگار دارن مریخی کد می زنن .. می فهمیدم چی نوشتن ولی وقتی با کدای خودم مقایسه می کردم تفاوت فاحشی رو می دیدم .. درسته شاید بگین برای حل یک مسئله راه های مختلفی هست و ممکنه دو تا راه حل زمین تا آسمان باهم فرق داشته باشن ولی من می گم برای به دست آوردن عدد 4 هم می شه بگی 2+2 هم می شه بگی 2/ (2*2*2) و هم یه انتگرال بنویسی و هم خیلی راه های دیگه که هیچ ربطی به هم ندارن ولی 2+2 کجا و باقی راه ها کجا ..
من می خوام بدونم معیار شما چیه برای کداتون .. یادمه یکی از دوستان عزیز بحثی رو مطرح کرده بود به اسم مرضی به اسم بهینه سازی کد... شاید این دغدغه های من رو بشه به نوعی در همون جهت ارزیابی کرد ...
واقعا بعضی وقتا که نمونه هایی دیگه رو می بینم ترس برم می داره که نکنه این همه مدت فقط garbage کد می زدم .. نمی دونم واقعا .. چه معیاری رو در نظر بگیرم که با توجه به اون خودم رو بسنجم . کدای MSDN ؟ ویدئوهای آموزشی این وری ها ؟ اون وری ها ...

[syntiberium]

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

[ایمان اختیاری]

بله درست می فرمایید . اما بهینه سازی تا کجا.. یه سری مقاله خونده بودم که بعضی وقتا بهینه سازی بیش از حد باعث افزایش order می شه .. و قطعا بهینه سازی بیش از حد باعث دور شدن از حل مسئله اصلی می شه ... حالا سوال ایجاد شد که چقدر بهینه کنیم .. معیار بهینه سازی چیه ؟ متشکرم.

[میلاد قاضی پور]

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

[eshpilen]

بله درست می فرمایید . اما بهینه سازی تا کجا.. یه سری مقاله خونده بودم که بعضی وقتا بهینه سازی بیش از حد باعث افزایش order می شه .. و قطعا بهینه سازی بیش از حد باعث دور شدن از حل مسئله اصلی می شه ... حالا سوال ایجاد شد که چقدر بهینه کنیم .. معیار بهینه سازی چیه ؟ متشکرم.
بهینه سازی یک چیزه و الگوریتم مناسب یک چیز دیگه.
اصطلاح بهینه سازی عمدتا درحد کار روی جزییات سطح پایین تر برنامه و واحدهای عملیاتی سطح پایین تر الگوریتم های کلی مربوط به منطق برنامه هست و اگر این راهکارها خیلی پیشرفته و پیچیده باشه و خودش الگوریتم مفصلی داشته باشه اغلب این الگوریتم ها باز هم برای حل مسائل و محدودیت های سطح پایین فنی که جزیی از فرایند الگوریتم اصلی برنامه هستن بکار میرن و الگوریتم اصلی جدید رو باعث نمیشن. اما اونی که شما مطرح میکنی الگوریتم اصلی و کلی حل مسئله هست که بنظرم با مفهوم متداول اصطلاح بهینه سازی تفاوت میکنه. وقتی ما میگیم بهینه سازی، اغلب فرض بر این هست که الگوریتم مناسبی داریم که بقدر کافی ساده شده و کامل و قوی هست.
بهینه سازی رو وقتی انجام میدن که لازم باشه. حداقل درمورد اپلیکیشن ها که اینطوره. و اینهمه ابزارهای RAD مثل زبانها و فریمورک های سطح بالا و محیطهای Visual خودشون اغلب برخلاف بهینه سازی Performance برنامه عمل میکنن از نظر فنی، اما در جهت مثبت نسبت به وقت و انرژی برنامه نویس و امنیت و منطق برنامه کار میکنن. و میبینید که اهمیت خاصیت دوم، کاملا به خاصیت اول میچربه.
اما چیزی که ظاهرا شما مطرح کردید، دقیقا جزء این بهینه سازیهای جزیی که فقط باید موقع ضرورت انجام بشن و اغلب منجر به پیچیدگی و ناخوانایی و بالا رفتن احتمال باگ و ناسازگاری و هزینهء نگهداری و تغییر و توسعهء برنامه در آینده میشن نیست بنظرم!
چیزی که شما میگید مبحث تحلیل و طراحی الگوریتم هست.
خودتون مثال ریاضی زدید. بنظر شما کسی که برای بدست آوردن 4 از راه حلی پیچیده تر از 2+2 استفاده میکنه آیا یک ریاضیدان خوب هست و راه حل مناسبی بدست آورده؟ در ریاضیات هر فرمول رو باید تاحد ممکن ساده کرد و به اجزای تجزیه ناپذیر رسوند. ریاضیدانی که نتونه این کار رو بکنه اصلا یک مهارت پایه ای ریاضی رو نداره و بنظرم بنابراین نمیتونه خیلی مسائل رو حل و کشف بکنه؛ چون برای حل و کشف خیلی مسائل نیاز به توانایی بیرون کشیدن سادگی و روابط اصلی از دل فرمولهای ظاهرا پیچیده و مفصل هست.

[m.soleimani]

دوست عزیز یه نگاه به این pdf بنداز فکر کنم برات جالب باشه

در کل شما باید ببینی دلخواهت هست به چه استانداردی کد بزنی برای مثال این نرم‌افزار کدهای شما را چک می‌کنه تا به سبک استاندارد مایکروسافت باشه

http://stylecop.codeplex.com/releases/view/48036

موفق باشید./

[Felony]

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

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

موفق باشید .

[eshpilen]

ببینید اون چیزی که من گفتم مرض و وسواس بهینه سازی، بر اساس چیزهایی هست که در عمل زیاد دیدم روشون مانور داده میشن و اصلا مربوط به طراحی الگوریتم و منطق اصلی برنامه نمیشدن. بطور مثال طرف میاد میگه بجای فلان سینتاکس یا تابع از فلان سینتاکس یا تابع دیگه استفاده کنید چون سریعتره. یا مثلا وقتی متغییر رو ذخیره میکنیم نوعش رو فلان بذاریم. یا حتما باید تعداد ارتباطها با دیتابیس رو تا فلان حد یا تاحداکثر ممکن کم بکنیم. خلاصه از این جور چیزا! چیزهایی که در عمل اغلب تاثیر مشهودی روی کارایی برنامه ندارن و به الگوریتم اصلی هم مربوط نمیشن. و کارهایی که فقط وقت و انرژی برنامه نویس رو هدر میدن، کد رو ناخواناتر میکنن، پیچیده تر و حجیم تر میکنن، و بنابراین احتمال باگ رو بالا میبرن، توسعه و تغییر و نگهداری برنامه رو دشوارتر میکنن.
حالا نگاهی بکنید به اون چیزی که شما گفتید. مثال 2+2. کاملا عکس این اثرات رو داره. کد رو خواناتر و کوتاهتر میکنه و احتمال باگ در برنامه رو پایین میاره. البته سرعت رو هم بالاتر میبره که این شبیه علت و نتیجهء مفروض بهینه سازیهای جزیی هست، اما بیشتر یه تشابه در نتایج هست تا تشابه در ماهیت.
اتفاقا بنده طرفدار طراحی الگوریتم های ساده شده و تجزیه ناپذیر هستم و میگم بجای بهینه سازیهای جزیی، باید روی الگوریتم و منطق اصلی کار کرد.

من میتونم بطور مثال برای یک متغییر در داخل برنامه از یک متغییر رشته ای استفاده کنم که بعنوان مقدارهای ممکن، یکسری کلمات درش بتونن درج بشن. بطور مثال رشته هایی مثل Register، Login و غیره. همینطوری بدون تحقیق و تست هم میشه حدس زد که اگر بجای یک متغییر رشته ای و کلمات چند کاراکتری از یک متغییر عددی استفاده کنم و مثلا بجای Register از عدد 1 و بجای Login از عدد 2 استفاده کنم و غیره، سرعت اجرا کمی بالاتر میره. اما آیا بنظر شما این دلیل موجهی برای این کار هست؟ مسلما استفاده از کلمات انگلیسی از نظر خوانایی و قابلیت نگهداری و توسعهء برنامه در آینده خیلی مناسبتر هست.
اونایی که میگم مرض وسواس در بهینه سازی دارن، چیزهایی کم و بیش در همین حد رو مطرح میکنن. مواردی که مطرح میکنن ظاهرشون پیچیده تر و پنهان تر و فریبنده هست، اما در عمل کم و بیش به دلایل مشابهی بنظر بنده عاقلانه نیستن و در مجموع بیشتر اثر منفی دارن تا مثبت. منظورم از اثر منفی، مجموع کل پارامترهای برنامه هست، نه فقط یک مبحث محدود Performance؛ اونم Performance ای که در عمل اغلب تفاوتش درحد مشهود نیست.
حالا یک وقت برنامه یا قطعه کدی برای کاربرد خاص و در شرایط خاص داریم، اون بحثش فرق میکنه و ممکنه بهینه سازیهای جزیی در اونجا توجیه بشن.
اما این افرادی که میگم رو به استدلالهایی مثل این میارن که بالاخره Performance بیشتر هم از همین ذره ذره بهینه سازیها و کسب کردن صدمهای ثانیه بدست میاد و باعث میشه در مجموع مثلا یک سرور وب بتونه به تعداد بیشتری درخواست/سایت سرویس بده.
فکر میکنم بتونیم هم عقیده باشیم که این یک استدلال سطحی و ناقص هست. و خیلی بهتره یک سرور به تعداد کمتری سرویس بده تا اینکه اپلیکیشن های خودمون رو پیچیده و ناخوانا و مستعد باگ بیشتر بکنیم و وقت و انرژی ارزشمند و گران قیمت برنامه نویس هم تلف بشه. و در غیر اینصورت، یعنی اگر بهینه سازی Performance در هر حدی با هر قیمتی توجیه شده باشه، باید استفاده از زبانها و فریمورک هایی مثل PHP و دات نت رو هم ترک کرد و رو به سی و اسمبلی آورد!

[هم دانشگاهی]

من تو این مدت اخیر به خصوص تعطیلات میان ترم برام تجربه شد که سوالات مسابقات ACM روی بهینه سازی کدها خیلی خیلی موثر هست !
درسته شاید اول فکر زمان رو بکنیم اما وقتی در سر فرصت کدها رو بررسی میکنیم میبینیم که خیلی راحت میشه کدها رو خیلی خیلی بهینه کرد ! فقط کافیه روی اون سوال ها متمرکز بشیم و سعی کنیم اون ها رو به صورت بهینه بنویسیم تا از نظر زمان و حافظه مناسب بشن !

[m.soleimani]

من تو این مدت اخیر به خصوص تعطیلات میان ترم برام تجربه شد که سوالات مسابقات ACM روی بهینه سازی کدها خیلی خیلی موثر هست !
درسته شاید اول فکر زمان رو بکنیم اما وقتی در سر فرصت کدها رو بررسی میکنیم میبینیم که خیلی راحت میشه کدها رو خیلی خیلی بهینه کرد ! فقط کافیه روی اون سوال ها متمرکز بشیم و سعی کنیم اون ها رو به صورت بهینه بنویسیم تا از نظر زمان و حافظه مناسب بشن !

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

[مهران رسا]

در این مورد قبلاً یک بحث مفصل شده که آقایان مداح و موسوی (اگر اشتباه نکنم) در این مورد توضیحاتی بسیار مفید ارائه داده اند . پیشنهاد میکنم یک نگاهی بهش بیندازید .

[JaguarXF]

چیز اسرار آمیز و پیچیده ای نیست

یک سری قوانین ظاهری داره برای نامگذاری متغیرها و توابع و غیره: که اسنادش در اینترنت موجوده . هم جاوا هم دات نت و زبونهای دیگه همگی یک داکیومنت پیشنهادی دارند برای این کار که خیلی تیمها و برنامه نویسان هم به همون استاندارد کد میزنند...خیلی تیمها هم استانداردهای داخلی خودشون رو دارند. حداقل انتظار این هست که همه اعضای یک تیم با یک استاندارد "باید" کد بزنند و یکی از مواردی که در Code Review های تیمی بهش دقت میشه "باید" همین باشه.

یک سری تکنیکها هم برای Performance هست که خودبخود هرچقدر کدهای حرفه ای بیشتری رو دیده باشید و هرچقدر تجربه خودتون بالاتر بره اتوماتیک وار بهتر کد میزنید. در عین حال همیشه ابزارهای Profiler برای زبانهای برنامه نویسی مدرن وجود دارد که از اونها استفاده میکنید برای پیدا کردن Performance Bottle Neck ها و Memory Leak ها ...

یک سری تکنیکها هم هست که این ممکنه از قدرت شما خارج باشه یعنی هرچقدر هم که برای یک هفته به کد زل بزنید شاید نتوانید تغییرش بدهید چون ممکن است از نظر تکنیکی توانایی اون رو نداشته باشید یا داشته باشید و اون هم اکثرا موارد مربوط به refactor کردن هست به نحوی که Loosely Coupled باشه و مواردی از این قبیل. این جور موارد رو معمولا به نر من اختیارش رو نباید به دست software eng داد ( یا حداقل من نمیدهم! لول) . اینها تصمیمات Architectural در کل کد هست که ممکنه هزاران خط کد رو ناگهان مجبور به تغییرش بشید.

اضافه بر اون دو قانون هم از خودم وضع کنم:

1- اگر تیمی کد مینویسید کدی که Code Review نشود برای عمه من خوب است.
2- فارغ از تیمی یا تک نفره بودن: کدی که Unit Test نداشته باشد هم قابل قبول نیست اما عمه من میتواند از آن استفاده کند.
2-2 : Code Coverage یونیت تست هایی که نوشته میشد هم مهم است. نمیشود کلاه شرعی سر تیم بگذری بگی بیاه نوشتم یونیت تست دیگه!

این بحثها همگی بخشی از و وابسته به اکو سیستمی هست که بشما برای تولید نرم افزار پایه گذاری کرده اید.