ফ্রেমওয়ার্কগুলি কি খুব বেশি বিমূর্ততা রাখে? [বন্ধ]

Question

আমি এক বছরের কম সময়ের জন্য প্রোগ্রামিং করছি এবং কিছু অভিজ্ঞতা লেখার সিস্টেম অ্যাপ্লিকেশন, ওয়েব অ্যাপ্লিকেশন এবং ব্যবসায় / সংস্থার জন্য স্ক্রিপ্ট নিয়েছি। তবে, জাজানো, রেলস বা জেন্ডের মতো কাঠামোর সাথে কাজ করা আমি সত্যিই কখনও করি নি।

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

1. মডিউল / ফ্রেমওয়ার্কের পরিবর্তিত প্রকৃতির কারণে প্রোগ্রামগুলি সত্যই দ্রুত তারিখ তৈরি করে,

2. ফ্রেমওয়ার্ক এবং মডিউলগুলি উপলব্ধ এবং তাদের সমস্ত আইডিয়াসক্রাইজির আধিক্যগুলির কারণে কোডটি বোঝা শক্ত করে তোলে,

3. আপনি যদি সমস্ত ডকুমেন্টেশন না পড়ে থাকেন তবে কোডকে কম যুক্তিসঙ্গত করে তোলে; উদাহরণস্বরূপ, আমি কিছু তালিকার বোধগম্যতা এবং শর্তসাপেক্ষ যুক্তি দিয়ে পড়তে পারি এবং কোন প্রোগ্রামটি কী করছে তা নির্ধারণ করতে পারে, তবে যখন আপনি সুনির্দিষ্ট স্ট্রিং এবং অভিধানগুলি পাস করার প্রয়োজনীয়তাগুলি দেখেন, আপনি যদি ইতিমধ্যে গুরু না হন তবে বিষয়গুলি বুঝতে কিছুটা অসুবিধা হয় একটি প্রদত্ত মডিউল; এবং:

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

আমাদের কি সত্যিই কোনও মাইএসকিউএল কোয়েরির মতো সহজ জিনিসের উপরে অ্যাবস্ট্রাকশন এর 50 টি স্তর পছন্দ করা দরকার? পিএইচপি-র পিডিও ইন্টারফেসের মতো কিছু কেন ব্যবহার করবেন না, যেখানে প্রস্তুত বিবৃতি / ইনপুট পরীক্ষা পরিচালনা করা হয় তবে সর্বজনীনভাবে বোধগম্য এসকিউএল কোয়েরি এখনও ফাংশনের একটি অংশ?

এই বিমূর্ততা কি সত্যিই দরকারী? বৈশিষ্ট্য বিন্দুগুলি কী তাদের অকেজো করে তোলে, কাঠামো ব্যবহার না করে লিখিত অনুরূপ অ্যাপ্লিকেশনগুলির তুলনায় অ্যাপ্লিকেশনগুলিকে আরও কঠিন করে তোলে?

Comments

কীওয়ার্ডস: as a relatively inexperienced programmer- আপনি যতক্ষণ সফ্টওয়্যার তৈরি করেন তত বেশি আপনি চাকাটিকে পুনর্নির্মাণের জন্য কম সময় ব্যয় করতে এবং বাড়ীতে আপনার পছন্দসই কাজগুলিতে বেশি সময় ব্যয় করার প্রশংসা করবেন।

— সার্গের্গ

Do we really need to put like 50 layers of abstraction on top of something as simple as a MySQL query?- প্রথমত, একটি ভাল কাঠামো হ'ল বিমূর্তির একটি স্তর (অভ্যন্তরীণভাবে 2 বা 3) এবং দ্বিতীয়ত "মাইএসকিউএল কোয়েরির মতো সহজ কিছু" বাস্তবে একটি ভাল ডজন বিমূর্ততা জড়িত। এমনকি আপনি আপনার ব্যাখ্যা করা ভাষা থেকে কার্যকর হওয়া ক্যোয়ারীটি এটি ডেটাবেস সার্ভারে পরিণত করার পরেও, আপনি এখনও শারীরিক স্টোরেজ ওভার ফাইল সিস্টেমে ইঞ্জিনগুলির দ্বারা ডাটাবেসগুলির উপর প্রশ্ন থাকতে পারেন। সুতরাং সংক্ষেপে: হ্যাঁ, আমাদের বিমূর্ততা প্রয়োজন, কারণ তারা আমাদের মাথাটি বিস্ফোরিত হতে রাখে।

