انجمنصفحه اولجستجوی انجمن

[farazin]

عادت های بد برنامه نویسان

همه بد کد می نویسند، جز من!
گاه اوقات یک برنامه نویس با دیدن کدهای شخص دیگر، به جای قبول کردن اختلاف نظر موجود در کدنویسی به زیر سوال بردن روش کدنویسی طرف مقابل می پردازد. درست است که در پروژه های تیمی رعایت استانداردهای تیم ضروریست، اما در مواردی که شخص در حال کار بر روی جزییات است و هیچ استانداردی را زیر سوال نبرده، بهتر است قبل از بحث در مورد کدهای نوشته شده، دیدگاه وی را در مورد این نوع کدنویسی بدانیم.
Copy & Paste
یک از بدترین کارهایی که توسط برنامه نویس انجام می شود و علاوه بر خود به کل تیم و پروژه آسیب وارد کند، Copy و Paste کردن کدها بدون بررسی و فراگیری دانش موجود در آنهاست. این مورد بویژه در برنامه نویسان وب بسیار مشاهده می شود. بهتر است به جای کپی کردن کد از جای دیگری، نیاز خود را با فراگیری تکنیک های لازم رفع کنید. در صورتی که مجبور به نسخه برداری از کد دیگری هستید، بهتر است تک تک خطوط آن را بررسی کرده و لایسنس مربوط به آن را رعایت فرمایید. پیشنهاد می کنم صفحه Copy and paste programming در ویکی پدیا را مطالعه کنید.
نام گزاری نامفهوم متغیرها
این مشکل بیشتر در برنامه نویسان کم تجربه دیده می شود. مثلا متغییری را با حرف u تعریف کرده و در بخش های مختلف استفاده می کند. شما فکر می کنید که منظور از u همان user است، بعد شک می کنید که شاید username باشد و در آخر متوجه می شوید که منظور وی usability بوده است! درصورتی که نام متغییر را با توجه به محتوای آن ها برگزیده شود، خوانایی برنامه دوچندان می شود.
این بخش خیلی زود تموم می شود
معمولا زمانی که یک بخش زودتر از موعد مقرر تمام می شود، بهتر است در مورد برنامه نوشته شده شک کنید! شاید برنامه نویس بخواهد با اینکار قدرت برنامه نویسی خود را نشان دهد ولی بارها دیده ام که بعد از چندین هفته و ماه، ایرادی در چنین برنامه ای رخ می دهد که نه تنها زحمات برنامه نویس را از بین می برد، بلکه باعث ضایع شدن شخصیت کاری وی می گردد. شاید اگر از همان اول برنامه نویس مدت زمان بیشتری را صرف نگارش، تست و بازبینی برنامه خود می کرد، ماندگاری برنامه بی نقص وی باعث افزایش اعتبار وی در محیط کاری می شد.
من نبودم! عدم مسئولیت پذیری و عذرخواهی
برخی اوقات بخشی از برنامه دچار ایراد می شود و کسی عهده دار ایراد بوجود آمده نیست. از لحاظ اخلاقی گفتن یک عذرخواهی نه تنها از شخصیت شما نمی کاهد، بلکه نشاندهنده حس مسئولیت پذیری شما می شود. البته با نوشتن توضیحات (Comment) در برنامه می توانید، نویسنده کد را به راحتی بیابید.
سرخوردگی از انجام کارهای تکراری
این مورد بارها برای من اتفاق افتاده است. بدترین بخش کار، انجام دادن مواردی است که هم سطحی هستند، هم حوصله می خواهند و هم از عهده افراد سطح پایین تر و دیگر بر می آیند. اما به هر حال مواردی پیش می آید که مجبور به انجام دادن این قبیل کارها هستید. بهترین راه حل حفظ آرامش و انجام دادن کار در اولین فرصت است. بعید می دانم راه حل دیگری پیدا شود.
انجام دادن ناقص کارها
برخی از برنامه نویس ها، بخصوص کم تجربه تر ها، معنای صحیح اتمام کار را نمی دانند. یعنی انجام دادن کار را به معنی نگارش کد می دانند و مراحل مستندسازی، تست، ادغام کد در پروژه و… را در زمان لازم برای اتمام کار در نظر نمی گیرند. چه بسا پیدا شدن یک خطا در مرحله تست می تواند وی را ساعت ها درگیر کند.
اعمال سلیقه شخصی
منظور از اعمال سلیقه شخصی عدم تفکر در هنگام برنامه نویسی نیست. بلکه مفهوم آن در نظر داشتن دیدگاه مشتری در اولویت بالاتر نسبت به دیدگاه شخصی است.



