لعنت به گوگل، من نمی خواستم دوباره وبلاگ بنویسم. خیلی کار دارم. وبلاگ نویسی به زمان، انرژی و خلاقیت نیاز دارد که می توانم از آنها به خوبی استفاده کنم: کتاب های من، ، بازی من و غیره. اما آنقدر مرا عصبانی کردی که مجبور شدم این را بنویسم.
پس بیایید این را تمام کنیم.
اجازه دهید با یک داستان کوتاه اما آموزنده از زمانی که برای اولین بار در گوگل شروع به کار کردم شروع کنم. می دانم که اخیراً چیزهای بد زیادی در مورد Google گفته ام، اما وقتی شرکت شخصی من مرتباً تصمیمات تجاری نالایق می گیرد، من را ناراحت می کند. در عین حال، ما باید به آن حق بدهیم: زیرساخت داخلی گوگل واقعاً خارق‌العاده است، به جرات می‌توان گفت که امروز هیچ چیز بهتری وجود ندارد. بنیانگذاران گوگل مهندسان بسیار بهتری از من بودند و این داستان فقط این واقعیت را تایید می کند.
اول، کمی پس زمینه: گوگل یک فناوری ذخیره سازی داده به نام دارد . این یک دستاورد فنی قابل‌توجه بود، یکی از اولین (اگر نه اولین) فروشگاه‌های ارزش کلیدی «بی‌نهایت مقیاس‌پذیر» (K/V): اساساً آغاز NoSQL بود. این روزها Bigtable هنوز در فضای ذخیره سازی نسبتا شلوغ K/V به خوبی کار می کند، اما در آن زمان (2005) به طرز شگفت انگیزی عالی بود.
یک چیز خنده دار در مورد Bigtable این است که آنها دارای اشیاء صفحه کنترل داخلی (به عنوان بخشی از پیاده سازی) به نام سرورهای تبلت، با نمایه های بزرگ بودند، و در مقطعی زمانی که مقیاس سیستم را افزایش می دادند، به گلوگاه تبدیل می شدند. مهندسان Bigtable در مورد چگونگی پیاده سازی مقیاس پذیری گیج بودند و ناگهان متوجه شدند که می توانند سرورهای تبلت را با حافظه های Bigtable دیگر جایگزین کنند. بنابراین Bigtable بخشی از پیاده سازی Bigtable است. این انبارها در همه سطوح وجود دارد.
یکی دیگر از جزئیات جالب این است که برای مدتی Bigtable در گوگل محبوب و فراگیر شد و هر تیم مخزن مخصوص به خود را داشت. بنابراین در یکی از جلسات جمعه، لری پیج به طور اتفاقی پرسید: «چرا ما بیش از یک Bigtable داریم؟ چرا فقط یکی نیست؟» در تئوری، یک فضای ذخیره سازی باید برای تمام نیازهای ذخیره سازی گوگل کافی باشد. البته، آنها هرگز به دلایل توسعه عملی (مثل عواقب یک شکست بالقوه) تنها به سراغ یکی نرفتند، اما این نظریه جالب بود. یک مخزن برای کل کیهان (به هر حال، آیا کسی می داند که آیا آمازون این کار را با Sable خود انجام داده است؟)
به هر حال داستان من اینجاست.
در آن زمان، کمی بیش از دو سال در گوگل کار می‌کردم و یک روز ایمیلی از تیم مهندسی Bigtable دریافت کردم که چیزی شبیه به این بود:
استیو عزیز،
سلام از تیم Bigtable. مایلیم به شما اطلاع دهیم که در [نام مرکز داده] از یک باینری Bigtable بسیار بسیار قدیمی استفاده می کنید. این نسخه دیگر پشتیبانی نمی شود و ما می خواهیم به شما کمک کنیم تا به آخرین نسخه ارتقا دهید.
لطفاً به من اطلاع دهید که آیا می توانید زمانی را برای همکاری در مورد این موضوع برنامه ریزی کنید.
بهترین ها،
تیم Bigtable
در گوگل ایمیل های زیادی دریافت می کنید، بنابراین در نگاه اول چیزی شبیه به این را خواندم:
گیرنده محترم
سلام از چند تیم ما می‌خواهیم آن را با هم در میان بگذاریم. بلاههههههههههههههههههههههههههه.
لطفاً به ما اطلاع دهید که آیا می توانید مقداری از زمان گرانبهای خود را برای بلاهههه برنامه ریزی کنید.
بهترین ها،
نوعی فرمان
تقریباً بلافاصله آن را حذف کردم، اما در لبه هوشیاری خود احساس دردناک و آزاردهنده ای داشتم که نه کاملا هرچند به نظر یک نامه رسمی است بدیهی است، که گیرنده اشتباه کرده است زیرا من از Bigtable استفاده نکرده ام.
اما عجیب بود.
بقیه روز را به تناوب در مورد کار و اینکه چه نوع گوشت کوسه را در آشپزخانه کوچک امتحان کنم، گذراندم، که حداقل سه مورد از آن به اندازه کافی نزدیک بودند که با پرتاب بیسکویت از روی صندلی من ضربه بزنم، اما فکر نوشتن هرگز مرا با یک احساس اضطراب خفیف رو به رشد رها نکرد.
آنها به وضوح نام من را گفتند. و ایمیل به آدرس ایمیل من فرستاده شد نه شخص دیگری و cc: یا bcc: نیست. لحن بسیار شخصی و واضح است. شاید این نوعی اشتباه است؟
در نهایت، کنجکاوی من را تحت تأثیر قرار داد و به کنسول Borg در مرکز داده ای که آنها اشاره کردند، رفتم.
و البته، ذخیره‌سازی BigTable را تحت مدیریت داشتم. ببخشید چی؟ به محتویاتش نگاه کردم وای! این از انکوباتور Codelab بود که در اولین هفته کارم در گوگل در ژوئن 2005 در آن نشستم. Codelab شما را مجبور کرد که Bigtable را اجرا کنید تا مقادیری را در آنجا بنویسید، و ظاهراً پس از آن هرگز فضای ذخیره‌سازی را نبستم. با وجود گذشت بیش از دو سال، هنوز کار می کرد.
چند جنبه قابل توجه در این داستان وجود دارد. اولاً، کار Bigtable در مقیاس Google آنقدر ناچیز بود که تنها دو سال بعد کسی متوجه فضای ذخیره‌سازی اضافی شد و فقط به این دلیل که نسخه باینری قدیمی بود. برای مقایسه، من یک بار به استفاده از آن فکر کردم برای بازی آنلاین من در آن زمان، این سرویس تقریباً 16 دلار در سال هزینه داشت. خالی Bigtable در GCP. من نمی گویم آنها از شما کلاهبرداری می کنند، اما به نظر شخصی من، این پول برای یک پایگاه داده لعنتی خالی است.
یکی دیگر از جنبه های قابل توجه این است که ذخیره سازی هنوز بعد از دو سال کار می کند. WTF؟ مراکز داده می آیند و می روند. آنها قطعی را تجربه می کنند، آنها تحت تعمیر و نگهداری برنامه ریزی شده قرار می گیرند، آنها همیشه تغییر می کنند. سخت افزار به روز می شود، سوئیچ ها تعویض می شوند، همه چیز به طور مداوم در حال بهبود است. لعنتی چطور توانستند با این همه تغییرات برنامه من را دو سال اجرا کنند؟ این ممکن است در سال 2020 یک دستاورد کوچک به نظر برسد، اما در سال های 2005-2007 بسیار چشمگیر بود.
و شگفت انگیزترین جنبه این است که یک تیم مهندسی بیرونی در یک ایالت دیگر به من نزدیک می شود، صاحب نمونه کوچک و تقریباً خالی Bigtable، که ترافیک صفر برای دو سال گذشته - و برای به روز رسانی آن کمک می کنند.
از آنها تشکر کردم، فضای ذخیره سازی را حذف کردم و زندگی طبق روال پیش رفت. اما سیزده سال بعد، هنوز به آن نامه فکر می کنم. زیرا گاهی اوقات ایمیل های مشابهی از Google Cloud دریافت می کنم. آنها به این شکل هستند:
کاربر گرامی Google Cloud،
به عنوان یادآوری، از اوت 2020 سرویس [سرویس ضروری که استفاده می‌کنید] را متوقف می‌کنیم و پس از آن نمی‌توانید نمونه‌های خود را ارتقا دهید. توصیه می کنیم به آخرین نسخه ارتقا دهید، که در مرحله آزمایش بتا است، هیچ مستندی ندارد، مسیر مهاجرت ندارد و با کمک مهربان ما از قبل قدیمی شده است.
ما متعهد هستیم که اطمینان حاصل کنیم که این تغییر کمترین تأثیر را بر همه کاربران پلتفرم Google Cloud دارد.
بهترین دوستان برای همیشه،
Google Cloud Platform
اما من تقریباً هرگز چنین نامه هایی را نمی خوانم، زیرا آنچه در واقع می گویند این است:
گیرنده محترم
برو به جهنم. لعنت به تو، لعنت به تو، لعنت به تو. هر کاری را که انجام می دهید رها کنید زیرا مهم نیست. مهم زمان ماست. ما زمان و پول خود را برای نگهداری از مزخرفات خود تلف می کنیم و از آن خسته شده ایم، بنابراین دیگر از آن حمایت نخواهیم کرد. پس برنامه های لعنتی خود را رها کنید و شروع به کندوکاو در اسناد مزخرف ما کنید، التماس مطالبی در انجمن ها داشته باشید، و اتفاقا، چیزهای جدید ما کاملاً با چیزهای قدیمی متفاوت است، زیرا ما این طرح را خیلی بد به هم زدیم، هه، اما این کار شماست. مشکل ما نیست
ما همچنان به تلاش خود ادامه می دهیم تا اطمینان حاصل کنیم که تمام پیشرفت های شما ظرف یک سال غیرقابل استفاده می شوند.
لطفا ول کن
Google Cloud Platform
و واقعیت این است که من تقریباً ماهی یک بار چنین نامه هایی را دریافت می کنم. این اتفاق به قدری مکرر و به قدری مداوم رخ می دهد که به ناچار رانده شد من از GCP به اردوگاه ضد ابر. من دیگر نمی‌پذیرم که به توسعه‌های اختصاصی آنها وابسته باشم، زیرا در واقع برای توسعه‌دهندگان ساده‌تر است که یک سیستم منبع باز را روی یک ماشین مجازی خالی نگه دارند تا اینکه تلاش کنند با سیاست Google در بستن محصولات «منسوخ» همگام شوند.
قبل از اینکه به Google Cloud برگردم زیرا من حتی نزدیک انتقاد از آنها انجام نشده است، اجازه دهید به عملکرد شرکت در برخی زمینه های دیگر نگاه کنیم. مهندسان گوگل به رشته مهندسی نرم افزار خود افتخار می کنند و این همان چیزی است که در واقع باعث ایجاد مشکلات می شود. غرور تله ای برای افراد بی احتیاط است و بسیاری از کارمندان گوگل را به این فکر واداشته است که تصمیمات آنها همیشه درست است و درست بودن (بر اساس برخی تعریف مبهم مبهم) مهمتر از توجه به مشتریان است.
من چند نمونه تصادفی از پروژه های بزرگ دیگر خارج از گوگل می زنم، اما امیدوارم این الگو را همه جا ببینید. به شرح زیر است: سازگاری به عقب سیستم ها را برای چندین دهه زنده و به روز نگه می دارد.
سازگاری به عقب هدف طراحی تمام سیستم های موفق طراحی شده برای آن است باز کردن استفاده کنید، یعنی با کد منبع باز و/یا استانداردهای باز پیاده سازی شود. احساس می‌کنم چیزی خیلی واضح می‌گویم که همه حتی ناراحت هستند، اما نه. این یک موضوع سیاسی است، بنابراین نمونه هایی لازم است.
اولین سیستمی که من انتخاب می کنم قدیمی ترین است: GNU Emacs که به نوعی ترکیبی بین Notepad ویندوز، هسته سیستم عامل و ایستگاه فضایی بین المللی است. توضیح آن کمی سخت است، اما به طور خلاصه، Emacs یک پلتفرم است که در سال 1976 (بله، تقریباً نیم قرن پیش) برای برنامه نویسی ایجاد شد تا شما را سازنده تر کند، اما خود را به عنوان یک ویرایشگر متن تغییر دهید.
من هر روز از Emacs استفاده می کنم. بله، من نیز هر روز از IntelliJ استفاده می‌کنم، این در نوع خود به یک پلتفرم ابزار قدرتمند تبدیل شده است. اما نوشتن برنامه‌های افزودنی برای IntelliJ کاری بسیار بلندپروازانه‌تر و پیچیده‌تر از نوشتن برنامه‌های افزودنی برای Emacs است. و مهمتر از همه، هر آنچه برای Emacs نوشته شده است حفظ می شود برای همیشه.
من هنوز از نرم افزاری که در سال 1995 برای Emacs نوشتم استفاده می کنم. و من مطمئن هستم که کسی از ماژول‌های نوشته شده برای Emacs در اواسط دهه 80 استفاده می‌کند، اگر نه زودتر. آنها ممکن است گهگاه نیاز به تغییر کمی داشته باشند، اما این واقعاً بسیار نادر است. من چیزی نمی دانم که تا به حال برای Emacs نوشته ام (و خیلی نوشته ام) که نیاز به معماری مجدد داشته باشد.
Emacs تابعی به نام make-opsolete برای موجودیت های منسوخ دارد. اصطلاحات Emacs برای مفاهیم اساسی رایانه (مانند آنچه "پنجره" است) اغلب با قراردادهای صنعتی متفاوت است زیرا Emacs آنها را مدتها پیش معرفی کرده است. این یک خطر معمولی برای کسانی است که از زمان خود جلوتر هستند: همه شرایط شما نادرست است. اما Emacs مفهومی از بی اعتباری دارد که در اصطلاح خود به آن می گویند ماندگاری.
اما به نظر می رسد در دنیای Emacs تعریف متفاوتی وجود دارد. اگر بخواهید، یک فلسفه زیربنایی متفاوت.
در دنیای Emacs (و در بسیاری از زمینه‌های دیگر که در زیر به آنها خواهیم پرداخت)، وضعیت API منسوخ شده اساساً به این معنی است: "شما واقعاً نباید از این رویکرد استفاده کنید، زیرا در حالی که کار می‌کند، از کاستی‌های مختلفی رنج می‌برد که ما خواهیم داشت. اینجا لیست کنید اما در نهایت این انتخاب شماست."
در دنیای Google، منسوخ بودن به این معنی است که "ما تعهد خود را نسبت به شما نقض می کنیم." درست است. این همان چیزی است که اساساً به معنای آن است. این بدان معنی است که آنها شما را مجبور می کنند به طور مرتب انجام برخی کارها، شاید کارهای زیاد، به عنوان مجازاتی برای اعتقاد به آنها : ما بهترین نرم افزار را داریم. سریع ترین! شما همه کارها را طبق دستورالعمل انجام می دهید، برنامه یا سرویس خود را راه اندازی می کنید و سپس بام، بعد از یکی دو سال خراب می شود.
مثل اینه که یه ماشین دست دوم بفروشی که بعد از 1500 کیلومتر حتما خراب میشه.
اینها دو تعریف فلسفی کاملاً متفاوت از "کهنگی" هستند. تعریف گوگل از بو . من این را باور نمی کنم در واقع منسوخ شدن برنامه ریزی شده به همان معنای اپل. اما گوگل قطعاً برنامه‌ریزی می‌کند تا برنامه‌های شما را به روشی دوربرگردان قطع کند. من این را می دانم زیرا بیش از 12 سال در آنجا به عنوان مهندس نرم افزار کار کردم. آنها دستورالعمل‌های داخلی مبهمی در مورد اینکه چقدر باید از سازگاری به عقب پیروی کرد، دارند، اما در نهایت به هر تیم یا سرویس فردی بستگی دارد. هیچ توصیه‌ای در سطح شرکت یا مهندسی وجود ندارد، و جسورانه‌ترین توصیه در مورد چرخه‌های منسوخ شدن این است که «سعی کنید به مشتریان 6 تا 12 ماه فرصت دهید تا قبل از شکستن کل سیستم‌شان، آنها را ارتقا دهند».
مشکل بسیار بزرگتر از آن چیزی است که آنها فکر می کنند، و برای سال های آینده ادامه خواهد داشت زیرا مراقبت از مشتری در DNA آنها نیست. بیشتر در این مورد در زیر.
در این مرحله من می خواهم یک بیانیه جسورانه بگویم که Emacs تا حد زیادی و حتی موفق است در درجه اول زیرا آنها سازگاری با عقب را بسیار جدی می گیرند. در واقع، این پایان نامه مقاله ما است. سیستم های باز موفق و با عمر طولانی موفقیت خود را مدیون جوامع کوچکی هستند که دهه ها در اطراف آنها زندگی کرده اند. افزونه ها/افزونه ها. این اکوسیستم است. قبلاً در مورد ماهیت پلتفرم‌ها و اهمیت آنها صحبت کرده‌ام، و اینکه چگونه گوگل در کل تاریخ شرکت‌های خود هرگز درک نکرده است که چه چیزی باعث ایجاد یک پلتفرم باز موفق خارج از اندروید یا کروم می‌شود.
در واقع، من باید به طور خلاصه به اندروید اشاره کنم زیرا احتمالاً به آن فکر می کنید.
اول، اندروید گوگل نیست. آنها تقریباً هیچ شباهتی با یکدیگر ندارند. اندروید شرکتی است که در ژوئیه 2005 توسط گوگل خریداری شد، این شرکت اجازه داشت تا کم و بیش مستقل عمل کند و در واقع تا حد زیادی در سال های میانی دست نخورده باقی مانده است. اندروید یک پشته فناوری بدنام و یک سازمان خاردار به همان اندازه بدنام است. همانطور که یکی از گوگل می گوید، "شما نمی توانید فقط به اندروید وارد شوید."
در مقاله قبلی، درباره بد بودن برخی از تصمیمات اولیه طراحی اندروید صحبت کردم. هک، زمانی که من آن مقاله را نوشتم، آنها چیزهای مزخرفی به نام "برنامه های فوری" منتشر کردند که اکنون (تعجب!) ، و اگر به اندازه کافی احمق بودید که به گوگل گوش دهید و محتوای خود را به این برنامه های فوری منتقل کنید، همدردی می کنم.
اما در اینجا یک تفاوت وجود دارد، یک تفاوت قابل توجه، و آن این است که مردم اندروید واقعاً درک می کنند که پلتفرم ها چقدر مهم هستند، آنها تمام تلاش خود را می کنند تا برنامه های قدیمی اندروید را کار کنند. در واقع، تلاش‌های آنها برای حفظ سازگاری به عقب آنقدر شدید است که حتی من، چند سال پیش، در طول مدت کوتاهی که در بخش اندروید داشتم، متوجه شدم که سعی می‌کنم آنها را متقاعد کنم که پشتیبانی از برخی از قدیمی‌ترین دستگاه‌ها و APIها را کنار بگذارند (اشتباه کردم. مانند بسیاری از چیزهای دیگر در گذشته و حال. ببخشید بچه های اندروید! حالا که به اندونزی رفته ام، می فهمم که چرا به آنها نیاز داریم).
افراد اندرویدی سازگاری را تا حد غیرقابل تصوری پیش می‌برند و مقادیر زیادی بدهی فنی قدیمی را در سیستم‌ها و زنجیره‌های ابزار خود جمع می‌کنند. اوه خدای من، شما باید برخی از کارهای احمقانه ای که آنها باید در سیستم ساخت خود انجام دهند، همه به نام سازگاری را ببینید.
برای این کار، من جایزه ارزنده "You're Not Google" را به اندروید می دهم. آنها واقعاً نمی خواهند تبدیل به گوگل شوند، که نمی داند چگونه پلتفرم های بادوام ایجاد کند، بلکه آندروید هستند می داند، چگونه انجامش بدهیم. و بنابراین گوگل از یک جهت بسیار باهوش عمل می کند: به مردم اجازه می دهد کارها را به روش خودشان در اندروید انجام دهند.
با این حال، برنامه های فوری برای اندروید ایده بسیار احمقانه ای بود. و آیا شما می دانید چرا؟ چون مطالبه کردند برنامه خود را بازنویسی و طراحی مجدد کنید! گویی مردم به سادگی دو میلیون برنامه را بازنویسی خواهند کرد. حدس می‌زنم برنامه‌های فوری ایده برخی از Googler بود.
اما یک تفاوت وجود دارد. سازگاری به عقب هزینه بالایی دارد. خود اندروید بار این هزینه ها را به دوش می کشد، در حالی که گوگل اصرار دارد که این بار به دوش کشیده شود شما، پرداخت مشتری
می توانید تعهد اندروید به سازگاری رو به عقب را در API های آن ببینید. وقتی چهار یا پنج زیرسیستم مختلف دارید که به معنای واقعی کلمه یک کار را انجام می‌دهند، این نشانه مطمئنی است که در هسته تعهد به سازگاری با عقب وجود دارد. که در دنیای پلتفرم ها مترادف با تعهد به مشتریان و بازار شماست.
مشکل اصلی گوگل در اینجا افتخار آنها به بهداشت مهندسی است. آنها وقتی راه‌های مختلف زیادی برای انجام یک کار وجود دارد، خوششان نمی‌آید، با روش‌های قدیمی و نه چندان مطلوب کنار روش‌های جدید و جذاب‌تر. منحنی یادگیری را برای افراد تازه وارد به سیستم افزایش می‌دهد، بار نگهداری APIهای قدیمی را افزایش می‌دهد، سرعت ویژگی‌های جدید را کاهش می‌دهد، و گناه اصلی این است که زیبا نیست. گوگل - مانند لیدی اسکات از آلیس در سرزمین عجایب تیم برتون:
لیدی اسکوت:
- آلیس، می دانی از چه چیزی بیشتر می ترسم؟
- افول اشراف؟
- می ترسیدم داشته باشم نوه های زشت.
برای درک مبادله بین زیبا و کاربردی، بیایید نگاهی به سومین پلتفرم موفق (بعد از Emacs و Android) بیندازیم و ببینیم که چگونه کار می کند: خود جاوا.
جاوا تعداد زیادی API قدیمی دارد. Deprecation در بین برنامه نویسان جاوا بسیار محبوب است، حتی محبوب تر از بسیاری از زبان های برنامه نویسی. خود جاوا، زبان اصلی و کتابخانه‌ها دائماً APIها را منسوخ می‌کنند.
برای مثال فقط یکی از هزاران مثال، منسوخ در نظر گرفته شده است. از زمان انتشار جاوا 1.2 در دسامبر 1998 منسوخ شده است. 22 سال از منسوخ شدن آن می گذرد.
اما کد واقعی من در تولید هنوز هم رشته ها را از بین می برد هر روز. واقعا فکر میکنی خوبه؟ کاملا! منظورم این است که البته اگر امروز بخواهم کد را بازنویسی کنم، آن را به شکل دیگری پیاده سازی می کنم. اما کد بازی من که در طول دو دهه گذشته صدها هزار نفر را خوشحال کرده است، با عملکردی برای بستن رشته هایی که بیش از حد طولانی آویزان هستند نوشته شده است. هرگز مجبور به تغییر آن نشد. من سیستم خود را بهتر از هر کسی می شناسم، من به معنای واقعی کلمه 25 سال تجربه کار با آن در تولید دارم و می توانم با اطمینان بگویم: در مورد من، بستن این تاپیک های کارگر خاص کاملاً است. بی ضرر. ارزش وقت و تلاش برای بازنویسی این کد را ندارد و از لری الیسون (احتمالا) تشکر می کنم که اوراکل من را مجبور به بازنویسی آن نکرده است.
اوراکل احتمالاً پلتفرم ها را نیز درک می کند. چه کسی می داند.
شواهدی را می توان در سرتاسر APIهای اصلی جاوا یافت که مملو از امواج منسوخ هستند، مانند خطوط یک یخچال طبیعی در یک دره. می توانید به راحتی پنج یا شش مدیر ناوبری صفحه کلید مختلف (KeyboardFocusManager) را در کتابخانه Java Swing پیدا کنید. در واقع یافتن یک API جاوا که منسوخ نشده باشد دشوار است. اما آنها همچنان کار می کنند! من فکر می‌کنم تیم جاوا فقط در صورتی واقعاً API را حذف می‌کند که رابط یک مشکل امنیتی آشکار ایجاد کند.
موضوع اینجاست، دوستان: ما توسعه دهندگان نرم افزار همه سرمان شلوغ است و در هر زمینه ای از نرم افزار با جایگزین های رقیب روبرو هستیم. در هر زمان، برنامه نویسان در زبان X زبان Y را به عنوان جایگزین احتمالی در نظر می گیرند. اوه، باور نمی کنی؟ آیا می خواهید آن را سوئیفت بنامید؟ مثلاً همه در حال مهاجرت به سویفت هستند و هیچکس آن را رها نمی کند، درست است؟ وای چقدر کم میدونی شرکت‌ها در حال محاسبه هزینه‌های تیم‌های توسعه موبایل دوگانه (iOS و Android) هستند - و آنها شروع به درک این موضوع کرده‌اند که آن سیستم‌های توسعه چند پلتفرمی با نام‌های خنده‌دار مانند Flutter و React Native در واقع کار می‌کنند و می‌توان از آنها برای کاهش اندازه آنها استفاده کرد. تیم های سیار دو بار یا برعکس، آنها را دو برابر بازدهی بیشتر می کند. پول واقعی در خطر است. بله، مصالحه وجود دارد، اما، از سوی دیگر، پول.
بیایید فرضی را فرض کنیم که اپل به طرز احمقانه ای از Guido van Rossum سرنخ گرفت و اعلام کرد که سوئیفت 6.0 با سوئیفت 5.0 به عقب ناسازگار است، دقیقاً مانند پایتون 3 که با پایتون 2 ناسازگار است.
من احتمالاً این داستان را حدود ده سال پیش تعریف کردم، اما حدود پانزده سال پیش با گیدو به فو کمپ اوریلی رفتم، با پل گراهام در یک چادر نشستم و چند عکس بزرگ. ما در گرمای شدید منتظر لری پیج نشستیم تا با هلیکوپتر شخصی‌اش به بیرون پرواز کند، در حالی که گیدو در مورد «پایتون 3000» پهپاد می‌کرد، که او آن را بر اساس تعداد سال‌هایی که برای مهاجرت همه به آنجا طول می‌کشد نامید. ما مدام از او می پرسیدیم که چرا سازگاری را به هم می زند، و او پاسخ داد: "یونیکد." و ما پرسیدیم، اگر مجبور باشیم کد خود را بازنویسی کنیم، چه مزایای دیگری خواهیم دید؟ و او پاسخ داد: "یوووووووووووووووووووووووووووووووووووووووووووو."
اگر Google Cloud Platform SDK ("gcloud") را نصب کنید، اعلان زیر را دریافت خواهید کرد:
گیرنده محترم
مایلیم به شما یادآوری کنیم که پشتیبانی از پایتون 2 منسوخ شده است، پس لعنت به شما
… و غیره. دایره زندگی
اما نکته اینجاست که هر توسعه دهنده ای یک انتخاب دارد. و اگر آنها را مجبور کنید به اندازه کافی کد را بازنویسی کنند، ممکن است به این موضوع فکر کنند دیگر گزینه ها. آنها گروگان شما نیستند، مهم نیست که چقدر ممکن است بخواهید آنها باشند. آنها مهمان شما هستند. Python هنوز یک زبان برنامه نویسی بسیار محبوب است، اما لعنتی، Python 3(000) چنان آشفتگی در جوامع خود و در بین کاربران جوامع خود ایجاد کرد که پانزده سال است که عواقب آن روشن نشده است.
چند برنامه پایتون در Go (یا روبی یا جایگزین دیگری) به دلیل این ناسازگاری رو به عقب بازنویسی شده است؟ چقدر نرم افزار جدید در چیزی غیر از پایتون نوشته شده است می تواند باشد نوشته شده در پایتون، اگر گویدو تمام دهکده را نمی سوزاند؟ گفتنش سخت است، اما پایتون به وضوح آسیب دیده است. این یک آشفتگی بزرگ است و همه ضرر می کنند.
بنابراین فرض کنید اپل از Guido سرنخ می گیرد و سازگاری را به هم می زند. فکر می کنید در ادامه چه اتفاقی می افتد؟ خوب، شاید 80-90٪ از توسعه دهندگان در صورت امکان نرم افزار خود را بازنویسی کنند. به عبارت دیگر، 10-20٪ از پایگاه کاربران به طور خودکار به برخی از زبان های رقیب مانند Flutter می رود.
این کار را چندین بار انجام دهید و نیمی از پایگاه کاربری خود را از دست خواهید داد. درست مانند ورزش، در دنیای برنامه نویسی، شکل فعلی نیز مهم است. всё. هر کسی که نیمی از کاربران خود را در عرض پنج سال از دست بدهد، یک بازنده بزرگ چربی محسوب می شود. شما باید در دنیای پلتفرم ها مد روز باشید. اما اینجاست که پشتیبانی نکردن از نسخه های قدیمی به مرور زمان شما را خراب می کند. زیرا هر بار که از شر برخی از توسعه دهندگان خلاص می شوید، (الف) آنها را برای همیشه از دست می دهید زیرا از دست شما به خاطر شکستن قرارداد عصبانی هستند و (ب) آنها را به رقبای خود می سپارید.
از قضا، من همچنین به Google کمک کردم تا زمانی که با ایجاد Grok، سازگاری با عقب را نادیده می‌گیرد، به گوگل کمک کردم، یک سیستم تجزیه و تحلیل و درک کد منبع که خودکارسازی و ابزارسازی خود کد را آسان می‌کند - شبیه به یک IDE، اما در اینجا سرویس ابری ذخیره می‌کند. نمایش تمام میلیاردها خط کد منبع Google در یک انبار داده بزرگ را تحقق بخشید.
Grok یک چارچوب قدرتمند برای انجام بازآفرینی خودکار در کل پایگاه کد آنها (به معنای واقعی کلمه در سراسر گوگل) برای Googlers فراهم کرد. این سیستم نه تنها وابستگی های بالادستی شما (که به آنها وابسته هستید) بلکه همچنین محاسبه می کند نزولی (که به شما بستگی دارد) بنابراین وقتی API را تغییر می‌دهید، می‌دانید که همه شما را شکست می‌دهید! به این ترتیب، وقتی تغییراتی ایجاد می کنید، می توانید تأیید کنید که هر مصرف کننده API شما به نسخه جدید به روز شده است و در واقع، اغلب با ابزار Rosie که آنها نوشته اند، می توانید فرآیند را کاملاً خودکار کنید.
این امر به پایگاه کد گوگل اجازه می‌دهد تا تقریباً به‌طور فراطبیعی تمیز باشد، زیرا آنها این خدمتکاران رباتیک را دارند که در خانه می‌چرخند و اگر SomeDespicablyLongFunctionName را به SomeDespicablyLongMethodName تغییر نام دهند، به‌طور خودکار همه چیز را تمیز می‌کنند، زیرا کسی تصمیم می‌گیرد که این نوه زشت است و باید او را بخواباند.
و صادقانه بگویم، برای گوگل بسیار خوب کار می کند... داخلی. منظورم این است که بله، انجمن Go در Google به دلیل عادت آنها به بازسازی مداوم، با جامعه جاوا در Google می خندد. اگر N بار چیزی را مجددا راه اندازی کنید، به این معنی است که نه تنها آن را N-1 بار خراب کرده اید، بلکه پس از مدتی کاملاً مشخص می شود که احتمالاً در امتحان نهم نیز آن را خراب کرده اید. اما، به طور کلی، آنها بالاتر از همه این هیاهو باقی می مانند و کد "تمیز" را حفظ می کنند.
مشکل زمانی شروع می شود که آنها سعی می کنند این نگرش را به مشتریان ابری خود و کاربران سایر API ها تحمیل کنند.
من شما را کمی با Emacs، Android و Java آشنا کردم. بیایید به آخرین پلتفرم موفق با عمر طولانی نگاه کنیم: خود وب. آیا می توانید تصور کنید که HTTP از سال 1995 که از تگ های چشمک زن استفاده می کردیم، چند بار تکرار شده است؟ و نمادهای "در حال ساخت" در صفحات وب.
اما همچنان کار می کند! و این صفحات هنوز کار می کنند! بله، بچه ها، مرورگرها قهرمانان جهان در سازگاری با عقب هستند. کروم نمونه دیگری از پلتفرم نادر گوگل است که سرش به درستی بسته شده است، و همانطور که ممکن است حدس زده باشید، کروم به طور موثر به عنوان یک شرکت سندباکس جدا از بقیه گوگل عمل می کند.
همچنین می‌خواهم از دوستان خود در توسعه‌دهندگان سیستم‌عامل تشکر کنم: Windows، Linux، NOT APPLE FUCK YOU APPLE، FreeBSD، و غیره، به خاطر انجام چنین کار عالی در زمینه سازگاری به عقب بر روی پلتفرم‌های موفق خود (اپل در بهترین حالت با The C می‌گیرد. نقطه ضعف این است که آنها همیشه همه چیز را بدون هیچ دلیل موجهی می شکنند، اما به نوعی جامعه با هر نسخه از آن عبور می کند، و ظروف OS X هنوز کاملاً منسوخ نشده اند... هنوز).
اما شما می گویید صبر کنید. آیا ما سیب ها را با پرتقال ها مقایسه نمی کنیم - سیستم های نرم افزاری مستقل روی یک ماشین واحد مانند Emacs/JDK/Android/Chrome در مقابل سیستم های چند سرور و API هایی مانند سرویس های ابری؟
خوب، من دیروز در این مورد توییت کردم، اما به سبک لری وال (خالق زبان برنامه نویسی Perl - تقریباً در هر.) بر اساس اصل "ممکن/قوانین" کلمه را جستجو کردم. منسوخ در سایت های توسعه دهنده گوگل و آمازون. و اگرچه AWS دارد صدها اسناد توسعه‌دهنده Google به دفعات بیشتر از GCP به ارائه خدمات اشاره می‌کنند که تقریباً هفت برابر بیشتر است.
اگر کسی در گوگل این مطلب را می‌خواند، احتمالاً آماده است نمودارهایی به سبک دونالد ترامپ بیرون بکشد که نشان می‌دهد در واقع همه چیز را درست انجام می‌دهند، و من نباید مقایسه‌های ناعادلانه‌ای مانند «تعداد ذکر کلمه منسوخ شده در مقابل» انجام دهم. تعداد خدمات" "
اما پس از گذشت این همه سال، Google Cloud همچنان سرویس شماره 3 است (من هرگز مقاله ای در مورد تلاش ناموفق برای تبدیل شدن به شماره 2 ننوشتم)، اما اگر بخواهیم خودی ها را باور کنیم، نگرانی هایی وجود دارد که می توانند به زودی به آنها رها شوند. شماره 4.
من هیچ استدلال قانع کننده ای برای "اثبات" تز خود ندارم. تنها چیزی که دارم نمونه های رنگارنگی است که در طی 30 سال به عنوان یک توسعه دهنده جمع آوری کرده ام. من قبلاً به ماهیت عمیقاً فلسفی این مسئله اشاره کردم. از جهاتی در جوامع توسعه دهندگان سیاسی شده است. برخی معتقدند که سازندگان پلتفرم ها باید به سازگاری اهمیت دهند، در حالی که دیگران فکر می کنند که این یک نگرانی است کاربران (خود توسعه دهندگان). یکی از دو. در واقع، آیا زمانی که تصمیم می گیریم هزینه مشکلات مشترک چه کسی باید متحمل شود، یک موضوع سیاسی نیست؟
پس این سیاست است. و احتمالاً پاسخ های خشمگینانه ای به سخنرانی من خواهد شد.
مانند کاربر پلتفرم Google Cloud، و به عنوان یک کاربر AWS به مدت دو سال (در حالی که برای Grab کار می کردم)، می توانم بگویم که تفاوت زیادی بین فلسفه های آمازون و گوگل در مورد اولویت ها وجود دارد. من به طور فعال در AWS توسعه نمی‌دهم، بنابراین به خوبی نمی‌دانم آنها چند بار APIهای قدیمی را حذف می‌کنند. اما این ظن وجود دارد که این اتفاق تقریباً به اندازه Google رخ نمی دهد. و من واقعاً معتقدم که این منبع مجادله و ناامیدی مداوم در GCP یکی از بزرگترین عواملی است که مانع توسعه پلتفرم می شود.
می‌دانم که نمونه‌های خاصی از سیستم‌های GCP که دیگر پشتیبانی نمی‌شوند را نام‌برده‌ام. می توانم بگویم تقریباً همه چیزهایی که استفاده کرده ام، از شبکه ها (از قدیمی ترین تا VPC) گرفته تا ذخیره سازی (Cloud SQL v1-v2)، Firebase (اکنون Firestore با API کاملاً متفاوت)، App Engine (حتی شروع نکنیم) , Cloud Endpoints Cloud Endpoint و تا... نمی دانم - کاملاً همه اینها شما را مجبور به بازنویسی کد پس از حداکثر 2-3 سال کردند و هرگز انتقال را برای شما خودکار نکردند و اغلب . انگار قرار بود اینطور باشد.
و هر بار که به AWS نگاه می کنم، از خودم می پرسم چرا لعنتی هنوز در GCP هستم. آنها به وضوح نیازی به مشتری ندارند. آن ها نیاز دارند خریداران. آیا تفاوت را متوجه میشوید؟ بگذار توضیح بدهم.
Google Cloud دارد ، جایی که مردم راه حل های نرم افزاری خود را پیشنهاد می کنند و برای جلوگیری از جلوه خالی رستوران، باید آن را با چند پیشنهاد پر می کردند، بنابراین با شرکتی به نام بیتنامی قرارداد بستند تا مجموعه ای از راه حل ها را ایجاد کنند که با یک کلیک یا باید به کار گرفته شوند. من خودم آن را "راه حل ها" می نویسم، زیرا این ها هیچ چیز لعنتی را حل نمی کنند. آنها به سادگی به عنوان چک باکس، به عنوان پرکننده بازاریابی وجود دارند و گوگل هرگز اهمیتی نداده است که آیا هیچ یک از ابزارها واقعاً کار می کنند یا خیر. من مدیران محصولی را می شناسم که روی صندلی راننده بوده اند و می توانم به شما اطمینان دهم که این افراد اهمیتی نمی دهند.
به عنوان مثال، یک راه حل استقرار ظاهراً "یک کلیک" را در نظر بگیرید. . من تا حد مرگ به دلیل ناهنجاری های Google Cloud SQL بیمار بودم، بنابراین شروع به ساختن خوشه Percona خودم به عنوان جایگزین کردم. و این بار به نظر می رسید که گوگل کار خوبی انجام داده است، آنها قصد داشتند با یک کلیک در زمان و تلاش من صرفه جویی کنند!
خب عالیه بریم بیایید پیوند را دنبال کرده و روی این دکمه کلیک کنید. برای موافقت با تمام تنظیمات پیش‌فرض و استقرار خوشه در پروژه ابری Google خود، «بله» را انتخاب کنید. هههههههههههه هیچ کدام از این مزخرفات کار نمی کند. این ابزار هرگز آزمایش نشد و از همان دقیقه اول شروع به پوسیدگی کرد، و اگر بیش از نیمی از "راه حل ها" با یک کلیک اجرا شوند، من را شگفت زده نمی کند (اکنون می فهمیم که چرا نقل قول ها) به طور کلی کار نمی کند. این تاریکی کاملاً ناامیدکننده است، جایی که بهتر است وارد آن نشوید.
اما گوگل حق دارد تشویق می کند شما از آنها استفاده کنید آنها از شما می خواهند خریده. برای آنها این یک معامله است. آنها چیزی نمی خواهند پشتیبانی. این بخشی از DNA گوگل نیست. بله، مهندسان از یکدیگر حمایت می کنند، همانطور که داستان من با Bigtable نشان می دهد. اما در محصولات و خدمات برای مردم عادی آنها همیشه بی رحم بودند در ، که حتی اگر میلیون ها کاربر داشته باشد، نمی تواند سودآوری داشته باشد.
و این یک چالش واقعی برای GCP است زیرا این DNA پشت همه ارائه‌های ابری است. آنها سعی نمی کنند از چیزی حمایت کنند. به خوبی شناخته شده است که آنها از میزبانی (به عنوان یک سرویس مدیریت شده) هر نرم افزار شخص ثالث خودداری می کنند تا زمان، تا زمانی که AWS همین کار را انجام دهد و کسب و کار موفقی را حول آن بسازد، و زمانی که مشتریان به معنای واقعی کلمه همان را بخواهند. با این حال، برای اینکه گوگل از چیزی پشتیبانی کند، کمی تلاش نیاز است.
این فقدان فرهنگ پشتیبانی، همراه با ذهنیت «بیایید آن را بشکنیم تا زیباتر شویم»، توسعه‌دهندگان را از خود دور می‌کند.
و اگر بخواهید یک پلتفرم با عمر طولانی بسازید این چیز خوبی نیست.
گوگل، بیدار شو، لعنتی. اکنون سال 2020 است. تو هنوز داری میبازی وقت آن رسیده است که به آینه نگاه کنید و پاسخ دهید که آیا واقعاً می خواهید در تجارت ابری بمانید یا خیر.
اگه میخوای بمونی پس شکستن همه چیز را متوقف کنید. بچه ها، شما پولدار هستید. ما توسعه دهندگان این کار را نمی کنیم. بنابراین وقتی نوبت به اینکه چه کسی بار سازگاری را به دوش می‌کشد، باید آن را بر عهده بگیرید. نه برای ما
زیرا حداقل سه ابر واقعا خوب دیگر وجود دارد. آنها اشاره می کنند.
و اکنون به تعمیر تمام سیستم های خراب خود ادامه خواهم داد. هه
تا دفعه بعد!
به روز رسانی PS پس از خواندن برخی از بحث های این مقاله (بحث ها عالی هستند، btw). پشتیبانی Firebase قطع نشده است و هیچ برنامه ای وجود ندارد که من از آن مطلع باشم. با این حال، آنها یک باگ ناخوشایند جریان دارند که باعث می‌شود کلاینت جاوا در App Engine متوقف شود. یکی از مهندسان آنها به من کمک کرد تا این مشکل را حل کنم، زمانی که در گوگل کار می کردم، اما آنها در واقع هرگز این باگ را برطرف نکردند، بنابراین من یک راه حل بیهوده دارم که باید هر روز برنامه GAE را دوباره راه اندازی کنم. و همینطور برای چهار سال! آنها اکنون Firestor را دارند. مهاجرت به آن کار زیادی نیاز دارد زیرا یک سیستم کاملاً متفاوت است و باگ Firebase هرگز برطرف نخواهد شد. چه نتیجه ای می توان گرفت؟ می توانید کمک بگیرید اگر در یک شرکت کار می کنید. من احتمالاً تنها کسی هستم که از Firebase در GAE استفاده می کنم زیرا کمتر از 100 کلید را در یک برنامه 100٪ بومی وارد می کنم و به دلیل یک اشکال شناخته شده کار هر چند روز یکبار متوقف می شود. من چه می توانم بگویم غیر از استفاده از آن با مسئولیت خودت. من دارم به Redis تغییر می کنم.
من همچنین دیده ام که برخی از کاربران با تجربه AWS می گویند که AWS معمولاً هرگز از هیچ سرویسی پشتیبانی نمی کند و SimpleDB یک مثال عالی است. به نظر می رسد فرضیات من مبنی بر اینکه AWS همان بیماری پشتیبانی را ندارد که Google دارد موجه است.
علاوه بر این، من متوجه شدم که 20 روز پیش تیم Google App Engine میزبانی یک کتابخانه مهم Go را شکست و یک برنامه GAE یکی از توسعه دهندگان اصلی Go را خاموش کرد. واقعا احمقانه بود
در نهایت، من شنیده‌ام که کارمندان Google قبلاً در مورد این موضوع بحث می‌کنند و به طور کلی با من موافق هستند (دوستان شما را دوست دارم!). اما به نظر می رسد که آنها فکر می کنند مشکل غیرقابل حل است زیرا فرهنگ گوگل هرگز ساختار انگیزشی مناسبی نداشت. فکر می‌کردم خوب است کمی وقت بگذارم تا درباره تجربه فوق‌العاده‌ای که از کار با مهندسان AWS در حین کار در Grab داشتم صحبت کنم. روزی در آینده، امیدوارم!
و بله، در سال 2005 آنها انواع مختلفی از گوشت کوسه را در بوفه غول پیکر ساختمان 43 داشتند، و مورد علاقه من گوشت کوسه سر چکشی بود. با این حال، تا سال 2006، لری و سرگئی از شر تمام تنقلات ناسالم خلاص شدند. بنابراین در طول داستان Bigtable در سال 2007 واقعاً هیچ کوسه ای وجود نداشت و من شما را فریب دادم.
وقتی چهار سال پیش به ابر Bigtable نگاه کردم (ببخش یا بگیر)، این جایی بود که هزینه آن بود. به نظر می رسد اکنون کمی کاهش یافته است، اما هنوز برای یک انبار داده خالی بسیار افتضاح است، به خصوص که اولین داستان من نشان می دهد که یک جدول بزرگ خالی چقدر در مقیاس آنها بی اهمیت است.
متاسفم برای توهین به جامعه اپل و نگفتن چیز خوبی در مورد مایکروسافت و غیره. شما خوب هستید، من واقعاً از همه بحث هایی که این مقاله ایجاد کرده قدردانی می کنم! اما گاهی اوقات برای شروع یک بحث لازم است کمی موج بزنید، می دانید؟
با تشکر برای خواندن.
به روز رسانی 2، 19.08.2020/XNUMX/XNUMX. راه راه !
به روز رسانی 3، 31.08.2020/2/2. یک مهندس گوگل در Cloud Marketplace با من تماس گرفت که معلوم شد دوست قدیمی من است. او می‌خواست بفهمد که چرا CXNUMXD کار نمی‌کند، و ما در نهایت متوجه شدیم که به این دلیل است که من شبکه‌ام را سال‌ها پیش ساخته بودم، و CXNUMXD روی شبکه‌های قدیمی کار نمی‌کرد، زیرا پارامتر زیرشبکه در قالب‌های آنها وجود نداشت. من فکر می کنم بهتر است کاربران بالقوه GCP مطمئن شوند که مهندسان کافی در گوگل را می شناسند...
منبع: www.habr.com