همانطور که می توانید بگویید ، من با سادگی وسواس دارم. بیشتر مقالاتی که من می نویسم در مورد مشکلات هر دو مهندسی بیش از حد یا زیر مهندسی صحبت می کنند.
با این حال ، در طول تمام دوران من ، من به موارد بیشتری از مهندسی زیر و مهندسی و بیش از حد دیگر نسبت به روش دیگر دست کشیده ام.
سوال باز است: چه چیزی ساده است؟ و من باید صادق باشم. نمی دانم تعداد زیادی از ایده ها در ذهن من رقابت می کنند ، بنابراین در عوض امروز به برخی از تجربیات من اجازه می دهم که مورد توجه قرار بگیرند و به یک درس تبدیل شوند ، امیدوارم که سایر توسعه دهندگان و مهندسان بتوانند سنتز کنند.
زیر پا گذاشتن
در سال 2015 من کار خود را برای شرکتی به نام Untrytrail (بعداً توسط هاپر به دست آورد) شروع کردم.
این شرکت با سرعت بسیار ترسناک و امیدوارکننده در حال رشد بود. آنها سعی کردند به GDS (سیستم توزیع جهانی) برای شرکتهای هواپیمایی Lowcost (و سایر وسایل حمل و نقل) در LATAM تبدیل شوند.
راه حل Untrytrail یک هیولا فرانکنشتاین بود که از تصمیمات بد ، راه حل های کثیف و فوق العاده ناگوار تشکیل شده بود. این یک معجزه بود که نرم افزار آن حتی شروع شد. همچنین جای تعجب نداشت که بیش از یک بار در روز خراب می شود.
من اولین توسعه دهنده داخلی آنها بودم. راه حل آنها توسط یک فریلنسر ساخته شده است. من آن راه حل را تحویل گرفتم و از من انتظار می رفت که با بزرگ شدن شرکت از آن مراقبت کنم.
تا به امروز از Uptrail بخاطر فرصتی برای کار برای آنها و برای آشفتگی آنها که باید با آنها کار کنند تشکر می کنم ، زیرا در غیر این صورت نمی دانستم که حل این مشکلات چقدر لذت بخش است.
ارائه دهندگان و خطوط هوایی یک چیز هستند ، آنها نیستند؟
این اولین مشکل واقعی بود که من در اینجا با آن روبرو شدم. هنگام تلاش برای ادغام یک ارائه دهنده بزرگ بلیط های پرواز (کسی که نامش را به خاطر نمی آورم اما در حال حاضر به عنوان Kiwi.com شناخته می شود) ، به دلیل این واقعیت که پسر فریلنسر ارائه دهندگان بلیط و خطوط هوایی را به عنوان یک چیز مشابه مدل کرده است ، متوجه یک مسدود کننده بزرگ شدم.
از جمله Kiwi.com به همان اندازه که باید به این دلیل که بلیط برای چندین شرکت هواپیمایی ، برخی از آنها ، که قبلاً در راه حل ما سخت شده بودند ، مستقیماً به جلو نبود.
این راه حل شامل بسیاری از راه حل ها بود ، اما همه آنها در همان جهت پیش می روند: بازسازی درک پشت کد ما – خطوط هوایی و ارائه دهندگان بلیط دو مفهوم متفاوت هستند.
رزرو ساده
بدون نیاز به اضافه کردن CPU یا منابع حافظه بیشتر در گلدان ، مشکلات مقیاس پذیری غیرمستقیم را به طور غیرمستقیم حل کنید. پس از آن Undertrail فرصتی برای رشد افقی مشخص کرد. این بار ، تمرکز به مشتریان کنترل دقیق تر بر آنچه که به طور معمول خدمات اضافی گفته می شود ، تغییر یافته است: ساق اضافی ، چمدان های غیرمعمول شکل ، وعده های غذایی با نورپردازی و پیشنهادات مشابه.
سپس اولین SNAG آمد: پرداخت ها به شدت با رزرو (همان جدول/مجموعه ، رابطه 1 به 1 ، همان چرخه عمر) همراه شدند-یک حوزه دامنه میراث که از مرگ امتناع ورزید. به جای تجدید نظر در مدل ناقص ، توسعه دهندگان در اطراف آن وصله دار شدند. نتیجه؟ جریان پرداخت جداگانه برای رزرو و افزودنی ها … به علاوه یک پرونده Frankenstein Edge برای پرداخت های ترکیبی.
خوشبختانه ، پیشنهاد من قبل از اجرای راه حل های گسترده تصویب شد. با جدا کردن پرداخت از رزرو ، ما اطمینان حاصل کردیم که پرداخت ها دارای چرخه عمر خود هستند و می توان یکپارچه با هر محصول آینده و کالاهای فعلی گره خورد.
موتور خرید آشکار
Untrytrail تیمی از آنچه را که ما “بوفرها” نامیدیم داشت. آنها برای تکمیل چرخه عمر رزرو لازم بودند. رزرو ، پرداخت ، پردازش و تحویل داده شد. قسمت پردازش توسط بوکر به پایان رسید. این شامل خرید دستی پروازهای خریداری شده در برخی از ارائه دهندگان ما بود.
هنگامی که ما فرصتی برای خودکارسازی آن قسمت دیدیم ، توسعه دهندگان بی ذهن شروع به ارائه راه حل کردند. برنده: یک کشور جدید بین پرداخت و پردازش. نتیجه؟ بوکر سردرگم ، چرخه عمر نامشخص ، خریدهای مضاعف ($ $ $) و موارد دیگر.
راه حل واقعی: وضعیت جدیدی وجود ندارد. ما فقط یک بوکر داریم که به جای استفاده از UI ، از API استفاده می کند ، اما دقیقاً همان کار را انجام می دهد: نقل قول می شود ، بهترین انتخاب می کند و محصولات را خریداری می کند. یک مشکل متفاوت جدید ، که لزوماً نحوه پردازش رزرو را تغییر نمی دهد.
غذا شناسی
در سال 2021 من به جهان التماس می کردم که فرصتی برای کار در شرکتی که به سرعت در حال رشد است ، اما با راه حلی که نمی تواند آن رشد را تحمل کند. غذا شناسی آن شرکت بود.
آنها آشپزخانه های پنهان را در سرتاسر لاتام اداره می کنند ، و منبع اصلی آنها و تنها منبع درآمد ، از فروش مواد غذایی از طریق سیستم عامل های تحویل مواد غذایی مانند Ubereats ، Doordash و Rappi ناشی می شود.
راه حل آنها همچنین یک هیولا فرانکنشتاین بود. یک یکپارچه متناسب با دریافت سفارشات از ارائه دهنده اصلی ما (RAPPI) ، و برای پشتیبانی از سایر ارائه دهندگان تحویل مواد غذایی که بعداً آمدند ، به طرز دردناکی وصله شد.
بنابراین ما از طریق راپی می فروشیم ، درست است؟
وقتی وارد شدم ، راه حل آنها به وضوح از درک گسترده ای از حوزه تجاری آنها رنج می برد. آنها به جای اینکه خود را به عنوان شرکتی ببینند که از طریق ابزارهای ناهمگن متعدد غذا می فروشند ، خود را به عنوان شرکتی می دیدند که از طریق راپی غذا می فروختند.
راه حل اولیه برای آن ظروف سرباز یا مسافر ایجاد یک گیرنده آگنوستیک از سفارشات (با محبت به نام هیولا کوکی توسط تیم) بود ، و به طور ضمنی تصور غلط اصلی مبنی بر اینکه هیچ اقدامی بین دریافت سفارش و ارسال آن به آشپزخانه وجود ندارد. سپس ما برای هر یک از سیستم عامل هایی که یکپارچه کردیم ، “یکپارچه سازنده” ساختیم ، هر یک از آنها از بازنمایی یک سفارش ترجمه می کنند ، به بازنمایی ما از یک سفارش. این امر به تیم این امکان را داد تا بدون نیاز به تغییر گیرنده اصلی ، به سرعت سیستم عامل های بیشتری را ادغام کند.
این فقط مدیریت منو است
در بعضی مواقع ، هنگامی که تیم سرانجام فضای لازم برای پرداختن به برخی از بخش های نه چندان مهم سیستم را برای کاهش هزینه ها و بهبود کارآیی داشت ، تیم شروع به کار برای خودکارسازی مدیریت منو کرد.
می دانید که هر زمان که از یکی از این برنامه های تحویل غذا استفاده می کنید ، می توانید منوی هر یک از رستوران های محله را کشف کنید ، درست است؟
خوب ، با توجه به این واقعیت که غذا شناسی بیش از 100 آشپزخانه داشت و در هر آشپزخانه می توانستیم حدود 10 مارک مختلف غذا را بفروشیم و با توجه به اینکه قبلاً حدود 10 سیستم عامل تحویل غذایی مختلف را ادغام کرده بودیم. چند فروشگاه (و به تبع آن منوها) مجبور شدیم مدیریت کنیم؟ 10K ، تقریباً ، درست است؟
خوب ، راه حل ارائه شده به عنوان یک WebApp به پایان رسید که در آن شما یک فایل اکسل را که از منو استفاده می کند بارگذاری کرده اید و فروشگاه هایی را که می خواهید آن منو را قرار دهید ، به صورت دستی انتخاب کردید.
راه حل نسبت به آنچه پیش بینی شده بود ، کاملاً ثابت بود. اجرای بسیار ساده لوح بود. شما پرونده را می خوانید ، و سپس منو را در تمام فروشگاه های انتخاب شده همگام می کنید.
اما پس از آن ، با توجه به اینکه هر سیستم عامل متفاوت است ، چگونه این واقعیت را مدیریت می کنید که هر سیستم عامل API متفاوت دارد؟ آیا اگر می خواهید بعداً از آن استفاده کنید ، مجدداً پرونده را بارگذاری کنید؟ در مورد بررسی وضعیت فعلی یک فروشگاه چیست؟ یا در صورت عدم هماهنگی چه اتفاقی می افتد؟
وقتی چشمم را در آن جهت چرخاندم ، تیم را ترغیب کردم که دوباره جریان را فکر کند. وقتی با راه حل بهتری روبرو شدیم ، افراد محصول از من پرسیدند “چرا اینقدر پیچیده است؟ آیا این فقط مدیریت منو نیست؟”
خوب ، محلول پیشنهادی از سه مؤلفه تشکیل شده است
- یک مدیر منو: یک خزنده ساده برای افزودن و اصلاح منوها و پیش نویس های منو.
- یک سرویس اختصاص دهنده منو: منوها و فروشگاه ها متفاوت هستند. آنها چگونه با یکدیگر ارتباط دارند؟ این سرویس کسی است که به شما می گوید کدام منو در کدام فروشگاه قرار دارد. به همین سادگی
- هماهنگ کننده های مختلف منوی مختلف: با در نظر گرفتن این واقعیت که هر پلتفرم متفاوت کار می کرد. ما به جای اینکه همه چیز را در یک سرویس واحد قرار دهیم ، در هر ادغام ایجاد کردیم ، که مسئول ترجمه منوی ما به بازنمایی آنها بود و به ما این امکان را می دهد تا خطاها ، مجدداً و نسخه سازی را با دقت بیشتری مدیریت کنیم.
در واقع پیچیده تر است ، اما …
نتیجه گیری
از همه این مثالها چه چیزی می توانیم مشاهده کنیم؟
همه آنها یک مدل دامنه را به چالش می کشند و آن را به یک مدل پیچیده تر تبدیل می کنند. به نظر می رسد همه نمونه ها از پیچیدگی ها هستند ، اما آیا آنها هستند؟
آنچه از همه این مدل های ساده به اشتباه ناشی می شود ، استحکام بود که توسعه دهندگان را وادار به ساخت و تکامل در اطراف آن کرد و پیچیدگی بیشتری را به آن اضافه کرد که ذاتاً از دامنه ناشی می شود.
توضیح بیش از حد باعث استحکام می شود. استحکام باعث ایجاد راه حل می شود. راه حل ها باعث پیچیدگی می شوند. طنز آن
دنیای واقعی با مدل های ناموفق – زمین ، ژئوسنتریسم ، استریت درخشنده ، تئوری کالری – که به طور قابل ملاحظه ای ساده و در عین حال فاجعه بار نادرست است ، پوشیده شده است. این چارچوب ها فقط با پیوند دادن استثنائات بیشتر بر روی هسته های شکننده خود ، به هم می پیوندند و بر روی عدم تطابق بین تئوری و واقعیت وصله می شوند.
یک توسعه دهنده خوب فقط کد ساده نمی نویسد. یک توسعه دهنده خوب آگاه است که برنامه نویسی یک عمل برای مدل سازی دامنه است و هر دامنه متفاوت با مقدار پیچیدگی همراه است که از آن جلوگیری نمی شود. یک توسعه دهنده خوب چشم تیز و مشتاق دارد تا این پیچیدگی را ببیند و پیش بینی کند ، و نرم افزاری را ایجاد می کند که آن را به طور دقیق مدل می کند ، در نتیجه از پیچیدگی اضافی ناشی از تفسیر نادرست واقعیت جلوگیری می کند.
“سادگی از نادیده گرفتن پیچیدگی ناشی نمی شود. این ناشی از تقسیم دقیق آن به آن و بازسازی آن از قسمت های قابل کنترل و ترکیب است.”
