دغدغه‌های یک برنامه‌نویس تنها
تاریخ مقاله : 07 / 10 / 1385
منبع : ماهنامه شبکه
نویسنده : بهروز نوعی پور
متن مقاله :
یک شب پای اینترنت نشسته بودم و بدون هدف مشخصی، به انگیزه یافتن یک خبر، مقاله یا سورس کد جالب در سایت‌های مختلف پرسه می‌زدم. گه‌گاه چیز جالبی پیدا می‌کردم، ولی چون بی‌حوصله بودم، آن صفحه را فقط روی کامپیوتر ذخیره می‌کردم تا بعد بخوانم. همین‌طور مشغول وبگردی بودم که به تدریج در افکار خودم غرق شدم. چشمانم به مانیتور بود، ولی ذهنم آنجا نبود. احساس کردم مقداری ناراحت و دلخورم. بعد خوب که فکر کردم، دیدم علتش این است که یک دنیا سورس‌کد، مقاله و منبع مجانی درباره برنامه‌نویسی پیشرفته وجود دارد که من نمی‌توانم طرفش بروم. چرا؟ چون بعضی از آن ها ساختار پیچیده‌ای دارند و بازخوانی و فراگرفتن آنها، وقت زیادی می‌طلبد که من ندارم. از طرفی، حتی اگر وقت کافی برای مطالعه و یادگیری این سورس‌کدهای پیچیده بگذارم، چگونه می‌توانم آنها را پایه و اساس پروژه‌های بعدی خودم قرار دهم؟
من به تنهایی چگونه می‌توانم از پس چنین پروژه‌های سنگینی برآیم؟ در خیلی از سایت‌ها حرف‌هایی درباره Versioning ،Enterprise Library، متدهای تست نرم‌افزار، متدولوژی طراحی دیتابیس، مدل سازی نرم‌افزار، مستندسازی کد و از همه مهم‌تر، کار تیمی مطرح شده است. وقتی من حتی یک برنامه‌نویس دیتابیس دم دستم نیست، سخت‌گیری در جداسازی هرچه بیشتر لایه دسترسی به داده‌ها از Business Layer و لایه نمایش در مدل شی‌ء گرایی، چه معنایی دارد؟ به نظرم این بیشتر نوعی ایده‌آلسیم است. وقتی در نود درصد پروژه‌ها باید هم تحلیلگر سیستم باشم، هم برنامه‌نویس، هم طراح اینترفیس باشم، هم طراح دیتابیس، هم تست کنم، هم اشکال زدایی، و هم دستآخر، شال و کلاه کنم بروم جلوی مغازه مشتری و برای گرفتن چک تسویه حساب پروژه چانه بزنم، اساسا ًOOP چه معنایی دارد؟
آیا شما هم یک برنامه‌نویس تنها هستید؟ از شما سؤالی دارم. پاسخش را به من نگویید. به خودتان بگویید. واقعاً چقدر خودتان را متعهد به رعایت اصولی می‌دانید که فوایدش بیشتر در کار تیمی ظاهر می‌شود نه کار انفرادی؟ راستش را بگویید. شما هم کثیف کدنویسی میکنید؟!
آخر مهندسی!
شاید خیلی از مردم ندانند، ولی ما برنامه‌نویس‌های ایرانی که می‌دانیم. اغلب ما به تنهایی برنامه‌نویسی می‌کنیم. بعضی‌ها فکر می‌کنند شرکت‌های نرم‌افزاری ایرانی قاعدتا محصولاتشان را به صورت تیمی تولید می‌کنند. بین خودمان باشد! در بیشتر این شرکت‌ها، منهای چندتای آنها که شرکت‌های بزرگی هستند - البته نه همه آن‌هایی که فقط هیکل بزرگ کرده‌اند - به‌رغم وجود چندین نفر کارمند، بازهم برنامه‌نویس و مغز متفکر یکی است. اگر آن یک نفر از شرکت برود، شرکت می‌خوابد! سورس‌کد یعنی آقای فلانی! داکیومنت 1 کجاست؟ توی مغز همان آقای فلانی! تحلیلگر سیستم کیست؟
همان آقای فلانی! و طراحی بانک اطلاعاتی؟ چه جالب! باز هم همان آقای فلانی! مسئول پشتیبانی و رفع اشکال مشتری چه کسی است؟ دیگر نمی‌گویم! پس بقیه چه‌کاره‌اند؟ بقیه عبارتند از تایپیست، اپراتور، منشی، گرافیست، مدیر شرکت، معاون، بازاریاب، بازهم بازاریاب، یک بازاریاب دیگر، حسابدار، مسئول فروش، تکنسین شرکت، پیک شرکت و البته این فهرست را می‌توان همین‌طور ادامه داد. یقیناً ما به این افراد در شرکت نیاز داریم ولی تیم برنامه‌نویسی کجاست؟ واقعاً ما چه استعداد فوق‌العاده‌ای در تأسیس و مدیریت یک شرکت نرم‌افزاری داریم! بسیار خوب! با این اوصاف معلوم است که چرا کیفیت نرم‌افزارهای اغلب شرکت‌های ایرانی از سطح معینی بالاتر نمی‌رود و چرا سورس‌کد اغلب نرم‌افزارهایی که می‌نویسیم ایراد دارد.
چرا بسیاری از شرکت‌های نرم‌افزاری به روش‌های اصولی مهندسی نرم‌افزار پایبندی کمی دارند؟ واقعیت این است که گاهی مشکلات اقتصادی آنها را مجبور می‌کند تیم نخبه خود را به حداقل برسانند. ولی منصف باشیم! خیلی وقت‌ها شیطنت اصلی زیر سر همان آقای فلانی است. خیلی از برنامه‌نویسان ایرانی دوست دارند تنها نخبه تیم خود باشند و پروژه‌ها را به شیوه <کلید در دست> جلو ببرند. چرا این‌طوری است؟ شاید به دیگر بروبچه‌های شرکت اعتماد نداریم. بعضی وقت‌ها دلایل اقتصادی دارد. می‌خواهیم فقط خودمان پولدار شویم. البته کار تولیدی در ایران بازده کمی دارد. از آن گذشته، فرهنگ رعایت کپی‌رایت نرم‌افزار و محصولات فکری در ایران ضعیف است و پشت قوانین اندکی هم که اخیراً تصویب شده، ضمانت اجرایی محکمی وجود ندارد. دلایل اخلاقی هم هست. در واقع نمی‌خواهیم اسرار کارمان را دیگران بدانند. شاید به این امید که اصطلاحاً <دست توی این کار زیاد نشود.> شاید هم می‌خواهیم نام و نشان و اعتباری برای خودمان به هم بزنیم.
گل‌بازی ساخت‌یافته با کد!
نمی‌خواهم شما را نصیحت کنم که بروید به صورت تیمی برنامه‌نویسی کنید. به فکرم رسید که شاید لازم باشد برای این شیوه برنامه‌نویسی، یعنی برنامه‌نویسی انفرادی، مدل و متدی بسازیم. وقتی در اینترنت گشتم، به خودم گفتم <ای بابا! ظاهراً این مشکل خیلی‌هاست.> ولی متأسفانه راه‌حل، مقاله، بحث و نظر در این زمینه اندک است. چون صنعت جهانی نرم‌افزار مایل نیست برای روش‌های اصولی و صحیح تولید نرم‌افزار آلترناتیوهای سست بنیاد به وجود بیاید و حق هم دارد. ولی اگر واقع‌بین باشیم، این متدولوژی‌های ساخت‌یافته و اصولی به کار ما نمی‌آیند. چون ما در اتمسفر و فضای کاری اساساً متفاوتی زندگی می‌کنیم. مشتریان ما به گونه دیگری هستند. فرهنگ اقتصادی مردم طور دیگری است و محصول فکری و نرم‌افزاری در این سرزمین معنا و مفهوم دیگری دارد. امیدوارم به زودی ما هم با تکیه بر اصول جهانی، به سمت برنامه‌نویسی تیمی و کار مهندسی برویم، ولی تا آن زمان چه؟
تا آن زمان ما نیاز به یک راه حل میانی داریم که به برنامه‌نویسان منفرد کمک کند خودشان کیفیت کارشان را بهبود ببخشند و به یک مدل، هم از نظر کسب‌وکار و هم از نظر فرآیند تکنیکی برنامه‌نویسی برسند. اغلب ما برنامه‌نویسان منفرد دلمان نمی‌خواهد به سمت کدنویسی کثیف (dirty code) برویم. شاید تاحدودی هم زور می‌زنیم از متدهای استاندارد برنامه‌نویسی شیء‌گرا پیروی کنیم، ولی کسی بالای سرمان نیست که مراقبمان باشد. حیف که مایل نیستم سورس‌کدهایم را مجانی نشانتان بدهم (!) ولی اگر می‌توانستید آنها را ببینید، متوجه می‌شدید که به‌زعم خودم OOP کار کرده‌ام، ولی گویا بعضی جاها هم زیرآبی رفته‌ام! اغلب ما دلمان می‌خواهد راهی برای هزاران برنامه‌نویس منفرد و محروم از مزایای برنامه‌نویسی تیمی، وجود داشته باشد که آنها را از این وضعیت بیرون بیاورد.
چه باید کرد؟ چه توصیه‌هایی به یک برنامه‌نویس منفرد می‌توان ارائه داد که موجب ارتقای کیفیت کارش شود؟ به نظر من می‌شود مدل و فلوچارتی درست کرد. یک فلوچارت کاری که به برنامه‌نویس توصیه‌کند <اول فلان‌کار را بکن، بعدش این‌کار را انجام بده، سپس آن کار را، و هروقت به فلان دوراهی رسیدی، این‌گونه تصمیم بگیر.> یا مثلاً: <... در این قسمت، کدنویسی کثیف بعداً برایت مشکل درست می‌کند، پرهیز کن. ولی در آن قسمت دیگر، مشکل چندانی به وجود نمی‌آید، نگران نباش، برو جلو...> و تا آخر. حتی می‌توان تجربیات را به اشتراک گذاشت. مثلاً کدنویسی کثیف را به لحاظ تئوریک تجزیه و تحلیل، و انواع اشتباهات را دسته بندی‌کنیم و ببینیم هر دسته در کدام نوع از پروژه‌های نرم‌افزاری مشکلآفرین خواهند شد. با استفاده از چنین اسلوبی حتماً کیفیت کارمان بالا می‌رود و کیفیت بالاتر، هم به اعتبار ما می‌افزاید و هم پول بیشتری در می‌آوریم!
به دغدغه اول این یادداشت بازمی‌گردم. اگر بشود مدلی برای <برنامه‌نویسی انفرادی ساخت‌یافته> پیدا کرد، حتماً می‌شود این کتابخانه‌های پیچیده و مفصل سورس‌کد در اینترنت - که یک دوجین آنها هم رایگان هستند - را با کمک آن متدولوژی در بافت نرم‌افزارهای <درب و داغانی> که به تنهایی می‌نویسیم، تزریق کنیم. به نظر من، متدولوژی توسعه و ارتقای نرم‌افزارهایی که سورس کد ناجوری دارند یا برنامه نویس در قسمت‌های مختلف از اسلوب و روش‌های یکنواختی استفاده نکرده‌است، با متدولوژی ارتقای نرم‌افزارهایی که سورس‌کدشان به صورت اصولی و بر اساس اصول مهندسی نوشته شده است فرق دارد.
اگر نتوانیم مدلی پیدا کنیم، باید همچنان از دست زدن به این سورس‌ها پرهیز کنیم. چون آنها خیلی تمیزند؛ و با منطق حاکم بر پخت و پز ما جور درنمی‌آیند. این باعث می‌شود همواره سطح دانش فنی ما از مقدار معینی بالاتر نرود؛ زیرا به زودی نسخه جدیدی از زبان برنامه‌نویسی مورد علاقه ما روانه بازار می‌شود و دوباره باید وقت خودمان را صرف رسیدن به یک سطح متوسط دیگر کنیم.
البته واضح است که خروجی چنین متدی هرگز به پای خروجی کار تیمی نمی‌رسد. اصولاً انسان یک موجود اجتماعی است و بهترین نتایج را فقط از دل کار گروهی به دست می‌آورد، ولی اسارت در مدار برنامه‌نویسی انفرادی هم معضل کوچکی نیست. حل ریشه‌ای این معضل به یک برنامه علمی و فرهنگی دراز مدت در سطح ملی نیاز دارد. اگر همین امروز شروع کنیم، یک نسل طول می‌کشد تا جواب بگیریم. این پاسخ سریعی برای هزاران برنامه‌نویس منفردی نیست که از این راه نان می‌خورند. پس ارزشش را دارد که به طور جدی روی این مسئله فکر کنیم. تا نظر شما چه باشد...
نقل قول: دغدغه‌های یک برنامه‌نویس تنها
من هم با شما موافقم(یعنی کی که موافق نیست؟!!!)
در ایران مشکل نرم افزار همانطور که فرمودید یکی و دو تا که نیست. فکر میکنید اگر یک شرکت برنامه سازی یک تیم حرفه ای رو دور هم جمع کنه و یه محصول ایده ال به بازار بفرسته با توجه به وضعیت اقتصادی مردم و قانون مرده کپی رایت و احتمالا(همون 100%) قیمت بالای آن نرم افزار ، شرکت مربوطه ورش نمیشکنه؟(همون ورشکست)
هیچ نهادی هم از شرکت مربوطه حمایت نخواهد کرد که لااقل قیمت نرم افزارش بیاد پایین
از شکستن قفل و کرک هم چیزی نگم بهتره.
نقل قول: دغدغه‌های یک برنامه‌نویس تنها
هر چند حدود دو سال از تاریخ انتشار مقاله میگذره، ولی به بهانه بالا آورده شدن تاپیک توسط یکی از کاربران...
با نویسنده موافقم که در ایران برنامه نویسی تیمی جایگاه مطلوبی نداره، ولی با این فضای نوشته اش که سعی کرده به نوعی برنامه نویسی انفرادی را مساوی کدنویسی کثیف معرفی کنه، موافق نیستم. کار تیمی خوب هست و باید برنامه نویسان ایرانی به این سمت حرکت کنند، ولی تنها کار کردن لزوما به معنی پیروی نکردن از اصول نیست. مشکل اکثر برنامه نویس هایی که در کارهای انفرادی نمی تونند اصول مشخصی را پیروی کنند این هست که به آنها اصول برنامه نویسی در یک نرم افزار بزرگ و بصورت گروهی را یاد می دهند، ولی آنها می خواهند همان نکات را در یک برنامه کوچک و بطور انفرادی اجرا کنند. نتیجه اش این می شود که برنامه نویس به این نتیجه می رسد که پیروی از این اصول بیشتر موجب اتلاف وقت می شود، تا افزایش بهره وری.
برنامه نویسی که تنها کار می کند، باید از روش هایی استفاده کند که مناسب پروژه های کوچک و متوسط باشد. مثلا بجای آنکه سعی کند تمام جزئیات مطرح شده در RUP را رعایت کند، و انواع و اقسام Artifactهای بی مصرف را برای پروژه خودش بسازد، یاد بگیرد که RUP باید برای نوع کاری که او انجام می دهد شخصی سازی شود، و قرار نیست از همه جزئیات آن در همه پروژه ها استفاده کرد. معمولا برنامه نویسان ما چنان پروسه های سنگینی را برای توسعه نرم افزار انتخاب می کنند، که اگر قرار باشد واقعا برنامه نویسی کنند، باید بی خیال متد توسعه انتخاب شده بشوند، و اگر بخواهند حتما از متد انتخاب شده پیروی کنند، باید بیشتر ار اهداف پروژه روی روش توسعه آن وقت صرف کنند. مثلا در یک پروژه تک نفره کوچک نیازی نیست که نمودارهای UML با تمام جزئیات و به دقیق ترین شکل ممکن رسم شوند، همینقدر که منظور مورد نظر را برسانند، کفایت می کند، ولی خیلی از برنامه نویسان در پروژه های کوچک و متوسط (که اغلب پروژه های ایرانی را تشکیل می دهند) چنان درگیر جزئیات غیرلازم یک نمودار UML می شوند که دغدغه رسم دقیق و با جزئیات UML برای آنها از دغدغه به سرانجام رسیدن پروژه پررنگ تر هست.
همین مسئله در سایر موضوعات برنامه نویسی هم صدق می کند، مثلا وقتی بحث Patternها مطرح می شود، علی رغم آنکه بارها گفته شده که Patternهای موجود فقط در شرایطی که در صورت مسئله آنها مشخص شده بهترین گزینه هستند، و برنامه نویس نباید در همه شرایط آنها را وحی منزل بداند، اما خیلی از برنامه نویسان ما بیشتر از اینکه دغدغه حل مسئله موجود در پروژه خود را داشته باشند، دنبال این هستند که در فلان کد حتما از فلان Pattern استفاده شود، و...
در واقع نوعی استاندارد زدگی بوجود میاد؛ یعنی برنامه نویس بجای اینکه متدهای ارائه شده، Patternها، و کلا استانداردهای مطرح شده را ابزاری برای تولید کد بهتر و در نتیجه محصول بهتری در نظر بگیره، و سعی کنه آنها را متناسب با نیازهای خودش شخصی سازی کنه، یا چنان غرق این استانداردها و متدها میشه که محصول نهایی را فراموش میکنه، یا این استانداردها را چنان دست و پا گیر میبینه که ترجیح میده برای حفظ محصول خودش، آنها را دور بزنه.
نقل قول: دغدغه‌های یک برنامه‌نویس تنها
پیشنهاد من این است که برنامه نویس‌های ایرانی برای ارتقای سطح دانش خود و کسب اعتماد به نفس در یک پروژه Open Source به طور جدی با چند برنامه نویس غیر ایرانی همکار شوند. مطمئنا این کار باعث ارتقای سطح دانش برنامه نویسان ایرانی خواهد شد.
نقل قول: دغدغه‌های یک برنامه‌نویس تنها
نقل قول:
نوشته شده توسط
afsharm
پیشنهاد من این است که برنامه نویس‌های ایرانی برای ارتقای سطح دانش خود و کسب اعتماد به نفس در یک پروژه Open Source به طور جدی با چند برنامه نویس غیر ایرانی همکار شوند. مطمئنا این کار باعث ارتقای سطح دانش برنامه نویسان ایرانی خواهد شد.
برنامه نویس خارجی از کجا گیر بیاریم که همکار شیم؟!
نقل قول: دغدغه‌های یک برنامه‌نویس تنها
با سلام
ببینید دوستان این مشکل نه تنها در مورد برنامه نویسی و دنیای کامپیوتر بلکه در کل کشور عزیز ما وجود داره. مثلاً شما در ورزش ملاحظه می کنید اکثر رشته هایی که ما در جهان حرفی برای گفتن داریم انفرادی هستند (کشتی ، وزنه برداری ، تکواندو . . .) یا اگر یک نگاه به ابداعات و اختراعات داخلی بیاندازید اکثراً یک یا دو نفره هستند. در مقاله ها ، پروژه ها و کنفرانس های داخلی نیز این موضوع به چشم می خورد (اکثر paper های داخلی که من میبینم یک یا حداکثر دو نفره هست ولی در خیلی از کشور های دیگر . . .)
بنظر شما مشکل از کجاست؟
