حرفه ای گری در برنامه نویسی
در قسمت قبلی این مطلب در مورد قبول مسئولیت و پاسخگو بودن یک برنامه نویس حرفه ای صحبت کردیم.
در این قسمت می خواهیم ببینیم یک برنامه نویس چگونه ممکن است آسیب برساند و چگونه می تواند از آن جلوگیری نماید.
اول، آسیب نرسانید
حالا ببینیم چگونه می توان این مسئولیت پذیری را در کار برنامه نویسی به بهترین نحو داشته باشیم. در این مورد می توان به سوگندنامه بقراط که پزشکان در اول کار خود به آن متعهد می شوند نظری انداخت، در آناولین مسئولیت و اولین هدف یک فرد که می خواهد بصورت حرفه ای کاری را شروع کند اینست که از قدرت خود در راه خوب استفاده کند.
حال یک برنامه نویس چه آسیبی می تواند به یک نرم افزار وارد آورد؟ یک برنامه نویسی می تواند از دو جهت آسیب وارد کند یکی به کارکرد برنامه و دیگری به ساختار برنامه. هر کدام را در ادامه شرح خواهیم داد و روش جلوگیری از آن را نیز ارائه خواهیم کرد.
آسیبهای کارکرد برنامه
منظور باگهایی است که ممکن است در برنامه وجود داشته باشد و کاری که باید انجام دهد را انجام ندهد و یا اینکه آنطور که باید انجام ندهد. در اینجا یک برنامه نویس حرفه ای موظف است برنامه ای بدون خطا و باگ تولید و تحویل دهد.
اما چطور می توان یک برنامه بدون خطا تولید کرد؟ با استفاده از روشهای تست برنامه. بله شما باید برنامه خود را تست کنید، تست کنید و باز هم تست کنید.
تست کردن برنامه معمولا کار سخت و زمان بری است ولی می توان با استفاده از روشهای تست یونیت یا Unit Test آنرا سریع و خودکار انجام داد. در آینده در این مورد حتما مطالب بیشتری خواهم نوشت.
اما در اینجا می توان گفت که کد شما باید تمامی تستهای تضمین کیفیت یا Automated QA را پاس کند. در این صورت شما می توانید در بالاترین حد ممکن از صحت کدهای خود اطمینان یابید.
یک تست درست و اصولی باید تمامی کدهای نوشته شده توسط شما را پوشش دهد و تمامی توابع و ورودی و خروجی آنها را تست کند. تنها پس از پاس شدن اینگونه تستها می توانید از صحت کدهای خود اطمینان داشته باشید و مسئولیت خطاهای احتمالی را نیز با جرات فراوان به عهده بگیرید.
آسیبهای ساختار برنامه
خوب حال که برنامه شما از نظر کارکرد کامل و صحیح است باید به جنبه دیگر کاری خود بعنوان یک برنامه نویس حرفه ای توجه کنید. باید ساختار برنامه نیز به گونه ای باشد که هرگونه تغییری در آینده در آن به سادگی صورت پذیرد و حداقل هزینه را داشته باشد.
اگر شما ساختار را درست طراحی نکنید، آینده را به خطر انداخته اید.
کدی که شما می نویسید باید توسط خود شما و یا هر برنامه نویس دیگری در کمترین زمان ممکن قابل توسعه باشد. من خودم به شخصه کدهای زیادی دیده ام که تنها برنامه نویسان بر روی کارکرد آن تمرکز داشته اند و اصلا به ساختار توجهی نکرده اند و بعد از مدتی که بنا به خواست مشتری و یا نیاز بازار نیاز به اضافه نمودن و یا تغییرات برخی از ویژگیها بوده است، سرعت بسیار کند و در برخی جاها امکان پذیر نبوده است.
حال چطور می توان کدی با ساختار مناسب تولید کرد؟ برای اینکار باید همیشه کدهای خود را مرور کنید و سعی کنید در آن تغییری ایجاد کنید، اگر دیدید این تغییر کمی مشکل است و در دیگر جاهای برنامه ایجاد مشکل میکند بدانید که ساختار برنامه شما بدرستی طرح ریزی نشده است.
من در سال گذشته مجبور شدم برنامه ای را که شاید بیش از ۱۰ سال قبل برای یک کارفرمایی نوشته ام را تغییراتی دهم و امکاناتی را با توجه به تغییرات بسیار در این سالها به آن اضافه کنم.
شاید یکی از سختترین روزهای کار برنامه نویسی من در همان روزهایی بود که سعی میکردم بفهمم این برنامه از کجا به کجا می رود و من چگونه می توانم در آن تغییری ایجاد کنم. کارفرما هم که نمی توانست قبول کند که برنامه ای که من در مدت زمان شاید چند ماه نوشته ام حال چند ماه هم طول میکشد که تنها چند تغییر کوچک در آن لحاظ کنم.
در آینده در مورد ساختار برنامه نویسی و نکات و روشهای مختلف آن بیشتر خواهم نوشت.
قصد ندارم در این مطلب تمامی جوانب و ریزه کاریهای این موارد را کاملا موشکافی کنم، برای همین مطالب خیلی خلاصه و موجز آورده شده است، اما در آینده روی هر کدام از این موضوعات بیشتر متمرکز خواهیم شد و بیشتر آنرا باز خواهم کرد.