من می خواهم برنامه نویس شوم - قسمت نهم

در قسمت هشتم با اصطلاحات کافی و لازم برای شروع این سفر آشنا شده اید. اما عمده مشکلی که بعد از شروع برنامه نویسی پیش می آید این است که کارآموزان با مثال های آموزشی و کدهای پیش پا افتاده دوره های آموزش رو به رو شده و برخی صبرشان لبریز می شود.

عده ای دوست دارند در همان ابتدا از مثال های واقعی در دنیای واقعی شروع کنند و عده ای نیز که لزوم این مورد را درک می کنند نگران این هستند که در دنیای واقعی چه خواهند کرد. در این مقاله سعی می کنیم به این دو مسئله پاسخ دهیم.

چرا در دوره های آموزشی نمی توان سمت واقعیت رفت

هدف دوره های آموزشی معمولا آموزش ابزار دست شما است برای خلق هر چه بتوان تصور کرد. مثلا در آموزش استفاده از یک اره برقی مثالی از ساخت کمد یا تخت نمی زنند یک تخته چوب است که باید آن را درست ببرید. لبه ها خراب نشود. از خط خارج نشوید. به کسی آسیب نزنید و استاندارد طرز ایستادن و ... (همین اره خیلی موارد دارد) را رعایت کنید.

بله معمولا صرف یادگرفتن ابزار به شما کمک نمی کند که بتوانید چیزهای بزرگی خلق کنید و این دلیل وجود کارآموزی است.

اما اگر همین ابزار را با تمرکز کافی و به درستی فرا نگیرید در کارآموزی هم چندان موفق نخواهید شد. به اصطلاح

خشت اول چون نهد معمار کج، تا ثریا می رود دیوار کج

پس اولین وظیفه شما تمرکز بر آنچه است که در حال آموزش آن هستید. هر سرنخی یافتید آن را بررسی کنید و با دقت تمرینات را دنبال کنید و سعی کنید آن ها را با آموزه های جدیدتان بهبود ببخشید.

بعد از ده سال هنوز وقتی یک برنامه را می نویسیم بخش هایی از آن را بارها می شود که اصلاح کنم. (زمانی که چیز جدیدی به ذهنم می رسد یا فکر می کنم که این قسمت می تواند تمیز تر باشد - تا زمانی که به کسب و کار و زمانبندی ارائه محصول آسیبی نزد وسواس نیست) هرچند می توان آن را رها کرد. چون کار می کند.

یک مسئولیت اجتماعی برنامه نویس بهبود هرچه بهتر سیستمی است که در حال توسعه آن است. در آینده اگر task (وظیفه) به شما دادند و در حین کار متوجه شدید می توان در حین انجام آن، کلاسی که در حال تغییر آن هستید را می توان بهتر کرد این کار را با رعایت اصول (دقت کنید مشکل در جای دیگری ایجاد نکند) انجام دهید.

بنابراین در دوره های آموزشی سعی در ساده سازی حالت تا حد ممکن آن را دارند و از واقعیت دور می شوند.

برای درک بهتر مثالی می زنیم.

فرض کنید یک سیستم مدیریت Asset (هرچه در یک اداره یا سازمان وجود دارد - از کامپیوتر ها و پرینتر ها بگیرید تا میز و صندلی و موبایل های امانی و دوربین و اتومبیل) در دوره آموزشی می شود دو موجودیت در نظر گرفت و کار را آموزش داد مثلا user و asset

اما در واقعیت این asset ها دارای گروه هستند که خود خصوصیاتی دارد مثلا اینکه آیا این گروه نیاز به بررسی و بازنگری دارد (چک دوره ای) خوب پس هر گروه asset ممکن است چندین چک دوره ای داشته باشد. حال این چک دوره ای یک موجودیت مجازی است (قابل لمس نیست و یک مفهوم است) اما خصوصیاتی دارد (نام آن چیست؟ چند وقت یک بار؟ چند روز قبل دوره اطلاع رسانی شود؟)

