smh
29-11-07, 00:57
آیا شما هم یك برنامهنویس تنها هستید؟ از شما سؤالی دارم. پاسخش را به من نگویید. به خودتان بگویید. واقعاً چقدر خودتان را متعهد به رعایت اصولی میدانید كه فوایدش بیشتر در كار تیمی ظاهر میشود نه كار انفرادی؟ راستش را بگویید. شما هم كثیف كدنویسی میكنید؟!
● آخر مهندسی!
شاید خیلی از مردم ندانند، ولی ما برنامهنویسهای ایرانی كه میدانیم. اغلب ما به تنهایی برنامهنویسی میكنیم. بعضیها فكر میكنند شركتهای نرمافزاری ایرانی قاعدتا محصولاتشان را به صورت تیمی تولید میكنند. بین خودمان باشد! در بیشتر این شركتها، منهای چندتای آنها كه شركتهای بزرگی هستند - البته نه همه آنهایی كه فقط هیكل بزرگ كردهاند - بهرغم وجود چندین نفر كارمند، بازهم برنامهنویس و مغز متفكر یكی است. اگر آن یك نفر از شركت برود، شركت میخوابد! سورسكد یعنی آقای فلانی! داكیومنت ۱ كجاست؟ توی مغز همان آقای فلانی! تحلیلگر سیستم كیست؟
همان آقای فلانی! و طراحی بانك اطلاعاتی؟ چه جالب! باز هم همان آقای فلانی! مسئول پشتیبانی و رفع اشكال مشتری چه كسی است؟ دیگر نمیگویم! پس بقیه چهكارهاند؟ بقیه عبارتند از تایپیست، اپراتور، منشی، گرافیست، مدیر شركت، معاون، بازاریاب، بازهم بازاریاب، یك بازاریاب دیگر، حسابدار، مسئول فروش، تكنسین شركت، پیك شركت و البته این فهرست را میتوان همینطور ادامه داد.
یقیناً ما به این افراد در شركت نیاز داریم ولی تیم برنامهنویسی كجاست؟ واقعاً ما چه استعداد فوقالعادهای در تأسیس و مدیریت یك شركت نرمافزاری داریم! بسیار خوب! با این اوصاف معلوم است كه چرا كیفیت نرمافزارهای اغلب شركتهای ایرانی از سطح معینی بالاتر نمیرود و چرا سورسكد اغلب نرمافزارهایی كه مینویسیم ایراد دارد.
چرا بسیاری از شركتهای نرمافزاری به روشهای اصولی مهندسی نرمافزار پایبندی كمی دارند؟ واقعیت این است كه گاهی مشكلات اقتصادی آنها را مجبور میكند تیم نخبه خود را به حداقل برسانند. ولی منصف باشیم! خیلی وقتها شیطنت اصلی زیر سر همان آقای فلانی است. خیلی از برنامهنویسان ایرانی دوست دارند تنها نخبه تیم خود باشند و پروژهها را به شیوه <كلید در دست> جلو ببرند. چرا اینطوری است؟
شاید به دیگر بروبچههای شركت اعتماد نداریم. بعضی وقتها دلایل اقتصادی دارد. میخواهیم فقط خودمان پولدار شویم. البته كار تولیدی در ایران بازده كمی دارد. از آن گذشته، فرهنگ رعایت كپیرایت نرمافزار و محصولات فكری در ایران ضعیف است و پشت قوانین اندكی هم كه اخیراً تصویب شده، ضمانت اجرایی محكمی وجود ندارد. دلایل اخلاقی هم هست. در واقع نمیخواهیم اسرار كارمان را دیگران بدانند. شاید به این امید كه اصطلاحاً <دست توی این كار زیاد نشود.> شاید هم میخواهیم نام و نشان و اعتباری برای خودمان به هم بزنیم.
● گلبازی ساختیافته با كد!
نمیخواهم شما را نصیحت كنم كه بروید به صورت تیمی برنامهنویسی كنید. به فكرم رسید كه شاید لازم باشد برای این شیوه برنامهنویسی، یعنی برنامهنویسی انفرادی، مدل و متدی بسازیم. وقتی در اینترنت گشتم، به خودم گفتم <ای بابا! ظاهراً این مشكل خیلیهاست.> ولی متأسفانه راهحل، مقاله، بحث و نظر در این زمینه اندك است. چون صنعت جهانی نرمافزار مایل نیست برای روشهای اصولی و صحیح تولید نرمافزار آلترناتیوهای سست بنیاد به وجود بیاید و حق هم دارد.
ولی اگر واقعبین باشیم، این متدولوژیهای ساختیافته و اصولی به كار ما نمیآیند. چون ما در اتمسفر و فضای كاری اساساً متفاوتی زندگی میكنیم. مشتریان ما به گونه دیگری هستند. فرهنگ اقتصادی مردم طور دیگری است و محصول فكری و نرمافزاری در این سرزمین معنا و مفهوم دیگری دارد. امیدوارم به زودی ما هم با تكیه بر اصول جهانی، به سمت برنامهنویسی تیمی و كار مهندسی برویم، ولی تا آن زمان چه؟
تا آن زمان ما نیاز به یك راه حل میانی داریم كه به برنامهنویسان منفرد كمك كند خودشان كیفیت كارشان را بهبود ببخشند و به یك مدل، هم از نظر كسبوكار و هم از نظر فرآیند تكنیكی برنامهنویسی برسند. اغلب ما برنامهنویسان منفرد دلمان نمیخواهد به سمت كدنویسی كثیف (dirty code) برویم.
شاید تاحدودی هم زور میزنیم از متدهای استاندارد برنامهنویسی شیءگرا پیروی كنیم، ولی كسی بالای سرمان نیست كه مراقبمان باشد. حیف كه مایل نیستم سورسكدهایم را مجانی نشانتان بدهم (!) ولی اگر میتوانستید آنها را ببینید، متوجه میشدید كه بهزعم خودم OOP كار كردهام، ولی گویا بعضی جاها هم زیرآبی رفتهام! اغلب ما دلمان میخواهد راهی برای هزاران برنامهنویس منفرد و محروم از مزایای برنامهنویسی تیمی، وجود داشته باشد كه آنها را از این وضعیت بیرون بیاورد.
● چه باید كرد؟
چه توصیههایی به یك برنامهنویس منفرد میتوان ارائه داد كه موجب ارتقای كیفیت كارش شود؟ به نظر من میشود مدل و فلوچارتی درست كرد. یك فلوچارت كاری كه به برنامهنویس توصیهكند <اول فلانكار را بكن، بعدش اینكار را انجام بده، سپس آن كار را، و هروقت به فلان دوراهی رسیدی، اینگونه تصمیم بگیر.> یا مثلاً: <... در این قسمت، كدنویسی كثیف بعداً برایت مشكل درست میكند، پرهیز كن. ولی در آن قسمت دیگر، مشكل چندانی به وجود نمیآید، نگران نباش، برو جلو...> و تا آخر. حتی میتوان تجربیات را به اشتراك گذاشت. مثلاً كدنویسی كثیف را به لحاظ تئوریك تجزیه و تحلیل، و انواع اشتباهات را دسته بندیكنیم و ببینیم هر دسته در كدام نوع از پروژههای نرمافزاری مشكلآفرین خواهند شد. با استفاده از چنین اسلوبی حتماً كیفیت كارمان بالا میرود و كیفیت بالاتر، هم به اعتبار ما میافزاید و هم پول بیشتری در میآوریم!
به دغدغه اول این یادداشت بازمیگردم. اگر بشود مدلی برای <برنامهنویسی انفرادی ساختیافته> پیدا كرد، حتماً میشود این كتابخانههای پیچیده و مفصل سورسكد در اینترنت - كه یك دوجین آنها هم رایگان هستند - را با كمك آن متدولوژی در بافت نرمافزارهای <درب و داغانی> كه به تنهایی مینویسیم، تزریق كنیم. به نظر من، متدولوژی توسعه و ارتقای نرمافزارهایی كه سورس كد ناجوری دارند یا برنامه نویس در قسمتهای مختلف از اسلوب و روشهای یكنواختی استفاده نكردهاست، با متدولوژی ارتقای نرمافزارهایی كه سورسكدشان به صورت اصولی و بر اساس اصول مهندسی نوشته شده است فرق دارد.
اگر نتوانیم مدلی پیدا كنیم، باید همچنان از دست زدن به این سورسها پرهیز كنیم. چون آنها خیلی تمیزند؛ و با منطق حاكم بر پخت و پز ما جور درنمیآیند. این باعث میشود همواره سطح دانش فنی ما از مقدار معینی بالاتر نرود؛ زیرا به زودی نسخه جدیدی از زبان برنامهنویسی مورد علاقه ما روانه بازار میشود و دوباره باید وقت خودمان را صرف رسیدن به یك سطح متوسط دیگر كنیم.
البته واضح است كه خروجی چنین متدی هرگز به پای خروجی كار تیمی نمیرسد. اصولاً انسان یك موجود اجتماعی است و بهترین نتایج را فقط از دل كار گروهی به دست میآورد، ولی اسارت در مدار برنامهنویسی انفرادی هم معضل كوچكی نیست. حل ریشهای این معضل به یك برنامه علمی و فرهنگی دراز مدت در سطح ملی نیاز دارد. اگر همین امروز شروع كنیم، یك نسل طول میكشد تا جواب بگیریم. این پاسخ سریعی برای هزاران برنامهنویس منفردی نیست كه از این راه نان میخورند. پس ارزشش را دارد كه به طور جدی روی این مسئله فكر كنیم. تا نظر شما چه باشد...
---------------------------------------------------------------------
بهروز نوعی پور
پینوشت:
۱- سند راهنمای سورس كد
پایگاه رسمی انتشارات سوره مهر
● آخر مهندسی!
شاید خیلی از مردم ندانند، ولی ما برنامهنویسهای ایرانی كه میدانیم. اغلب ما به تنهایی برنامهنویسی میكنیم. بعضیها فكر میكنند شركتهای نرمافزاری ایرانی قاعدتا محصولاتشان را به صورت تیمی تولید میكنند. بین خودمان باشد! در بیشتر این شركتها، منهای چندتای آنها كه شركتهای بزرگی هستند - البته نه همه آنهایی كه فقط هیكل بزرگ كردهاند - بهرغم وجود چندین نفر كارمند، بازهم برنامهنویس و مغز متفكر یكی است. اگر آن یك نفر از شركت برود، شركت میخوابد! سورسكد یعنی آقای فلانی! داكیومنت ۱ كجاست؟ توی مغز همان آقای فلانی! تحلیلگر سیستم كیست؟
همان آقای فلانی! و طراحی بانك اطلاعاتی؟ چه جالب! باز هم همان آقای فلانی! مسئول پشتیبانی و رفع اشكال مشتری چه كسی است؟ دیگر نمیگویم! پس بقیه چهكارهاند؟ بقیه عبارتند از تایپیست، اپراتور، منشی، گرافیست، مدیر شركت، معاون، بازاریاب، بازهم بازاریاب، یك بازاریاب دیگر، حسابدار، مسئول فروش، تكنسین شركت، پیك شركت و البته این فهرست را میتوان همینطور ادامه داد.
یقیناً ما به این افراد در شركت نیاز داریم ولی تیم برنامهنویسی كجاست؟ واقعاً ما چه استعداد فوقالعادهای در تأسیس و مدیریت یك شركت نرمافزاری داریم! بسیار خوب! با این اوصاف معلوم است كه چرا كیفیت نرمافزارهای اغلب شركتهای ایرانی از سطح معینی بالاتر نمیرود و چرا سورسكد اغلب نرمافزارهایی كه مینویسیم ایراد دارد.
چرا بسیاری از شركتهای نرمافزاری به روشهای اصولی مهندسی نرمافزار پایبندی كمی دارند؟ واقعیت این است كه گاهی مشكلات اقتصادی آنها را مجبور میكند تیم نخبه خود را به حداقل برسانند. ولی منصف باشیم! خیلی وقتها شیطنت اصلی زیر سر همان آقای فلانی است. خیلی از برنامهنویسان ایرانی دوست دارند تنها نخبه تیم خود باشند و پروژهها را به شیوه <كلید در دست> جلو ببرند. چرا اینطوری است؟
شاید به دیگر بروبچههای شركت اعتماد نداریم. بعضی وقتها دلایل اقتصادی دارد. میخواهیم فقط خودمان پولدار شویم. البته كار تولیدی در ایران بازده كمی دارد. از آن گذشته، فرهنگ رعایت كپیرایت نرمافزار و محصولات فكری در ایران ضعیف است و پشت قوانین اندكی هم كه اخیراً تصویب شده، ضمانت اجرایی محكمی وجود ندارد. دلایل اخلاقی هم هست. در واقع نمیخواهیم اسرار كارمان را دیگران بدانند. شاید به این امید كه اصطلاحاً <دست توی این كار زیاد نشود.> شاید هم میخواهیم نام و نشان و اعتباری برای خودمان به هم بزنیم.
● گلبازی ساختیافته با كد!
نمیخواهم شما را نصیحت كنم كه بروید به صورت تیمی برنامهنویسی كنید. به فكرم رسید كه شاید لازم باشد برای این شیوه برنامهنویسی، یعنی برنامهنویسی انفرادی، مدل و متدی بسازیم. وقتی در اینترنت گشتم، به خودم گفتم <ای بابا! ظاهراً این مشكل خیلیهاست.> ولی متأسفانه راهحل، مقاله، بحث و نظر در این زمینه اندك است. چون صنعت جهانی نرمافزار مایل نیست برای روشهای اصولی و صحیح تولید نرمافزار آلترناتیوهای سست بنیاد به وجود بیاید و حق هم دارد.
ولی اگر واقعبین باشیم، این متدولوژیهای ساختیافته و اصولی به كار ما نمیآیند. چون ما در اتمسفر و فضای كاری اساساً متفاوتی زندگی میكنیم. مشتریان ما به گونه دیگری هستند. فرهنگ اقتصادی مردم طور دیگری است و محصول فكری و نرمافزاری در این سرزمین معنا و مفهوم دیگری دارد. امیدوارم به زودی ما هم با تكیه بر اصول جهانی، به سمت برنامهنویسی تیمی و كار مهندسی برویم، ولی تا آن زمان چه؟
تا آن زمان ما نیاز به یك راه حل میانی داریم كه به برنامهنویسان منفرد كمك كند خودشان كیفیت كارشان را بهبود ببخشند و به یك مدل، هم از نظر كسبوكار و هم از نظر فرآیند تكنیكی برنامهنویسی برسند. اغلب ما برنامهنویسان منفرد دلمان نمیخواهد به سمت كدنویسی كثیف (dirty code) برویم.
شاید تاحدودی هم زور میزنیم از متدهای استاندارد برنامهنویسی شیءگرا پیروی كنیم، ولی كسی بالای سرمان نیست كه مراقبمان باشد. حیف كه مایل نیستم سورسكدهایم را مجانی نشانتان بدهم (!) ولی اگر میتوانستید آنها را ببینید، متوجه میشدید كه بهزعم خودم OOP كار كردهام، ولی گویا بعضی جاها هم زیرآبی رفتهام! اغلب ما دلمان میخواهد راهی برای هزاران برنامهنویس منفرد و محروم از مزایای برنامهنویسی تیمی، وجود داشته باشد كه آنها را از این وضعیت بیرون بیاورد.
● چه باید كرد؟
چه توصیههایی به یك برنامهنویس منفرد میتوان ارائه داد كه موجب ارتقای كیفیت كارش شود؟ به نظر من میشود مدل و فلوچارتی درست كرد. یك فلوچارت كاری كه به برنامهنویس توصیهكند <اول فلانكار را بكن، بعدش اینكار را انجام بده، سپس آن كار را، و هروقت به فلان دوراهی رسیدی، اینگونه تصمیم بگیر.> یا مثلاً: <... در این قسمت، كدنویسی كثیف بعداً برایت مشكل درست میكند، پرهیز كن. ولی در آن قسمت دیگر، مشكل چندانی به وجود نمیآید، نگران نباش، برو جلو...> و تا آخر. حتی میتوان تجربیات را به اشتراك گذاشت. مثلاً كدنویسی كثیف را به لحاظ تئوریك تجزیه و تحلیل، و انواع اشتباهات را دسته بندیكنیم و ببینیم هر دسته در كدام نوع از پروژههای نرمافزاری مشكلآفرین خواهند شد. با استفاده از چنین اسلوبی حتماً كیفیت كارمان بالا میرود و كیفیت بالاتر، هم به اعتبار ما میافزاید و هم پول بیشتری در میآوریم!
به دغدغه اول این یادداشت بازمیگردم. اگر بشود مدلی برای <برنامهنویسی انفرادی ساختیافته> پیدا كرد، حتماً میشود این كتابخانههای پیچیده و مفصل سورسكد در اینترنت - كه یك دوجین آنها هم رایگان هستند - را با كمك آن متدولوژی در بافت نرمافزارهای <درب و داغانی> كه به تنهایی مینویسیم، تزریق كنیم. به نظر من، متدولوژی توسعه و ارتقای نرمافزارهایی كه سورس كد ناجوری دارند یا برنامه نویس در قسمتهای مختلف از اسلوب و روشهای یكنواختی استفاده نكردهاست، با متدولوژی ارتقای نرمافزارهایی كه سورسكدشان به صورت اصولی و بر اساس اصول مهندسی نوشته شده است فرق دارد.
اگر نتوانیم مدلی پیدا كنیم، باید همچنان از دست زدن به این سورسها پرهیز كنیم. چون آنها خیلی تمیزند؛ و با منطق حاكم بر پخت و پز ما جور درنمیآیند. این باعث میشود همواره سطح دانش فنی ما از مقدار معینی بالاتر نرود؛ زیرا به زودی نسخه جدیدی از زبان برنامهنویسی مورد علاقه ما روانه بازار میشود و دوباره باید وقت خودمان را صرف رسیدن به یك سطح متوسط دیگر كنیم.
البته واضح است كه خروجی چنین متدی هرگز به پای خروجی كار تیمی نمیرسد. اصولاً انسان یك موجود اجتماعی است و بهترین نتایج را فقط از دل كار گروهی به دست میآورد، ولی اسارت در مدار برنامهنویسی انفرادی هم معضل كوچكی نیست. حل ریشهای این معضل به یك برنامه علمی و فرهنگی دراز مدت در سطح ملی نیاز دارد. اگر همین امروز شروع كنیم، یك نسل طول میكشد تا جواب بگیریم. این پاسخ سریعی برای هزاران برنامهنویس منفردی نیست كه از این راه نان میخورند. پس ارزشش را دارد كه به طور جدی روی این مسئله فكر كنیم. تا نظر شما چه باشد...
---------------------------------------------------------------------
بهروز نوعی پور
پینوشت:
۱- سند راهنمای سورس كد
پایگاه رسمی انتشارات سوره مهر