VIP همه چیز درباره برنامه نویسی

[☾♔TALAYEH_A♔☽]

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


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

در ارتباط با دلایلی که چرا برخی از پروژه ها از صفر کدنویسی نمی‌شوند و در آن‌ها از کامپوننت ها و کتابخانه‌های موجود استفاده می شود، می‌توان موارد زیر اشاره کرد:

۱- نرم‌افزارها و اپلیکیشن ها در طول زمان رشد می کنند، پیچیده‌تر می‌شود و در نهایت نسبت به نسخه بتای خود به مراتب حرفه‌ای تر می‌شوند و این در حالی است که زمان اختصاص یافته برای توسعه این دست نرم‌افزارها و اپلیکیشن ها محدود و محدودتر می گردد. منطقی‌تر به نظر می‌رسد اگر برنامه نویسان بیشتر از آن که روی کدنویسی زیرساخت پروژه زمان صرف کنند (که در اکثر پروژه ها این زیرساخت تاحدودی مشابه است)، تمرکز خود را روی کدنویسی بخش‌های اختصاصی پروژه شان متمرکز سازند.

۲- کامپوننت ها و فریم ورک هایی که در سرتاسر دنیا مورد استفاده قرار می‌گیرند به مراتب دارای باگ های کمتری نسبت به کدهایی هستند که یک برنامه نویس فریلنسر در اتاق کارش می نویسد!

۳- بسیاری از فریم ورک های موجود در بازار به صورت رایگان در اختیار توسعه دهندگان قرار می‌گیرد و همین مسأله حاکی از آن است که هزینه‌های مرتبط با توسعه یک پروژه به مراتب کاهش خواهد یافت.

۴- توسعه زیرساخت پروژه در زمینه‌های مختلف مثل امنیت، راندمان و … کاری حساس، دقیق، زمان بر و پرهزینه است اما اگر شما از کامپوننت های متن باز و رایگان استفاده کنید، می توانید از به روزرسانی به هنگام و ساختاری پروژه خود اطمینان حاصل کنید.

به خاطر داشته باشید
توجه داشته باشیم که شرکت فیسبوک ابتدا برای برنامه نویسی این شبکه ی اجتماعی از زبان برنامه نویسی PHP استفاده کرد اما پس از آن که این شبکه جای خود را در میان کاربران باز کرد و به درآمدزایی هنگفتی دست یافت، مدیران این شرکت تصمیم گرفتند زبان اختصاصی این شرکت تحت عنوان Hack را توسعه داده و شبکه ی اجتماعی فیسبوک را روی آن بنا کنند.

آنچه مسلم است این که انتخاب ترکیبی از ابزارهای موجود برای توسعه اپلیکیشن خود کاری حساس بوده و نیازمند برخورداری از تجربه در این زمینه است. برای همین منظور، راه کارهایی را در ادامه برای شما آورده‌ایم که می‌تواند به شما در انتخاب ابزار مد نظرتان کمک شایانی کند:

- هر ابزاری در یک بستر خاص بهترین اثربخشی را خواهد داشت. منظور ما در اینجا از بستر عبارت است از ساختار دیتابیس، پروتوکل های ارتباطی، سرور،‌ وب سرویس، ای پی آی و … پس این احتمال وجود دارد ابزاری که شما انتخاب کرده‌اید با بستر توسعه نرم افزاری تان همخوانی نداشته باشد و همین مسأله منجر به پیچیده‌تر شدن پروژه شما خواهد شد.

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

- برخی از ابزارهای موجود نیازمند کانفیگ یا تنظیم کردن هستند که مسأله تنظیم کردن آن‌ها شاید نیازمند صرف وقت و هزینه قابل توجهی باشد.

- برخی از ابزارهای به اصطلاح رایگان آن طور که باید و شاید Free نیستند. در ابتدا ما تصور می‌کنیم که ابزار مد نظر ما کاملاً رایگان است و شروع به استفاده از آن می‌کنیم اما وقتی پروژه به جاهای حساس خود می‌رسد و نیازمند استفاده از کامپوننت های خاصی است، کاشف به عمل خواهد آمد که می بایست بخشی از سورس کد را از توسعه‌دهنده اصلی خریداری کنیم و همین مسأله می‌تواند آینده نرم‌افزار ما را تحت الشعاع قرار دهد.

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

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

 

[☾♔TALAYEH_A♔☽]

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: پیش از آن که دیگران را متهم کنید، کد خود را چک کنید!


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

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

 

[☾♔TALAYEH_A♔☽]

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


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

یک برنامه نویس خوب کسی است که وقتی کدهای یک برنامه نویس دیگر را تحویل می‌گیرد -فارغ از این که برنامه نویس قبلی چه کسی بوده- تمام تلاش خود را به کار خواهد بست تا کدها را بهبود بخشد و این در حالی است که این بهبود کار می‌تواند هم در زمینه بهبود راندمان کدها بوده و یا حتی در زمینه کامنت گذاری باشد. به نظر شما در چنین شرایطی نتیجه نهایی چه خواهد شد؟

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

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

 

