مقدمه

۹۷ نکته که هر برنامه نویس باید بداند، کتابی که تو سال ۹۰ بودش با یکی از دوستام امید تصمیم گرفتیم بخونیم، یادمه همون موقع ها بودش که من یه سری از این نکته ها رو شروع کردم ترجمه کردن همین جوری از رو دل این کار رو کردم. اون روزی فایلش رو دیدم دلم نیومد تو بایگانیم خاک بخوره منتشرش میکنم تو هر بخش ۳ نکته و انشاالله اگر وقت کنم بخش های و نکات دیگر این کتاب رو ترجمه میکنم.

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

 

 

نکته شماره ۱

Act with Prudence
1-گوینده : seb rose  : زمانی که کاری را انجام می دهید با احتیاط انجا دهید و به عواقب آن بیاندیشید .

مهم نیست یک برنامه نوشته شدنش چقدر ساده به نظر برسد ، در ابتدای کار ، شما نمیتوانید جلوی فشار های زمانی که پیش می آید رو بگیرید. اگر زمانی خودتون رو در وضعیتی یافتید که مجبور بودید به این بودید که بین ” انجام درست ” و یا ” انجام سریع ” یک پروژه یکی را انتخاب کنید ، مطمئا انجام سریع جاذبه بیشتری دارد اما این رو در نظر بگیرید که انجام سریع یک بازگشت برای تعمیر را به همراه دارد زمانی که شما به خود و یا تیم و یا مشتری خود چینین اجازه ای را میدهید، اما در تمام پروژه ها که به شما پیشنهاد میشه ، در آینده مشکل جدید برای شما بوجود میاورد و این مسائله را برجسته میکند؛ این کار معوق شناخته شده بدهی فنی نام دارد و برای شما اصلا مناسب نیست ، به قول Martin Fowler این بدهی فنی تعمدی بوده و نباید با بدهی فنی ناخواسته اشتباه گرفته شود.
بدهی فنی دقیقاً مثل یک قرض و یا وام هستش: ممکن است در مدت کوتاهی شما رو بهرمنده کند ، اما شما تا مادامی که کار را به درستی انجام دهید مجبور هستید که برای تسویه کار خود کار کنید. این راه نزدیک و در رو هستش که شما کد در بار اول صحیح بزنید وگرنه اضافه کردن کد بعد از اانجام کار سخت تر می باشد.آن هم به دلیل آن می باشد که شما پروژه رو ترک کردید و موارد آزمون شده و عیب های پرورش یافته ای را پیش روی خود میبینید .
بد تر این است بعد از مدت زمانی طولانی که شما پروژه را رها کرده اید کار برگشت بخورد ، خصوصا زمان حل مشکل اصلی به این پی می برید که  مشکل شما اساسی هستش و در لایه های اصلی و بالایی برنامه وجود دارد و این درست کردن کار را بشدت سخت تر می کند و شما را از نوشتن کد سریع تر پشیمان می کند.
پرداخت بدهی فنی باید در اسرع وقت انجام پذیرد زیرا که شما کار را تمام شده فرض کردید و این باعث بی تدبیری و بوجود آوردن اشکال در برنامه های شما میشود.

 

نکته شماره ۲

Apply Functional Programming Principles
2-  گوینده : Edward Garson برنامه نویسی تابعی ( تابع محور ) اخیرا بدنه اصلی جامعه برنامه نویسی از برنامه نویسی تابعی لذت می برد.

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

نکته شماره ۳