— back2dos

FWIW, হ্যাঁ, কখনও কখনও আমরা নদীর গভীরতানির্ণয়কে ছাড়িয়ে যাই। কাজটি করার জন্য আমি একটি কাঠামোটি যে পরিমাণ ব্যবহার করি তা আমার প্রাথমিকভাবে ভাবার চেয়ে কম হয়; কখনও কখনও আপনার নিজের কোড লেখার ফলে একটি সহজ নকশা, সমস্যার ডোমেনের আরও ঘনিষ্ঠ ফিট এবং আরও ভাল পারফরম্যান্স, লাইসেন্সিং মাথা ব্যথা ছাড়াই ফলাফল হয়।

— রবার্ট হার্ভে

সেখানে বেশ কয়েকটি মাইক্রো ফ্রেমওয়ার্ক রয়েছে। এগুলি হালকা ওজনের ফ্রেমওয়ার্ক যা কিছু লোক আরও আকর্ষণীয় মনে করে। যেমন: flask.pocoo.org । আমি কখনই ব্যবহার করিনি।

— আইপল

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

— ফিল

Answer 1

ফ্রেমওয়ার্ক সত্যই জটিল হতে পারে। সমস্যাগুলি খুব সহজেই উত্থিত হতে পারে যখন কোনও কাঠামো খুব বেশি "মতামতযুক্ত" হয়, অর্থাত্ যখন এটি সত্যই প্রয়োগের একটি নির্দিষ্ট শৈলী পছন্দ করে এবং সমস্ত অংশ এই নির্দিষ্ট শৈলীর সমর্থন করার দিকে তত্পর হয়।

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

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

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

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

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

---

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

এটি কারণ প্রযুক্তিগত বিমূর্ততা খুব কমই "ফুটো" হয়, অর্থাত পাইথনে অ্যাপ্লিকেশন লেখার সময় আপনাকে মেশিনের কোডটি খুব কমই ডিবাগ করতে হবে। ব্যবসায়ের নিয়ম বিমূর্তি একই প্রযুক্তিগত স্তরে কাজ করে যদিও এটি কেবল "কোড বান্ডিল"। আপনি সম্ভবত হবে কুকি সেট করা থাকে অথবা পাসওয়ার্ড হ্যাশ যে কিছু বিন্দু, যার মানে আপনি 3rd পার্টি কোড প্রচুর মাধ্যমে ডাইভিং হবেন এ তৈরি করা হয় ডিবাগ করা প্রয়োজন।

Comments

“আপনি যদি কুকিজ এবং প্রমাণীকরণ সিস্টেমগুলি বুঝতে না পারেন তবে বিমূর্ততা থেকে শুরু করা ভাল ধারণা নয় Y হ্যাঁ, তবে এটি নিজের দ্বারা স্ক্র্যাচ থেকে তৈরি করার চেয়ে সম্ভবত এটি এখনও আরও ভাল।

— শোভ

@ এসভিক দ্রুত? হ্যাঁ। উত্তম? এটি বিতর্কযোগ্য।

— লাঞ্চমিট317

@ লাঞ্চমিট317 আমার অর্থ হ'ল কেউ যদি জানেন না যে তিনি কী করছেন এবং একটি কাঠামো ব্যবহার করেন তবে তিনি সম্ভবত কিছু ভুল করবেন। তবে তিনি যদি সমস্ত কোড নিজের দ্বারা লিখে থাকেন তবে তিনি ভুল করার বিষয়ে প্রায় নিশ্চিত।