[☾♔TALAYEH_A♔☽]

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


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

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

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

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

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

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

 

[☾♔TALAYEH_A♔☽]

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


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

حال می بایست به این سؤال پاسخ دهیم که به چه نوع کدی صفت زیبا اطلاق می گردد. این سؤال بسیار انتزاعی است چرا که مفهوم زیبایی چیزی کاملاً نسبی است. درکی که هنرمندان از زیبایی دارند به مراتب متفاوت تر از مهندسان یا برنامه نویسان است. لذا نیاز است تا مسئله ی زیبایی در برنامه نویسی را کمی بشکافیم!

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

 

[☾♔TALAYEH_A♔☽]

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

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

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

به عنوان نمونه، می‌توان زبان برنامه نویسی پی اچ پی را مثال زد. سایتی تحت عنوان php-fig.org استانداردی تحت عنوان PSR که مخفف واژگان PHP Standard Recommendation است را برای برنامه نویسان پی اچ پی طراحی کرده که علاقمندان با استفاده از این استانداردها می توانند از کدهایی برخوردار شوند که سایر برنامه نویسان پی اچ پی با نگاه کردن به کدهای ایشان کمتر دچار سردرگمی شوند.

نکته
سورس کد سکان آکادمی کاملا منطبق بر استاندارد PSR است و همین مسئله کار گروهی روی توسعه ی بخش های مختلف این سایت را بسیار اثربخش تر ساخته است.

به طور مثال، کدی که در زیر مشاهده می کنید بر اساس استاندارد PSR نوشته شده است:

<?php
namespace Vendor\Package;

use FooInterface;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass;

class Foo extends Bar implements FooInterface
{
public function sampleFunction($a, $b = null)
{
if ($a === $b) {
bar();
} elseif ($a > $b) {
$foo->bar($arg1);
} else {
BazClass::bar($arg2, $arg3);
}
}

final public static function bar()
{
// method body
}
}
در واقع، در کد بالا پس از namespace و دستورات use یک اینتر قرار گرفته است و یا این که علامت } مرتبط با کلاس Foo در خط بعد نوشته شده است. به عنوان مثالی دیگر، آرگومان های متد sampleFunction با یک کاما و اسپیس از یکدیگر مجزا شده اند و این در حالی است که کاما به آرگومان اول چسبیده، سپس یک فاصله قرار گرفته و در نهایت آرگومان دوم نوشته شده است.

 

[☾♔TALAYEH_A♔☽]

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


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

آنچه مسلم است این که کاربران هرگز مثل برنامه نویسان فکر نمی‌کنند چرا که ایشان برخلاف توسعه دهندگان زمان کمتری را پای کامپیوتر می نشینند،‌ با نحوه کار کردن سیستم‌ها خیلی آشنایی ندارند، فاقد مهارت های حل مسأله هستند که اکثر برنامه نویسان از آن‌ها برخوردارند، با الگوهایی که برنامه نویسان برای طراحی و کدنویسی مورد استفاده قرار می‌دهند آشنا نیستند و غیره. به عبارت دیگر، ارتباطی که یک End User با یک برنامه یا اپلیکیشن دارد همچون ارتباطی است که یک برنامه نویس با یک خودرو دارد. درست است که برنامه نویس می‌داند که چگونه سوار خودرو شود، کمربند خود را ببندد و ...، اما این آقا یا خانم برنامه نویس هرگز نمی‌داند که سازوکار سیستم این خودرو به چه شکل است.

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

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

 

[☾♔TALAYEH_A♔☽]

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: به کارگیری اصولی از توابع در برنامه نویسی


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

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

 

[☾♔TALAYEH_A♔☽]

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


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

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

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

 

[☾♔TALAYEH_A♔☽]

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


انتشارات Oreilly کتاب بسیار جالبی تحت عنوان Ninety Seven Things Every Programmer Should Know به بازار عرضه کرده است که در آن با توجه به تجربیات برنامه نویسان تراز اول دنیا، ۹۷ نکته ی کوتاه اما در عین حال کاربردی در حوزه برنامه نویسی توضیح داده شده است که در این دوره قصد داریم تک تک این چیزها را مورد بررسی قرار داده و ببینیم پیروی از این اصطلاحا Best Practice ها چه فایده ای در زندگی حرفه ای برنامه نویسان، طراحان سایت و وب مسترها دارا است. علاوه بر این، تجربیات مدرس دوره و همچنین کادر آموزشی سکان آکادمی را هم در قالب نکات فوق الذکر خواهیم گنجاند تا این ۹۷ چیز را بومی سازی کرده و برنامه نویسان ایرانی ارتباط بهتری با مطالب آموزشی این دوره برقرار سازند.

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

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

دانلود رمان و کتاب های جدید