Ask, “What Would the User Do?” (You Are Not the User)
3 – گوینده : Giles Colborne بپرسید کاربر چه کار می خواهد انجام دهد ؟ ( شما یک کاربر نیستید.)
ما همواره تمایل داریم فرض کنیم که دیگران نیز مثل ما فکر می کنند .  اما آنها اینگونه نیستند. روان شناسان آن را توافق کاذب می نامند. وقتی مردم فکر و یا عمل می کنند و غیر آنچه است که می می دانیم و یا عمل می کنم. ما ناخودآگاه به آنها انگ انتخاب راه نا مناسب را میزنیم.
این سو جهت گیری نشان میدهد که چرا برنامه نویسان برایشان سخت است که خود را جای کاربرانشان بگذارند. کاربران مانند برنامه نویسان نمی اندیشند. برای شروع ، به عنوان مثال آنها ساعات کمی پشت رایانه خود مینشیند. آنها نه میدانند رایانه شان چطور کار می کنند نه به این موضوع اهمیت میدهند. این بدین معناس که کاربران  نمیتوانند انرژی برای هر مشکل صرف کنند و راه و تکنیک برنامه نویسی آن را یاد بگیریند. آنها الگو ها ( pattern ) هایی را که برنامه نویس استفاده کرده به رسمیت نمیشناسند و برای آنها فقط رابط کاربری اهمیت دارد.
بهترین روش برای این که بدانید یک کاربر چگونه می اندیشد این است که به (عملکرد) یکی از آنها نگاه کنید. از کاربر سوال کنید در تکمیل یه یک کار  یا شبیه آنچه که در حال توسعه آن هستید ، مطمئن بشید که کار رو درست انجام میدهید مثلا : “اضافه کردن یک ستون اعداد” خوب است ؟ “محاسبه های هزینه های ماه گذشته شما” بهتر است؟ اجتناب از وظایف خیلی خاص هستند به طور مثال : “آیا میتوانید  سلول های گسترده را انتخاب کنید و فرمول جمع را در زیر وارد کنید ” یک سر نخ بزرگ در این سوال وجود دارد ، آیا این صحبت کاربر احساس نمی کند مانع پیشرفتش میشود؟ سعی نکنید به او کمک کنید سوال خود را مطرح کنید “چرا او این کار را انجام میدهد؟”
در ابتدا شما می بایست متوجه این باشید که شیرازه فکری کاربر به این شکل است : آنها سعی می کنند کارها را به طور کامل انجام دهند معمولا این اشتباهات در این مکان ها رخ میدهد. طراحی شما می بایستی در حول این شیرازه رفتاری انجام شود این با نشست های طراحی متفاوت است، آنجایی که مردم تمایل به شنیدن آنچه که برخی می گویند دارند ، “چه چیزی کاربر اگر میخواهد که…” این امر موجب پیشرفت امکانات و ایجاد سر درگمی بیش از آنچه می خواهد میشود، به کاربر نگاه کنید این سر در گمی از بین می رود.
شما گیر های کاربران را خواهید دید. زمانی که شما گیر کنید به اطراف می نگرید ، اما زمانی که کاربران گیر می کنند ( به جای این کار فقط ) تمرکز می کنند. این کار را برای آنها سخت تر می کند آنها احساس می کنند که راه حل در جای دیگر در صفحه نمایش آنها وجود دارد. این یکی از دلایلی است که متن برای کاربران یه راهنمای ضعیف به شمار می آید در باره ی رابط کاربری ، اگر شما دستور العمل و یا کمکی متنی را در اختیار کاربر می گذارید باید مطمئن بشوید در محل مورد مشکل موثر واقع میشود. این گونه تمرکز محدود کاربر به این می انجامد که معمولا tool tips از منو های مفیدتر هستند.پ
معمولا کاربران تمایل به در هم برهم زدن برنامه دارند ، آنها راهی را پیدا می کنند که جوابگو باشد مهم نیست چقدر برایشان پیچیده باشد ، بهتر است یک راه آشکار برای انجام کار در نظر بگیرید شبیه استفاده از دو یا سه کلید میانبر.
شما در آینده خواهید دید که تفاوتی بسیار میان آنچه کاربر می گوید و آنچه انتظار دارد از شما و آنچه عمل می کند وجود دارد ، که این مسائله نگران کننده است. و راه معمول طلب کردن آنچه کاربر می خواهد از طریق سوال می باشد و بهترین راه برای گرفتن مایحتاج کاربر از طریق تماشای او میسر می شود. هزینه ی یک ساعت دیدن کاربر خیلی کمتر از آن است که شما بشینید و حدس بزنید که کاربر چه چیزی را میخواهد

 

صحبت آخر:

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