غول بی شاخ و دمی بنام برنامه نویسی!

بقول یارو میگه کار هرکس نیست خرمن کوفتن، گاو نر میخواهد و مرد کهن!

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

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

البته اینو بگم که خیلی ها پیشرفت در برنامه نویسی و خبره بودن در این باب و نوشتن برنامه های برتر رو در یه پارامترهایی میدونن مثل شیء گرایی یا استفاده از الگوهای دیزان و معماری. مثلا میگن برنامه نویس حرفه ای اونه که OOP خوب بلد باشه و برنامه رو بصورت شیء گرا بنویسه، یا همینطور از MVC استفاده کنه (بجاش). و بجز اینا یکسری مسائل دیگری هم که بنظرم میرسه که ممکنه درمورد برنامه نویس خوب و برنامه های حرفه ای و سطح بالا مطرح بشه، مباحثی مثل بهینه سازی (از نظر پرفورمنس) و مقیاس پذیریه.

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

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

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

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

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

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

مسائلی که مورد تمرکز و بحث اصلی من در این مقاله هستن، مواردی هستن که برای نوشتن برنامه یا نوشتن برنامهء کامل و مستحکم، ضروری هستن. خیلی از برنامه ها رو میشه بدون OOP و MVC هم نوشت، اما بدون مسائل پایه ای که من میگم نمیشه. مثل اینکه آدم بدون لباس و کفش زنده میمونه و حتی میتونه سالم و قوی و سلامت و خوش هم باشه، ولی بدون بدن سالم حالا هر لباس و کفش و کلاه خوبی هم که تنش باشه اون شخص نمیتونه شخص کارا و خوشی باشه! غیر از اینه؟ پس بدن سالم اساسی تر و ضروری تر و پایه ای تر و قدم اول برای یک انسان کارا و خوشحال بودنه. لباس و کفش و کلاه و پول و خونه و ماشین در درجه های بعدی و سطوح بعدی هستن. شما باید اول پایه رو درست کنید، وگرنه حکایت این میشه که خشت اول چون نهد معمار کج…!

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

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

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

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

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

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

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

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

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

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

یک مثال دیگه میزنم.
یک مسئلهء دیگری که شاید بیشتر برنامه نویسان در برنامه هاشون درنظر نمیگیرن اینه که اگر کانفیگ برنامه بعد از مدتی تغییر داده بشه چی میشه، آیا برنامه درست عمل میکنه، آیا با عملیاتی که در زمانی که برنامه کانفیگ های دیگری داشته انجام شدن یا در میانهء انجام هستن مشکل و تداخلی پیش نمیاد؟
مثلا من همین دیروز پریروز یک برنامه ای نوشتم که روی یک فایلی با محتوای خاصی یکسری عملیات ویرایشی توسط کاربر انجام میده. من اومدم و برای این برنامه امکانUndo گذاشتم که کاربر اگر کار اشتباهی کرد و گزینهء ذخیرهء فایل رو زد و پشیمان شد بتونه با زدن دکمهء Undo به شرایط قبل از ذخیره کردن تغییرات برگرده. برای این کار، من قبل از ذخیره کردن هر ویرایش، یک نسخه از فایل جاری رو تحت نام خاص بعلاوهء شمارهء افزایشی با هر نسخه، در جایی ذخیره میکنم. برای تعداد امکان Undo کردن و در نتیجه تعداد فایلهای بکاپ که ذخیره میشن یک متغییر کانفیگ گذاشتم. برام این سوال پیش آمد که خب حالا اگر مثلا دارم یک فایل رو چند بار ویرایش و ذخیره میکنم، اونوقت در این حین تعداد Undo های ممکن رو تغییر بدم، بعد بیام و گزینهء Undo رو برای اون فایلی که داشتم روش کار میکردم اجرا کنم، چی میشه؟ آیا هنوزم درست کار میکنه؟ مثلا شاید قبلا تعداد Undo های ممکن 10 تا بوده، من 8 بار ویرایش کردم و بنابراین 8 فایل بکاپ ایجاد شده، بعد تعداد Undo های ممکن رو به 5 تغییر میدم، حالا اگر دکمهء Undo رو بزنم چی میشه؟ من این مورد رو تست کردم و متوجه شدم که در این شرایط سیستم دچار خطا میشه چون بجای اینکه فایل بکاپ شماره 8 رو بازیابی کنه میاد و فایل شماره 5 رو بازیابی میکنه. با مقداری تفکر و تلاش و تست تونستم الگوریتم Undo رو کاملتر کنم که این حالات رو به نحو درست و امنی هندل کنه. البته طبیعتا این، کار افزوده و حجم و پیچیدگی کد افزوده برای برنامه نویس میشه، ولی برای داشتن یک برنامهء قابل قبول لازمه. برنامه ای که حداقل در حد سواد و بینش و باریک بینی خودت راضیت بکنه. وگرنه بله کسی که اصولا اینقدر سواد و توان و دقت نداره با کوچکترین موفقیت اولیه و سطحی در برنامه نویسی، حال دنیا رو میبره و شاید فکر هم میکنه که شاهکار کرده!