حال فرض کنید بگویند پرینتر با هر 10000 پرینت باید چک شود فارغ از اینکه شش ماه یک بار هم باید چک شود. پس مفهوم جدیدی دارید به نام کارکرد که برای هر asset باید ثبت شود و دارای تعداد. تاریخ و ... است و باید به موجودیت چک دوره ای هم خصوصیتی اضافه شود که کارکرد را هم لحاظ کند (چه نوع کاری و چه تعداد) که در محاسبات لحاظ شود.

حال به شما می گویند کارهای سیستم را نمی توانند همه انجام دهند. پس باید گروه کاربری داشته باشید که هر گروه کاربری به یک سری از ماژول ها در سیستم دسترسی دارند (دو مفهوم جدید اضافه شد)

بعد به شما میگویند Asset های it را فقط کارمندان it ببینند و asset های اداری را منابع انسانی

پس کاربران علاوه بر گروه کاربری (سطح 1 و سطح 2 و ...) یک گروه سازمانی هم دارند. گروه سازمانی معمولا ساختار درختی دارد یعنی یکی مدیر دیگری است و او نیز مدیری دارد که وقتی یک کارمندی یک موردی را ثبت می کند تمام مدیران بالا دست او نیز باید به آن دسترسی داشته باشند

حال می گویند باید همین چک دوره ای را با توجه به نوع آن ثبت کرد مثلا تعمیری است یا تامینی (خرید کارتریج) بعد اطلاعات تعمیر یا تامین را وارد کرد (بسته به هر نوع یک موجودیت به سیستم اضافه می شود چرا که هر کدام خصوصیات خاص خود را دارند) فرض کنید بگویند هر فاکتوری برای ما داده اند نیز باید در آن تعمیر یا تامین ثبت شود هم اطلاعات آن هم اسکن فاکتور اصلی (دو موجودیت فاکتور و فایل فاکتور به سیستم اضافه شد)

اگر من بخواهم ادامه دهم می توانم یک ساعت تمام قابلیت به این سیستم اضافه کنم. که در دوره های آموزشی جای این بحث ها نیست. این مثال و موارد مشابه را اصطلاحا business یک برنامه می گویند.

تمرین کنید

آنچه الان تمرین کردیم را تحلیل یک کسب و کار می گویند. تحلیل کسب و کار یک شغل در کنار برنامه نویسی است و معمولا شامل استخراج نیازمندی ها و بررسی ارتباطات موجودیت های سیستم با نگاه واقع گرایانه و همچنین در نظر گرفتن آینده سیستم است (ممکن است قابلیت های جدیدی در آینده اضافه شود که سیستم باید امکان گسترش را داشته باشد نه اینکه آن را از ابتدا نوشت - البته تا حد امکان)

اگر علاقه دارید برای تمرین به دور و بر خود نگاه کنید و سعی کنید یک سیستم را تحلیل کنید. مثلا صندوق خانگی. مثلا مدیریت آپارتمان. رستوران. یک مرکز تعمیرات.

سعی کنید با تحلیل خود را با دوستان دیگرتان به اشتراک بگذارید و بحث کنید (هیچ وقت متعصبانه به تحلیل خود نچسبید - قبول کنید ممکن است حتی پدرتان که یک کارمند یا راننده تاکسی است چیزی به ذهنش برسد و بهتر از شما به یک مسئله نگاه کند که پشتوانه آن تجربه اجتماعی است)

در این شغل یا این مهارت که برنامه نویس نیز باید آن را داشته باشد لازم است همه چیز را کنار بگذارید. ابزار دستتان و قابلیت های آن و در حال توسعه هر سیستمی هستید خود را جای کاربر آن قرار دهید. باید در ذهنتان نقش بازی کنید و کاملا در نقش خود فرو روید. سپس نقشتان را عوض کنید و جای مدیریت این سیستم قرار بگیرید و همینطور تمامی زوایای آن را بررسی کنید.

همچنین برنامه های دیگر را ببینید و الگو بگیرید و اگر توانستید تحلیل بهتری ارائه دهید. برای شروع زمانی که با پایگاه های داده آشنا شدید می توانید برای شروع از Data Model یا مدل پایگاه داده شروع کنید که تقریبا (نه دقیقا هر جدول معادل یکی از موجودیت ها شماست) و با مشخص شدن جداول و ارتباط آنها یک شمای کلی از کسب و کار را دارید.