— সোভিক

সম্মত হন। "আপনি গ্রন্থাগারগুলি ব্যবহার করেন তবে ফ্রেমওয়ার্কগুলি আপনাকে ব্যবহার করে" একটি ভাল উদ্ধৃতি। আমাদের আরও পুনঃব্যবহারযোগ্য লাইব্রেরি এবং অনেক কম-ইন-ওয়ান ফ্রেমওয়ার্ক দরকার।

— gbjbaanb

@gbjbaanb খুব সম্মত হয়েছে বিশেষত যেহেতু সমস্ত কিচেন-সিঙ্ক ফ্রেমওয়ার্কগুলিতে খুব কমই কোডের মান থাকে have ব্রেস্ট-অফ-ব্রিড লাইব্রেরিগুলি প্রায়শই জেনেরিক কাঠামোর প্রয়োগের চেয়ে অনেক ভাল।

— প্রতারণা করুন

Answer 2

আমার কাছে মনে হচ্ছে আপনি বিমূর্ততা এবং কোড পুনঃব্যবহারের ভুল বোঝেন।

পুরো সফ্টওয়্যার ডেভলপমেন্ট ইন্ডাস্ট্রি অ্যাবস্ট্রাকশনগুলিতে নির্মিত। কেবল এগুলি ব্যবহার না করার কারণে, যেমন ফ্রেমওয়ার্ক, গ্রন্থাগারগুলি এবং সাধারণ কোড যা ঘরে বসে লেখা নেই, এড়ানো এড়ানো আপনার এক টুকরো সফটওয়্যার তৈরি করতে প্রয়োজনীয় ব্যয় একশ, হাজার, সম্ভবত আরও বেশি করে বাড়িয়ে তুলবে।

যেমন আপনি স্ক্র্যাচ থেকে একটি জাম্বো জেট তৈরি করেন না, অন্যান্য বিমান তৈরি করার সময় বছরের পর বছর ধরে বিকাশিত কোনও ইঞ্জিনিয়ারিং জ্ঞান ব্যবহার না করে, আপনি স্ক্র্যাচ থেকে ব্যবসায়িক সফ্টওয়্যার লিখেন না।

আপনি প্রথমে পিএইচপি বা রুবি ব্যবহার করে তা পেয়ে গেছেন, ইতিমধ্যে আপনার বিপুল পরিমাণ বিমূর্ততা রয়েছে, তাই না? সর্বাধিক সুস্পষ্ট:

1. অপারেটিং সিস্টেম, প্রোগ্রামিং ল্যাঙ্গুয়েজ এবং সংকলক এসেমব্লার এবং হার্ডওয়ারের উপর একটি বিশাল বিমূর্ততা সরবরাহ করে,

2. ওয়েব সার্ভার সকেট, ব্যর্থতা, এইচটিটিপি প্রোটোকল, ইত্যাদির বিমূর্ততা সরবরাহ করে,

3. এসকিউএল একটি স্থায়ী স্টোরেজ সহায়তাতে কীভাবে ডেটা সংরক্ষণ করা হয় এবং দ্রুত অ্যাক্সেসের জন্য মেমরিতে রাখে, এসিডি, মিররিং ইত্যাদি নিশ্চিত করে তার বিমূর্ততা সরবরাহ করে S

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

ফ্রেমওয়ার্কগুলি এর থেকে আলাদা নয়। তারা যা করে তা আপনি করতে পারেন। ঠিক এই যে আপনি সেই একই কাঠামোগুলি পুনরায় করা আপনার সময় নষ্ট করবেন, এই পার্থক্যের সাথে frame ফ্রেমওয়ার্কগুলি আরও ভাল করবে এবং খুব প্রায়ই তাদের কোডটি আপনার চেয়ে ভালভাবে পরীক্ষা করা ও ডকুমেন্টেড হবে।

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

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

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