حالا بجز اینطور مثالها، یکسری جزییات در منطق هم هست که موقعی که میخوایم شروع به طراحی الگوریتم کنیم باید درموردشون فکر و تصمیمگیری کنیم. مثلا همین بحث تغییر کانفیگ یک بعد دیگر هم داره. مثلا این سوال مطرح است که منطق درست کدومه، اینکه اگر کاربر از قبل داشته روی فایلی کار میکرده که اون زمان حداکثر تعداد Undo ها 10 تا بوده، حالا که 5 تا شده باید تعداد Undo های ممکن برای اون کاربر هم به 5 تا کاهش پیدا کنه و یا نه و باید تعداد Undo های ممکن از زمانی که کار شروع شده محسوب بشه و بعدا دیگه حتی با تغییر کانفیگ سیستم هم تغییر نکنه؟ (که برای این تغییر نکردن هم البته باید الگوریتم درست تست و طراحی بشه) و چرا! اینا خودشون درسته شاید در درجهء بعدی اهمیت باشن اما در کل مسائل چندان ساده و پیش پا افتاده و کم اهمیتی نیستن،. بحث خود کدنویسی و طراحی الگوریتم نیست بلکه بحث منطق سطح بالاتر و کاربردی ماست که بعدش منجر به طراحی الگوریتم و کدنویسی بر اساس اون میشه. فکر کردن و تصمیمگیری درست روی اینطور مسائل هم بخشی از کار برنامه نویسی است که باز نیاز به دانش و بینش و صرف وقت و انرژی خاص خودش داره. مثلا گاهی هست حتی باید تحقیق کرد، پرسید، یا برنامه های دیگر رو بررسی و تست کرد و الگو گرفت و روشن شد که در اون موارد چطور عمل میکنن و چه استانداردی دارن.

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

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

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

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

