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

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

ادامه مطلب ←

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

ادامه مطلب ←

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

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

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

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

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

ادامه مطلب ←

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

ادامه مطلب ←

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

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

ادامه مطلب ←

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

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

ادامه مطلب ←