اخلاق کار برنامه نویس حرفه ای (5)

این آخرین بخش سری مطالب حرفه ای گری در برنامه نویسی است. پیشنهاد میکنم حتما بخشهای گذشته را مطالعه کنید:

اخلاق کاری- قسمت اول

اخلاق کاری – قسمت دوم

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

آشنایی با حوزه کار برنامه

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

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

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

هر چند ممکن است شما این را وظیفه مدیر پروژه و یا کارفرما بدانید که باید آنها را به شما انتقال دهد، ولی دریافتهای مستقیم شما می تواند نکات بهتر و واضحتری را در اختیارتان بگذارد.

با کارفرما یا مشتری خود یکی شوید!

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

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

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

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

انسانیت

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

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

اگر اشتباه خنده داری بکند خودش اول از دیگران به اشتباه خود می خندد. و به اشتباه دیگران نمی خندد چون می داند خودش نیز ممکن است روزی اشتباه کند.

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

سخن آخر

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

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

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

لطفا نظرات خود را با من و دیگر خوانندگان در بگذارید.

اخلاق کار برنامه نویس حرفه ای (4)

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

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

تمرین کردن

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

می توانید به این کاتاها بصورت یک تمرین ۱۰ دقیقه اول روز برای گرم کردن و یک ۱۰ دقیقه در پایان روز برای سرد کردن خود نگاه کنید!

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

همکاری

دومین راه برای یادگیری کار کردن با دیگران است. اینکه با یک نفر یا افراد دیگر برای تحلیل و پیاده سازی برنامه همفکری کنیم، می تواند نکات زیادی را به ما بیاموزد. کلا یکی از روشهای خوب برنامه نویسی که برای یادگیری بسیار مفید است روش برنامه نویسی جفتی (pair programming) است که در آن دو نفر در یک سطح یا در سطوح متفاوت در کنار هم و با یک سیستم شروع به نوشتن یک برنامه می کنند. در این روش هر کدام در قسمتهایی نظر خود را اعلام میکنند و همینطور در مورد کارهایی که انجام شده است از هم سوال می پرسند.

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

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

شاید به همین دلیل باشد که اکثر برنامه نویسان یا گیکها معمولا در یک اتاق تاریک، ساعتها وقت خود را به تنهایی می گذرانند و این باعث می شود که دیگران، برنامه نویسان را انسانهایی جامعه گریز و انزوا طلب قلمداد کنند.

آموختن دانسته ها به دیگران (منتوریگ)

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

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

یک برنامه نویس حرفه ای نباید از هیچ فرصتی برای یاددادن دانسته های خود به دیگران صرف نظر کند.

برای اینکه مطلب طولانی نشود در پستی دیگر ادامه بحث را خواهم آورد.

اخلاق کار برنامه نویس حرفه ای (3)

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

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

این بخش بدلیل اینکه مفصل تر می باشد من آنرا در ۳ قسمت آورده ام که این نوشته قسمت اول آنست.

اخلاق کاری

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

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

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

در کتاب The Clean Coder عمو باب می گوید که مثلا اگر شما قرار است در هفته ۴۰ ساعت برای کارفرما خود کار کنید باید ۶۰ ساعت زمان برای کار کردن بگذارید. که ۴۰ ساعت برای کارفرما و ۲۰ ساعت دیگر برای خودتان است تا مطالعه کنید، تمرین کنید، کدهای جدید بنویسید و کدهایی را ببینید و در کل سطح مهارت خود را بالا ببرید و یا بهتر بگویم بالا نگه دارید.

ممکن است گاهی لازم باشد بیشتر هم وقت بگذارید. این زمان برای خودتان است و نه کارفرما.

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

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

البته که شما نباید از وقتی که برای کارفرما اختصاص داده اید (همان ۴۰ ساعت) برای اینکار استفاده کنید. کارفرما نباید هزینه اینکه شما ممکن است چیزی را برای انجام پروژه وی ندانید، را بدهد؛ چرا که یک برنامه نویس حرفه ای استخدام کرده است و دستمزد برنامه نویس حرفه ای را هم پرداخت میکند.

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

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

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

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

خودم در سالهای ۷۶ و ۷۷ با اینکه بیش از ۵ سال کار برنامه نویسی برای خودم انجام داده بودم دنبال شرکتهای نرم افزاری میگشتم که من را بصورت رایگان بپذیرند تا در کنار آنها آموزش ببینم و شاید مدت ۲ سال بصورت رایگان در چند شرکت بزرگ، برنامه نویسی کردم که گاهی اوقات متوجه میشدم سواد برنامه نویسی من از برخی از کارکنان و برنامه نویسان رسمی آنها نیز بالاتر است ولی هیچ وقت این باعث نشد که از یادگیری از آنها دست بردارم.

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

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

حوزه کاری خود را بشناسید

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