در وهله های بعدی در طراحی اینترفیس، یکسری مسائل ظریف دیگر که البته برای خودم هم هنوز جای بحث و تحقیق و تغییر نظر داره چیزهایی هست مثل اینکه با عملیات نامربوط/غیرفعال باید چه کرد؟ یعنی مثلا فرض کنیم ما یه جایی Pagination داریم ولی آیتم های داده ای اونقدری نیستن که از یک صفحه بیشتر بشن. اونوقت آیا مثلا گزینه یا ورودی «رفتن به صفحهء شمارهء…» باید در صفحه موجود باشه؟ آیا در حالتی که کاربردی نداره باید به حالت Disable باشه؟ در خیلی برنامه ها من دیدم که اساسا در این زمینه زیاد روی اینترفیس کار نمیکنن و حالات خاص رو از حالات دیگر تفکیک نمیکنن و اینترفیس کم و بیش مشترک و یکسان است برای تمام شرایط، و فقط به منطق و عملکرد و چکهای پشت صحنه اکتفا میشه. یعنی مثلا در این حالت هنوزم گزینهء رفتن به صفحهء معین وجود داره و کاربر میتونه ازش استفاده کنه، اما طبیعتا در عمل کاری انجام نمیده یا بعضی وقتا هم یک پیام میدن که مثلا صفحهء مورد نظر وجود نداره. همین مسئلهء پیام دادن یا ندادن هم در حالت کلی باز این تفاوت و سوال در برنامه ها وجود داره که باید چطور عمل کرد. مثلا چه فقط یک صفحه داشته باشیم و چه 100 صفحه، کاربر وقتی شماره صفحه ای رو وارد و ارسال میکنه که وجود نداره، بعضی سیستمها هیچ عکس العملی نشون نمیدن، بعضیا پیام میدن که صفحه وجود نداره، بعضیا از همون زمان ورود شماره به کاربر فیدبک میدن یا به وارد کردن شماره صفحه معتبر محدودش میکنن، و از اون طرف بعضیا حالات خاص رو به شکل خاص هندل میکنن، مثلا اگر 100 تا صفحه داریم و کاربر شماره صفحه 1000 رو وارد کرد سیستم آخرین صفحه یعنی صفحهء 100 رو میاره، بعضیا حتی ممکنه صفحهء اول رو بیارن.
همهء اینا بحث استاندارها و منطق بهینه و مفید هست که البته از برنامه به برنامه و شرایط به شرایط و کاربر تا کاربر و نوع و اهمیت کار تفاوت میکنه و لزوما نمیشه یک حکم مطلق کلی برای همه داد. من خودم جواب تمام این سوالها رو الان حضور ذهن ندارم که مطرح و با رفتارهای دیگر یا اشتباه مقایسه کنم و هدف این مقاله هم این نیست، ولی مسئله ای که میخوام بگم اینه که همهء این مسائل وجود دارن و مطرح و مهم هستن بجای خودشون و جزیی از کار و وظایف برنامه نویسان هستند که برنامه نویسان باید درست بدونن درست فکر کنن درست تصمیم بگیرن و هندل کنن. مهم فکر کردن، تحقیق کردن، دانستن و تصمیم گرفتن است، که اینا باعث میشه کارایی و کمال یک برنامه بهبود قابل توجهی پیدا بکنه، وگرنه بله ممکنه در بعضی موارد اختلاف نظر هم باشه یا تصمیم اشتباه هم گرفته بشه. بهرحال بازم مشکل اینه که در این حیطه ها کم دانشی و ناشی گری یا تنبلی و اهمال حداقل بعضی از برنامه نویسان دیده میشه.

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

برنامه نویسان زیادی هستن که هنوز در یادگیری و احاطه و استفاده از رگولار اکسپرشن مشکل دارن! حتی یک طرفی یک بار اومده بود پرسیده بود که آیا یادگیری و استفاده از رگولار اکسپرشن برای همهء برنامه نویسان ضرورت داره؟!!

یک ضعف و کم کاری بزرگی که در خیلی برنامه نویسان دیده میشه ضعف در توانایی در زبان انگلیسی برای خوندن و درک و استفاده از منابع اصلی است که این ضعف اساسی و بزرگیه برای هر برنامه نویسی که شاید خیلی ضعف های دیگر هم به همین مسئله ربط دارن. زبان انگلیسی یکی از اولین مواردی هست که هر برنامه نویس نوآموزی و اصولا هر شخص با تخصص و شغل در حیطهء کامپیوتر باید از همون اول شروع کنه و هرچه زودتر خودش رو به توانایی کافی در اون برسونه. بنده یکی دو سال اول نصف وقت و انرژیم صرف همین مسئله میشد و اولین کاری که تموم کردم حفظ معانی کامل حدود 4 هزار لغت انگلیسی در این مدت بود. یادگیری و تمرین و تثبیت و تکرار و پیشرفت در زبان انگلیسی بعد از این هم تا پایان عمر ما همچنان گرچه با صرف وقت و انرژی کمتری باید طبیعتا همواره ادامه داشته باشه.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

*

شما می‌توانید از این دستورات HTML استفاده کنید: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>