نرم افزارهای موبایل hybrid سازمانی (Enterprise)

Apache_Cordova1

اگر با اکوسیستم نرم افزارهای سازمانی (Enterprise) آشنا باشید، حتما این موضوع را متوجه شده اید که روند نیاز به نرم افزارهای موبایل در زمینه های سازمانی نسبت به چند سال گذشته رشد زیادی داشته است. اکثر نرم افزارهای سازمانی محصولی (off the shelf) یا اختصاصی دارای یک یا چند نرم افزار موبایل جهت سهولت در استفاده از نرم افزار اصلی و پایه هستند.

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

software-home

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

  • نرم افزارهای native
  • نرم افزارهای cross platform با استفاده از فناوری های xamarin و …
  • نرم افزارهای موبایل با استفاده از webview در یک برنامه native یا همان نرم افزارهای hybrid

احتمالا به اندازه کافی با تولید نرم افزارهای موبایل با استفاده از فناوری های native آشنا هستید. به طور مثال نرم افزارهای موبایل اندرویدی با استفاده از زبان جاوا تولید می شوند و نرم افزارهای iOS ای نیز با استفاده از swift یا objective c.

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

به خواندن ادامه دهید

Greenfield development VS Brownfield development

code

به دنبال ترجمه فارسی این دو اصطلاح نیستم. مدتی پیش مقاله ای در مجله MSDN مطالعه می کردم که به اصطلاح Brownfield development مواجه شدم. به طور ساده تعریف این دو عبارت به صورت زیر هستند

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

Brownfield development: زمانی که شما روی یک پروژه موجود کار می کنید و با تغییراتی که در آن ایجاد می کنید نسخه نرم افزار را هم افزایش می دهید، فعالیت های شما در این دسته قرار می گیرند.

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

خصوصیات این دو نوع برنامه نویسی چیست؟ چه تخصص هایی برای انجام هر چه بهتر هر یکی از این انواع نیاز است؟

رفع ابهام

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

Brownfield development

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

  • خواندن کد های نوشته شده توسط دیگران دانش و تجربه شما را افزایش خواهد داد. (همان طور که در اینجا مطرح کرده ام)
  • برنامه نویسی روی کارهای دیگران نیازمند این است که شما قوه یادگیری و انطباق سریعی داشته باشید و این خصوصیت شما تقویت خواهد شد

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

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

Greenfield development

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

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

برنامه نویسی در پروژه ای که از ابتدا شروع شده است لذت های خاص خود را دارد ولی می تواند معایبی نیز داشته باشد.

  • عدم یادگیری مدیریت زمان: به این معنی که شما همیشه درگیر ایجاد امکانات جدیدی هستید و همیشه حق خود می دانید که زمان در نظر گرفته شده برای کارهایتان بیشتر از حد انتظار شود. چون بالاخره کار جدید است و قبلا انجام نشده است.
  • سندروم ایجاد همه چیز از نو: اگر شما به این سندروم مبتلا باشید اصلا علاقه ای به استفاده مجدد کدهای قبلی نخواهید داشت. به طور مثال اگر یک سیستم مدیریت دسترسی قبلا در سیستم های شرکت کار می کرده، شما تصمیم می گیرید از آن استفاده نکنید و معادل جدیدتر و به روزتر آن را ایجاد کنید. البته بعضی زمان ها امکان استفاده از کد های قدیمی وجود ندارد چون صورت مسئله دوباره نویسی همان ابزارها است.
  • تبدیل شدن به دانشمند برنامه نویسی: این مورد با مورد یک و دو بسیار هم راستا است. زمانی که شما علاقه خیلی زیاد به یادگیری الگوهای معماری و طراحی دارید و نوشتن نرم افزار بهانه ای می شود برای تمرین کردن آن الگوها، نه رفع نیازهای کاربران (که حقوق شما را تامین می کنند!)

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

آیا سابقه کاری در درآمد برنامه نویسی نقش مهمی دارد؟

title

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

جواب ساده به این سوال خیر است.

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

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

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

پس یک برنامه نویس می تواند سابقه کاری زیادی داشته باشد. ولی در تمام این مدت کار مهم و با ارزشی انجام نداده باشد.

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

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

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

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

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

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

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


بروزرسانی ۱۳۹۴/۱۰/۱:

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

نگاهی به Gartner HypeCycle 2014

در نوشته قبل در مورد روش تحقیق HypeCycle به صورت خلاصه صحبت کردم. در این نوشته قصد دارم مثالی اجمالی از نمودار مذکور ارائه دهم که شرکت Gartner برای بررسی فناوری ها در سال ۲۰۱۴ منتشر کرده است.

HC_ET_2014

 

نمودار بالا فقط نمونه ناچیزی از خروجی های تحقیقاتی شرکت Gartner است. تحقیقات این شرکت در سال ۲۰۱۴ شامل ۲۰۰۰ فناوری در ۱۱۹ دسته بندی بود.

به خواندن ادامه دهید

معرفی کوتاه HypeCycle

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

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

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

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

