یک برنامه‌نویس تنها

یک شب پای اینترنت نشسته بودم و بدون هدف مشخصی، به انگیزه یافتن یک خبر، مقاله یا سورس کد جالب در سایت‌های مختلف پرسه می‌زدم. گه‌گاه چیز جالبی پیدا می‌کردم، ولی چون بی‌حوصله بودم، آن صفحه را فقط روی کامپیوتر ذخیره می‌کردم تا بعد بخوانم.
یک شب پای اینترنت نشسته بودم و بدون هدف مشخصی، به انگیزه یافتن یک خبر، مقاله یا سورس کد جالب در سایت‌های مختلف پرسه می‌زدم. گه‌گاه چیز جالبی پیدا می‌کردم، ولی چون بی‌حوصله بودم، آن صفحه را فقط روی کامپیوتر ذخیره می‌کردم تا بعد بخوانم. همین‌طور مشغول وبگردی بودم که به تدریج در افکار خودم غرق شدم. چشمانم به مانیتور بود، ولی ذهنم آنجا نبود. احساس کردم مقداری ناراحت و دلخورم. بعد خوب که فکر کردم، دیدم علتش این است که یک دنیا سورس‌کد، مقاله و منبع مجانی درباره برنامه‌نویسی پیشرفته وجود دارد که من نمی‌توانم طرفش بروم. چرا؟ چون بعضی از آن ها ساختار پیچیده‌ای دارند و بازخوانی و فراگرفتن آن‌ها، وقت زیادی می‌طلبد که من ندارم. از طرفی، حتی اگر وقت کافی برای مطالعه و یادگیری این سورس‌کدهای پیچیده بگذارم، چگونه می‌توانم آن‌ها را پایه و اساس پروژه‌های بعدی خودم قرار دهم؟
من به تنهایی چگونه می‌توانم از پس چنین پروژه‌های سنگینی برآیم؟ در خیلی از سایت‌ها حرف‌هایی درباره Versioning ،Enterprise Library، متدهای تست نرم‌افزار، متدولوژی طراحی دیتابیس، مدل سازی نرم‌افزار، مستندسازی کد و از همه مهم‌تر، کار تیمی مطرح شده است. وقتی من حتی یک برنامه‌نویس دیتابیس دم دستم نیست، سخت‌گیری در جداسازی هرچه بیشتر لایه دسترسی به داده‌ها از Business Layer و لایه نمایش در مدل شی‌ء گرایی، چه معنایی دارد؟ به نظرم این بیشتر نوعی ایده‌آلسیم است. وقتی در نود درصد پروژه‌ها باید هم تحلیلگر سیستم باشم، هم برنامه‌نویس، هم طراح اینترفیس باشم، هم طراح دیتابیس، هم تست کنم، هم اشکال زدایی، و هم دستآخر، شال و کلاه کنم بروم جلوی مغازه مشتری و برای گرفتن چک تسویه حساب پروژه چانه بزنم، اساسا ًOOP چه معنایی دارد؟
آیا شما هم یک برنامه‌نویس تنها هستید؟ از شما سؤالی دارم. پاسخش را به من نگویید. به خودتان بگویید. واقعاً چقدر خودتان را متعهد به رعایت اصولی می‌دانید که فوایدش بیشتر در کار تیمی ظاهر می‌شود نه کار انفرادی؟ راستش را بگویید. شما هم کثیف کدنویسی می‌کنید؟!
● آخر مهندسی!
شاید خیلی از مردم ندانند، ولی ما برنامه‌نویس‌های ایرانی که می‌دانیم. اغلب ما به تنهایی برنامه‌نویسی می‌کنیم. بعضی‌ها فکر می‌کنند شرکت‌های نرم‌افزاری ایرانی قاعدتا محصولاتشان را به صورت تیمی تولید می‌کنند. بین خودمان باشد! در بیشتر این شرکت‌ها، منهای چندتای آن‌ها که شرکت‌های بزرگی هستند - البته نه همه آن‌هایی که فقط هیکل بزرگ کرده‌اند - به‌رغم وجود چندین نفر کارمند، بازهم برنامه‌نویس و مغز متفکر یکی است. اگر آن یک نفر از شرکت برود، شرکت می‌خوابد! سورس‌کد یعنی آقای فلانی! داکیومنت ۱ کجاست؟ توی مغز همان آقای فلانی! تحلیلگر سیستم کیست؟
همان آقای فلانی! و طراحی بانک اطلاعاتی؟ چه جالب! باز هم همان آقای فلانی! مسئول پشتیبانی و رفع اشکال مشتری چه کسی است؟ دیگر نمی‌گویم! پس بقیه چه‌کاره‌اند؟ بقیه عبارتند از تایپیست، اپراتور، منشی، گرافیست، مدیر شرکت، معاون، بازاریاب، بازهم بازاریاب، یک بازاریاب دیگر، حسابدار، مسئول فروش، تکنسین شرکت، پیک شرکت و البته این فهرست را می‌توان همین‌طور ادامه داد. یقیناً ما به این افراد در شرکت نیاز داریم ولی تیم برنامه‌نویسی کجاست؟ واقعاً ما چه استعداد فوق‌العاده‌ای در تأسیس و مدیریت یک شرکت نرم‌افزاری داریم! بسیار خوب! با این اوصاف معلوم است که چرا کیفیت نرم‌افزارهای اغلب شرکت‌های ایرانی از سطح معینی بالاتر نمی‌رود و چرا سورس‌کد اغلب نرم‌افزارهایی که می‌نویسیم ایراد دارد.
چرا بسیاری از شرکت‌های نرم‌افزاری به روش‌های اصولی مهندسی نرم‌افزار پایبندی کمی دارند؟ واقعیت این است که گاهی مشکلات اقتصادی آن‌ها را مجبور می‌کند تیم نخبه خود را به حداقل برسانند. ولی منصف باشیم! خیلی وقت‌ها شیطنت اصلی زیر سر همان آقای فلانی است. خیلی از برنامه‌نویسان ایرانی دوست دارند تنها نخبه تیم خود باشند و پروژه‌ها را به شیوه <کلید در دست> جلو ببرند. چرا این‌طوری است؟ شاید به دیگر بروبچه‌های شرکت اعتماد نداریم. بعضی وقت‌ها دلایل اقتصادی دارد. می‌خواهیم فقط خودمان پولدار شویم. البته کار تولیدی در ایران بازده کمی دارد. از آن گذشته، فرهنگ رعایت کپی‌رایت نرم‌افزار و محصولات فکری در ایران ضعیف است و پشت قوانین اندکی هم که اخیراً تصویب شده، ضمانت اجرایی محکمی وجود ندارد. دلایل اخلاقی هم هست. در واقع نمی‌خواهیم اسرار کارمان را دیگران بدانند. شاید به این امید که اصطلاحاً <دست توی این کار زیاد نشود.> شاید هم می‌خواهیم نام و نشان و اعتباری برای خودمان به هم بزنیم.
● گل‌بازی ساخت‌یافته با کد!
نمی‌خواهم شما را نصیحت کنم که بروید به صورت تیمی برنامه‌نویسی کنید. به فکرم رسید که شاید لازم باشد برای این شیوه برنامه‌نویسی، یعنی برنامه‌نویسی انفرادی، مدل و متدی بسازیم. وقتی در اینترنت گشتم، به خودم گفتم <ای بابا! ظاهراً این مشکل خیلی‌هاست.> ولی متأسفانه راه‌حل، مقاله، بحث و نظر در این زمینه اندک است. چون صنعت جهانی نرم‌افزار مایل نیست برای روش‌های اصولی و صحیح تولید نرم‌افزار آلترناتیوهای سست بنیاد به وجود بیاید و حق هم دارد. ولی اگر واقع‌بین باشیم، این متدولوژی‌های ساخت‌یافته و اصولی به کار ما نمی‌آیند. چون ما در اتمسفر و فضای کاری اساساً متفاوتی زندگی می‌کنیم. مشتریان ما به گونه دیگری هستند. فرهنگ اقتصادی مردم طور دیگری است و محصول فکری و نرم‌افزاری در این سرزمین معنا و مفهوم دیگری دارد. امیدوارم به زودی ما هم با تکیه بر اصول جهانی، به سمت برنامه‌نویسی تیمی و کار مهندسی برویم، ولی تا آن زمان چه؟
تا آن زمان ما نیاز به یک راه حل میانی داریم که به برنامه‌نویسان منفرد کمک کند خودشان کیفیت کارشان را بهبود ببخشند و به یک مدل، هم از نظر کسب‌وکار و هم از نظر فرآیند تکنیکی برنامه‌نویسی برسند. اغلب ما برنامه‌نویسان منفرد دلمان نمی‌خواهد به سمت کدنویسی کثیف (dirty code) برویم. شاید تاحدودی هم زور می‌زنیم از متدهای استاندارد برنامه‌نویسی شیء‌گرا پیروی کنیم، ولی کسی بالای سرمان نیست که مراقبمان باشد. حیف که مایل نیستم سورس‌کدهایم را مجانی نشانتان بدهم (!) ولی اگر می‌توانستید آن‌ها را ببینید، متوجه می‌شدید که به‌زعم خودم OOP کار کرده‌ام، ولی گویا بعضی جاها هم زیرآبی رفته‌ام! اغلب ما دلمان می‌خواهد راهی برای هزاران برنامه‌نویس منفرد و محروم از مزایای برنامه‌نویسی تیمی، وجود داشته باشد که آن‌ها را از این وضعیت بیرون بیاورد.
چه باید کرد؟ چه توصیه‌هایی به یک برنامه‌نویس منفرد می‌توان ارائه داد که موجب ارتقای کیفیت کارش شود؟ به نظر من می‌شود مدل و فلوچارتی درست کرد. یک فلوچارت کاری که به برنامه‌نویس توصیه‌کند <اول فلان‌کار را بکن، بعدش این‌کار را انجام بده، سپس آن کار را، و هروقت به فلان دوراهی رسیدی، این‌گونه تصمیم ‌بگیر.> یا مثلاً: <... در این قسمت، کدنویسی کثیف بعداً برایت مشکل درست می‌کند، پرهیز کن. ولی در آن قسمت دیگر، مشکل چندانی به وجود نمی‌آید، نگران نباش، برو جلو...> و تا آخر. حتی می‌توان تجربیات را به اشتراک گذاشت. مثلاً کدنویسی کثیف را به لحاظ تئوریک تجزیه و تحلیل، و انواع اشتباهات را دسته بندی‌کنیم و ببینیم هر دسته در کدام نوع از پروژه‌های نرم‌افزاری مشکلآفرین خواهند شد. با استفاده از چنین اسلوبی حتماً کیفیت کارمان بالا می‌رود و کیفیت بالاتر، هم به اعتبار ما می‌افزاید و هم پول بیشتری در می‌آوریم!
به دغدغه اول این یادداشت بازمی‌گردم. اگر بشود مدلی برای <برنامه‌نویسی انفرادی ساخت‌یافته> پیدا کرد، حتماً می‌شود این کتابخانه‌های پیچیده و مفصل سورس‌کد در اینترنت - که یک دوجین آن‌ها هم رایگان هستند - را با کمک آن متدولوژی در بافت نرم‌افزارهای <درب و داغانی> که به تنهایی می‌نویسیم، تزریق کنیم. به نظر من، متدولوژی توسعه و ارتقای نرم‌افزارهایی که سورس کد ناجوری دارند یا برنامه نویس در قسمت‌های مختلف از اسلوب و روش‌های یکنواختی استفاده نکرده‌است، با متدولوژی ارتقای نرم‌افزارهایی که سورس‌کدشان به صورت اصولی و بر اساس اصول مهندسی نوشته شده است فرق دارد.
اگر نتوانیم مدلی پیدا کنیم، باید همچنان از دست زدن به این سورس‌ها پرهیز کنیم. چون آن‌ها خیلی تمیزند؛ و با منطق حاکم بر پخت و پز ما جور درنمی‌آیند. این باعث می‌شود همواره سطح دانش فنی ما از مقدار معینی بالاتر نرود؛ زیرا به زودی نسخه جدیدی از زبان برنامه‌نویسی مورد علاقه ما روانه بازار می‌شود و دوباره باید وقت خودمان را صرف رسیدن به یک سطح متوسط دیگر کنیم.
البته واضح است که خروجی چنین متدی هرگز به پای خروجی کار تیمی نمی‌رسد. اصولاً انسان یک موجود اجتماعی است و بهترین نتایج را فقط از دل کار گروهی به دست می‌آورد، ولی اسارت در مدار برنامه‌نویسی انفرادی هم معضل کوچکی نیست. حل ریشه‌ای این معضل به یک برنامه علمی و فرهنگی دراز مدت در سطح ملی نیاز دارد. اگر همین امروز شروع کنیم، یک نسل طول می‌کشد تا جواب بگیریم. این پاسخ سریعی برای هزاران برنامه‌نویس منفردی نیست که از این راه نان می‌خورند. پس ارزشش را دارد که به طور جدی روی این مسئله فکر کنیم. تا نظر شما چه باشد...

منبع : انجمن علمی دانشگاه شیخ بهایی