از بین مهمترین مستندات نرم افزار می توان به مستند توسعه نرم افزار SDP، مستند RFP یا درخواست پروپوزال، مستند معماری نرم افزار، مدل داده Data Model، مستند سناریو و مستند Sequence diagram اشاره کرد که برای آشنایی بیشتر با آنان باید درس مهندسی نرم افزار رشته کامپیوتر را مطالعه کنید و با آن ها آشنا باشید. (در هر یک از شغل های زیر باشید باید این مستندات را بدانید)

مشاغل مرتبط

تعاریفی که در زیر آمده آیه نیست و احتمالا هر کسی تعاریف دیگری داشته باشد. موارد زیر صرفا برای آشنایی بهتر شما با فضای کاری و ترسیم آینده شغلیتان است.

تحلیل گر:

امروز هر کدام از مهارتهایی که در گذشته یک برنامه نویس انجام میداد یک شغل جدا است. مثلا تحلیل گر نیازمندی های سیستم و قابلیت های آن را فارغ از آنکه کدام موجودیت است و کدام یک خصوصیت در یک موجودیت صرفا استخراج می کند و باید دید کاملی نسبت به کسب و کاری که در حال توسعه برنامه در آن است پیدا کند (انگار چند سال است که کار او مربوط به آن کسب و کار است)

طراح

طراح سیستم وظیفه دارد موجودیت ها را از این نیازمندی ها استخراج کند و ارتباطات را مشخص کند و حتی کلاس های شما را تعیین کند و ممکن است بگوید چه کلاسی چه توابعی خواهد داشت

معمار سیستم

برنامه نویس هایی هستند که معمار نرم افزار هستند و می گویند برای توسعه برنامه مرتبط با این کسب و کار از چه ابزارها (زبان، کتابخانه ها، فریم ورک و ...) استفاده شود و از چه معماری استفاده شود

معماری نرم افزار شامل روش هایی است که ارتباطات کلاس ها را با نگاه کلی تر و فارغ از موجودیت ها بیان می کند مثلا می گوید برای هر موجودیت باید یک سه کلاس نوشته شود که هر کدام وظیفه مشخصی در خصوص آن موجودیت انجام می دهد (مثلا برای asset یک کلاس AssetService برای توسعه توابع معمول که در ذهن دارید و یک کلاس AssetRepository برای دریافت و ارسال اطلاعات asset بین پایگاه داده و کلاس assetService و یک کلاس Asset که صرفا اطلاعات یک Asset را شامل می شود و ...)

برنامه نویس

برنامه نویس با توجه به معماری توافق شده و با در نظر گرفتن طراحی شروع به توسعه می کند و حتی ممکن است توابعی بنویسد که مقداری از پیش تعیین شده به توابع اصلی بفرستد و انتظار خروجی از پیش تعیین شده ای داشته باشد (به این توابع unit test ) می گویند و برای این است که هر موقع تابع تغییر کرد همچنان مطمئن شوید که کار خود را درست انجام می دهد و تست را اصطلاحات پاس می کند یا خیر. البته ممکن است نیاز باشد تست های بیشتری به یک تابع اختصاص داد

برنامه نویس تست

برنامه نویس هایی هستند که علاوه بر unit test تست های بیشتری انجام می دهند مثلا توابعی می نویسند که یک فرایند را به طور کامل تست کند مثلا یک کارکرد زیاد برای asset ثبت شود و انتظار داشته باشند سیستم وضعیت asset را نیازمند به چک دوره ای نشان دهد. که به این تست ها Integration test معمولا می گویند.

کارشناس تست

افرادی نیز در سازمان وجود دارند که تست های بیشتری انجام می دهند مثلا سیستم شما را باز می کنند و سعی میکنند کاری کنند که سیستم خطا دهد ببیند سیستم از کار می افتد یا به کار خود ادامه می دهد و همه خطا ها را پوشش داده و برای آن راه حلی دارد که Functional test می گویند و بررسی می کنند با نیازمندی های اعلام شده می خواند یا خیر که User Acceptance Testing می گویند