در کتاب، عمو باب هم می گوید در این ۵۰ سال تاریخ برنامه نویسی ممکن است بسیاری از اتفاقاتی که افتاده دیگر اکنون نیازی نباشد که یک برنامه نویس بداند ولی بسیاری از آنها مواردی هستند که همچنان در برنامه نویسی کاربرد دارند و دانستن آنها برای یک فرد حرفه ای ضروریست.

همچنین بطور خیلی خلاصه لیستی از چیزهایی که یک برنامه نویس حرفه ای باید در این مورد بداند را لیست کرده است:

  • الگوهای طراحی Design Patterns: شما باید بتوانید هر ۲۴ الگو طراحی برنامه نویسی که در کتاب Gang of Four آمده است را شرح دهید.
  • اصول طراحی Design Principles: شما باید اصول SOLID در طراحی شیء گرا را بشناسید. (که اشاره می کند به ۵ اصل طراحی شیء گرا که برای اولین بار همین آقای عمو باب در سال ۲۰۰۰ مطرح نمود و مخفف Single responsibility, Open-closed, Liskov substitution, Interface segregation Dependency inversion می باشد).
  • متدهای پیاده سازی: شما باید با روشهای XP، SCRUM، Lean، Kanban، Waterfall و همچنین طراحی و آنالیز ساخت یافته نیز آشنایی داشته باشید.(Structured Analysis , Structured Design)
  • دیسیپلین: شما باید در زمینه های TDD و طراحی شیء گرا، برنامه نویسی ساخت یافته، یکپارچه سازی مداوم (Continuous Integration) و همینطور برنامه نویسی دوتایی (یا جفتی) (Pair Programming) تمرین های کافی را داشته باشید.
  • ابزارهای اصلی طراحی: شما باید روش استفاده از این ابزارها را بدانید: UML ،DFDs، نمودارهای ساختار (Structured ChartsPetri Nets ، State Transition Diagrams and Tables، فلوچارت و جداول تصمیم.

یادگیری مداوم

باید همواره در حال یادگیری باشید تا از این بازار کنار گذاشته نشوید. باید همیشه به روز باشید تا بتوانید بهترین انتخاب را برای کارفرمای خود انجام دهید. شما باید بتوانید اطلاعات کافی در مورد ابزار، فریمورکها و زبانهای برنامه نویسی مختلف داشته باشید.

باز هم عمو باب در کتاب آورده است، کدام پزشک موفقی را میشناسید که آخرین ژورنالهای پزشکی را نداشته باشد؟ چه کسی وکیلی را استخدام میکند که از آخرین تغییرات قانون خبر نداشته باشد؟ یک برنامه نویسی را استخدام میکند که به روز نباشد؟

کتاب، بلاگ، مقاله و … بخوانید. در گروه ها و انجمنها و خبرنامه های مختلف عضو شوید. همیشه چیزهایی را خارج از حوزه تخصصی خود هم یاد بگیرید.

اگر برنامه نویس .NET هستید حتما زبان Java را هم یاد بگیرید، همینطور اگر برنامه نویس Java هستید با Ruby هم کار کنید. اگر با Cبرنامه نویسی میکنید زبان Lisp را هم یاد بگیرید. و اگر دوست دارید مغزتان حسابی به چالش کشیده شود زبانهایی مانند Prolog و Forth را کار کنید.

اخلاق کاری هنوز ادامه دارد و چند مورد دیگر آنرا در قسمت دوم این موضوع آورده ام.

حرفه ای گری در برنامه نویسی (2)

در قسمت قبلی این مطلب در مورد قبول مسئولیت و پاسخگو بودن یک برنامه نویس حرفه ای صحبت کردیم.

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

اول، آسیب نرسانید

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

حال یک برنامه نویس چه آسیبی می تواند به یک نرم افزار وارد آورد؟ یک برنامه نویسی می تواند از دو جهت آسیب وارد کند یکی به کارکرد برنامه و دیگری به ساختار برنامه. هر کدام را در ادامه شرح خواهیم داد و روش جلوگیری از آن را نیز ارائه خواهیم کرد.

آسیبهای کارکرد برنامه

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

اما چطور می توان یک برنامه بدون خطا تولید کرد؟ با استفاده از روشهای تست برنامه. بله شما باید برنامه خود را تست کنید، تست کنید و باز هم تست کنید.

تست کردن برنامه معمولا کار سخت و زمان بری است ولی می توان با استفاده از روشهای تست یونیت یا Unit Test آنرا سریع و خودکار انجام داد. در آینده در این مورد حتما مطالب بیشتری خواهم نوشت.

اما در اینجا می توان گفت که کد شما باید تمامی تستهای تضمین کیفیت یا Automated QA را پاس کند. در این صورت شما می توانید در بالاترین حد ممکن از صحت کدهای خود اطمینان یابید.

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

آسیبهای ساختار برنامه

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

اگر شما ساختار را درست طراحی نکنید، آینده را به خطر انداخته اید.

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

حال چطور می توان کدی با ساختار مناسب تولید کرد؟ برای اینکار باید همیشه کدهای خود را مرور کنید و سعی کنید در آن تغییری ایجاد کنید، اگر دیدید این تغییر کمی مشکل است و در دیگر جاهای برنامه ایجاد مشکل میکند بدانید که ساختار برنامه شما بدرستی طرح ریزی نشده است.

من در سال گذشته مجبور شدم برنامه ای را که شاید بیش از ۱۰ سال قبل برای یک کارفرمایی نوشته ام را تغییراتی دهم و امکاناتی را با توجه به تغییرات بسیار در این سالها به آن اضافه کنم.

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

در آینده در مورد ساختار برنامه نویسی و نکات و روشهای مختلف آن بیشتر خواهم نوشت.

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

برنامه نویس حرفه ای کیست (1)

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

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

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

این مطلب را با استفاده از برداشتی آزاد از فصل اول کتاب The Clean Coder نوشته آقای Robert C. Martin معروف به Uncle Bob یا همان عمو باب، با عنوان Professionalism نوشته ام.

البته سعی کردم در مثالها به مواردی اشاره کنم که ما در جامعه خود بیشتر میبینیم که بر اساس تجربه ها ی خودم بوده است.

مراقب باشید که چه چیزی می خواهید


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

یک برنامه نویس حرفه ای دو خصیصه کلیدی دارد یکی مسئولیت پذیری و دیگری پاسخگو بودن است.

اگر برنامه ای که تحویل کارفرما می شود بدلیل یک مشکل در کد برنامه مثلا ۱۰ میلیون تومان به وی ضرر برساند، یک برنامه نویس غیر حرفه ای در مقابل شانه های خود را بالا می اندازد و می گوید: «خوب هیچ برنامه ای بدون باگ که نمی شود».

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

پس بدانید که اگر ادعای حرفه ای بودن دارید باید تبعات ناشی از آن که شامل قبول مسئولیت کارکرد صحیح برنامه می باشد را نیز بپذیرید.

گرفتن مسئولیت


عمو باب در اینجا داستانی از اولین مسئولیتش بعنوان یک برنامه نویس می نویسد که بعد از تحویل دادن برنامه با امکانات جدید به مشتریان که در آن سالها می بایست برنامه را روی Tape بصورت حضوری می برد و برای هر یک نصب میکرد، یک مشکلی بوجود آمد که برنامه کار نکرد و این باعث شد صدای نارضایتی تمام مشتریان و متعاقبا کارفرما در آید. اما مشکل اینجا بود که عمو باب نمی دانست چرا این مشکل بوجود آمده است.

حالا شما فرض کنید بعنوان یک برنامه نویس در این موقعیت باشید، چه میکنید؟

من در سال ۷۶ در یک شرکت نرم افزاری در مشهد بصورت کارآموز مدتی مشغول بودم که با زبان برنامه نویسی پاسکال برنامه می نوشتند، این شرکت در آن سالها جزء برترین شرکتهای نرم افزاری مشهد و یا حتی ایران محسوب میشد.

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

یک روز وقتی در این مورد با او صحبت کردم گفت: «ما بیش از ۳۰۰ مشتری داریم اگر بعد از اینکه برنامه رو برای همه آنها فرستادیم و بعد به مشکل خورد من باید به شرکت پاسخ بدهم نه تو، پس ترجیح میدهم کدی را که خودم دیدم و تست کردم رو کمپایل کنم.»

حتی وقتی یک فایل com برای تغییر فونت Draft در چاپگرهای سوزنی درست کردم که در برنامه ها برای فارسی سازی چاپگر استفاده کنند، با اینکه روی چندین چاپگر چک شد و نتیجه مثبت بود از من کد برنامه رو خواست تا قبل از انتشار از نحوه کار آن مطمئن شود.

البته وقتی من گفتم سورسی در کار نیست و من روی یک فایل com دیگر تنها با استفاده از HexEditor جدول ماتریسی فونتها رو طراحی کردم و تغییر دادم بازهم کار رو از من قبول نکرد و اون فایل حداقل تا وقتی که من اونجا بودم همراه برنامه منتشر نشد.

درک این موضوع در آن سالهای جوانی برای من کمی دشوار بود و من همه جا از این موضوع گلایه میکردم، ولی بعدها در مسئولیتهایی که داشتم دقیقا این موضوع را تجربه کردم که خیلی هم برایم گران تمام شد.

اگر شما برنامه نویس هستید و یا قصد دارید که برنامه نویس شوید و یا اینکه قصد دارید برنامه نویسانی را استخدام نمایید، باید بدانید که یکی از مهمترین مشخصه های یک برنامه نویس قابل اعتماد و حرفه ای همین موضوع مسئولیت پذیری است.

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

در بخشهای بعدی این مطلب نیز با من همراه باشید.