আরেকটি বিষয় হ'ল আপনার কোডের পঠনযোগ্যতা। কল্পনা করুন আপনি একটি ই-বাণিজ্য ওয়েবসাইট তৈরি করেছেন। পরে, আপনি প্রকল্পটি রেখে গেছেন এবং অন্য বিকাশকারীকে এটি বজায় রাখা উচিত।

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

• যদি আপনার নিজের কার্ট থাকে তবে আপনার সহকর্মীকে কিছু কাস্টম কোড বজায় রাখতে হবে, কোথাও সহায়তা পেতে সক্ষম না হয়ে ডকুমেন্টেড এমনকি নয়।

একটি কাঠামো ব্যবহার করে, আপনি একটি কোড উপর নির্ভর করে যা হয়:

• অভিজ্ঞ বিকাশকারীদের দ্বারা লিখিত,

• প্রায়শই জুড়ি-পর্যালোচনা,

• ইউনিট-পরীক্ষা

• ব্যাপকভাবে নথিভুক্ত,

• কয়েক হাজার বিকাশকারী দ্বারা বছর ধরে ব্যবহৃত,

• প্রায়শই সমর্থিত, যাতে আপনি কোনও বাগ রিপোর্ট করতে পারেন এবং এটি বাস্তবে সংশোধন করতে পারেন,

• এমন অনেক বিকাশকারী দ্বারা পরিচিত যারা সম্ভাব্য সাবধানতা এবং সমস্যাগুলি জানেন এবং স্ট্যাক ওভারফ্লোয়ের মতো সাইটে সহায়তা করতে পারেন।

• আপনার জন্য এখনই বিনামূল্যে উপলব্ধ।

Comments

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

@ ম্যাটফেনউইক - আমার কাছে ওপি বলছে যে আপনি যদি এই ফ্রেমওয়ার্কগুলি একেবারে ব্যবহার করেন তবে বিমূর্ততা অনেক বেশি এগিয়ে গেছে এবং আরও সমস্যা তৈরি করে তবে সেগুলি মূল্যবান। অবশ্যই প্রশ্নটি খারাপ বিমূর্তি খারাপ না?

— জেফো

Answer 3

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

Answer 4

হুমম লেজারএসএমবির একটি দিক যা আমরা প্রচুর পরিমাণে কাজ করেছি তা হ'ল কাঠামোর প্রতি আমাদের দৃষ্টিভঙ্গি। যদিও এই ধরণের বিমূর্ততার সাথে দুটি মূল সমস্যা আসে। এইগুলো:

1. নির্ভরতা বিস্ফোরণ, এবং

2. ভুল বিমূর্ততা

প্রথমটি বিকল্পটির চেয়ে ভাল যা চাকাটি পুনরায় উদ্ভাবন করছে। দ্বিতীয়টি হ'ল একটি শক্ত লেবেল কারণ এটি একটি দুর্বল সংজ্ঞায়িত সমস্যা সমস্যা থেকে আসে বা প্রায়শই লোকেরা এর উদ্দেশ্যে ব্যবহারের বাইরে কিছু ব্যবহার করে।

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

একটি বড় সমস্যা অবশ্যই হ'ল কোডটি তত বেশি স্বয়ংক্রিয়ভাবে কোড হয়, বিশেষত যখন এটি অস্বচ্ছ হয় তখন কী ভুল হচ্ছে তা দেখতে ততই কঠিন। এটি ওআরএম সম্পর্কিত একটি বিষয় যা @ জুয়েলেট উপরে তোলে ( /software//a/190807/63722 দেখুন )।

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

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

শেষ পর্যন্ত "অত্যধিক" কিছুটা বিষয়ভিত্তিক, তবে একটি উদ্দেশ্য স্তরে এটি আপনি কী করছেন তার উপরও নির্ভর করে। যদি আপনি ফ্রেমওয়ার্কটি ঠিক এমনভাবে করা হয় যা ঠিকঠাকটি করার জন্য তৈরি করা হয়েছিল, তবে একটি সু-নকশাকৃত কাঠামো পুরোপুরি বিমূর্ততা সরবরাহ করবে। আপনি যদি এমন কোনও কিছু করছেন যা কোনও ফিটের তুলনায় খানিকটা কম, বিমূর্ততা খুব বেশি এবং খুব ফাঁস হয়ে যাবে।

