আমি বারো বছর ধরে প্রোগ্রামিং করছি এবং অনেক ভাষার সাথে কাজ করেছি। এর মধ্যে রয়েছে C , C++ , Java , Python , C# , এবং অবশেষে, JavaScript । প্রতিটি ভাষা বা কাঠামোর নিজস্ব নিয়ম রয়েছে। উদাহরণস্বরূপ, রাস্ট ফাংশন নামের জন্য স্নেক-কেস ব্যবহার করে।
যাইহোক, কিছু নিয়ম, সরঞ্জাম এবং নিদর্শন রয়েছে যা আমি উপলব্ধি করতে পেরেছি। আমি এগুলিকে আমার ফ্রন্টএন্ড অ্যাপ্লিকেশনগুলিতে অন্তর্ভুক্ত করি। এই নিয়মগুলি আমার সাথে আরও বেশি অনুরণিত হয় এবং কোডিংকে একটি মসৃণ প্রক্রিয়া করে তোলে। এখানে কয়েকটি যা আমি বিশেষভাবে পছন্দ করি:
আমার প্রথম টিপ সি থেকে আসে, আমি যে প্রথম ভাষা শিখেছি। মনে আছে যখন আমরা ক্লাসের সাথে প্রতিক্রিয়া লিখতাম? শুধু এটা সম্পর্কে চিন্তা আমার ঠান্ডা দেয়. যখন প্রতিক্রিয়া কার্যকরী উপাদানগুলিতে স্যুইচ করা হয়, তখন এটি কোডটিকে কেবল পড়া সহজ নয়, পরীক্ষা করাও সহজ করে তোলে।
এটি কার্যকরী প্রোগ্রামিংয়ের নীতিগুলির সাথে আরও ভালভাবে সারিবদ্ধ করে।
এই পদ্ধতিটি ফ্রন্টএন্ড ফ্রেমওয়ার্কের সাথে দুর্দান্ত কাজ করে কারণ তারা প্রায়শই কোডের পুনঃব্যবহারযোগ্য টুকরো তৈরিতে ফোকাস করে। ফ্রন্টএন্ড ডেভেলপমেন্টে কার্যকরী প্রোগ্রামিং ব্যবহার করা সবসময়ই আমার জন্য এই ধারণাটি বুঝতে এবং নতুন ফ্রন্টএন্ড বৈশিষ্ট্যগুলি তৈরি করার জন্য একটি সহায়ক কৌশল ছিল।
আমার প্রতিটি ফ্রন্টএন্ড অ্যাপ্লিকেশনে কার্যকরী প্রোগ্রামিং নীতিগুলি অনুসরণ করা আবশ্যক।
আপনি যদি কার্যকরী প্রোগ্রামিং এর সাথে পরিচিত না হন তবে আমি এটিকে আরও অন্বেষণ করার পরামর্শ দিই। এই বিন্দুটি কারণ ছাড়াই এই তালিকার শুরুতে নেই। এটি আপনার বিকাশ প্রক্রিয়ায় যে সুবিধাগুলি আনতে পারে তা যথেষ্ট।
আমি যখন প্রথম প্রোগ্রামিং শুরু করি, তখন আমি কোড ফরম্যাটিং-এ খুব একটা মনোযোগ দিইনি। আমি অনুমান করি যে এটি সব বিশ্ববিদ্যালয়ে শুরু হয়েছিল যেখানে আমি একটি সাদা থিম সহ আমার দুর্দান্ত কোডব্লকস আইডিইতে C++ শিখছিলাম।
GitHub এ 2016 থেকে আমার পুরানো কোডের দিকে ফিরে তাকালে, আমি দেখতে পাচ্ছি যে আমি বিন্যাস করার জন্য শুধুমাত্র স্পেস ব্যবহার করেছি। আমি স্বয়ংক্রিয়ভাবে এটি যত্ন নিতে কোনো সরঞ্জাম ব্যবহার করিনি.
এখন, আমি বুঝতে পারি যে এটি একটি ভুল ছিল। আপনি যদি আপনার প্রকল্পে কিছু স্বয়ংক্রিয় করতে পারেন, আপনার অবশ্যই উচিত। এখন, আমি সবসময় প্রতিটি প্রকল্পের শুরুতে Prettier এবং ESLint সেট আপ করি। আপনি যদি এটিতে অনেক সময় ব্যয় করতে না চান তবে আপনি Airbnb- এর মতো পূর্বে তৈরি কনফিগারেশন ব্যবহার করতে পারেন।
আমাকে বিশ্বাস করুন, আপনি এটি অনুশোচনা করবেন না!
ওহ এবং আপনার IDE-তে ফাইল সংরক্ষণ অ্যাকশনে একটি স্বয়ংক্রিয় ফর্ম্যাটিং সেট আপ করতে ভুলবেন না!
এখন আপনার কাছে দুর্দান্ত ফর্ম্যাটার রয়েছে, আসুন সেগুলি স্বয়ংক্রিয় করি! আমি কখন প্রি-কমিট হুকগুলি ব্যবহার শুরু করেছি তা আমি ঠিক মনে করতে পারি না, তবে তারা আমার প্রকল্পগুলিতে দুর্দান্ত সহায়তা করেছে। কেন ম্যানুয়ালি ফরম্যাট যখন প্রতিটি কমিটের আগে স্বয়ংক্রিয় হতে পারে? হাস্কি এবং লিন্ট-স্টেজের মতো সরঞ্জামগুলি এই অটোমেশনকে সম্ভব করে তোলে।
যদিও অ্যাঙ্গুলারের অনেক ভক্ত এবং সমালোচক আছে, আমি ইতিবাচক দিকে ফোকাস করতে পছন্দ করি। কৌণিক প্রায়ই বড় কোম্পানি এবং বড় অ্যাপ্লিকেশনের জন্য প্রথম পছন্দ হয়. আমি মনে করি অ্যাঙ্গুলারে নেওয়া অনেক সিদ্ধান্তগুলি জিনিসগুলি বজায় রাখা সহজ রাখার জন্য ছিল।
এই কারণেই আমি আমার সমস্ত ফ্রন্টএন্ড প্রকল্পের জন্য কাবাব-কেস ব্যবহার করার সিদ্ধান্ত নিয়েছি। এটি কয়েকটি সুবিধা প্রদান করে, যেমন:
'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ],
আমি সহজ জিনিস রাখতে পছন্দ করি। আমি যদি আমার জীবনকে সহজ করতে পারি এবং এটি থেকে কিছু সুবিধা পেতে পারি, আমি এর জন্য সবই আছি।
আরেকটি জিনিস আমি কৌণিক থেকে ধার করেছি তারা কীভাবে ফাইলের নাম দেয়। কৌণিক ফাইলগুলিকে এমনভাবে নামকরণের সুপারিশ করে যা তাদের ফাংশন এবং প্রকার প্রতিফলিত করে। আমি খুঁজে পেয়েছি যে এটি আমার জন্য একটি প্রকল্পের কাঠামো নেভিগেট করা এবং বুঝতে সহজ করে তোলে। কৌণিক ভাষায়, ফাইলের নামের সাধারণত তিনটি অংশ থাকে: বৈশিষ্ট্য এলাকা, ফাইলের ভূমিকা এবং ফাইলের ধরন।
উদাহরণস্বরূপ, heroes.component.ts
দেখায় যে ফাইলটি heroes
বৈশিষ্ট্যের একটি উপাদান এবং এটি একটি TypeScript ফাইল। heroes.service.ts
heroes
জন্য একটি পরিষেবা।
আমি services
একটি বড় অনুরাগী নই, কিন্তু আমি আমার প্রতিক্রিয়া উপাদানগুলির জন্য একটি অনুরূপ কাঠামো ব্যবহার করি৷ এখানে একটি উদাহরণ:
my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx
আমি আমার হুক এবং ফাংশন জন্য এই প্যাটার্ন ব্যবহার. এই প্যাটার্নটি আমাকে তাদের সম্পর্কিত ফাইলগুলির পাশে আমার পরীক্ষাগুলি রাখতে শেখায়।
আমি আগে যে প্যাটার্নটি উল্লেখ করেছি তা খুবই সহায়ক, কিন্তু আমরা এটিকে অটোমেশনের মাধ্যমে আরও ভালো করে তুলতে পারি। কৌণিক CLI ব্যবহারকারীদের স্বয়ংক্রিয়ভাবে কোড তৈরি করতে দেয় , এবং আমি সবসময় একই কাজ করতে plop ব্যবহার করি। Plop এর টেমপ্লেট সিস্টেম খুব শক্তিশালী, কিন্তু সবচেয়ে গুরুত্বপূর্ণ, এটি সময় বাঁচায়।
অটোমেশনের সাথে, আমাকে একটি উপাদানের মৌলিক কাঠামো সম্পর্কে চিন্তা করতে বেশি সময় ব্যয় করতে হবে না। এই কাজটি স্বয়ংক্রিয় হতে পারে, যা আমাকে আমি যা করতে চাই তার উপর ফোকাস করতে দেয়।
আমি এখানে বিস্তারিতভাবে একটি domain
কী তা ব্যাখ্যা করতে যাচ্ছি না। আপনি যদি এটি সম্পর্কে আরও জানতে চান তবে আমি এই নিবন্ধটি পড়ার পরামর্শ দিচ্ছি। এই মুহূর্তে, আমি ফুল-স্ট্যাক ডেভেলপারদের একটি দলের সাথে কাজ করছি, এবং আমরা খুঁজে পেয়েছি যে আমাদের ফ্রন্টএন্ড প্রকল্পে একটি ডোমেন স্তর থাকা সত্যিই দরকারী।
এটি যেখানে আমরা আমাদের সমস্ত প্রধান প্রকার এবং অপারেশন রাখি। এটি আমাদের অ্যাপে 'সত্যের উৎস' হিসেবে কাজ করে।
আপনি যদি দেখতে চান কিভাবে আমি আমার অ্যাপে 'ডোমেন' পরিচালনা করি, আপনি এই নিবন্ধটি দেখতে পারেন। আমি এই বিষয়টি বর্ণনা করার জন্য সেখানে অনেক সময় ব্যয় করি।
Kotlin- এর সাথে আমাদের কাজ করার সময়, আমরা একবার একটি সমস্যার সম্মুখীন হয়েছিলাম যেখানে যুক্তি একাধিক স্তর জুড়ে মিশে গিয়েছিল, যেমন আমাদের ডোমেনের ভিতরে সংগ্রহস্থলে সংজ্ঞায়িত একটি প্রকার ব্যবহার করা। এটি একটি ক্লিন আর্কিটেকচারের দৃষ্টিকোণ থেকে নো-গো, কিন্তু সবাই ভুল করে।
তখনই আমরা ArchUnit আবিষ্কার করি, আমাদের আর্কিটেকচার পরীক্ষার ইউনিটের জন্য একটি টুল। এটি মূলত চেক করে যে আমরা সঠিকভাবে আমাদের আর্কিটেকচার মেনে চলছি কিনা।
আপনি যদি একটি নির্দিষ্ট আর্কিটেকচার বজায় রাখেন তবে এটি কোনও সময়ে ভাঙা হয়নি কিনা তা পরীক্ষা করার জন্য একটি সরঞ্জাম থাকা কার্যকর হতে পারে। নির্ভরতা-ক্রুজারের মতো একটি হাতিয়ার এক্ষেত্রে অমূল্য হতে পারে।
এবং এটি আপনার ফ্রন্টএন্ড প্রকল্পগুলিকে উন্নত করার জন্য অন্যান্য ভাষা এবং কাঠামোর নিদর্শনগুলির আমার প্রয়োজনীয় তালিকাটি শেষ করে। আমি আশা করি আপনি এই তথ্যটি সহায়ক বলে মনে করেছেন এবং এই কৌশলগুলির মধ্যে অন্তত একটি আপনাকে আপনার নিজের কাজে এটি বাস্তবায়ন করতে অনুপ্রাণিত করেছে!