আপনি হয়তো জানেন, Chrome DevTools হল HTML, CSS এবং JavaScript ব্যবহার করে লেখা একটি ওয়েব অ্যাপ্লিকেশন। বছরের পর বছর ধরে, DevTools বিস্তৃত ওয়েব প্ল্যাটফর্ম সম্পর্কে আরও বৈশিষ্ট্য সমৃদ্ধ, স্মার্ট এবং জ্ঞানী হয়েছে। যদিও DevTools বছরের পর বছর ধরে প্রসারিত হয়েছে, এর স্থাপত্যটি মূলত মূল স্থাপত্যের সাথে সাদৃশ্যপূর্ণ যখন এটি এখনও WebKit- এর অংশ ছিল।
এই পোস্টটি ব্লগ পোস্টগুলির একটি সিরিজের অংশ যা আমরা DevTools-এর আর্কিটেকচারে যে পরিবর্তনগুলি করছি এবং এটি কীভাবে তৈরি করা হয়েছে তা বর্ণনা করে৷ আমরা ব্যাখ্যা করব কিভাবে DevTools ঐতিহাসিকভাবে কাজ করেছে, কী কী সুবিধা এবং সীমাবদ্ধতা ছিল এবং এই সীমাবদ্ধতাগুলি দূর করার জন্য আমরা কী করেছি। অতএব, আসুন মডিউল সিস্টেমের গভীরে ডুব দেওয়া যাক, কীভাবে কোড লোড করতে হয় এবং কীভাবে আমরা জাভাস্ক্রিপ্ট মডিউল ব্যবহার করে শেষ করেছি।
শুরুতে কিছুই ছিল না
যদিও বর্তমান ফ্রন্টএন্ড ল্যান্ডস্কেপে বিভিন্ন ধরনের মডিউল সিস্টেম রয়েছে যার চারপাশে তৈরি করা টুল রয়েছে, সেইসাথে এখন-প্রমিত জাভাস্ক্রিপ্ট মডিউল ফরম্যাট , যখন DevTools প্রথম তৈরি করা হয়েছিল তখন এগুলোর কোনোটিই ছিল না। DevTools কোডের উপরে তৈরি করা হয়েছে যা 12 বছরেরও বেশি আগে ওয়েবকিটে প্রাথমিকভাবে পাঠানো হয়েছিল।
DevTools-এ একটি মডিউল সিস্টেমের প্রথম উল্লেখ 2012 থেকে শুরু হয়েছে: উত্সগুলির একটি সংশ্লিষ্ট তালিকা সহ মডিউলগুলির একটি তালিকার প্রবর্তন ৷ এটি ছিল পাইথন অবকাঠামোর অংশ যা সেই সময়ে DevTools কম্পাইল এবং তৈরি করতে ব্যবহৃত হয়েছিল। একটি ফলো-আপ পরিবর্তন 2013 সালে একটি পৃথক frontend_modules.json ফাইল ( কমিট ) এবং তারপর 2014 সালে পৃথক module.json ফাইল ( কমিট ) তে সমস্ত মডিউল বের করে।
একটি উদাহরণ module.json ফাইল:
{
"dependencies": [
"common"
],
"scripts": [
"StylePane.js",
"ElementsPanel.js"
]
}
2014 সাল থেকে, module.json প্যাটার্নটি DevTools-এ এর মডিউল এবং সোর্স ফাইলগুলি নির্দিষ্ট করতে ব্যবহার করা হয়েছে৷ ইতিমধ্যে, ওয়েব ইকোসিস্টেম দ্রুত বিকশিত হয়েছে এবং ইউএমডি, কমনজেএস এবং অবশেষে প্রমিত জাভাস্ক্রিপ্ট মডিউল সহ একাধিক মডিউল ফর্ম্যাট তৈরি করা হয়েছে। যাইহোক, DevTools module.json ফর্ম্যাটের সাথে আটকে আছে।
DevTools কাজ করার সময়, একটি অ-প্রমিত এবং অনন্য মডিউল সিস্টেম ব্যবহার করার কয়েকটি খারাপ দিক ছিল:
-
module.jsonফরম্যাটে কাস্টম বিল্ড টুলিং প্রয়োজন, আধুনিক বান্ডলারের মতো। - কোন IDE ইন্টিগ্রেশন ছিল না, যার জন্য আধুনিক IDE গুলি বুঝতে পারে এমন ফাইল তৈরি করতে কাস্টম টুলিংয়ের প্রয়োজন ছিল ( VS কোডের জন্য jsconfig.json ফাইল তৈরি করার জন্য আসল স্ক্রিপ্ট )।
- মডিউলগুলির মধ্যে ভাগাভাগি সম্ভব করার জন্য ফাংশন, ক্লাস এবং অবজেক্টগুলিকে বিশ্বব্যাপী সুযোগে রাখা হয়েছিল।
- ফাইলগুলি অর্ডার-নির্ভর ছিল, যার অর্থ
sourcesতালিকাভুক্ত করা হয়েছিল তা গুরুত্বপূর্ণ। কোন গ্যারান্টি ছিল না যে আপনি যে কোডের উপর নির্ভর করেন তা লোড হবে, অন্য কোন মানুষ এটি যাচাই করেছে।
সর্বোপরি, DevTools এবং অন্যান্য (আরো বহুল ব্যবহৃত) মডিউল ফরম্যাটে মডিউল সিস্টেমের বর্তমান অবস্থার মূল্যায়ন করার সময়, আমরা এই সিদ্ধান্তে পৌঁছেছি যে module.json প্যাটার্ন এটি সমাধান করার চেয়ে আরও বেশি সমস্যা তৈরি করছে এবং আমাদের সরে যাওয়ার পরিকল্পনা করার সময় এসেছে। ইহা হতে.
মানদণ্ডের সুবিধা
বিদ্যমান মডিউল সিস্টেমগুলির মধ্যে, আমরা স্থানান্তর করার জন্য জাভাস্ক্রিপ্ট মডিউল বেছে নিয়েছি। সেই সিদ্ধান্তের সময় জাভাস্ক্রিপ্ট মডিউলগুলি এখনও Node.js-এ একটি পতাকার পিছনে শিপিং করা হয়েছিল এবং NPM-এ উপলব্ধ প্রচুর পরিমাণে প্যাকেজগুলির একটি জাভাস্ক্রিপ্ট মডিউল বান্ডিল ছিল না যা আমরা ব্যবহার করতে পারি। এই সত্ত্বেও, আমরা উপসংহারে পৌঁছেছি যে জাভাস্ক্রিপ্ট মডিউলগুলি সেরা বিকল্প।
জাভাস্ক্রিপ্ট মডিউলের প্রাথমিক সুবিধা হল এটি জাভাস্ক্রিপ্টের জন্য প্রমিত মডিউল বিন্যাস । যখন আমরা module.json এর ডাউনসাইডগুলি তালিকাভুক্ত করেছি (উপরে দেখুন), আমরা বুঝতে পেরেছি যে তাদের প্রায় সবই একটি অ-প্রমিত এবং অনন্য মডিউল বিন্যাস ব্যবহার করার সাথে সম্পর্কিত।
অ-প্রমিত একটি মডিউল বিন্যাস বেছে নেওয়ার অর্থ হল আমাদের রক্ষণাবেক্ষণকারীরা ব্যবহার করা বিল্ড টুল এবং সরঞ্জামগুলির সাথে ইন্টিগ্রেশন তৈরি করতে আমাদের নিজেদেরকে সময় বিনিয়োগ করতে হবে।
এই ইন্টিগ্রেশনগুলি প্রায়শই ভঙ্গুর ছিল এবং বৈশিষ্ট্যগুলির জন্য সমর্থনের অভাব ছিল, অতিরিক্ত রক্ষণাবেক্ষণের সময় প্রয়োজন, কখনও কখনও সূক্ষ্ম বাগগুলির দিকে পরিচালিত করে যা অবশেষে ব্যবহারকারীদের কাছে পাঠানো হবে।
যেহেতু জাভাস্ক্রিপ্ট মডিউলগুলি স্ট্যান্ডার্ড ছিল, এর মানে হল যে VS কোডের মতো IDE, ক্লোজার কম্পাইলার/টাইপস্ক্রিপ্টের মতো টাইপ চেকার এবং রোলআপ/মিনিফায়ারের মতো বিল্ড টুলগুলি আমাদের লেখা সোর্স কোড বুঝতে সক্ষম হবে। অধিকন্তু, যখন একজন নতুন রক্ষণাবেক্ষণকারী DevTools টিমে যোগদান করবে, তখন তাদের একটি মালিকানাধীন module.json ফর্ম্যাট শিখতে সময় ব্যয় করতে হবে না, যেখানে তারা (সম্ভবত) জাভাস্ক্রিপ্ট মডিউলগুলির সাথে ইতিমধ্যেই পরিচিত হবে।
অবশ্যই, যখন DevTools প্রাথমিকভাবে নির্মিত হয়েছিল, তখন উপরের সুবিধাগুলির কোনটিই বিদ্যমান ছিল না। স্ট্যান্ডার্ড গ্রুপ, রানটাইম ইমপ্লিমেন্টেশন এবং জাভাস্ক্রিপ্ট মডিউল ব্যবহার করে ডেভেলপারদের ফিডব্যাক প্রদান করে তারা এখন যেখানে আছে সেখানে যেতে বছরের পর বছর ধরে কাজ করেছে। কিন্তু যখন জাভাস্ক্রিপ্ট মডিউলগুলি উপলভ্য হয় তখন আমাদের একটি পছন্দ ছিল: হয় আমাদের নিজস্ব ফর্ম্যাট বজায় রাখুন, অথবা নতুনটিতে স্থানান্তরিত করতে বিনিয়োগ করুন৷
চকচকে নতুনের দাম
যদিও জাভাস্ক্রিপ্ট মডিউলের প্রচুর সুবিধা ছিল যা আমরা ব্যবহার করতে চাই, আমরা অ-মানক module.json জগতে রয়েছি। জাভাস্ক্রিপ্ট মডিউলগুলির সুবিধাগুলি কাটার অর্থ হল যে আমাদের প্রযুক্তিগত ঋণ পরিষ্কার করার জন্য উল্লেখযোগ্যভাবে বিনিয়োগ করতে হবে, এমন একটি মাইগ্রেশন সম্পাদন করতে হবে যা সম্ভাব্য বৈশিষ্ট্যগুলি ভেঙে দিতে পারে এবং রিগ্রেশন বাগগুলি প্রবর্তন করতে পারে৷
এই মুহুর্তে, এটি "আমরা কি জাভাস্ক্রিপ্ট মডিউল ব্যবহার করতে চাই?" এর একটি প্রশ্ন ছিল না, কিন্তু একটি প্রশ্ন ছিল "জাভাস্ক্রিপ্ট মডিউল ব্যবহার করতে সক্ষম হওয়া কতটা ব্যয়বহুল?" . এখানে, আমাদের ব্যবহারকারীদের রিগ্রেশনের সাথে ভাঙ্গার ঝুঁকি, প্রকৌশলীদের খরচ (বড় পরিমাণ) সময় স্থানান্তরিত করার খরচ এবং আমরা যে সাময়িক খারাপ অবস্থায় কাজ করব তার মধ্যে ভারসাম্য বজায় রাখতে হয়েছিল।
যে শেষ পয়েন্ট খুব গুরুত্বপূর্ণ হতে পরিণত. যদিও আমরা তাত্ত্বিকভাবে জাভাস্ক্রিপ্ট মডিউলগুলি পেতে পারি, একটি মাইগ্রেশনের সময় আমরা কোড দিয়ে শেষ করব যেটি module.json এবং JavaScript মডিউল উভয়কেই বিবেচনা করতে হবে। এটি অর্জন করা কেবল প্রযুক্তিগতভাবে কঠিন ছিল না, এর মানে হল যে DevTools-এ কাজ করা সমস্ত ইঞ্জিনিয়ারদের এই পরিবেশে কীভাবে কাজ করতে হবে তা জানতে হবে। তাদের নিজেদেরকে ক্রমাগত জিজ্ঞাসা করতে হবে "কোডবেসের এই অংশের জন্য, এটা কি module.json বা JavaScript মডিউল এবং আমি কিভাবে পরিবর্তন করব?"।
উঁকিঝুঁকি: আমাদের সহকর্মী রক্ষণাবেক্ষণকারীদের মাইগ্রেশনের মাধ্যমে গাইড করার লুকানো খরচ আমাদের প্রত্যাশার চেয়েও বড় ছিল।
খরচ বিশ্লেষণের পর, আমরা উপসংহারে পৌঁছেছি যে জাভাস্ক্রিপ্ট মডিউলে স্থানান্তর করা এখনও সার্থক। অতএব, আমাদের প্রধান লক্ষ্য ছিল নিম্নলিখিত:
- নিশ্চিত করুন যে জাভাস্ক্রিপ্ট মডিউলগুলির ব্যবহার সম্ভাব্য সর্বাধিক পরিমাণে সুবিধাগুলি কাটায়৷
- নিশ্চিত করুন যে বিদ্যমান
module.jsonভিত্তিক সিস্টেমের সাথে একীকরণ নিরাপদ এবং ব্যবহারকারীর নেতিবাচক প্রভাব (রিগ্রেশন বাগ, ব্যবহারকারীর হতাশা) নিয়ে যায় না। - সমস্ত DevTools রক্ষণাবেক্ষণকারীকে মাইগ্রেশনের মাধ্যমে গাইড করুন, প্রাথমিকভাবে দুর্ঘটনাজনিত ভুল রোধ করতে বিল্ট-ইন চেক এবং ব্যালেন্স সহ।
স্প্রেডশীট, রূপান্তর এবং প্রযুক্তিগত ঋণ
যদিও লক্ষ্যটি পরিষ্কার ছিল, module.json বিন্যাস দ্বারা আরোপিত সীমাবদ্ধতাগুলি সমাধান করা কঠিন বলে প্রমাণিত হয়েছে। আমরা স্বাচ্ছন্দ্য ছিলাম এমন একটি সমাধান তৈরি করার আগে এটি বেশ কয়েকটি পুনরাবৃত্তি, প্রোটোটাইপ এবং স্থাপত্য পরিবর্তন নিয়েছিল। আমরা যে মাইগ্রেশন কৌশলটি শেষ করেছি তার সাথে আমরা একটি ডিজাইন ডক লিখেছি। ডিজাইন ডক আমাদের প্রাথমিক সময়ের অনুমান তালিকাভুক্ত করেছে: 2-4 সপ্তাহ।
স্পয়লার সতর্কতা: মাইগ্রেশনের সবচেয়ে নিবিড় অংশটি 4 মাস এবং শুরু থেকে শেষ পর্যন্ত 7 মাস লেগেছিল!
যদিও প্রাথমিক পরিকল্পনাটি সময়ের পরীক্ষায় দাঁড়িয়েছিল: আমরা DevTools রানটাইমকে পুরানো পদ্ধতি ব্যবহার করে module.json ফাইলের scripts অ্যারেতে তালিকাভুক্ত সমস্ত ফাইল লোড করতে শেখাব, যখন জাভাস্ক্রিপ্ট মডিউল সহ modules অ্যারেতে তালিকাভুক্ত সমস্ত ফাইল গতিশীল আমদানি । modules অ্যারেতে থাকা যেকোনো ফাইল ইএস আমদানি/রপ্তানি ব্যবহার করতে সক্ষম হবে।
অতিরিক্তভাবে, আমরা মাইগ্রেশনটি 2টি ধাপে সম্পাদন করব (আমরা শেষ পর্যায়টি 2টি উপ-পর্যায়ে বিভক্ত করেছি, নীচে দেখুন): export - এবং import -পর্যায়গুলি৷ একটি বড় স্প্রেডশীটে কোন পর্যায়ে ট্র্যাক করা হয়েছিল কোন মডিউলের স্থিতি:
অগ্রগতি পত্রকের একটি স্নিপেট এখানে সর্বজনীনভাবে উপলব্ধ।
export -পর্যায়
প্রথম ধাপে মডিউল/ফাইলের মধ্যে ভাগ করা উচিত ছিল এমন সমস্ত প্রতীকের জন্য export -বিবৃতি যোগ করা। প্রতি ফোল্ডারে একটি স্ক্রিপ্ট চালানোর মাধ্যমে রূপান্তরটি স্বয়ংক্রিয় হবে। নিম্নোক্ত চিহ্নটি module.json বিশ্বে বিদ্যমান থাকবে:
Module.File1.exported = function() {
console.log('exported');
Module.File1.localFunctionInFile();
};
Module.File1.localFunctionInFile = function() {
console.log('Local');
};
(এখানে, Module হল মডিউলের নাম এবং File1 হল ফাইলের নাম। আমাদের সোর্সট্রিতে, সেটা হবে front_end/module/file1.js ।)
এটি নিম্নলিখিতগুলিতে রূপান্তরিত হবে:
export function exported() {
console.log('exported');
Module.File1.localFunctionInFile();
}
export function localFunctionInFile() {
console.log('Local');
}
/** Legacy export object */
Module.File1 = {
exported,
localFunctionInFile,
};
প্রাথমিকভাবে, আমাদের পরিকল্পনা ছিল এই পর্যায়ে একই-ফাইল আমদানি পুনরায় লেখার। উদাহরণস্বরূপ, উপরের উদাহরণে আমরা Module.File1.localFunctionInFile localFunctionInFile এ পুনরায় লিখব। যাইহোক, আমরা বুঝতে পেরেছি যে এই দুটি রূপান্তরকে আলাদা করলে স্বয়ংক্রিয়ভাবে প্রয়োগ করা সহজ এবং নিরাপদ হবে। অতএব, "একই ফাইলে সমস্ত প্রতীক স্থানান্তর করুন" import -ফেজের দ্বিতীয় উপ-পর্যায় হয়ে উঠবে।
যেহেতু একটি ফাইলে export কীওয়ার্ড যোগ করলে ফাইলটিকে "স্ক্রিপ্ট" থেকে একটি "মডিউলে" রূপান্তরিত করে, তাই অনেক DevTools পরিকাঠামো সেই অনুযায়ী আপডেট করতে হয়েছিল। এর মধ্যে রানটাইম (গতিশীল আমদানি সহ) অন্তর্ভুক্ত ছিল, তবে মডিউল মোডে চালানোর জন্য ESLint এর মতো সরঞ্জামও রয়েছে।
এই সমস্যাগুলির মধ্য দিয়ে কাজ করার সময় আমরা একটি আবিষ্কার করেছি যে আমাদের পরীক্ষাগুলি "স্লোপি" মোডে চলছিল। যেহেতু জাভাস্ক্রিপ্ট মডিউলগুলি বোঝায় যে ফাইলগুলি "use strict" মোডে চলে, এটি আমাদের পরীক্ষাগুলিকেও প্রভাবিত করবে৷ যেমনটি দেখা গেল, একটি অ-তুচ্ছ পরিমাণ পরীক্ষা এই ঢালুতার উপর নির্ভর করছে, যার মধ্যে একটি পরীক্ষা যা with 😱 ব্যবহার করেছে।
শেষ পর্যন্ত, export -বিবৃতি অন্তর্ভুক্ত করার জন্য প্রথম ফোল্ডারটি আপডেট করতে প্রায় এক সপ্তাহ সময় লেগেছে এবং রিল্যান্ডের সাথে একাধিক প্রচেষ্টা ।
import -পর্যায়
সমস্ত প্রতীক উভয়ই export -বিবৃতি ব্যবহার করে রপ্তানি করার পরে এবং বিশ্বব্যাপী সুযোগে (লেগেসি) রয়ে যাওয়ার পরে, ইএস আমদানি ব্যবহার করার জন্য আমাদের ক্রস-ফাইল প্রতীকগুলির সমস্ত উল্লেখ আপডেট করতে হয়েছিল। শেষ লক্ষ্য হবে সমস্ত "লেগেসি এক্সপোর্ট অবজেক্ট" মুছে ফেলা, গ্লোবাল স্কোপ পরিষ্কার করা। প্রতি ফোল্ডারে একটি স্ক্রিপ্ট চালানোর মাধ্যমে রূপান্তরটি স্বয়ংক্রিয় হবে।
উদাহরণস্বরূপ, নিম্নলিখিত চিহ্নগুলির জন্য যা module.json বিশ্বে বিদ্যমান:
Module.File1.exported();
AnotherModule.AnotherFile.alsoExported();
SameModule.AnotherFile.moduleScoped();
তারা রূপান্তরিত হবে:
import * as Module from '../module/Module.js';
import * as AnotherModule from '../another_module/AnotherModule.js';
import {moduleScoped} from './AnotherFile.js';
Module.File1.exported();
AnotherModule.AnotherFile.alsoExported();
moduleScoped();
যাইহোক, এই পদ্ধতির সাথে কিছু সতর্কতা ছিল:
- প্রতিটি চিহ্নের নাম
Module.File.symbolNameনামে করা হয়নি। কিছু প্রতীকের নাম দেওয়া হয়েছিল শুধুমাত্রModule.Fileবা এমনকিModule.CompletelyDifferentName। এই অসামঞ্জস্যতার মানে হল যে আমাদের পুরানো গ্লোবাল অবজেক্ট থেকে নতুন আমদানি করা বস্তুতে একটি অভ্যন্তরীণ ম্যাপিং তৈরি করতে হবে। - কখনও কখনও মডিউলস্কোপড নামের মধ্যে সংঘর্ষ হবে। সবচেয়ে বিশিষ্টভাবে, আমরা নির্দিষ্ট ধরণের
Eventsঘোষণা করার একটি প্যাটার্ন ব্যবহার করেছি, যেখানে প্রতিটি চিহ্নের নাম ছিল শুধুEvents। এর মানে হল যে আপনি যদি বিভিন্ন ফাইলে ঘোষিত একাধিক ধরণের ইভেন্টের জন্য শুনছেন, তাহলে সেইEventsজন্যimport-statement-এ একটি নাম সংঘর্ষ ঘটবে। - যেহেতু এটি পরিণত হয়েছে, ফাইলগুলির মধ্যে সার্কুলার নির্ভরতা ছিল। এটি একটি বিশ্বব্যাপী সুযোগের প্রসঙ্গে ঠিক ছিল, কারণ সমস্ত কোড লোড হওয়ার পরে প্রতীকটির ব্যবহার ছিল। যাইহোক, যদি আপনার
importপ্রয়োজন হয়, সার্কুলার নির্ভরতা স্পষ্ট করা হবে। এটি অবিলম্বে একটি সমস্যা নয়, যদি না আপনার গ্লোবাল স্কোপ কোডে সাইড-ইফেক্ট ফাংশন কল না থাকে, যা DevTools-এরও ছিল। সর্বোপরি, রূপান্তরটিকে নিরাপদ করতে কিছু অস্ত্রোপচার এবং রিফ্যাক্টরিংয়ের প্রয়োজন ছিল।
জাভাস্ক্রিপ্ট মডিউল সহ একটি সম্পূর্ণ নতুন বিশ্ব
ফেব্রুয়ারী 2020-এ, সেপ্টেম্বর 2019-এ শুরু হওয়ার 6 মাস পরে, ui/ ফোল্ডারে শেষ পরিস্কার করা হয়েছিল। এটি মাইগ্রেশনের অনানুষ্ঠানিক সমাপ্তি চিহ্নিত করেছে। ধুলো স্থির হতে দেওয়ার পরে, আমরা আনুষ্ঠানিকভাবে 5 ই মার্চ 2020 তারিখে মাইগ্রেশন সমাপ্ত হিসাবে চিহ্নিত করেছি। 🎉
এখন, DevTools-এর সমস্ত মডিউল কোড শেয়ার করতে JavaScript মডিউল ব্যবহার করে। আমরা এখনও আমাদের লিগ্যাসি পরীক্ষার জন্য বা DevTools আর্কিটেকচারের অন্যান্য অংশগুলির সাথে একীভূত করার জন্য বিশ্বব্যাপী সুযোগে ( module-legacy.js ফাইলগুলিতে) কিছু চিহ্ন রেখেছি। সময়ের সাথে সাথে এগুলি সরানো হবে, কিন্তু আমরা ভবিষ্যতে উন্নয়নের জন্য এগুলিকে ব্লকার হিসাবে বিবেচনা করি না। আমাদের জাভাস্ক্রিপ্ট মডিউল ব্যবহারের জন্য একটি স্টাইল নির্দেশিকাও রয়েছে।
পরিসংখ্যান
এই মাইগ্রেশনের সাথে জড়িত CL এর সংখ্যার জন্য রক্ষণশীল অনুমান (চেঞ্জলিস্টের সংক্ষিপ্ত রূপ - গেরিট-এ ব্যবহৃত শব্দ যা একটি পরিবর্তনকে প্রতিনিধিত্ব করে - একটি GitHub পুল অনুরোধের অনুরূপ) প্রায় 250 CL, মূলত 2 ইঞ্জিনিয়ার দ্বারা সঞ্চালিত হয় । করা পরিবর্তনের আকার সম্পর্কে আমাদের কাছে সুনির্দিষ্ট পরিসংখ্যান নেই, তবে পরিবর্তিত লাইনগুলির একটি রক্ষণশীল অনুমান (প্রতিটি CL এর জন্য সন্নিবেশ এবং মুছে ফেলার মধ্যে পরম পার্থক্যের যোগফল হিসাবে গণনা করা হয়) মোটামুটি 30,000 (সমস্ত DevTools ফ্রন্টএন্ড কোডের ~20%) )
Chrome 79-এ পাঠানো export ব্যবহার করে প্রথম ফাইল, ডিসেম্বর 2019-এ স্থিতিশীল অবস্থায় প্রকাশ করা হয়েছে। Chrome 83-এ পাঠানো import স্থানান্তরিত করার শেষ পরিবর্তন, 2020 সালের মে মাসে স্থিতিশীল অবস্থায় প্রকাশ করা হয়েছিল।
আমরা একটি রিগ্রেশন সম্পর্কে সচেতন যেটি Chrome স্থিতিশীল-এ পাঠানো হয়েছে এবং যেটি এই মাইগ্রেশনের অংশ হিসাবে চালু করা হয়েছিল৷ একটি বহিরাগত default রপ্তানির কারণে কমান্ড মেনুতে স্নিপেটগুলির স্বয়ংক্রিয়-সম্পূর্ণতা ভেঙে গেছে । আমাদের আরও বেশ কিছু রিগ্রেশন হয়েছে, কিন্তু আমাদের স্বয়ংক্রিয় পরীক্ষা স্যুট এবং ক্রোম ক্যানারি ব্যবহারকারীরা এগুলি রিপোর্ট করেছি এবং তারা Chrome স্থিতিশীল ব্যবহারকারীদের কাছে পৌঁছানোর আগে আমরা সেগুলি ঠিক করেছি৷
আপনি crbug.com/1006759- এ লগ-ইন করে সম্পূর্ণ যাত্রা দেখতে পারেন (সমস্ত CL এই বাগের সাথে সংযুক্ত নয়, তবে বেশিরভাগই রয়েছে)।
আমরা যা শিখেছি
- অতীতে নেওয়া সিদ্ধান্তগুলি আপনার প্রকল্পে দীর্ঘস্থায়ী প্রভাব ফেলতে পারে। যদিও জাভাস্ক্রিপ্ট মডিউল (এবং অন্যান্য মডিউল ফরম্যাট) বেশ কিছু সময়ের জন্য উপলব্ধ ছিল, DevTools মাইগ্রেশনকে ন্যায্যতা দেওয়ার অবস্থানে ছিল না। কখন স্থানান্তরিত হবে এবং কখন নয় তা নির্ধারণ করা কঠিন এবং শিক্ষিত অনুমানের উপর ভিত্তি করে।
- আমাদের প্রাথমিক সময়ের অনুমান কয়েক মাসের চেয়ে সপ্তাহে ছিল। এটি মূলত এই সত্য থেকে উদ্ভূত যে আমরা আমাদের প্রাথমিক খরচ বিশ্লেষণে প্রত্যাশার চেয়ে বেশি অপ্রত্যাশিত সমস্যা খুঁজে পেয়েছি। যদিও মাইগ্রেশন পরিকল্পনা শক্ত ছিল, প্রযুক্তিগত ঋণ ছিল (অনেকবার যা আমরা পছন্দ করতাম) ব্লকার।
- জাভাস্ক্রিপ্ট মডিউল মাইগ্রেশনে প্রচুর পরিমাণে (আপাতদৃষ্টিতে সম্পর্কহীন) প্রযুক্তিগত ঋণ পরিচ্ছন্নতা অন্তর্ভুক্ত ছিল। একটি আধুনিক স্ট্যান্ডার্ডাইজড মডিউল ফরম্যাটে স্থানান্তর আমাদেরকে আধুনিক দিনের ওয়েব ডেভেলপমেন্টের সাথে আমাদের কোডিং সেরা অনুশীলনগুলিকে পুনরায় সংগঠিত করার অনুমতি দিয়েছে। উদাহরণস্বরূপ, আমরা আমাদের কাস্টম পাইথন বান্ডলারকে একটি ন্যূনতম রোলআপ কনফিগারেশন দিয়ে প্রতিস্থাপন করতে সক্ষম হয়েছি।
- আমাদের কোডবেসের উপর বড় প্রভাব থাকা সত্ত্বেও (কোডের 20% পরিবর্তিত), খুব কম রিগ্রেশন রিপোর্ট করা হয়েছিল। প্রথম কয়েকটি ফাইল স্থানান্তরিত করার সময় আমাদের অনেক সমস্যা ছিল, কিছুক্ষণ পরে আমাদের একটি শক্ত, আংশিকভাবে স্বয়ংক্রিয়, কর্মপ্রবাহ ছিল। এর মানে হল যে আমাদের স্থিতিশীল ব্যবহারকারীদের জন্য নেতিবাচক ব্যবহারকারীর প্রভাব এই মাইগ্রেশনের জন্য ন্যূনতম ছিল।
- সহকর্মী রক্ষণাবেক্ষণকারীদের একটি নির্দিষ্ট স্থানান্তরের জটিলতা শেখানো কঠিন এবং কখনও কখনও অসম্ভব। এই স্কেলের স্থানান্তরগুলি অনুসরণ করা কঠিন এবং প্রচুর ডোমেন জ্ঞান প্রয়োজন৷ একই কোডবেসে কর্মরত অন্যদের কাছে সেই ডোমেন জ্ঞান হস্তান্তর করা তারা যে কাজটি করছে তার জন্য নিজেরাই পছন্দনীয় নয়। কী ভাগ করতে হবে এবং কী বিশদ ভাগ করা উচিত নয় তা জানা একটি শিল্প, তবে একটি প্রয়োজনীয়। তাই বৃহৎ স্থানান্তরের পরিমাণ কমানো বা অন্তত একই সময়ে না করা অত্যন্ত গুরুত্বপূর্ণ।
প্রিভিউ চ্যানেল ডাউনলোড করুন
আপনার ডিফল্ট ডেভেলপমেন্ট ব্রাউজার হিসেবে Chrome Canary , Dev বা Beta ব্যবহার করার কথা বিবেচনা করুন। এই পূর্বরূপ চ্যানেলগুলি আপনাকে সর্বশেষ DevTools বৈশিষ্ট্যগুলিতে অ্যাক্সেস দেয়, অত্যাধুনিক ওয়েব প্ল্যাটফর্ম API পরীক্ষা করে এবং আপনার ব্যবহারকারীদের আগে আপনার সাইটে সমস্যাগুলি খুঁজে পায়!
Chrome DevTools টিমের সাথে যোগাযোগ করা হচ্ছে
পোস্টের নতুন বৈশিষ্ট্য এবং পরিবর্তনগুলি বা DevTools সম্পর্কিত অন্য কিছু নিয়ে আলোচনা করতে নিম্নলিখিত বিকল্পগুলি ব্যবহার করুন৷
- crbug.com এর মাধ্যমে আমাদের কাছে একটি পরামর্শ বা প্রতিক্রিয়া জমা দিন।
- আরও বিকল্প ব্যবহার করে একটি DevTools সমস্যা রিপোর্ট করুন
> সাহায্য > DevTools-এ একটি DevTools সমস্যা রিপোর্ট করুন । - @ChromeDevTools- এ টুইট করুন।
- আমাদের DevTools YouTube ভিডিও বা DevTools টিপস YouTube ভিডিওগুলিতে নতুন কী আছে সে সম্পর্কে মন্তব্য করুন৷