ده اصل برای کد نویسی خوب و ایده آل

شاید شما تا کنون نام دیتر ریمز (Dieter Rams) را نشنیده باشید،اما مطمئنا افرادی که در زمینه طراحی صنعتی تحصیل کرده‌اند،با او و ده اصل معروفش آشنایی دارند.ریمز،متولد ۱۹۳۲، دانش آموخته معماری داخلی و یکی از طراحان و معماران شناخته شده و صاحب سبک آلمانی است که با تلاش‌های فراوانش در پیشبرد و توسعه طراخی صنعتی،نقش به سزایی را ایفا کرده است.او در ادامه فعالیت‌های خودش،در سال ۱۹۵۵ به عنوان طراح داخلی،بوسیله شرکت آلمانی بروان (Broun) سازنده لوازم الکتریکی خانگی،استخدام شد.او سال‌ها طراح محصولات بروان بود و توانست در سال ۱۹۶۱،رئیس بخش طراحی این کمپانی معروف آلمانی شود.او در سالهای ۱۹۸۷ تا ۱۹۹۷ بعنوان رئیس تنها موسسه رسمی کشور آلمان در زمینه دیزاین بنام ًرات فور فرم گبونگ ً که در حقیقت تشکیلاتی جهت تحقیقات و ارائه پیشنهادات در دیزاین می باشد،گردید.
سال‌ها پیش از آن که کمپانی اپل با افزودن پیشوند i به اسم محصولات خود و عرضه آنها با طراحی زیبا،چشمگیر و دلفریب،به رقبایش فخر بفروشد،این کمپانی بروان بود که به لطف برخورداری از طراحی چون ریمز،به تولید محصولات خانگی ظریف شهرت داشت.ریمز در شرکت براون محصولات متعددی از جمله انواع وسایل الکترونیکی،ماشین حساب، قهوه‌ساز، رادیو، وسایل دفتری و… طراحی کرد.در وسایل الکترونیکی که او طراحی میکرد،دکمه‌ها،کلید‌ها،صفحه‌های و شماره‌گیر به کوچک‌ترین اندازه کاهش داده شده و با نظم مرتب می‌شدند. هدف ریمز این بود که محصولات مفیدی طراحی کند که راحت به کار بیافتند.طراحی های ریمز اغلب بی دردسر به نظر می آید، با یک سادگی بدیع که نتیجه تجربیات سخت و مکرر، با مواد جدید و توجه وسواس گونه به جزئیات برای اطمینان از اینکه هر قسمت و تکه‌ بی‌عیب به نظر بیاید.امروزه قسمت اعظم طراحی های او برای شرکت براون، بخشی از مجموعه‌های دائمی موزه‌های بین‌المللی شده‌اند.
ریمز در طول دوران فعالیت خود طرح‌های گوناگون و موفقی را ارائه کرد.ابتکار، ساخت محصول مفید، زیبایی شناختی، فهمیدن محصول، محبوبیت، صداقت، پایداری، دوام، علاقه به محیط زیست و سادگی، ده اصلی است که ریمز برای نزدیک شدن به طراحی خوب (Less but better) تعریف کرده است.طبق این نظریه یک دیزاین خوب بایستی دارای این ده مشخصه باشد.با کمی تغییر در این ده اصل و جایگزین کردن واژه “طراحی” با “کد”،در عبارت “طراحی خوب” به “ده اصل برای کدنویسی خوب” میرسیم و میتوانیم از این اصول مفید برای بالا بردن کیفیت کار در برنامه‌نویسی بهره ببریم .پس بهتر است زودتر به سراغ آن برویم:


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

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

۳. کد خوب کدی است که اصول زیبایی شناسی در آن به کار رفته باشد
برخی از محیط‌های مجتمع برنامه‌نویسی(IDEها) میتوانند کد‌ها را به ترتیبی کاملا زیبا آرایش نموده و مرتب کنند.در کدنویسی همچون طراحی،اصل زیبایی‌شناسی بسیار مهم است زیرا به‌طور مستقیم در طراحی محصولاتی که استفاده میکنیم بازتاب می‌یابد.

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

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

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

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

۸. کد خوب تا آخرین جزئش باید دقیق و هدفمند باشد
باگ‌ها و اشکالاتش برطرف شود.آزمایشات و تست‌های متعددی در محیط‌های متفاوت روی آن انجام شود و …

۹. کد خوب باید با محیط زیست سازگار باشد
اگر کمی فکر کنید خودتان ربطش را درک خواهید کرد.

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