۸-قانون «بوی اسکات»

اردوگاه «بوی اسکات» یک قانون دارد: «همیشه محوطه را تمیزتر از زمانی که به آن وارد شده‌اید ترک کنید.» اگر زباله‌ای روی زمین دیدی، بدون توجه به این که چه کسی آن را انداخته است، تمیزش کن. نیت‌ات این باشد که اردوگاه را برای گروه بعدی که می‌آیند بهتر کنی. (در واقع شکل اصلی این قانون که «رابرت استفنسن اسمیت بیدن پاول*» بنیانگذار اردوگاه اسکات بیان کرده است، این بود: «سعی کن وقتی دنیا را ترک می‌کنی، دنیا بهتر از وقتی باشد که به آن وارد شدی.»)

اگر ما قانونی مشابه این را در کدنویسی داشته باشیم چه اتفاقی می‌افتد: «همیشه وقتی یک ماژول را تحویل می‌دهی تمیزتر از وقتی باشد که آن را تحویل می‌گیری»؟ بدون توجه به این که نویسنده اولیه آن ماژول چه کسی بوده است، چی می‌شود اگر ما مقداری (هر چند ناچیز) تلاش کنیم تا آن را بهبود بدهیم؟ نتیجه چه خواهد شد؟

ادامه مطلب

۶- قبل از بازنویسی کد

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

ادامه مطلب

آموزش جاوا، فصل یازدهم: ساختار کلاس ها در جاوا

همانطور که در فصل قبل گفتیم کلاس ها سنگ بنای برنامه نویسی شی گرا هستند. یک برنامه جاوا از تعدادی کلاس ساخته می شود. اشیا از روی کلاس ها ساخته می شوند و ارتباط اشیا با هم مسأله را حل می کند. حالا اگر قدری دقیق تر به کلاس ها نگاه کنیم، می بینیم که خود کلاس ها از اجزای کوچکتری ساخته می شوند. بار دیگر به ویژگی های برنامه های شی گرا از دید Alan Kay دقت کنید:

  1. هر چیزی یک شی است.
  2. یک برنامه مجموعه‌ای از اشیا است که با استفاده پیام‌رسانی به یکدیگر می‌گویند که چه کار باید بکنند.
  3. هر شیء‌ای دارای حافظه‌ای است که از سایر اشیا ساخته شده است.
  4. هر شیء‌ای یک «نوع» دارد.
  5. تمام اشیای همنوع می‌توانند پیام‌های یکسانی دریافت کنند.

ادامه مطلب

۵- زیبایی در سادگی است

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

«زیبایی متن و هماهنگی و ظرافت و جذابیت و موزونی بسته به سادگی است.»

این گفته همه آن چیزی که ما به عنوان توسعه دهنده نرم‌افزار در آرزوی آن هستیم را در یک جمله بیان می‌کند.

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

  • خوانا بودن
  • قابل نگهداری بودن
  • سرعت در توسعه
  • زیبایی کیفی

ادامه مطلب

فیلم‌های آموزشی اندروید

سلام به همراهان همیشگی اسمارت‌لب

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

اگر موضوعی مد نظر دارید برای آموزش زیر همین مطلب کامنت بگذارید و اگر با نرم‌افزارهای ویرایش فیلم مانند corel videostudio pro کار کرده‌اید و تمایل دارید در این موضوع با من همکاری کنید لطفا یک ایمیل به info در اسمارت لب بفرستید و از تجربه‌هایتان برایم بنویسید. لطفا در ایمیل دستمزد مورد انتظار و نیز میزان ساعات همکاری را هم بنویسید.

متشکرم

۴- استانداردهای کدنویسی را به صورت خودکار اعمال کن

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

ادامه مطلب

۳- بپرس «کاربر چه کار خواهد کرد؟» (تو کاربر نیستی)

ما معمولا عادت داریم که فرض کنیم دیگر آدم‌ها مثل ما فکر می‌کنند. اما اینگونه نیست. روانشناسان این گرایش را «سوگیری اجماعی خطا» می‌نامند. وقتی که مردم برخلاف ما فکر یا عمل می‌کنند، ما (ناخودآگاه) شدیدا به آن‌ها برچسب ناقص می‌زنیم.

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

ادامه مطلب

۱-با احتیاط عمل کن

«هر کاری که به عهده می‌گیری، با احتیاط عمل کن و نتایج آن را در نظر داشته باش» -آنون

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

ادامه مطلب

معرفی کتاب: ۹۷ چیزی که هر برنامه نویس باید بداند

مدتها از تکمیل و انتشار دو کتاب «واقعی شدن» و «صفر تا یک» می‌گذرد. در این مدت تصمیم داشتم از بین چند کتاب محبوبم یکی را برای ترجمه آغاز کنم که البته فراوانی مشغله و کمی تا قسمتی تنبلی مانع شد! در این فاصله تقریبا همه آن‌ها ترجمه شده و با بازار آمدند و ترجمه دوباره آن‌ها دوباره کاری می‌شد. بنابراین به سراغ کتابی رفتم که فکر نمی‌کنم کسی آن را ترجمه کرده باشد:

۹۷ چیزی که هر برنامه‌نویس باید بداند: مجموعه‌ای از پندهای نخبه‌ها

این کتاب را تا زمانی که سایت اختصاصی‌اش را آماده کنم در اسمارت‌لب منتشر می‌کنم. از منوی بالای صفحه «کتاب ۹۷ چیزی که…» را باز کنید!