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

دیپلویمنت (اجرا و پیاده سازی صحیح نرم افزار یا سخت افزار)

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

با فرارسیدن شب یکشنبه حداقل یکنفر از هرگروه باید آنلاین می بود تا تست های تاییدیه ی عملکرد (smoke tests) را هدایت کند. بیشتر اوقات دیپلویمنت ها با موفقیت انجام میشدند و گاهی نیز شکست میخوردند. این پروسه در تعطیلات آخرهفته انجام میشد اما کسی شکایتی نداشت. توسعه دهندگان می بایست قبل از شنبه کدهای خود را تایید میکردند. مدیران توسعه دهنده ای که این پروسه برایشان تازگی داشت از ارتکاب اشتباه وحشت داشتند.
اعضای تیم بخوبی از سخت بودن دیپلویمنت ها مطلع بودند. آنها دائما برای بهتر شدن آن تلاش میکردند و به محض انجام آن زندگی برایشان شیرین میشد. پروسه ی دیپلویمنت TweetDeck واقعا لذت بخش، آسان و بدون استرس بود. در اولین روز کاری براحتی کدها را دپلوی کردم. درواقع هرکسی در هر موقع از روز می تواند این کار را انجام دهد. رول بک ها نیز به سادگی دپلویمنت هستند. هیچ عجله ای برای ساختن قطار دپلویمنت نبوده و هیچ چیز بصورت دستی انجام نمیشود. فیچرهای بزرگ و جدید، توسعه ی یک رابط کاربری ساده یا حتی فیکس کردن باگ ها فورا فرستاده میشوند. اعضای تیم من را مجاب کردند که پروسه ی دپلویمنت همیشه اینگونه نبوده است. آنها مدت ها برای بهتر شدن دپلویمنت خود تلاش کرده و نتیجه گرفته اند.

بازبینی کدها نیازمند عشق، زمان و پذیرش  

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

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

آشتی با کاهنده ی فیچر(feature flagging)

درس سوم:با فیچر فلگینگ کنترل کامل ساخت و رهاسازی پروژه را بدست بگیرید.
ساخت و تکمیل یک فیچر جدید هفته ها طول میکشد و در این مدتی با مسائلی از قبیل شروع با بک اند و ختم شدن به رابط کاربری و غیره مواجه هستید. اما با فیچر فلگینگ هیچ یک از آنها اهمیتی ندارند. و تا زمانیکه فیچر شما برای ارائه آماده شود از قبل دیپلوی شده و مشکلی با سایر پایگاه کد ندارد.
فیچرفلگ یک ارزش بولی(Boolean value) است که کد مرتبط با آنچه که روی آن کار میکنید را احاطه کرده و کد تنها زمانی اجرا میشود که ارزش آن ثابت شود.
در ماههای ابتدایی تجربه کاری بعنوان توسعه دهنده، فیچری که روی آن کار میکردم را به یک لینک نویگیشن مجهز کردم به این ترتیب بااینکه این فیچر هنوز آماده نشده بود قابل رویت بود.
نکته مثبت درخصوص استفاده از فیچرفلگینگ در TweetDeck این است که نیازی به خاموش یا روشن کردن فیچر نیست. درواقع با استفاده از واسطی باعنوان Deckcider یک استاتوس تنظیم شده و برای اجرای استاتوس کد موردنظر درخواست های API معینی را ایجاد میکند. ما همچنین می توانیم فیچرها را بطور تدریجی و مرحله ای تا مرحله ی معرفی به کاربران گسترش دهیم. ابتدا در محیط اجرایی، سپس کارمندان، سپس ده درصد از کاربران، بیست درصد از کاربران، سپس سی درصد از کاربران و درنهایت تمام کاربران. این روش کمک میکند تا باگ ها و رفتارهای غیررمنتظره را پیش از آزاد سازی نهایی شناسایی کنید.
تفسیر کدها، تعیین اینکه کدام یک از مسیرهای لاجیک باید اجرا شود و یا اینکه کدام ورژن رابط کاربری بایدنمایش داده شود پروسه ای آشفته و درهم است. اما در توییتر اینگونه نیست. شما همواره می توانید به محض روشن کردن یک فیچر کدها را تمییزو تصفیه کنید. هرچند انجام اینکار ضروری نیست، حداقل در روزهای ابتدایی. بهنگام شناسایی یک باگ مشخص کردن آن با فلگ به فیچر امکان میدهد تا سریعا خاموش شود.

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

