আপনি একটি কোর্স সম্পন্ন করেছেন, YouTube-এ ভিডিওগুলির একটি সিরিজ দেখেছেন, বা iOS উন্নয়ন সম্পর্কে নিবন্ধগুলির একটি সিরিজ পড়েছেন, এবং এখন আপনি আপনার প্রথম পোষা প্রকল্প লিখতে প্রস্তুত বোধ করছেন৷

প্রথমত, ভাল কাজ! সেটা খুবই ভালো. আপনি শান্ত! 💪

দ্বিতীয়ত, একটি পোষা প্রকল্প আপনার দক্ষতা একটি চমত্কার বৃদ্ধি. যখন আপনি নিজে থেকে কিছু করা শুরু করেন, নির্দেশাবলী অনুসরণ না করে — আপনাকে প্রচুর সময় এবং প্রচেষ্টা ব্যয় করতে হবে, Google প্রচুর, নতুন তথ্যের স্তূপ পড়তে হবে এবং এটিকে আপনার ক্ষেত্রে সঠিকভাবে ফিল্টার করার এবং ফিট করার চেষ্টা করতে হবে। সংক্ষেপে, এটি ইতিমধ্যে একটি বাস্তব কাজ যা আপনাকে পাঁচ গুণ বাড়িয়ে দেবে।

যাইহোক, বেশিরভাগ নতুনরা মূল বিষয়গুলি উপেক্ষা করে (তাদের উদ্যোগের বাইরে নয়, তবে তাদের গুরুত্ব না বুঝে)। গত ছয় মাস ধরে আমি সক্রিয় ছিলাম পরামর্শ এবং নতুনদের তাদের প্রশ্ন এবং সমস্যা সহ পোষা প্রকল্প সহ সাহায্য করা।

আমি শীর্ষস্থানীয় 3টি পয়েন্ট চিহ্নিত করেছি যেগুলি আপনার, একজন শিক্ষানবিশ হিসাবে, আপনার থাকা আবশ্যক তালিকায় অন্তর্ভুক্ত করা উচিত, মাস্টার, বুঝতে এবং ব্যবহার করুন৷

অ্যাক্সেস লেভেল

প্রথমে, প্রায় কেউই private মডিফায়ারে মনোযোগ দেয় না। এদিকে, আপনি যদি মাঝরাতে তাদের ঘুম থেকে জাগিয়ে দেন তবে সবাই তাত্ক্ষণিকভাবে SOLID ব্যাখ্যা করতে পারে। বিভিন্ন স্মার্ট নিবন্ধ পড়ার পরে, লোকেরা এস (একক দায়িত্ব) এর ধারণা অনুসারে ক্লাসের একটি গুচ্ছ তৈরি করার চেষ্টা করে।

এবং তারপর, একটি পরিষ্কার বিবেকের সাথে, তারা class A class B থেকে A শ্রেণীর সম্পত্তি এবং তদ্বিপরীত পরিবর্তন করে।

 class A { var someAValue: Int? } class B { let a = A() func foo() { a.someAValue = 1 } }

সাধারণভাবে, যদি এটি এখনও অস্পষ্ট হয়, তবে এখানে পরিকল্পনাটি রয়েছে: সর্বদা সর্বত্র private লিখুন , এবং যখন কম্পাইলার অভিযোগ করেন — চিন্তা করুন, বাইরে থেকে এই সম্পত্তি বা ফাংশন অ্যাক্সেস করা কি ঠিক হবে? এবং যদি এটি হয় - private সরান ।

আপনি যখন চিন্তা করেন, বাস্তব-বিশ্বের তুলনা দিয়ে নিজেকে গাইড করুন। উদাহরণস্বরূপ, যদি আপনার ক্লাস একটি দোকান হয়, তাহলে goods সম্পত্তি স্পষ্টতই বহিরাগত গ্রাহকের কাছে অ্যাক্সেসযোগ্য হওয়া উচিত। কিন্তু moneyInCashRegister পরিষ্কারভাবে শুধুমাত্র অভ্যন্তরীণ স্টোরের কর্মচারী দ্বারা পরিবর্তন করা যেতে পারে।

