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