نمونه ای از این نمودار جالب را در زیر می توانید ببینید.

559px-Gartner_Hype_Cycle.svg

به خواندن ادامه دهید

همان بهتر که سر پایین تایپ کنید

9-17-14

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

به خواندن ادامه دهید

phonegap و cordova به درد بخور هستند؟

Apache_Cordova1

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

در مبحث cross platform نیز روش های متفاوتی وجود دارد.

  • نوشتن برنامه با زبان خاص و کامپایل و deploy کردن به چند سیستم عامل (appcelerator, xamarin)
  • نوشتن برنامه با استفاده از webview مانند cordova, phonegap, AppGyver

به خواندن ادامه دهید

معیارهای انتخاب فریم ورک یا کامپوننت های برنامه نویسی

vs

این مطلب از سری مطالب چه چیزهایی یاد بگیرم است!

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

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

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

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

در انتخاب یک فریم ورک و  یا ابزار خاص خوب است به نکات زیر توجه کنید. البته بیشتر موارد زیر ناشی از تجربیات خود من در انتخاب های ناردست! یا درستی بوده است که تا الان داشته ام. سوالات زیر را در مورد گزینه های موجود بپرسید.

  • واقعا مفید است؟!
    این سوال را در اولین مرحله از خودتان بپرسید. آیا واقعا مفید است؟ یا چون یک برنامه نویسی که خیلی خفن به نظر می رسد آن را پیشنهاد داده، به آن علاقه مند شده اید؟ مفید بودن معیار های مختلفی دارد. ولی در این مرحله بپرسید که آیا به طور کلی مسئله من را حل خواهد کرد؟!
  • دانش درون شرکتی در این مورد موجود است؟
    چقدر دانش در درون شرکت در مورد آن وجود دارد؟ نیاز است فردی یا تیمی را به عنوان مشاور به شرکت دعوت کنید؟ نیاز است افراد شرکت چه مقدار از زمان خود را صرف یادگیری آن کنند؟ اصلا به طور کلی فردی در شرکت قادر خواهد بود با آن کار کند و مسئله را حل کند؟ آیا با توجه به زمانی که از نیروهای شرکت می گیرد ارزش استفاده کردن دارد؟
  • دانش بومی در ایران در این مورد موجود است؟
    در واقع این سوال را طور دیگری بپرسیم. آیا اگر برنامه نویسی که به آن تسلط دارد به هر دلیلی قطع همکاری کرد در زمان معقولی جایگزینی برای آن یافت خواهد شد؟ یا نیاز مبرم به آموزش افراد جدید الورود خواهد بود؟ بدیهی است که گزینه هایی که به شدت دانش موجود در ایران درباره آنها کم است، از حاشیه امنیت پایین برخوردار هستند و ریسک بالای دارند. البته در بعضی موارد هم استفاده از یک گزینه با توجه به این مورد نیز به صرفه خواهد بود. مثلا وقتی پروژه ای را انجام می دهید که برای اولین بار در ایران در حال انجام است.
  • چه مقدار تغییر در زیرساخت های فعلی نیاز است تا از این مورد استفاده شود؟
    از خودتان بپرسید چه مقدار تغییرات در فرایند ها یا زیرساخت های فعلی نیاز است تا بتوان از آن استفاده کرد؟ اگر تغییرات زیاد بود و استفاده از گزینه مورد نظر ارزش افزوده بالایی داشت خوب تغییرات را اعمال کنید. ولی همیشه در ذهن داشته باشید هر چه قدر پروژه به جلو پیش برود و بیشتر در فاز نگهداری باشید تغییرات بنیادین هزینه بر و بی فایده خواهند بود. شاید بعضی وقتها دوباره نوشتن یک محصول پاسخ بهتری برای بعضی مشکلات باشد.
  • متن باز است؟ متن باز بودن امکانات یا اختیاراتی در اختیار برنامه نویسان و شرکت قرار می دهد؟
    آیا گزینه مورد نظر شما متن باز است؟ این متن باز بودن چه امکاناتی به شما می دهد؟ فقط نگویید خودمان می توانیم کدش را بگیریم و تغییرات بدهیم. چون این کار را نخواهید کرد. متاسفانه عادت جدید برنامه نویسان لااقل در ایران این است که وقتی ابزاری را انتخاب کردند و بعد از کار با آن یک مقدار اذیت شدند خیلی به دنبال رفع مشکل در آن ابزار یا پیدا کردن راه حل مخصوص آن ابزار نخواهند رفت، به دنبال ابزار مشابه دیگری خواهند رفت. به این مورد اطمینان دارم. وقتی به این فکر کردید که کد پروژه ای را خودتان ویرایش خواهید کرد به آخرین باری فکر کنید که این کار را انجام داده اید. امیدوارم منظورم را متوجه شده باشید. علاوه بر همه این ها نگهداری از پروژه های بزرگ متن باز معمولا کار زمان بری است و اگر پروژه یا ابزار کاربران زیاد فعالی در اینترنت نداشته باشد این کار دشوارتر هم خواهد شد.
  • شرکتی پشتیبانی آن را بر عهده دارد؟ شرایط و هزینه پشتیبانی چگونه است؟
    خیلی وقت ها ممکن است پروژه ای به صورت اولیه متن باز باشد. ولی شرکت یا شرکت هایی کارهای مربوط به پشتیبانی و نگهداری آن را به صورت رایگان یا غیر رایگان به عهده گرفته باشند. به نظر من اگر پروژه یا ابزاری به صورت باشد خیلی خیلی مفید خواهد بود. چون علاوه بر این که شما یک پشتیبانی منسجم و مستمر را در اختیار دارید، می توانید از مزایای متن باز بودن آن نیز استفاده کنید. به نظر من همیشه تلاش کنید پشتیبانی از یک ابزار را برون سپاری کنید، شاید هنوز امادگی مدیریت و نگهداری چند ابزار را به صورت بومی در سازمان خود نداشته باشید.
  • نمونه پروژه موفق تجاری ای دارد؟
    آیا گزینه مورد شما در پروژه ها یا محصولات تجاری به صورت جدی استفاده شده است یا فقط یک سری نمونه کد یا پروژه های ساده از آن وجود دارد؟ یا به طور کلی توجه کنید که کاربران آن بیشتر طرفدار دو آتشه هستند یا این که واقعا در پروژه های خود از آن استفاده کرده اند؟ موفق بوده اند؟
  • نقشه راه آن چگونه است؟
    آیا مسئولین پروژه یا ابزار مورد نظر شما در حال برنامه ریزی برای ارائه نسخه major هستند؟ آیا در حال برنامه ریزی برای ادغام با پروژه ای دیگر هستند؟ ایا پروژه مورد نظر شما deprecated شده است؟ آیا کار بر روی آن قطع شده است یا در حال قطع شدن است؟ پاسخ به سوالاتی از این دست به شما در تصمیمتان کمک بزرگی خواهد کرد.
  • آیا به صورت مستمر روی آن کار می شود؟
    این که روی یک پروژه به صورت مستمر کار شود به شما این اطمینان را خواهد داد که در مدت زمان قابل قبولی با از بین رفتن ابزار و ناپدید شدن آن روبرو نخواهید شد. روش های مختلفی برای تشخیص کار مستمر روی یک پروژه وجود دارد. به طور مثال بررسی تاریخ های بروزرسانی نسخه ها. حجم تیکت های پشتیبانی موجود و مدت زمان پاسخگویی به آنها. وجود مشاوره فعال برای پروژه. وجود کتاب، وجود وبلاگ های بروز، وجود مقالات در سایت های مختلف، و یکی از مهمترین ها وجود سوال و جواب های بروز در سایت stackoverflow.com