সর্বোপরি, একজন গ্রাহকের নগদ রেজিস্টারে অ্যাক্সেস থাকা উচিত নয়, এমনকি put দিয়েও, fetch যাক।

কেউ যুক্তি দিতে পারে, "আমি পুরোপুরি বুঝতে পারি কোন সম্পত্তি স্পর্শ করা যেতে পারে এবং কোনটি private সংশোধক ছাড়াও পারে না"। যাইহোক, লেখার অ্যাক্সেস লেভেল মডিফায়ার ডিজাইনের অংশ। আমি নিশ্চিত যে আপনি তৃতীয় তলায় দরজা সহ একটি বাড়ির জন্য একটি নীলনকশা তৈরি করবেন না।

এবং তারপর, শুধু এটি খুলতে না মনে রাখবেন. সর্বোপরি, এটি সম্ভবত অন্যরাও আপনার কোড ব্যবহার করবে।

যাইহোক, var এবং let এর সাথে একটি অনুরূপ পরিস্থিতি বিদ্যমান। আবার, সর্বদা let ব্যবহার করুন যদি না আপনি অবিলম্বে নিশ্চিত হন যে আপনি মান পরিবর্তন করবেন।

স্থাপত্য সরলতা

আমি একটি প্রবণতা লক্ষ্য করেছি যেখানে নতুনরা সবকিছু আগে থেকে পরিকল্পনা করার চেষ্টা করে। যদিও এটি প্রশংসনীয়, বিকাশকারীরা প্রায়শই তাদের অভিজ্ঞতার অভাবের কারণে ভুল করে। তারা অত্যধিক জটিল পরিচালকদের প্রাক-প্রস্তুত করে (সাধারণত থেকে কপি করা হয় স্ট্যাকওভারফ্লো ) অনেক জটিল পদ্ধতি সহ, যা তারা শেষ পর্যন্ত ব্যবহার করে না। ফলস্বরূপ, কোডের পরিমাণ এবং জটিলতা বৃদ্ধি পায়।

একটি সুবিধাজনক, রেডিমেড পরিষেবার মতো মনে হওয়ার পরিবর্তে, আমাদের প্রোগ্রামার শুধুমাত্র সমস্যা এবং ভুল বোঝাবুঝির সাথে শেষ হয়েছিল। একই স্থাপত্যের জন্য যায়।

আমার বক্তব্য জানাতে আমি সংক্ষেপে আপনাকে প্রোগ্রামিংয়ের ইতিহাসের মধ্য দিয়ে যাত্রা করি। 1960 এর দশকের শেষের দিকে, প্রোগ্রামিংয়ের জনপ্রিয়তা বাড়তে শুরু করলে, প্রোগ্রামগুলির আকারও বৃদ্ধি পায়। যেমন আপনি বুঝতে পারেন, একটি বড় প্রোগ্রামের আকার মানে কোডের আরও লাইন, যা প্রোগ্রামটি বোঝার ক্ষেত্রে জটিলতা এবং অসুবিধা বাড়ায়।

এই সমস্যাটি সমাধান করার জন্য, কাঠামোগত প্রোগ্রামিং আবির্ভূত হয়েছে - ফাংশন এবং পদ্ধতি যা প্রোগ্রামগুলিকে ছোট, পরিচালনাযোগ্য অংশে বিভক্ত করার অনুমতি দেয়। কোডটি মডুলার, পুনরায় ব্যবহারযোগ্য এবং আরও বোধগম্য হয়ে উঠেছে।

কাঠামোর আবির্ভাব প্রোগ্রামগুলিতে আরও বৃদ্ধির দিকে পরিচালিত করে যতক্ষণ না তারা আবার তাদের আকার এবং জটিলতার সীমাতে পৌঁছায়। অতএব, 1970-এর দশকের শেষের দিকে এবং 1980-এর দশকের গোড়ার দিকে, অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিং পদ্ধতি গঠিত হয়েছিল। এই সমাধানটি ক্রমবর্ধমান জটিল কাজগুলিকে সম্বোধন করে নমনীয় এবং মাপযোগ্য সিস্টেম তৈরি করতে সক্ষম করেছে।

