https://virgool.ir/feed/@milad.khanmohammadiبرنامه نویس و توسعه دهنده ارشد فرانت اند، علاقه مند به ایده ی T-Shapedfa2026-11-11 18:05:45https://files.virgool.ir/upload/users/1584417/avatar/p1s0Lg.jpeghttps://virgool.ir/@milad.khanmohammadihttps://virgool.ir/@milad.khanmohammadi/برنامه-نویس-توسعه-دهنده-یا-مهندسی-به-شکل-t-qn9cfaovqrmfمهندسی به شکل حرف T یا T-Shaped Engineerمدتهای طولانی است که برنامه نویسان و دست اندرکاران این حوزه، به دنبال مسیر بهینه و درستی هستند در جهت افزایش دانش و تخصص. تا هم بتوانند در جایگاه شغلی که در سازمان دارند مفید واقع شوند و هم جز عناصر اصلی سازمان باشند تا بتوانند موضع قدرت بیشتری را کسب کنند.چه کسی است که از رشد و پیشرفت و ارتقای شغلی خود را بر حذر کند؟!اما بزرگترین چالش در این مسیر، ایجاد و تبلیغ تکنولوژی های مختلفی است که دایماً وارد دنیای برنامه نویسی می شوند و این مسئله به نوبه ی خود، هم باعث پیشرفت کامیونیتی می شود و هم موجب عقب افتادن گروه زیادی از برنامه نویسان از یک راه حل و فریم ورک جدید (solution) می شود.همچنین وجود تکنولوژی فراوان و هیجان انگیز گاها، موجب تشویش ذهنی افراد می شود. چرا که فرد (در اینجا مهندس) را دچار تناقضات فراوانی می کند، که آیا دانشم تا این مرحله کافی ست یا نیاز دارم همچنان عناوین و فریم ورک های جدید را آموزش ببینم؟ این طرز فکر مستقیما به اعتماد نفس ما برنامه نویسان ضربه می زند.انتخاب بین متخصص بودن در یک حوزه (specialist) یا دانش کلی داشتن در حوزه‌های مختلف (generalist)، سالهاست موضوع بحث جامعه ی برنامه نویسان است اما این روزها، صنعت به چیزی بین این دو مفهوم نیاز دارد.به عنوان یک مثال، برنامه نویسی را در نظر بگیرید که در زمینه ی Front-End تخصص بالایی دارد. زمانی که پروژه به پایان خود در مرحله ی پیاده سازی می رسد، مدیر پروژه از این فرد میخواد که برای انجام عملیات استقرار و deploy یک فایل Docker file به ایشان تحویل دهد تا image و container مورد نظر از قسمت Front-End ایجاد شود. اگر این فرد، تنها یک برنامه نویس متخصص فرانت اند باشد (specialist)، در ایجاد Docker file دچار مشکل خواهد شد، چرا که دانشی در مورد linux, shell script, containerization , kubernetes و اصول DevOps ندارد. پس مشکل از همین قسمت آغاز می شود. اما چه باید کرد؟ در ادامه همراه باشید تا دو مدل کلی از مهندسان را بررسی کنیم و سپس مدل سوم یا همان T-shaped را به عنوان چاره کار معرفی کنیم.یک مهندس خوب شدن نیاز به جمع آوری تجربیات فراوانی دارد، هر پروژه ای حتی کوچک، یک فرصت محسوب می شود تا یک ابزار یا یک تکنیک جدید یاد بگیریم. و این زمانی خودش را نشان می دهد که انواع تکنیک هایی که در پروژه های متعدد یاد گرفته ایم در یک پروژه ی جدید به کارمان می آید.اما بریم سراغ دو مدل کلی از مهندسان که در گذشته و هم اکنون، که تعدادشان زیاد است:کلی‌دان‌ها یا Generalists یا همان developer هاسبک کاری یک Generalist که به انواع تکنولوژی ها میبایست آشنا باشد.اگر قصد دارید مسیر کسب دانش کلی را طی کنید، مهارت‌های شما به صورت افقی رشد خواهد کرد. یعنی از آموختن مفاهیم جدید لذت خواهید برد و می‌توانید حس کنجکاوی خود را از طریق کار کردن با ابزارها و زبان‌های مختلف اغنا کنید.متخصص شدن در همه چیز دشوار است. برای متبحر شدن در هر تکنولوژی، لازم است مدت زمان زیادی را به آن اختصاص دهید. یک فرد "توسعه دهنده" یا "developer" در یک زمان روی انواع تکنولوژی ها تمرکز می‌کند بنابراین توجه او بین آن چیزها تقسیم می‌شود.معمولا developer ها به حوزه‌های مهارتی زیادی ورود می‌کنند اما بسیاری از آنها دارای دانش سطحی هستند. اغلب، زمانی که نیاز به انجام کارهای چالش‌برانگیز در پروژه وجود داشته باشد، مهندسانی با دانش عمیق‌تر(specialist) بیشتر به درد پروژه میخورند.در انگلیسی عبارتی داریم تحت عنوان “A jack of all trades, but a master of none” که شاید در فارسی خودمان اینگونه ترجمه شود که "همه کاره و هیچ کاره". با وجود بار منفی این جمله و ضرب المثل، اما در زمینه ی برنامه نویسی بار این جمله منفی نیست و اتفاقا هم سمت شغلی developer (در این جا همان فردی که تکنولوژی های زیادی را به صورت عمومی و سطحی می داند.) از جمله شغل های پر نیاز امروز است.دنیای پیچیده ی امروز برنامه نویسی نیاز به افراد حرفه ای دارد.( T-Shaped engineer )متخصص‌ها یا Specialists یا همان programmer هامتخصص‌ها زمان و تلاش خود را وقف مجموعه محدودی از فناوری‌ها و ابزارها می‌کنند. آنها لذت کشف حوزه‌های مختلف را قربانی اختصاص دادن وقت و تلاش خود روی یک حوزه ی خاص می‌کنند و به همین دلیل فاقد دانشی ورای مبانی و اصول ابتدایی در حوزه‌های پشتیبان هستند اما در کاری که انجام می‌دهند متبحر می‌شوند.بسیاری از برنامه‌نویسان به دلیل علاقه به رویارویی با چالش‌ها در این دسته قرار می‌گیرند. آنها عاشق حل کردن معماها و گره‌گشایی از مشکلات پیچیده هستند. اغلب این متخصص‌ها هستند که مسئول یافتن سخت‌ترین و باارزش‌ترین راه‌حل‌ها می‌شوند. تخصص آنها به آنها بینشی می‌دهد که سایر برنامه‌نویسان فاقد آن هستند. اختصاص دادن تمام وقت خود به یک زبان، stack یا تکنولوژی می‌تواند محدودکننده باشد. به عنوان مثال فرض کنید فردی در برنامه نویسی با JavaScript بسیار متبحر و حرفه ای باشد. مسیر شغلی (career path) این فرد نمی تواند به مدیریت پروژه یا معمار سیستم منتهی شود چرا که این فرد دانشی از قسمت های مهم دیگر در پروژه ندارد. به عنوان مثال این فرد نمی تواند عملیات review و یا CI/CD را به عهده بگیرد. همچنین اگر مشکلی در ساختار API باشد، نمی تواند با دلیل و مدرک با همتای خودش در قسمت backend گفتمان خوبی داشته باشد.توانایی این فرد، در حل مسائل و ارائه ی بهترین راه حل ها تنها در دنیای JavaScript خواهد بود. ارزشی که این فرد به پروژه اضافه می کند این است که شما می توانید با خیال راحت چالش برانگیزترین قسمت های پروژه در قسمت JavaScript را به وی بسپارید. مثلا از وی بخواهید که یک سیستم video chat با تکنولوژی WEBRTC برای شرکت و سازمان تان بسازد.نیاز کمپانی‌ها، بازار و استعدادشاید جالب باشد که بدانید صنعت نرم‌افزار همچنان در حال آزمون و یافتن راه‌هایی برای تولید کارآمدتر و بهینه تر است.امروزه ما برنامه نویسان سریع‌تر از قبل محصول را lunch می‌کنیم، مرتبا در آن تغییر ایجاد کرده و از همه مهم‌تر، اگر مجبور شویم تمام feature ها را reject می‌کنیم. امروزه، پروژه‌ها به ندرت از ابتدا تا انتها طبق برنامه پیش می‌روند. در طول پروسه تولید، اصلاحات انجام می‌شود. گاهی کل امکانات و ویژگی‌ها کنار گذاشته شده و ویژگی‌های جدید جای آنها را می‌گیرند و حتی ممکن است جزییات sprint دستخوش تغییرات زیادی شود. اینجاست که کمپانی‌های پیشرو و خاص به دنبال روش‌های هوشمندانه‌تر برای انجام کارها هستند. اما برای رسیدن به این هدف، دنیای نرم افزار نیاز به استعدادهای مختلف دارند.پس نیاز به تغییر شخصیت برنامه نویس از سمت کمپانی هم وجود دارد.روش کار در گذشتهدر گذشته، کار تولید محصول بر اساس منابعی که در دسترس بود، اولویت بندی می‌شد. اگر پروژه و feature ها نیاز به برنامه نویسان بک اند بیشتری داشتند، برنامه‌نویسان Javaی بیشتری استخدام می شدند و در زمانی که بخش backend مواردش را انجام می داد مدیر پروژه به دنبال ایجاد کار برای آنها بود تا بیکار نباشند. به نظر می رسد این رویکرد که هر قسمت در پروژه را به طور کامل از بخش دیگر جدا کنیم در ادامه برای سازمان مشکلاتی را ایجاد خواهد کرد.من بارها شاهد این رویکرد و طرز فکر در مدیران پروژه ها بوده‌ام که مدیر محصول تلاش می‌کرد بفهمد چگونه تیم UI را مشغول نگه دارد. چند ماه بعد تیم بک اند روی بازسازی و بهبودها تمرکز می‌کرد اما هیچ‌کس برای پیاده‌سازی نقاط پایانی جدید و مورد نیاز وجود نداشت.مثلا اگر با همین روند متخصصان در یک حوزه پیش برویم، چه کسی در پروژه عملیات deploy را به عهده می گیرد؟ چه کسی می تواند review خودکار در پروژه را راه اندازی کند؟ چه کسی pipeline های مربوط به test stage را می نویسد؟در ادامه ی این سناریو اگر از مهندسان خواسته شود وظایفی را بر عهده بگیرند که در حالت عادی انجام نمی‌دادند، این برای افرادی که وقت خود را صرف متخصص شدن در یک استک دیگر کردند، خسته کننده خواهد بود. گرچه این رویه می‌توانست نشانه ی بدی در پروژه باشد اما من خیلی موافق نیستم. این افراد به دلیل مجموعه مهارت‌هایی که داشته اند، استخدام شده اند، اما در بعضی مواقع مسیر تغییر می‌کند. شاید یک ابزار جدید وارد بازار شود، یا ممکن است نظر کاربران تغییر کند. مثلا آنها به جای استفاده از وب اپلیکیشن ترجیح بدهند از وبسایت شما استفاده کنند.آیا در این حالت باید برنامه نویسان اپلیکیشن در شرکت را اخراج کرد و به جای آنها افراد با قابلیت های مورد نیاز فعلی را استخدام کرد؟جواب خیر استبهترین بودن در دو حوزه (یا ترکیب specialist و generalist)پروژه های امروزی نیاز به برنامه نویسانی دارند که بتوانند خود را با پویایی دنیای مدرن وفق دهند. یعنی متخصصانی که خودکفا هستند و وقتی مثلا تیم DevOps از دسترس خارج است، دچار وقفه نمی‌شوند. در حالت ایده‌ال هر یک از افراد تیم باید در صورت نیاز جای بقیه افراد تیم – از تغییرات کوچک در UI تا رفع باگ CI – را پر کند. البته این شرایط در سخن آسانتر از عمل است. کسب مهارت‌های مختلف برای بازدهی داشتن در حوزه‌های مختلف به سال‌ها صرف زمان نیاز دارد. شما هم باید در معرض بخش‌های مختلف محصول قرار بگیرید. اما حواستان باشد که یک کمپانی با تفکیک‌ شدید تیم‌ها به شما این فرصت را نخواهد داد.در عین حال، وقتی نیاز به انجام کارهای پیچیده وجود داشته باشد، یک تیم از افراد developer (کلی‌دان) فاقد تجربه کافی برای اتخاذ تصمیمات مناسب است(مثلا چگونگی نوشتن یک ویدیو چت به صورت peer to peer). وقتی عملکرد دیتابیس نیاز به بهبود داشته باشد یا تصمیماتی برای معماری محصول گرفته شود، نیاز به فردی است که به صورت عمیق روی آن موضوع تمرکز کرده باشد.مهندس به شکل T یا T-Shaped Engineerتکامل تدریجی روش‌های تولید نرم‌افزار نیاز به نوع جدیدی از مهندسی یعنی "توسعه دهنده های متخصص" دارد.(specialistهایی که generalist هستند!) بنابراین عبارت مهندس به شکل T یا T-Shaped Engineer ایجاد شد. این عبارت برای توصیف برنامه نویسی به کار می رود که توزیع دانش او مانند حرف انگلیسی T است. خط افقی نشانگر دانش گسترده کار در حوزه‌های مختلف است و خط عمودی تخصص در یک حوزه خاص را نشان می‌دهد.یک برنامه نویس backend حرفه ای که می‌تواند UI مورد نیاز پروژه ی خود را ایجاد کند، و کمی هم style و CSS به آن اعمال کند در این دسته قرار می‌گیرد. یا یک برنامه نویس Front-End که می‌تواند در زمان نیاز یک سرویس node js را ایجاد کند و image داکر را هم آپدیت کند یا بتواند یک اندپوینت API را رفع باگ کند هم یک مهندس T شکل است.داشتن تیمی از مهندسان جنرالیست متخصص به این معنی است که آن کار می‌تواند بدون نگرانی در مورد در دسترس بودن برنامه‌نویسان، انجام شود. این رویکرد باعث می شود همه افراد نقش بیشتری در پروژه داشته باشند.ممکن است اسامی دیگری هم در این مورد بشنوید که معنا و مفهوم آنها همین T-Shaped هستند:multi-skilledgeneralizing specialisticicle-shapedpaint dripcomb-shapedمهندسان T-Shaped به بقیه کمک می کنند تا اعضای تیم بتوانند بهتر با یکدیگر ارتباط برقرار کنند:با یادگیری مهارت های یکدیگر، یک زبان مشترک بین ما و نفر مقابل در تیم ایجاد می شود. و این باعث می شود که به سادگی با یکدیگر تعامل کنیم. به عنوان نمونه اگر گرافیست تیم، درک خوبی از قوانین HTML داشته باشد، قادر است طرح منطقی تر و بهینه تری را تحویل نفر بعد بدهد.معایب مهندسی T شکلدر اختیار داشتن متخصصان تی شکل یک عصای جادویی نیست. به این معنی نیست که همه می‌توانند همه کار انجام دهند و آن را به بهترین شکل ارائه دهند. گرچه این افراد دانش گسترده‌ای دارند اما به این معنا نیست که آنها می‌توانند عملکرد استثنائی و منحصر به فردی در همه حوزه ها داشته باشند.ممکن است گاهی کسب و کارها به اشتباه انتظار داشته باشند که این مهندسان در همه چیز متخصص باشند. مهندسان تی شکل می‌توانند به سرعت با تکنولوژی‌های مختلف آداپته شوند اما همچنان فقط یک حوزه اصلی برای تمرکز دارند. انتظار اینکه یک جنرالیست متخصص بتواند یک کارشناس در حوزه ابری، معماری میکروسرویس و رابط‌های کاربری باشد، اصلا واقع‌بینانه نیست. برنامه‌نویسان می‌توانند مهارت‌های مختلفی داشته و از یکدیگر پشتیبانی کنند اما دانستن نقاط قوت هر یک از افراد تیم بسیار تعیین‌کننده است. در غیر این صورت باز هم در موقعیتی هستیم که انتظار داشته باشیم جنرالیست‌ها تصمیماتی بگیرند که نیاز به تخصص‌های جدی دارد.آیا مهندسی T شکل یک انتخاب است؟من اخیرا شروع به انجام گفتگو‌هایی در لینکدین در مورد متخصص‌ها و جنرالیست‌ها کرده‌ام. این روزها یک فرد حرفه‌ای باید کدام گزینه را انتخاب کند؟ برخی از پاسخ‌ها از سوی افراد غیرفنی بود که نشان می‌داد که این مساله فقط در صنعت نرم‌افزار وجود ندارد.خلاصه‌ای که می‌توانم از تمام پاسخ‌ها بدهم این است که افراد بیشتر به سمت جنرالیست بودن یا متخصص تی شکل بودن تمایل پیدا کرده‌اند. من فکر نمی‌کنم این یک جریان زودگذر باشد. این یک نیاز واقعی در کسب و کارها است و جنرالیست بودن ممکن است دیگر تنها یک گزینه نباشد بلکه یک نیاز است. حتی اگر شما وقت خود را به یک موضوع اختصاص داده باشید، لازم است که در چندین حوزه پشتیبان هم دانشی کسب کنید. پیاده‌سازی‌های مدرن به قدری عالی شده‌اند که به ما این امکان را می‌دهند که در کل فرآیند توسعه بیشتر مشارکت داشته باشیم اما مسئولیت یادگیری بیشتر را هم به همراه دارد.وقتی چیزی را می‌سازید که نیاز به نوشتن تست برای آن وجود دارد، در این صورت این سوال ایجاد می‌شود که چگونه آن را پیاده کنید. برای این کار باید تصمیم بگیرید کدام زیرساخت بهترین نتیجه را خواهد داشت. وقتی که فرآیند توسعه به اتمام رسید، چالش‌های بیشتر سربرمی‌آورند. لازم است که بر محصولی که lunch می‌کنید نظارت کرده و کار نگهداری آن را بر عهده بگیرید که کار ساده‌ای نیست. برای انجام تمام این کارها به صورت صحیح به چیزی بیشتر از دانش کار کردن با مجموعه‌ای گسترده از ابزارها نیاز دارید. وقتی فرهنگ به سوی ذهنیت «خودت بساز، خودت اجرا کن» تغییر پیدا می‌کند، متخصص بودن در یک حوزه دیگر کافی نیست.میلاد خان محمدیمیلاد خان محمدیFri, 29 Jul 2022 15:37:25 +0430