سلام برای نوشتن مستندات یه کتابخونه نیاز بود تا یه وبلاگ ایجاد کنم، برای همین تصمیم گرفتم روش کار رو که با فریمورک hexo انجام میشه براتون بصورت فیلم آموزشی ضبط کنم.
در مورد هگزو باید بهتون بگم که یه فریمورک خیلی ساده و قوی برای ایجاد سایت های استاتیک هستش علاوه بر اینکه خیلی ساده هستش بسیار عالی و قوی هم هست. اگه اشتباه نکنم هگزو توسط برنامه نویس های چینی طراحی شده و یا حداقل اکثرا چینی ها بهش علاقه دارن!
توی این ویدئوی ۳۰ دقیقه ای با هم دیگه سیستممون رو کانفیگ میکنیم تا هگزو رو نصب کنیم چندتا مطلب تست میفرستیم رو وبلاگمون و در آخر وبلاگمون رو روی سایت گیتهاب منتشر میکنیم. بدون اینکه نیاز به تهیه هاست و دامنه باشه.
راستی من تو ویدئو فراموش کردم که بگم شما میتونید پوشه Public که شامل فایل های html و… هستش رو هرجا که دوست دارید اپلود کنید و استفاده کنید. محدودیتی نداره میتونید روی هاست شخصی بزارید یا روی گیتلب و…
در دنیای ایدهآل من، همه پروژهها همیشه به موقع تمام میشوند و هیچ وقت خرجشان از بودجه تخمینی بیشتر نمیشود. تازه با همان بودجه، تیمها نه تنها میتوانند Featureهای اضافه بسازند، که میتوانند قبل از بیرون دادن نسخه نهایی همه چیز را چندین بار هم تست کنند. اما حیف، دنیای واقعی اینقدرها هم دلنشین نیست؛ بلکه در فرآیند توسعه نرمافزار، با هر قدمی که میگذاریم مشکلات جدیدی از چپ و راست جلوی پایمان سبز میشوند. یکی از رایجترین و همهگیرترین این مشکلها، بدهی فنی (Technical Debt) است.
بدهی فنی چیست؟
بدهی فنی، کارهای تکمیلیای است که برای کامل کردن فرآیند توسعه نرمافزار، زمانی در آینده باید آنها را انجام بدهیم. بدهی فنی نتیجه عجله کردن در تحویل کارکرد یا پروژهای است که در آینده، نیاز به بازسازی خواهد داشت. به عبارت دیگر، پیامد اولویت دادن تحویل سریع به نوشتن کد ایدهآل است.
بدهی فنی مثل بدهی بانکی است؛ اگر به موقع پرداختش نکنیم، جریمه میشویم و بدهیمان از قبل هم بیشتر میشود. بیتوجهی به بدهیهای فنی باعث میشود عملکرد نرمافزار ضعیف شود، تغییر دادن آن سخت یا حتی غیرممکن باشد، و احتمال ایراد پیدا کردن برنامه بعد از هر بروزرسانی بیشتر و بیشتر شود.
اما همانطور که با وام گرفتن میشود سریعتر به اهداف بزرگ زندگی رسید، بدهیهای فنی هم الزاماً بد نیستند. اگر آنها را درست مدیریت کنید، مزایای بینظیری برای شرکتتان خواهند داشت؛ بخصوص اگر از آن شرکتهایی باشید که رشد سریع دارند. در چنین شرکتی باید محصولات را سریع و زودبهزود ارائه کنید تا بتوانید تناسب محصول/بازار را پیدا کرده، نیازهای مشتری را برآورده کنید، و از فرصتهایی که سر راهتان پیش میآید بهره ببرید. با مدیریت بدهی فنی، تضمین خواهید کرد که حرص دویدن، در بلندمدت زمینتان نخواهد زد.
درست است که هیچ دستورالعملی برای همه آدمهای روی کره زمین جوابگو نیست، اما به نظر میرسد آشنایی با انواع بدهیهای فنی، به تیمها کمک میکند تا در مورد بدهی فنی حرف بزنند و مشکلات مربوط به آن را به شکل بهتری حل کنند.
دگ لیودن (Dag Liodden)، کوفاندر و CTO شرکت فناوری تبلیغاتی تپاد (Tapad) بیشتر از ۱۴ سال است که دارد با بدهی فنی سر و کله میزند؛ در ادامه نگاهی میاندازیم به سه نوع اصلی بدهی فنی که توسعهدهندگان بیشتر از همه با آنها سروکار دارند و استراتژیهایی که دگ لیودن برای روبهرو شدن با هر کدام پیشنهاد میکند را مرور میکنیم:
۱. بدهی فنی عامدانه
بدهی فنی و عواقب آن
مهندسها معمولا خودشان میدانند که کدام راه، راه درست انجام کار است و کدام راه، راه سریع آن. خیلی وقتها، راه سریع همان کار درست است (برای جلوگیری از Over-engineering)، اما بعضی وقتها هم اعضای تیم عمداً کار «اشتباه» را انجام میدهند، چرا که باید محصول را به سرعت به بازار برسانند.
برای رساندن محصول به بازار، گاهی اوقات مجبورید خودتان عمداً بدهی فنیتان را زیاد کنید. وقتی این مسیر را در پیش میگیرید، فقط به زمانی که در آن صرفهجویی کردهاید فکر نکنید؛ بلکه به این هم بیندیشید که برای بازپرداخت بدهیای که ایجاد کردهاید در آینده چه باید بکنید. مطمئن شوید که ذینفعان محصول میدانند که این صرفهجویی، منجر به کاهش سرعت آماده شدن Featureهای دیگر در آینده خواهد شد.
راه حل: شاید بگویید که این کار خیلی با فرهنگ چابک (Agile) تیم شما سازگار نیست! اما ایده خوبی است که وقت ایجاد این نوع از بدهی فنی، کارهایی که انجام ندادهاید را در بکلاگ محصول (Backlog) یادداشت کنید. اگر این کارهای ناتمام به طور مشخص ثبت نشوند، بعید است که بدهی فنی در آینده پرداخت شود. بدون پرداخت بدهیها، در گذر زمان بدهی فنی عامدانه تبدیل به بدهی ناشی از طراحی اتفاقی خواهد شد. مسئولیت به وجود آمدن این نوع بدهیها بر عهده مالک محصول (Product Owner) و ذینفعان است؛ زیرا به خاطر تصمیمات تجاری است که به وجود میآیند.
۲. بدهی فنی ناشی از طراحی تاریخگذشته یا اتفاقی
هنگام طراحی سیستمهای نرمافزاری، سعی کنید بین «آیندهنگری در کدنویسی» و «سادگی و سرعت تحویل» تعادل برقرار کنید. کار سختی است، و هر کسی گاهی در آن شکست میخورد. با گذر زمان، رشد سیستم، و تغییر نیازها، ممکن است به این نتیجه برسید که طراحی کارتان مشکل دارد و یا اینکه ایجاد یک کارکرد جدید تبدیل به کاری سخت و کند شده است. در یک طراحی خوب و اصیل، Refactor یا بازسازی تدریجی کدها خیلی آسانتر خواهد بود. اما بعضی وقتها هم چارهای نیست؛ باید خون دل خورد، نشست و یک دور Refactor مفصل و پر و پیمان انجام داد.
راه حل: اینکه چطور Refactor مفصلی بکنیم خودش چندین پست جدا میطلبد، اما نیاز به انجام آن یک چیز طبیعی است. هرچند وقت یک بار، مثلا هر دو سال یک بار یا هر وقت که سیستم در وضعیت باثباتی بود، لازم است که چنین کاری انجام شود. اگر نشود، آنوقت ممکن است Over-engineering کنید و باعث شوید سیستم به شکل غیر ضروریای مرتباً کند باشد. رهبران تیم و مالک محصولها باید اطمینان حاصل کنند که برای بازپرداخت این نوع بدهی در آینده زمان کنار میگذارند؛ چرا که علت به وجود آمدن آن، تصمیمات مربوط به طراحی سیستم و تغییر مداوم نیازهای سیستم است.
۳. بدهی فنی ناشی از فرسودگی نرمافزاری
فرسودگی سیستم و بدهی فنی متعاقب آن
بدهی فنی ناشی از فرسودگی نرمافزاری (Bit rot)، به مرور زمان به وجود میآید. تغییراتی که به تدریج در یک Component یا یک سیستم ایجاد میکنیم، باعث میشوند که کمکم سیستم پیچیدگیهای غیرضروریای پیدا کند. این پیچیدگی بخصوص زمانی تشدید میشود که چندین نفر بدون اینکه طراحی اولیه سیستم را درست فهمیده باشند، روی آن کار کنند. از جمله علایم چنین حالتی، برنامهنویسی کپیپیستی (یا به عبارتیCargo Cult Programming) است.
راه حل: این تنها نوع از بدهیهای فنی است که باید با Refactor مداوم کدها، به کلی از آن اجتناب کرد. تیمهایی که قوی هستند، برای فهم طراحی سیستمی که رویش کار میکنند، وقت کافی میگذارند؛ حتی اگر طراحی اولیه آن کار خودشان نبوده باشد. آنها به مرور طراحی را بهبود میبخشند و در طول مسیر، کدهای بد را تمیز میکنند. مسئولیت جلوگیری از به وجود آمدن این نوع بدهی با تیم توسعه نرمافزار است، زیرا این تکبهتک اعضای توسعهدهنده هستند که آن را به وجود میآورند.
تقسیمبندی انواع بدهی فنی یک راه حل معجزهآسا نیست. اینطور نیست که چوبدستی را تکان بدهیم و فقط با طبقهبندی، مدیریت کردن بدهی را به طور جادویی آسان شود. اما این کار، تیم شما را قدرتمندتر میکند و گفتگوهای مفیدتری در اینباره خواهید داشت. بدهی فنی شما به سیستم هرگز تمام نخواهد شد، و نباید هم بشود. نکته مهم این است که همیشه حواستان باشد که این بدهی چطور باعث کندی تیمتان میشود، و سعی کنید بین «تحویل Featureها در کوتاهمدت» و «افزایش بازدهی کلی در میانمدت و بلندمدت»، تعادل برقرار کنید.
کوئرامگ مجلهای تخصصی برای توسعهدهندگان است که هر هفته با مطلبهایی در زمینه تکنولوژی، رشد فردی و آینده برنامهنویسی بهروزرسانی میشود. برای اطلاع از آخرین مطلبهای کوئرامگ، میتوانید اکانت توئیتر یا کانال تلگرام ما را دنبال کنید.
اگر برای مدتی به توسعه نرم افزارهای اندرویدی با اندروید استودیو پرداخته باشید، متوجه شدید که پس از مدتی حجم دایرکتوری که حاوی پروژه هاست خیلی زیاد شده است.
در هر پروژه اندرویدی که با اندروید استودیو میسازیم چند دایرکتوری زائد داریم که بیلدسیستم آن ها را ایجاد میکند. این دایرکتوری ها عبارتند از:
۱- دایرکتوری gradle. که در روت دایرکتوری پروژه قرار گرفته است. ( با دایرکتوری gradle آن را اشتباه نگیرید)
۲- دایرکتوری build که داخل دایرکتوری app هست.
با حذف این دو دایرکتوری حجم یک پروژه ممکن است از حدود ۴۰ مگابایت به زیر ۱ مگابایت برسد.
اگر ۴۰ پروژه داشته باشیم، چیزی حدود ۱٫۶ گیگابایت فضا اشغال شده است. که میتوان با حذف دایرکتوری های زائد آن را به حدود ۴۰ مگابایت کاهش داد.
با هر بار build کردن پروژه، این دایرکتوری ها دوباره ایجاد می شوند.
قاعدتا برای ما حرام است که به صورت دستی وارد همه دایرکتوری ها بشویم و دایرکتوری های زائد را حذف کنیم.
پس یک بش اسکریپت می نویسیم که این کار را برایمان انجام دهد.
در این اسکریپت روی تمام دایرکتوری های موجود در دایرکتوری پروژه های اندرویدمان یک حلقه میزنیم و دایرکتوری های gradle. و build را در صورت وجود حذف میکنیم.
این اسکریپت خیلی خیلی ساده است. اما با این حال l اگر می خواهید از آن استفاده کنید ابتدا روی یک پروژه تست کنید تا مطمئن شوید مشکلی برای پروژه هایتان ایجاد نمی کند.
مرتب سازی مقادیر یک آرایه در برنامه نویسی، احتمالا جزو سوالاتی است که برای هر برنامه نویسی پیش میآید! فارق از اینکه با چه زبانی و چه IDE یا Code Editorای کار میکنید، باید این رو در نظر داشته باشید که ساده نگاه کردن شما به مسئله هستش که براتون راه حل میسازه. نکته: همیشه موقع حل چنین چالیش هایی همه به دنبال این هستند که مثلا هر عدد رو با عدد بقلیش رو چک کنن! یا هر عدد رو با کل اعداد دیگه! اما این مدل راه حل ها باعث ایجاد سردرگمی میشه و بیش از پیش از جواب دور میشید.
توی بخش بعد ساده ترین راه ممکن توی عالم رو برای این مسئه بررسی میکنیم.
الگوریتم مرتب سازی مقادیر یک آرایه
ابتدا کمترین و بیشترین مقدار در آرایه رو پیدا کنید.
یک آرایه به طول آرایه اصلی بسازید.
از کمترین مقدار به سمت بیشترین مقدار رفته و هر بار یکی به مقدار قبل اضافه کنید.
در صورتی که مقدار حال حاضر در مرحله ۳ با یکی از خانههای آرایه اصلی برابر بود اولین خونه خالی توی آرایه مرحله ۲ رو به عدد مورد نظر نسبت بده در غیر این صورت برگرد مرحله ۳
ششمین روز از چالش هم گذشت و در این روز با یاری خدا و با همتی مضاعف سرفصل های Advanced کتابخانه React هم تمام شد. از فردا پروژه اصلی خودم که به نوعی استارت آپ محسوب می شه رو استارت می زنم و به امید خدا تا پایان این چالش ۱۰۰ روزه به مرحله بهره برداری می رسونمش 🙂
طی سال های گذشته که به برنامه نویسی مشغولم، یکی از دغدغه های دوستان و همکارانم که از نزدیک اون رو لمس کردم، خرید ابزارها و تجهیزات به روز برای برنامه نویسی است. به عنوان مثال فردی که هر روز در اینترنت جستجو می کنه تا آخرین مدل مک بوک رو خریداری کنه و باهاش کد بزنه. یا فردی که حتما باید مانیتور دوم و سوم و … داشته باشه تا موفق به تایپ یک خط کد بشه! من ۱۰۰٪ مخالف این ایده نیستم و در اینکه ابزار مناسب هر حرفه ای می تونه سرعت رشد و بهره وری در اون حرفه رو بالا ببره شکی نیست، اما از طرفی باید در نظر داشت که آیا حد تعادل هم رعایت می شود؟ آیا در مدت زمانی که برای جستجوی فلان مدل لپ تاپ صرف شده نمی توانستیم ۱۰۰ خط بیشتر کد بزنیم؟ آیا هزینه ای که صرف خرید مانیتور دوم شده، نمی توانست خرج یک دوره آموزشی جذاب و کاربردی شود؟
به نقل از جیسون فراید: بسیاری از گلف بازان آماتور فکر میکنند که آنها نیاز به باشگاههای گران قیمت دارند اما در اصل این نوعِ چرخش دست است که مهم است.
به تعبیری دیگر شاید بهتر باشه ابتدا با ابزارهای موجود، تمرکز رو روی پیشرفت خودمون تا سطح قابل قبولی (حرفه ای) بزاریم و سپس برای افزایش بهره وری و پیشرفت تا سطوح بالاتر (فوق حرفه ای) به فکر ارتقا ابزار باشیم.
نظر شما در این باره چیه؟
تا فردایی دیگر و روزی دیگر همه شما رو به خداوند بزرگ و منان می سپارم.
شاید تا الان بارها مطالب مختلفی راجب برنامه نویسی اپلیکیشن های موبایل بوسیله زامارین رو خونده باشین و هردفعه با این کلمه مواجه شده باشین که زامارین سرعت توسعه رو زیاد میکنه! فکر کردین که چطور ممکنه سرعت کار زیاد بشه؟
بزارید با یه مثال بهتون توضیح بدم که ما چطور میتونیم با کمک زامارین برنامه هامون رو با سرعت بیشتری تولید کنیم!
فرض کنید که ما قرار هست یک لیست از اطلاعات رو به کاربر نشون بدیم برای این کار نیاز به یک Listview یا RecyclerView داریم همینطور نیاز هست که آیتم هارو شخصی سازی کنیم و طبق نیازمون اون هارو چینش بدیم.
اگر این برنامه رو با اندروید استودیو بصورت Native انجام بدیم باید این کار هارو انجام بدیم.
یه ویو برای RecyclerView یا Listview بسازیم
یه ویو دیگه برای آیتم های هر ردیف بسازیم
یه کلاس مدل بسازیم
یه کلاس آداپتور بسازیم و ردیف هارو متصل کنیم به ویو (کلی کد نویسی باید بکنیم…)
داخل ویو اصلی اداپتور رو مقدار دهی کنیم و…
حتی اگه بخوایم همه کدهارو کپی پیست کنیم یه ۵ تا ۱۰ دقیقه ای زمان میبره تا سرهم بشه!
حالا بزارید یه نگاه به زامارین بندازیم:
یه ListView میزاریم روی لایوت و همین لیست ویو رو براش Template تعریف میکنیم. تمام!
به همین راحتی قالب ItemTemplate رو خودمون هرطور که دوست داشته باشیم ایجاد میکنیم و با کمک Binding ها مقدار هارو متصل میکنیم به کنترل ها، برای نمایش داده ها تو لیست ویو هم کافیه داده هارو که بصورت List هستن وصلشون کنیم به ItemSource لیست ویو. در کمتر از ۳ دقیقه کامل میشه پیاده سازیش کرد (اگرم کدهارو کپی پیست کنید بیشتر از چند ثانیه نمیشه) !
دیگه نیاز نیست که آداپتور بسازیم، چندتا ویو جداگونه براش بسازیم و… حتی برای ایونت های کلیک و… هم نیازی به کدنویسی نیستش و از همون ایونت های پیشفرض میتونیم براحتی استفاده کنیم.
حالا علاوه بر این موارد ما میتونیم از کتابخونه های بسیار زیادی که برای دات نت موجوده و کاملا هم رایگان هستن استفاده کنیم که دیگه نیازی نباشه خودمون براش کد بنویسیم.
در آخرین لحظات شب درست نزدیک نیمه شب در حال آپلود پست امروز برای پنجمین روز از چالش مهیج و زیبای ۱۰۰ روز کد زدن هستم.
همچنان طبق برنامه در حال یادگیری کتابخانه React هستم و امروز موفق شدم با کمک و الهام گرفتن یکی از پروژه های موجود بر روی Codepen، همچنین مرور JavaScript و نگاهی کلی به تگ های HTML و CSS، پروژه کارت ویزیت الکترونیک رو به پایان برسونم و سورس کد اون رو برای شما عزیزان روی گیت هاب با این آدرس قرار بدم. امیدوارم بتونید در پروژه هاتون ازش استفاده کنید.
به افرادی که قصدشون شروع یادگیری و کار با کتابخانه React و فریمورک React Native هست، شدیدا توصیه می کنم از دوره JavaScript سایت موزیلا استفاده کنند. مزیت این دوره علاوه بر سادگی و روانی اون، حذف موضوعاتی از سرفصل های جاوااسکریپت است که هرگز در برنامه نویسی React از آنها استفاده نمی شود.
تا فردایی دیگر همه شما رو به خداوند بزرگ و منان می سپارم.
من یه برنامه نویسم,شش ساله دارم بین کدهام زندگی میکنم.روزا کد میزنم,شبا بهشون فکر میکنم و خوابشون رو میبینم.عاشق قهوه و چای هستم.وقتی به باگ میخورم دلم میخاد لم بدم بین کدها و سیگار بکشم و آهنگ داریوش گوش بدم!اونکه رفته دیگه هیچ وقت نمیاد…
فک میکنم کد مثل ترشی میمونه باید جا بیافته تا کار کنه.شب کار نمیکنه و صبح بلند میشی و میبینی در اوج ناباوری داره کار میکنه.
تصور اطرافیانم از من یک دختر باهوش با یک شغل شیک و باکلاس!لم دادم پای کامپیوترم و با زدن چند تا دکمه فورا یک سایت رو بالا میارم و به پول کلانی میرسم!دقیقا به همین راحتی…
نزدیکانم اما منو یک موجود عجیب می بینن که قادره ساعت ها و حتی تمام طول روز بدون پلک زدن ,حرف زدن و یا حتی بدون اینکه بشنوه و یا چیزی بخوره زل بزنه به صفحه ی سیاه مانیتورش…
کارفرمام اما منو یک ماشین میبینه بدون هیچ گونه احساس و یا حس خستگی…
درون گرایی و غیر اجتماعی بودن توی اکثر برنامه نویسا وجود داره!که همین دو مورد به مرور باعث کاهش اعتماد بنفس اونا میشه.یه جورایی رفتن به سمت یک پدیده ی روانی دیگه به اسم سندروم است که اکثر برنامه نویسا به اون دچار هستند.بر خلاف اینکه من تمام تلاش خودم رو در ارتباط با یک پروژه انجام دادم و شواهد نشون میده که من موفق بودم ولی همچنان احساس میکنم لیاقت این موفقیت رو ندارم!
من یک برنامه نویسم پرم از حس خستگی ذهنی و بی انگیزگی در مواجهه هر روزم با روش های جدید,تکنولوژی جدید,فریمورک جدید و …
من یک برنامه برنامه نویسم مثل همه تفریح رو دوست دارم اما تفریح من پر از استرسه و برام شادی آور نیست!
من یک برنامه نویسم پرم از ترس قضاوت از فیدبک های مختلف کارفرما
من یک برنامه نویسم ,پرم از حس سرزنش و نقد دائمی,پرم از حس مقایسه بین خروجی من و خروجی سایرین …
عاشق شغلم هستم و پرم از حس تردید بین ادامه دادن یا ندادن…
چند روز پیش که با اندروید استدیو کار میکردم با این صحنه روبرو شدم???♂ فک کردم که مشکل از کشه و باید پاک بشه، بعد از پاک کردن کش دوباره بازم همین مشکل بود??♂ همه لایه ها باز میشن ولی به جز اون لایه ای که تازه طراحی کرده بودم?
بعد که کمی دقت کردم، از کتابخونه متریال گوگل استفاده کرده بودم، نسخه های آلفای این کتابخونه با اندروید استدیو ۳.۴.۱ مشکل دارن و اگه در لایه خودتون از material button استفاده کنید، با این مشکل مواجه میشید.?
ورژن کتابخونه:
۱٫۱٫۰-alpha06
خب حالا میرسیم به راه حل:
ازونجا که ورژن آلفای این کتابخونه امکانات زیادی داره و بهش نیاز دارم باید برم و اندروید استودیو ۳.۵ از چنل بتا دانلود کنم، مشکل در این نسخه حل شده?
راهحل دوم اینه که ورژن کتابخونه رو دانگرید کنید به
منظور از برنامه نویسان راک استار کسانی هستند که توانایی تولید مقادیر زیادی کد و پیاده سازی قابلیت های سیستم با سرعتی زیاد را دارا هستند، به شکلی که در مقابلشون احساس میکنید یک دورف کوتوله هستید.
این برنامه نویسان به طور مداوم کد های هسته سیستم را بدون اینکه دیگران را در جریان بگذارند بازنویسی میکنند و بقیه باید از طراحی جدید سر در بیاورند و کدهای خودشان را برای تطبیق با طراحی جدید بازنویسی کنند. این افراد، دست به کارهایی ناگهانی در پروژه میزنند که به طور غافلگیر کننده ای مسیر پروژه را عوض میکند و باعث میشوند که گاهی حتی نیمی از کارهای دیگر افراد تیم دور ریخته شود چون کد های آنها بر اساس طراحی قبلی سیستم نوشته شده اند و دیگر قابل استفاده نیستند.
برنامه نویسان راک استار سر و صدای زیادی درباره کارهایی که انجام میدهند به پا میکنند و مدیران اغلب شیفته این برنامه نویسان میشوند. پس بردن شکایت این آدمها پیش مدیر زیاد ایده خوبی نیست! آنها هر کار که دلشان بخواهد توی کد انجام میدهند، به کدهای هر کس که دلشان بخواهد، هر جور که بخواهند انتقاد میکنند اما هیچکس حق ندارد و یا در حدی نیست که از کدهای آنها ایراد بگیرد و در مقابل انتقاد دیگران رویکرد مغرورانه و تهاجمی دارند.
در فیلم مردان ایکس شخصیتی وجود داشت به نام سایکلاپس، که از چشم هایش لیزری پر قدرت بیرون میزد که میتوانست همه چیز را نابود کند. برنامه نویسای راک استار تقریبا مثل همان شخصیت هستند که پر از استعداد هستند و این قابلیت ها در همه جهات به شکلی کنترل نشده بیرون ریخته میشود و در صورتی که کنترل و متمرکز نشوند میتوانند تخریب کننده باشند.
این افراد قابلیت این را دارند که به سرعت یک ویژگی را پیاده سازی کرده و بعد بدون اینکه زیاد به تاثیرات و عواقب جانبی پیاده سازی و طراحی خود فکر کنند کار را انجام شده دانسته و به سرعت سراغ کار بعدی بروند. در این روش معمولا باید یک نفر کنار این برنامه نویسان راک استار باشد که بتواند کمی از سرعت آنها کم کرده و حواسش به گندکاری ها و ریخت و پاش های آنها باشد! اما مشکلی که اینجا وجود دارد این است که این افراد معمولا زیاد اهل تعامل با دیگران نیستند و ترجیح میدهند تکاوری کار را پیش ببرند تا بعدا هم بتوانند خودشان به تنهایی همه غنایم را تصاحب کنند. همچنین این افراد نسبت به دردسری که برای بقیه ایجاد میکنند به نظر بی تفاوت میآیند.
اگر به عنوان یک مدیر این مطلب را مطالعه میکنید،
متوجه باشید که این افراد میتوانند باعث شوند که شما به سریع انجام شدن کارها به شکل غیر واقعی اعتیاد پیدا کنید و توقع داشته باشید که همه چیز با سرعت این برنامه نویسان راک استار پیش برود و به زودی فراموش میکنید که این روش ممکن است چه عوارض بلند مدتی برای تیم در پیش داشته باشد. در کوتاه مدت احساس خوبی خواهید داشت از اینکه پروژه به سرعت در حال انجام شدن است اما درک این قضیه که این مدل افراد و روش کار کردنشان در بلند مدت چه تاثیرات منفی ای میتواند روی تیم داشته باشد کمی سخت است. مخصوصا اگر هیچکدام از اعضای دیگر تیم بازخوردی را به گوش شما نرسانند. این وظیفه شماست که چنین شرایطی را در تیم تشخیص داده و بتوانید این افراد را مدیریت کرده و به یک جهت متمرکز و بی خطر برای تیم هدایت کنید. یکی از راه های کمتر کردن عوارض کارهای این افراد این است که مجبورشان کنید به مستند سازی! اینگونه از اینکه توی کدها شیرجه زده و بی مهابا دست به تغییر بزنند تا حدودی جلوگیری میشود و مستند سازی به آنها این فرصت را میدهد که بلند مدت تر فکر کرده و همه چیز را فدای سرعت نکنند.
اگر به عنوان کسی که با یکی از برنامه نویسان راک استار همکار هست این نوشته را مطالعه میکنید،
باید با این افراد تعامل کرده و بهشان عواقب کارشان را گوشزد کنید. باید سر میزشون رفته و بگویید که: “لازمه بدونی که ما دو سوم از کدهایی که توی دو هفته گذشته نوشتیم رو باید دور بریزیم صرفا به خاطر تصمیمی که شما گرفتی. در حالی که اگر شما قبل از تصمیم گیری با ما مشورت میکردی و به ما میگفتی که قصد داری پروژه رو به چه سمت و سویی ببری الان میتونستیم کاری کنیم که پروژه وارد تاخیر نشه.” باید به محض مشاهده نشانه های تاخیر در پروژه پیش مدیر بروید و بگویید که پروژه با تاخیر یک هفته ای مواجهه شده است، صرفا به خاطر تغییراتی که بدون هماهنگی داده شده اند. مدیران به خروجی و نتیجه اهمیت میدهند و اینطوری میفهمند این برنامه نویسان راک استار آنقدرها هم باعث سریعتر انجام شدن کارها نمیشوند.
اگر خودتون که این نوشته را مطالعه میکنید یک برنامه نویس راک استار هستید،
متوجه باشید که وقتی تنهایی کد مینویسید با وقتی که در تیم هستید خیلی تفاوت دارد. شما موقعی که تنها کار می کنید میتوانید با هر سرعتی که میخواهید کار کنید اما برای اینکه بتوانید در یک تیم بازدهی داشته باشید باید با بقیه هم تعامل کنید. تعامل کلید بازدهی یک تیم هست. اگر یاد بگیرید که با دیگر اعضای تیم تعامل و صحبت کنید و نسبت به عواقب تغییراتی که توی سیستم اعمال میکنید و کدها و طراحی های خود کمی متواضعانه تر برخورد کنید میتوانید جزو بهترین اعضای تیم باشید و به حداکثر بازدهی و تاثیر گذاری خود برای تیم برسید.