পরের দশকে, আমরা কম্পিউটার গেমের গর্জন প্রত্যক্ষ করেছি। ব্যবহারকারীর ক্রিয়াগুলির প্রতিক্রিয়া (ক্লিক, প্রেস) সমালোচনামূলক বলে প্রমাণিত হয়েছিল, যা ইভেন্ট-চালিত প্রোগ্রামিংয়ের উত্থানের দিকে পরিচালিত করে।

এবং ওয়েব এবং ডেস্কটপ অ্যাপ্লিকেশনগুলিতে কোড সংগঠিত করার জন্য — যখন একই ডেটা বিভিন্ন দৃষ্টিকোণ থেকে পুনর্বিন্যাস করার প্রয়োজন হয় — এমভিসি প্যাটার্ন (অর্থাৎ, মডেলটিকে এর ভিজ্যুয়াল উপস্থাপনা থেকে আলাদা করা) আবির্ভূত হয়েছিল।

আপনি মূল ধারণাটি উপলব্ধি করেছেন: একটি সমস্যা দেখা দেয়, -> একটি সমাধান আবির্ভূত হয়। সমস্যা -> সমাধান।

তাহলে কেন শিক্ষানবিস প্রোগ্রামাররা এখন এমন সময়ে সমাধান (আর্কিটেকচার) প্রয়োগ করা শুরু করে যখন সমস্যাগুলি এখনও দেখা দেয়নি? টিউটোরিয়ালগুলি অবিলম্বে অন্তত একটি MVP বেছে নেওয়ার পরামর্শ দেয়। এক/দুটি স্ক্রিনের জন্য পরীক্ষামূলক কাজগুলি সর্বদা MVC ব্যবহার না করার জন্য নির্দিষ্ট করে।

সাক্ষাত্কারের সময়, একজন ব্যক্তি যিনি একই এক/দুটি স্ক্রীন সহ কয়েকটি পোষা প্রকল্প লিখেছেন তাকে VIPER সমস্যা সম্পর্কে জিজ্ঞাসা করা হয়। যদি তিনি এখনও তাদের সম্মুখীন না হন তবে তিনি কীভাবে সমস্যাগুলি সম্পর্কে জানতে পারেন?

লোকেরা প্রায়শই স্থাপত্যের প্রেক্ষাপটে পরীক্ষাযোগ্যতার সুবিধার কথা বলে, কিন্তু তারা কখনও লিখিত পরীক্ষা দেয়নি। এবং যদি তারা থাকে, তবে এটি শুধুমাত্র কিছু টিউটোরিয়ালের উপর ভিত্তি করে ছিল, শুধুমাত্র ইউনিট পরীক্ষার উপর ফোকাস করে একটি প্রকৃত অ্যাপ্লিকেশনের সাথে তাদের আবদ্ধ না করে।

তারা MVP স্কিমকে সহজ ভাষায় ব্যাখ্যা করতে পারে, কিন্তু ViewInput এবং ViewOutput এর মতো একই নামের প্রোটোকলের ক্ষেত্রে তারা প্রায়ই বিভ্রান্ত হয়ে পড়ে। গভীরভাবে, তারা ইতিমধ্যেই এই সমস্ত কিছুকে ওভারহেড হিসাবে দেখেছে 🙄🤯

উপসংহার: নিজের জন্য সমস্যা তৈরি করবেন না। MVC এর জন্য লজ্জিত হবেন না। যখন আপনার কন্ট্রোলার খুব বড় হয়ে যায়, বা আপনি অসুবিধার সম্মুখীন হন, তখন আপনি বুঝতে পারবেন নতুন পন্থা খোঁজার সময় এসেছে।

