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

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

چنین سیاستی در برنامه نویسی اصطلاحاً Technical Debt گفته می‌شود که به صورت تحت الفظی می‌توان آن را به «بدهی فنی» ترجمه کرد این بدهی فنی اصلاً چیز خوبی نیست و گاهی اوقات منجر به بوجود آمدن فجایعی در تولید نرم افزار می شود. برای روشن شدن این مسأله مثالی می زنیم. بدهی فنی همچون وام گرفتن است که در کوتاه مدت کار ما را راه می‌اندازد اما غافل از این که در آینده می بایست با بهره ای که روی آن می‌آید -مثلا 30 درصد بیشتر- قرض خود را پرداخت کنیم.

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

📌 منبع: https://goo.gl/0GSHll

«اگر شما از اولین نسخه نرم‌افزار خود حالتان بهم نخورد، شک نداشته باشید که نرم‌افزار خود را خیلی دیر به بازار عرضه کرده اید!»

راید هافمن، موسس لینکدین

۲۹ فرمان لینوکس که باید بدانید

http://goo.gl/79lpgV

کدهای نرم‌افزارهای موفق چه ویژگی دارند؟

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

http://goo.gl/92m33G

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

https://github.com/hirak/prestissimo

۵۴ مفهوم در تست نرم‌افزار

http://arsin.ir/?p=549

معرفی crashlytics

اگر برنامه‌نویس اندروید (یا iOS. این سولوشن برای هر دو پلتفورم معرفی شده) باشید، احتمالا یکی دوتا چیز شما رو خیلی اذیت کرده. اول اینکه هر دفعه که ماژول یا بخش جدیدی به نرم‌افزارتون اضافه میکنید باید یه APK بگیرید و برای کارفرما، مدیر پروژه، مدیر محصول، بقیه برنامه‌نویسها، تست ‌کننده‌ها، یا کلا هر کسی که درگیر پیشروی پروژه و تست کردنشه بفرستید. احتمالا اینجوری عمل میکنید که APK رو به همراه کمی توضیحات ایمیل میکنید یا میذارید دراپ باکس یا تو حالت رو مخ ترش تلگرام میکنید. بعد میشینید منتظر نظرات اونا و گزارش خطاهای احتمالی. مشکل دوم هم وقتی پیش میاد که گزارش خطا میگیرید. تو اینجور مواقع احتمالا جملاتی میشنوید مثل: اومدم لاگین کنم کرش کرد! یا “اصن باز نمیشه!” و حالا تازه نوبت شما میشه که جملاتشون رو رمزگشایی کنید و بفهمید ایراد کار از کجا بوده.

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

http://thearash.net/?p=399

قانون DRY

قانون DRY مخفف واژگان Don`t Repeat Yourself به معنی «هرگز کار تکراری نکنید!» است. اگر در کدنویسی مواقعی برای ما پیش می‌آید که قطعه کدی را از جایی در سورس کد کپی کرده سپس در جای دیگر دقیقاً همان قطعه کد را پیست می کنیم، بر اساس قانون DRY این کار کاملاً اشتباه است.

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

«قانون YAGNI»

قانون YAGNI که مخفف واژگان You Ain`t Gonna Need It به معنی «بعید به نظر می رسه که در آینده بهش نیاز داشته باشی!» است. برای برنامه نویسان -به‌ خصوص برای برنامه نویسان مبتدی- بسیار پیش می‌آید که دوست دارند برنامه‌هایی که می‌نویسند کامل و جامع باشند و جالب است بدانیم که در برخی مواقع برنامه نویسان دچار وسواس فکری می‌شوند به این شکل که می‌خواهند در برنامه ی مد نظرشان تمامی ایده‌هایی که دارند اعمال شوند.

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

 استک‌اورفلو با ارائه ی بخش Documentation، کار را برای برنامه نویس ها ساده تر کرد

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

#خبر | ادامه متن ...

«متدهای کوچک تر»

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

«نام گذاری های خیلی کوتاه یا خیلی بلند»

تحت هیچ عنوان متغیری را تحت عنوان مثلاً i نامگذاری نکنید چرا که در مرور سورس کد در آینده توسط خودمان و یا سایر توسعه دهندگان دچار سردرگمی خواهیم شد. نام های بسیار طولانی نیز مشکل زا هستند. به طور مثال نامی همچون noOfStudentsInEachClassOfUniversity به معنی «تعداد دانشجویان در هر کلاس دانشگاه» را می‌توان خیلی ساده‌تر و به صورت studentsNo به معنی «تعداد دانشجویان» نوشت.

یک ابزار برای تبدیل CSS شما به CSS بهینه تر است و Module هایی برای راحت تر کردن کد نویسی CSS به ما میدهند. برای مثال: کد شما را فشرده میکند، پیشوند های مروگر را اضافه میکنند قابلیت هایی مثل متغیر ها و… را به شما میدهد قابلیت هایی که در آینده به CSS اضافه خواهند شد را اکنون در اختیار شما قرار میدهد و ده ها قابلیت دیگر که بررسی میکنیم.

http://goo.gl/dkeDFH

«کامنت گذاری»

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

گفته می‌شود کد خوب کدی است که آنقدر تمیز نوشته شده باشد و همه چیز آن شفاف باشد که نیازی به کامنت نداشته باشد و خود کد گویای عملکردش باشد اما به هر حال امروزه کامنت گذاری در سورس کد به عنوان یک Best Practice در آمد و لاجرم ما هم می بایست از این قانون تبعیت کنیم.

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

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

«کلاس های همه فن حریف»

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

«انتخاب یک زبان برنامه نویسی، فرقی نمی‌کند چه زبانی!»

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

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

#مبتدی | منبع: https://goo.gl/gfpf6v

وقتی یه برنامه نویس داره درباره راه حل فکر میکنه و ... :/

«حرف زدن آسونه. کد رو نشونم بده.» لینوس توروالدز

💬 مقاله جالب و مفیدی هست پیشنهاد میکنم مطالعه کنید و به دوستانتون هم معرفی کنید بخونن

http://blog.sariina.com/1240-martial-arts-lessons