اولا که خودت نمیفهمی چی داری میخونی! دوما که … حالا موندهاش رو بخون شاید اینبار فهمیدی
درود بسیار بر دوستان گرامی. میدونم تو دلتون چی میگین و کاملا حق با شماست. گرفتار بودم بابا! هم کاری هم احساسی هم غیر کاری و غیر احساسی. حال و حوصلهی مقدمه چینی هم ندارم پس میریم سر اصل مطلب.
خوب جوونا، میخوام ببرمتون به اون دور دور ها زمانی که بابا کوچک بود. اون زمونا تو هنوز به دنیا نیومده بودی. اون زمانهای دور که دل ما پر بود از شادی وشور و تو موها تو بافته بودی و با گل سفید یاس گلوبند ساخته بودی، من هم داشتم برای خودم کتاب میخوندم تا یک روزی برم تو مایکرسافت استخدام بشم (خوب چیه مگه؟ بچه بودم خوب! ) . هم انگلیسی و هم فارسی. اما برخی مطالب رو ده بار هم میخوندم نمیفهمیدیم. بویژه مباحث مدیریتی و مهندسی رو. برنامه نویسی رو سه سوت میگرفتم اما مهندسی رو نه. نخست فکر میکردم چون اینا برگردان فارسی هستن پس لابد چرت و پرت هستن اینه که فارسی رو گذاشتم کنار و زدم تو نخ انگلیسی. البته انگلیسیاش خیلی بهتر بود اما بازم همون آش بود و همون کاسه و من نمیفهمیدم چرا یک سری از مطالب اینقدر برای من نا ملموس هستن. من تا سالها درست نمیفهمیدم فاز امکان سنجی با طراحی چه فرقی میکنه یا اینکه روشهایی که بر پایهی آزمودن نرمافزار ساخته شدن چه سودی دارن؟ حتی فازهای کلاسیک رو هم درست نمیفهمیدم چه برسه به روشهای مردن رو. بعدا که وارد کار شدم و یکی دو تا نرمافزار نوشتم و با مشتری سر و کله زدم دیدم کمکم داره یه چیزایی حالیم میشه و حتی چند بار ناچار شدم برخی از اون مطالب رو دوباره بخونم اما اینبار با بارهای پیش یک فرق بزرگ داشت… من میفهمیدم چی دارم میخونم! نخستین باری که وادار شدم به معنی «تحلیل» درست فکر کنم برای یک نرمافزاری بود که نیاز به ساختن یک الگوریتم ویژه برای پردازش داده داشت. من خیلی باهوش بودم و تا پیش از اون نیازی نداشتم که اول فکر کنم بعد کد بنویسم. همهی فازها و نقشها رو از بر بودم اما درست نمیفهمیدم. تا اینکه اون روز از صبح تا شب دهنم سرویس شد اما نتونستم الگوریتم رو پیاده سازی کنم. مشکل ابن بود که من به اندازهی کافی تحلیل نمیکردم و خیال میکردم همهی مسئله رو فهمیدم اما هیشه وسط کدنویسی یکهو میفهمیدم که فلان بخش رو تازه دارم میبینم یا فلان جای کار با بهمان جای بقیهی کار ناهماهنگی داره و هزار جور گیر و گرفتاری دیگه که حتی فکرش رو هم نمی کردم. یک ده باری دوباره کاری کردم و بار دهم به خودم اومدم و دیدم کلا درکم از مسئله تغییر کرده و آلان متوجه میشم که نخستین راه حلی که در اندیشه داشتم چهاندازه چرت و پرت بوده. با خودم گفتم اینجوری نمیشه و من نخست باید تا جایی که میتونم به این مسئله فکر کنم و همهی زوایا و خفایاش رو بفهمم بعد برم سراغ کدنویسی. اینجا بود که وادار شدم فلوچارت بکشم و یو.ام.ال. بازی دربیارم و تازه فهمیدم که فاز تحلیل حرف حسابش چیه و آلان دیگه تا تحلیل نکنم یک کلمه هم حرف نمیزنم
نتیجهی اخلاقی این داستان اینه که یک سری چیزایی برای کارهای کوچیک و یک نفری و دو روزه معنی نمیده. یک مسئله کوچیک یا یک برنامهی ساده تحلیل و طراحی نمیخواد. بدون اینکه حتی خودتون بفهمید در آن واحد هم تحلیل میکنید و هم طراحی و هم کدنویسی و آزمودن یک نرمافزار ساده هم که داستان نداره. اینقدر اجراش میکنی تو تغییر میدی تا خروجی دلخواه بدست بیاد. این روش کار کردن هیچ اشکالی نداره. راستش رو بخواهید برای نرمافزارهای کوچیک اصلا کار خوبی نیست که برید فاز بندی کنید و نقش تعیین کنید و خودتون رو بندازید تو دردسر. اما فردا که رفتین تو بازار کار چی؟ اونجا هم همینه؟ همه کاری رو یک نفره میتونید بکنبد؟ مختون میکشه که در آن واحد هم تحلیل کنید هم طراحی هم کدنویسی؟ تازه اگر هم کردید از کجا میفهمید کارتون رو درست انجام دادین؟ آیا همه نرمافزارها رو میشه اینقدر اجرا کرد و تغییر داد تا خروجی مطلوب بدست بیاد؟ آشکاره که خیر. بیتردید دنیای واقعی اینجوری نیست و ما نیاز داریم که همهی این چیزایی که تو این کتابها خوندیم و از بر کردیم رو بهش عمل کنیم اما چه جوری؟ ما که نفهمیدیم چی خوندیم. ما که تا پیش از این کار بزرگی نکردیم، پروژهای تحویل ندادیم که کار تیمی بخواد. استادمون چیزی ازمون نخواسته که تحلیل بخواد. ما تنها یک سری نام و نوشته رو از بر کردیم و آلان که بهشون نیاز داریم نمیدونیم باید چی کار کنیم.
مهنیس نرمافزار یعنی درست و باصرفه نرمافزار ساختن و مانند هر شاخهی دیگری از مهندسی فرآیند دراز و پیچیدهی ساخت محصول (نرمافزار) رو به چند بخش ساده تر و محدودتر بخشبندی کرده. این بخشها رو باید درست درک کنیم و گرنه همیشه لنگان خواهیم بود اما مشکل اینه که بیشتر ما داریم نرمافزار رو در دانشگاه یاد میگیریم که در نتیجه هیچ وقت با یک نرمافزار حقیقی سر و کله نمیزنیم. یک چیزایی تا زمانی که با اندازهی حقیقیشون روبرو نشید خودشون رو نشون نمیدن. برای نمونه همه میدونند که هندلینگ دویست شیش از پراید بهتره اما تو هیچ وقت اینو تو آموزش رانندگی نمیفهمی. تنها زمانی میفهمی که خدای نکرده تو اتوبان یک کسخلی با صد و بیست تا بپیچه جلوت و تو با چهار تا حرکت تند و تیز ماشین رو جمع کنی. اونوقت میتونی بگی کم کم داری معنی هندلینگ رو میفهمی. حالا یک نفر که اطلاعات عمومیاش خوبه میتونه تا محرم و صفر دربارهی هندلینگ رزت و پرت کنه اما در واقع نمیفهمه که داره چی میگه. فقط میگه. مثل معارف و ادبیات زمان کنکور که همهاش رو از بر بودیم اما دوزار نمیفهمیدیم. دانشگاه که میری میشه همون زرت و پرت. چرا؟ چون شونصد صفحه فرآیند میخونی اما در آخر پروژهای که بهت میدن یک مشت چیزای کلیشهای است که حتی برای کلاس طراحی الگوریتم هم آسونه. به سخن دیگر تو هیچ وقت در میانهی یک چالش واقعی قرار نمیگیری که خودت حس کنی هدلینگ سیشارپ بهتره یا جاوا یا اینکه روشهای کلایسک بهتره یا مدرن. هیچ وقت مجبور نمیشی کار تیمی کنی تا بفهمی زمانی که میگن فلان فرآیند بدرد کار تیمی میخوره ولی بهمان فرآیند بدرد نمیخوره یعنی چی. همین گرفتاری دربارهی فازها و بخش بندیهای منطقی هم برقراره. برای نمونه تو هیچ وقت نیاز پیدا نمیکنی بخشهای متفاوت کار رو به آدمهای متفاوت با تواناییهای متفاوت بسپاری. چرا؟ چون هر چی برنامه تو دانشگاه مینویسی در اندازهای نیست که تو رو وادار به اندیشیدن دربارهی این چیزا کنه. تو یک نفری از عهدهی همهاش بر میای و باورت میشه که دیگه آخرش همینه. اما نیست! تا زمانی که اندزاهی کار بزرگ نشه تو حتی اگر خودتو خفه هم بکنی درست نمیتونی بفهمی فاز تحلیل با طراحی چه فرقی میکنه اما زمانی که مسئله بزرگ شد و تو مجبور بودی پیش از دست بردن به کدنویسی یه چند روزی رو اندیشه کنی اون وقت تازه متوجه میشی که گویا کار چند بخش داره که یکیش تحلیله. در یک بخش اندیشه میکنند و در بخش دیگه حاصل اون اندیشه رو کاری میکنن. اینا رو گفتم که بدونید با خوندن این اراجیفی که من میگم نمیتونید ارزش درست و جایگاه واقعی فازها یا نقشها یا هر چیز دیگری رو بفهمید اما میتونید یک دید یهتری پیدا کنید و تندتر به اون مقصد پایانی برسید. راهش اینه که برید خودتون برو بندازید در یک پروژهی بزرگ. برای خوتون یک چیز اساسی تعریف کنید و فازش رو بگیرید. برای نمونه من دارم در آی.اس.پی خودمون نرمافزای میسازم که کاربران رو مدیریت کنه و سر همین کار تازه کمکم دارم روش تی.دی.دی رو میفهمم. پیش از این هم میتونستم دربارهی این روش صد صفحه دری وری براتون بگم اما آلان میدونم که اون صد صفحه (با اینکه واژه به واژه اش درست و دقیق بودند) اما به اندازه ی ده صفحهای که آلان میتونم براتون بگم ارزش نداشته. پس برین برای خودتون یک پروژه تعریف کنید و فازشو بگیرین.
نتیجه رو براتون کوتاه میکنم:
- برخی مفاهیم برای همه جور نرمافزاری برقراره (کوچیک و بزرگ) اما برخی مفاهیم تنها برای نرمافزارهای بزرگ و پیجیده معنی میده. برخی مفاهیم تنها زمانی معنی میده که کار تیمی کنید و برخی دیگر زمانی که در تنگنای زمانی باشید یا براستی با یک مشتری سر و کله بزنید.
- اون چیزهایی که برای نرمافزار های حقیقی (= بزرگ و پیچیده و احتملا نیازمند کار تیمی) معنی میده رو نمیتونید با کتاب خوندن و یا نوشتن پروژههای دانشگاهی و کلیشهای یاد بگیرید
- پس برین برای خودتون پروژه تعریف کنید و با کله برین توش تا بفهمین چی شد
ممنونم . فقط همین و می تونم بگم .
خواهش
دمت گرم. خيلي به دردم خورد.