به امید انتخاب های خوب.

چه چیزهایی یاد بگیریم: زبان برنامه نویسی

Languages

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

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

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

  • آیا نیاز به cross platform بودن دارید؟
  • به بازار کار خارج از ایران نیم نگاهی دارید؟ یا فقط به بازار ایران توجه دارید؟
  • دوست دارید موقعیت های کاری زیادی داشته باشید؟ یا اگر موقعیت کاری کمتری داشتید ولی درآمد تان خوب بود کافی است؟

آیا نیاز به cross platform بودن دارید؟

با توجه به این که اکوسیستم فعلی زبان های برنامه نویسی به سمت cross platform شدن بیشتر پیش می روند خیلی نیازی نیست نگران این موضوع باشید. اگر تکنولوژی های مایکروسافت ای را انتخاب کنید با درصد قابل قبولی می توانید برنامه ها و سیستم های مستقل از پلتفرم تولید کنید. ولی همیشه در نظر  داشته باشید که موضوع cross platform کار ساده و پیش پا افتاده ای نیست و درد سرها و مشکلات خاص خود را دارد.

به بازار کار خارج از ایران نیم نگاهی دارید؟ یا فقط به بازار ایران توجه دارید؟

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

دوست دارید موقعیت های کاری زیادی داشته باشید؟

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

نکته: از نظر فنی خیلی خوب خواهد بود که یک در زبان هایی که می آموزید یک زبان با ذات dynamic و یک زبان با ذات static وجود داشته باشد. مشاهده کردن تفاوت های زبان های dynamic و static قدرت حل مسئله و طراحی شما را بالا می برند.

 

چه چیزهایی یاد بگیریم: انتخاب پلتفرم (Platform)

حتما اینجا و اینجا را مطالعه کنید.

StockfreshDecisions

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

کلا تصمیم جدی نگرفتن در این موضوع باعث می شود که شما بعد از مدتی همه کاره و هیچ کاره بشوید.

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

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

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

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

همیشه اولویت اصلی را علایق خود بگذارید

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

  • طرز فکر طرفداری (fan)
  • طرز فکر اقتصادی

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

مشورت فراموش نشود

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

و همیشه در نظر داشته باشید که در نهایت هیچ تفاوتی نخواهد کرد که شما لینوکس کار هستید، یا ویندوز کار، یا مک و هر چیز دیگری… مهم تاثیرگذاری شما است و بس.