Answer 5

হ্যাঁ, তারা দরকারী। এগুলি আপনাকে পরীক্ষা করার, অতিরিক্ত ব্যাগ সংশোধন করার এবং অতিরিক্ত সমস্যা সমাধানের সমাধান প্রদানের জন্য আপনার প্রয়োজনীয় সমস্যার সমাধানের জন্য প্রচুর অন্যান্য অভিজ্ঞ বিকাশকারীদের সুবিধা প্রদান করে এবং আপনার যে সমস্যাগুলি নিয়ে চিন্তা করতে হবে না তার সমাধান প্রদান করেছেন ফ্রেমওয়ার্ক ব্যবহার করে নিজেকে।

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

সমস্ত ফ্রেমওয়ার্কগুলিতে অবশ্যই একটি শেখার বক্রতা রয়েছে এবং এটি আপনার জন্য আরও বেশি কাজ সঞ্চার করে। যাইহোক, কাঠামোটি শিখার অর্থ আপনি সময় সাশ্রয় করেছেন এবং দ্বিতীয়বার আপনার স্ক্র্যাচ থেকে আপনার অ্যাপ্লিকেশনটি পুনরায় লেখার পরিবর্তে পরবর্তী প্রকল্পে সেই সমস্ত জ্ঞান অর্জন করতে পারবেন।

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

Answer 6

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

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

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

Answer 7

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

আমার পক্ষে, মুখ্য বিষয়টি হল যে আমাকে বিনিয়োগের প্রয়োজনের চেয়ে আমাকে কোনও সংস্থান থেকে আরও বেশি পেতে হবে। অথবা, অন্য একটি কোণ থেকে, আমি বলব যে যত তাড়াতাড়ি কোনও কাঠামোর প্রয়োজনীয়তা পুরষ্কারের চেয়ে বেশি পাওয়া যায়, সমস্ত সুবিধা অনুপস্থিত। সুতরাং এটি 'হ্যাঁ! অনুগ্রহ! এবং তোমাকে ধন্যবাদ!' যারা আমার নিজের এইচটিএমএল / সিএসএস / পিএইচপি এবং এসকিউএল এর মধ্যে প্রয়োজন হিসাবে সোজা হয়ে যায় এবং কাজ করবে তাদের সম্পত্তি তৈরি করুন।

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

Answer 8

কিছু লোক বলেছেন এটি হলিউডের ফ্রেমওয়ার্কের মূল নীতি : "আমাদের ডাকবেন না, আমরা আপনাকে ডাকব"। বিপরীতে, যখনই আপনি কোনও লাইব্রেরি ব্যবহার করেন, আপনার কোড লাইব্রেরিকে কল করে , অন্যভাবে নয়।

আপনি দেখতে পাচ্ছেন, গুরুত্বপূর্ণ বিষয়টি হ'ল নিয়ন্ত্রণে থাকা - যিনি নিয়ন্ত্রণের প্রবাহকে নিয়ন্ত্রণে রাখেন। কোন বিবৃতি কোনটির পরে চালিত হয় কে সিদ্ধান্ত নেয়?

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

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

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

আমি মনে করি না যে সিদ্ধান্ত নেওয়া বুদ্ধিমানের কাজ হবে এটি পূর্বের বা পরবর্তীকালের মতো হওয়া ভাল।

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

...

এবং আরও সুনির্দিষ্টভাবে, যদি আপনি জ্যাঙ্গোর মতো ফ্রেমওয়ার্ক পছন্দ না করেন তবে ফ্লাস্কের মতো "মাইক্রোফ্রেমওয়ার্কস" অনুসন্ধান করুন :)