دغدغه های یک برنامه نویس تنها

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