UI সরলতা

ফ্রন্ট-এন্ড ডেভেলপমেন্ট নতুনদের জন্য একটি ডোপামাইন স্বর্গ। আপনি কোড লিখুন এবং অবিলম্বে স্ক্রীনে ফলাফল দেখতে পাবেন — আপনার পুরষ্কার পাচ্ছেন 🍭। এটা নিঃসন্দেহে প্রেরণাদায়ক। যাইহোক, এই মুদ্রার একটি উল্টানো দিক আছে। নতুনরা প্রায়শই এখনই অত্যধিক জটিল UI তৈরি করার চেষ্টা করে।

অধিকন্তু, জটিল বৈশিষ্ট্যগুলি জটিল UI অনুসরণ করে। যদিও সুইফটইউআই আজ কাজটিকে সহজ করে তোলে, তবুও কেউ প্রকৃত অগ্রগতি না করে ঘণ্টা এবং বাঁশি যোগ করতে অনেক সময় ব্যয় করতে পারে।

আমি একটি কোর্সে iOS ডেভেলপমেন্ট শিখেছি যেখানে আমরা দল গঠন করেছি এবং একটি একক প্রকল্পে কাজ করেছি। আমার দলে, একজন লোক ডার্ক মোডের জন্য ফন্ট এবং রং বেছে নিয়ে আমাদের অ্যাপ ডেভেলপমেন্ট শুরু করার পরামর্শ দিয়েছেন।

সামগ্রিকভাবে, তিনি এটিতে পুরো কোর্সটি ব্যয় করেছেন এবং এটি লক্ষণীয় যে ফন্ট এবং রঙগুলি দুর্দান্ত হয়ে উঠেছে। যাইহোক, লোকটি সেই সমস্ত সময়ে প্রকৃত কোডের প্রায় শূন্য লাইন লিখেছিল।

নিঃসন্দেহে, আপনার অ্যাপ্লিকেশনটির সৌন্দর্য এবং কার্যকারিতা অত্যন্ত গুরুত্বপূর্ণ। অবশেষে, আপনাকে এই দিকটিতে সময় ব্যয় করতে হবে। সহজ কিছু দিয়ে শুরু করাই ভালো। একটি MVP (ন্যূনতম কার্যকর পণ্য) বিকাশ করুন, সবচেয়ে গুরুত্বপূর্ণ বৈশিষ্ট্যগুলিতে ফোকাস করুন এবং সেখান থেকে লঞ্চ করুন।

দ্য 80-20 নিয়ম এখানে প্রযোজ্য — অ্যাপ্লিকেশনের মৌলিকত্ব তৈরি করুন এবং তারপর অতিরিক্ত যোগ করুন। বিপরীত পন্থা জটিল সূক্ষ্মতার সাথে আঁকড়ে ধরার দিকে নিয়ে যাবে এবং ক্রমাগত একটি প্রধান কার্যকারিতা নিয়ে কাজ করবে যা ভাঙতে থাকে।

মোবাইল ডেভেলপমেন্টে নতুনদের জন্য, সময়ের আগেই জটিল সমাধান গ্রহণ করার ঝুঁকি রয়েছে। ফ্রন্ট-এন্ড বিকাশের চাক্ষুষ পুরষ্কারগুলি লোভনীয় হতে পারে, একটি সাধারণ MVP দিয়ে শুরু করা প্রায়শই বুদ্ধিমানের কাজ।

ঐতিহাসিক প্রবণতাগুলি পরামর্শ দেয় যে প্রকৃত চ্যালেঞ্জগুলির প্রতিক্রিয়া হিসাবে সমাধানগুলি বিকশিত হওয়া উচিত।

ভিত্তিগত নীতিগুলি বোঝা এবং বাস্তব-বিশ্বের সমস্যাগুলি উদ্ভূত হওয়ার সাথে সাথে সমাধান করা কার্যকর বিকাশের জন্য গুরুত্বপূর্ণ।

এছাড়াও এখানে প্রকাশিত