مدیر فنی CTO و راهبر توسعه نرم افزار

معمولا در یک پروژه چندین برنامه نویس و برنامه نویس تست وجود دارند و همچنین کارآموزانی چون شما که به تازگی وارد تیم می شوید معمولا ساختار در پروژه های بزرگ به این صورت است که تیم های کوچک تشکیل شده و یک نفر در آن تیم به عنوان راهبر انتخاب می شود که در صورت لزوم به دیگر اعضا کمک کند و برخی تصمیمات در تیم با مشورت با اوست و همچنین راهبران توسعه نیز با شخص دیگری که همه تیم های فنی از جمله تیم های تست را مدیریت می کند در ارتباط هستند که او را مدیر فنی می گویند.

کارشناس پشتیبانی نرم افزار

افرادی آشنا با سیستم های نرم افزاری آشنایی دارند و به خوبی حرف مشتری را فهمیده می دانند مشکل می تواند از کدام بخش باشد و با توجه به اطلاعات خود یا کاربر را راهنمایی می کنند که به درستی از نرم افزار استفاده کنند یا گزارش باگ ثبت می کنند که ایراد مورد نظر اصلاح شود.

صاحب محصول product owner

معمولا بین کارشناسان تست. پشتیبانی. مدیران فنی و تحلیل گران و طراحان و مشتری هستند تا محصول دقیقا آن چیزی باشد که باید و ارتباطات این بخش ها را تسهیل می کند و یک پل ارتباطی امن و امین بین این واحد ها است. این موقعیت شغلی نیازمند تجربه بسیاری است و بعضا افرادی در این موقعیت هستند که تمامی این موقعیت ها را تا حدی تجربه کرده باشند و بتوانند به زبان همه این واحد ها آشنا باشند و حرف آن ها را بفهمند و مشکلات آنان را درک کنند و در کل کار راحتی نیست و اگر به اشتباه به شخص بی تجربه ای سپرده شود که بسیار دیده می شود این واحد ها هستند که برای او تعیین میکنند کدام واحد چه کند به جای اینکه او تصمیم گیرنده باشد. با دیکتاتوری هم محصول زمین خواهد خورد

اسکرام مستر scrum master

در سازمان های بزرگ بخشی از کار صاحب محصول را شخص دیگری به عهده می گیرد و رابط بین مدیر فنی و برنامه نویسان با صاحب محصول می شود که وظیفه مدیریت وظایف تیم فنی و اولویت بندی آن ها و زبان بندی آنها را دارد این شخص با شیوه های مدیریت توسعه نرم افزار مانند شیوه چابک Agile آشناست و استانداردهای آن را به خوبی می داند

مدیر محصول product manager

مدیران محصول معمولا فرصتی برای آینده محصول نخواهند داشت و باید شخصی مدیریت توسعه هرچه بهتر محصول را در دست بگیرد و به صاحب محصول کمک کند.

کلام آخر

سعی کنید با دقت آموزش خود را دنبال کنید و برای کارآموزی سخت نگیرید (من در شروع این سفر بعد از یادگیری زبان در یک استارتاپ (شرکت نوپا) کارآموز بودم و تقریبا حقوقی نمیگرفتم) بعد از آن در شرکت بزرگ تری به عنوان برنامه نویس تازه کار Junior مشغول به کار شدم. تا حدی می توانم بگویم قبل از آن را حتی آموزش به حساب نمی آورم و بعد از استخدام به عنوان Junior یادگیری را آغاز کرده ام.

هیچ کس و هیچ دوره آموزشی شما را یک شبکه و سه ماهه برنامه نویس نمی کند (گول افراد سودجو که می خواهند شما را برنامه نویسانی با دانش ضعیف و ادعای واهی کنند و از شما پول بگیرند نخورید) برای آموزش ابزار باید حداقل شش ماه زمان بگذارید و شش ماه دوره کار آموزی بگذرانید