درس چهارم: تعیین جهت و میزان موفقیت محصول خود را به دیتا واگذار کنید.
اولین کمپانی که برای آن کار کردم تاکید زیادی بر تصمیم گیری براساس دیتا داشت. درصورت اجرای هرگونه تغییر یا یک ایده ی جدید می بایست ضرورت اجرای آنرا با توجه به دیتا اثبات می کردیم. به گفته مدیریت بخش دیتا: "بدون دیتا شما صرفا فردی معمولی با یک ایده یا نظریه هستید". این نگرش کمک میکرد تا از مفید بودن محصول خود برای مشتری مطمئن باشیم.
اما چنین فیچری را چگونه باید طراحی کرد؟ چطور بفهمیم طراحی که انتخاب میکنیم تاثیر مطلوب را خواهد داشت؟ اینجاست که نقش آزمون اهمیت می یابد.
در TweeterDeck تغییرات واسط کاربری را با این امید که خوشایند کاربران خواهد بود انجام میدادیم. اما بیشتر اوقات تصوراتی که درباره ی کاربران داریم اشتباه هستند. بتازگی تیم front-end
توییتر در اتاقی گردهم آمده و تلاش کردند حدس بزنند کدام واسط کاربری باتوجه به تست A/B نتیجه بهتری خواهد داشت اما نیمی از افراد هربار اشتباه حدس میزدند.
ما نمی توانیم فرض را براین قراردهیم که تغییری که ایجاد میکنیم تاثیری خواهد داشت که مدنظر ماست. بنابراین تصمیم گرفتیم آزمونی را اجرا کنیم. برای اجرای این آزمون کاربران را در چندین گروه قرار دادیم. یک گروه از کاربران به فیچر جدید دسترسی داشتند و گروه دیگر نه. ما فرض را براین قرار دادیم گروهی که به فیچر جدید دسترسی دارد نتیجه بهتری خواهد داشت. زیبایی اجرای این آزمون این است که بجای تصمیم گیری کورکورانه می توانیم با اطمینان و براساس داده ها برای ارائه فیچرهای جدید تصمیم بگیریم.

استخدام توسعه دهنده بدون توجه به رتبه و درجه

درس پنجم: آزمودن داوطلبان براساس مشکلات واقعی موجب میشود شرکت کنندگان با هرسابقه ای بدرخشند.
هنگامیکه برای استخدام در توییتر تقاضا دادم باخودم فکر میکردم حتما یک کمپانی مانند توییتر آزمون سختی از شرکت کنندگان خواهد گرفت و سخت ترین سوالاتی را مطرح میکند که تنها باهوشترین های فارغ التحصیل CS قادر به جواب دادن به آن هستند. خوشبختانه اصلا اینگونه که فکر میکردم نبود. البته آزمون گرفته شده واقعا سخت بود اما مسائلی که باید حل میشد از واقعیت دور نبودند.
اولین تست شامل فیکس های باگ، عملکرد و تستینگ بود. دومین تست، پیمایش DOM و انجام دادن با دست و مهارت را شامل میشد. درواقع بجای یک تخته ی وایتبرد و ماژیک زمان، دسترسی به اینترنت و وظیفه ای به من محول شد تا روی آن کار کنم. بعبارت دیگر از من خواسته شد روی مشکلاتی کار کنم که در این حرفه حتما با آن مواجه میشدم.
درواقع توییتر قصد داشت تا در میان اعضای تیم خود تنوع را افزایش دهد. تنوع نه براساس جنسیت بلکه براساس تجربه و سابقه. شش ماه بعد و پس از اتمام استخدام های جدید، Tom Ashworth اعلام کرد TweetDeck متنوع ترین و متمایزترین تیم را داراست. به گفته وی آنها پروسه ی مصاحبه را بگونه ای طراحی کرده بودند که یک شغل واقعی را برای شرکت کنندگان شبیه سازی کرده و توانایی آنها در حل مشکلات واقعی را محک بزند نه الگوریتم ها و درسهایی که در دانشگاه یاد گرفته بودند. به گفته ی یکی از مهندسان عالی رتبه ی توییتر هفت سال است که آنها هیچ الگوریتمی در این کمپانی ندیده اند.
درعصر حاضر تنها پنجاه درصد از توسعه دهندگان از فارغ التحصیلان رشته ی کامپیوتر هستند. بعبارت دیگر بیشتر توسعه دهندگان بصورت تجربی و یا از طریق دوره های آنلاین آموزش دیده اند. اگر قصد دارید تنوع تیم مهندسی خود را افزایش دهید پروسه ی مصاحبه را طوری طراحی کنید که این دسته از افراد خود آموخته کنار گذاشته نشوند.