যখন কোনও ফ্রেমওয়ার্ক ব্যবহার না করা হয় [বন্ধ]

Question

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

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

কে যত্ন করে, তাই না? আমাদের কাঠামো আছে! "হাত দিয়ে এটি কীভাবে করা যায়" তা আমাদের জানতে হবে না! রাইট?

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

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

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

Comments

যখন এটির কাঠামোটি কোনও মাইক্রোসফ্ট মালিকানাধীন পণ্য নয় এবং আপনাকে একটি এমএসএসকিএল ডাটাবেসের সাথে সংযোগ স্থাপন করতে হবে।

— অ্যান্ড্রু কে এস

প্রত্যেকের "খুব বিশেষায়িত" হওয়ার বিষয়ে বিষয়টি বেশ হাস্যকর। আপনি x86 প্ল্যাটফর্মের জন্য এসেমব্লার কোড লিখতে পারেন? আপনি যদি তাই করতে পারেন তবে 8051 বলার জন্য আপনি কি একই করতে পারেন? এমনকি যদি আপনি উভয়ই করতে সক্ষম হন তবে প্রচুর পরিমাণে আপনি করতে পারবেন না। আজ এটি টিম ওয়ার্ক - আপনার কাজ করতে সক্ষম হওয়ার জন্য এবং অন্যদের সাথে সহযোগিতা করতে সক্ষম হওয়ার জন্য আপনার যতটা জানা দরকার। এটাই.

— kubal5003

যখন সেই কাঠামোটি পার্লে তৈরি হয়। স্ফীত / বদ্ধ ফ্রেমওয়ার্কগুলিও আমাকে প্রস্রাব করে। এমএসটিস্ট এর একটি উদাহরণ।

— চাকরী

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

— ক্রিস

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

— gbjbaanb

Answer 1

"ফ্রেমওয়ার্ক ব্যবহার করা কখন উপযুক্ত হবে তা নির্ধারণ করার জন্য একটি ভাল মেট্রিক থাকতে হবে।"

আসলে তা না. যদি কোনও প্রযুক্তির যথাযথ ব্যবহার নির্ধারণের জন্য ভাল মেট্রিক থাকে, তবে আপনি ভাষা, সম্পাদক এবং পদ্ধতিগুলির পবিত্র যুদ্ধ দেখতে পাবেন না।

যে গ্রুপগুলির সাথে আমি সবার সাথে কাজ করেছি তারা একই কাজ করে - ব্যয় এবং বেনিফিট সম্পর্কে অনুমান করুন, সর্বাধিক উত্পাদনশীল পথ বেছে নিন এবং আশা করি তারা সঠিক আছেন। এটি মারাত্মকভাবে বৈজ্ঞানিক নয় - একটি অংশ স্বীকৃতি, তিনটি অংশের অভিজ্ঞতা, এক অংশ বিপণনে সংবেদনশীলতা, এক অংশের চালক এবং পাঁচটি অংশের র‌্যাঙ্কের মতামত।

Comments

এগারো ভাগ? ও

— মিশেল আইরেস

@ মিশেল আইরেস এটি 11 এ যায়!

— 0 奇 说 আর্চ শু'

তিনি "শতাংশ" বলেননি, তাই না? ; ও)

— হেলটনবাইকার

Answer 2

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

একজন বিকাশকারী এবং জৈবিক প্রজাতির জন্য - খুব বেশি বিশেষজ্ঞ হওয়া প্রকৃতপক্ষে দীর্ঘমেয়াদে একটি সমস্যায় পরিণত হতে পারে। দীর্ঘমেয়াদে বেঁচে থাকার জন্য, একাধিক ক্ষেত্রে তার দক্ষতা বিকাশের প্রচেষ্টাটি যত্ন সহকারে ভারসাম্য বজায় রাখতে হবে।

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

Answer 3

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

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

Answer 4

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

আমি "লাইব্রেরি" সহ "ফ্রেমওয়ার্ক" সিনোমিক্যাল ব্যবহার করতে যাচ্ছি।

---

কাঠামো বাস্তবায়নের আগে অবশ্যই কয়েকটি বিষয় বিবেচনা করতে হবে, এখানে কয়েকটি সাধারণ উদাহরণ রয়েছে।

# 1। কাঠামো সময় এবং প্রচেষ্টা বাঁচাতে হবে?

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

ফ্রেমওয়ার্কগুলি নির্মিত হয়, ক) জটিল উপাদানগুলিতে একটি প্রোগ্রামার-বান্ধব ইন্টারফেস যুক্ত করুন বা খ) ইতিমধ্যে সুপরিচিত (বা প্রতিষ্ঠিত) উপাদানগুলিতে বিমূর্ততা যুক্ত করুন।

আধুনিক (বা কিছু ক্ষেত্রে প্রাক্তন) আসলে উন্নয়নের পথে যেতে পারে । এটি প্রযোজ্য বিশেষত যখন আপনি বা আপনার প্রোগ্রামিং টিম একটি নতুন কাঠামো বাস্তবায়ন করতে চলেছে, যেখানে তারা এর আগে কখনও কাজ করেনি।

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

# 2 আপনার আবেদনের স্কেল

বলা হয়ে থাকে যে "কিছু করার মতো মূল্য অতিরিক্ত করা উচিত" তবে সাধারণত এটি হয় না। আপনার আবেদনের বিন্দুটি যদি "আলু" মুদ্রণ করে তবে একটি সুপার-মাপের কাঠামো কার্যকর করার কোনও ভাল কারণ সম্ভবত নেই ।

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

অন্যদিকে যদি কোনও ফ্রেমওয়ার্ক ভিতরে (যেমন ডাটাবেস ফ্রেমওয়ার্কগুলি) প্রচুর নোংরা কাজ করে, তবে আপনি এটি ফ্রেমওয়ার্কটি কেবল "আংশিকভাবে" ব্যবহার করলেও এটি কার্যকর করা কার্যকর হতে পারে। একটি ভাল উপাখ্যানটি হ'ল আপনার নিজস্ব ADO.NET বা মঙ্গোডিবি-ড্রাইভার তৈরি করার চেষ্টা না করা , কেবল আপনাকে পুরো লাইব্রেরিটি ব্যবহার করার দরকার নেই বলে।

কখনও কখনও ফ্রেমওয়ার্কগুলি ওপেন-সোর্স আসে (এবং 'আপনি যা-কিছু করতে চান'-লাইসেন্স সহ)। এটি একটি নতুন সম্ভাবনা খুলে দেয় যেখানে কোনও প্রোগ্রামিং দল কেবল একটি কাঠামোর অংশ বেছে নিতে পারে।

এটি শেষ পর্যন্ত # 1 এবং # 3 প্রশ্নের সাথে আবার সম্পর্কযুক্ত।

# 3 প্রভাব।

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

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

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

কিছু ফ্রেমওয়ার্কগুলি খুব সংস্থান- ভারীও হতে পারে ।

এটি অবশ্যই পয়েন্ট # 1 এবং # 2 তে ফিরে বেঁধেছে।

---

এটি সমস্তই কেবলমাত্র "বিবেচনার বৃত্ত", এবং আপনার কোনও কাঠামো কার্যকর করা উচিত কিনা তা সিদ্ধান্ত নেওয়ার জন্য কোনও আসল বৈজ্ঞানিক পদ্ধতি নেই।

কর্পিন মার্চ এটি খুব ভাল সংক্ষিপ্তসার করেছে:

যে গ্রুপগুলির সাথে আমি সবার সাথে কাজ করেছি তারা একই কাজ করে - ব্যয় এবং বেনিফিট সম্পর্কে অনুমান করুন, সর্বাধিক উত্পাদনশীল পথ বেছে নিন এবং আশা করি তারা সঠিক আছেন। এটি মারাত্মকভাবে বৈজ্ঞানিক নয় - একটি অংশ স্বীকৃতি, তিনটি অংশের অভিজ্ঞতা, এক অংশ বিপণনে সংবেদনশীলতা, এক অংশের চালক এবং পাঁচটি অংশের র‌্যাঙ্কের মতামত।

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

সমস্ত কাঠামোর ব্যবহারের ক্ষেত্রে রয়েছে, এটি সঠিক উদ্দেশ্যে বাস্তবায়নের বিষয়।

Answer 5

অন্যান্য বিকাশকারীরা কি কাঠামোটি জানেন?

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

নতুন প্রোগ্রামারদের বেসিকগুলি না জানার বিষয়ে আপনার বক্তব্য সম্পর্কে, আপনি আমার চেয়ে অনেক বেশি মমতাশীল! হ্যাঁ, এটি লজ্জাজনক, তবে আমি কি অন্য কারও অদক্ষতা নিয়ে চিন্তায় সময় কাটাচ্ছি? Nup। (এই অনুমানের উপর ভিত্তি করে এই সম্প্রদায়ের এই নতুন সদস্যরা তাত্ক্ষণিকভাবে আপনার সাথে কাজ করছে না))

Answer 6

নিম্নলিখিত শর্তগুলি সত্য রাখলে আমি (এবং কেবলমাত্র যদি) একটি কাঠামো ব্যবহার করব:

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

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

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

Comments

শেষ অনুচ্ছেদে একটি অতি সাধারণ জাল রয়েছে: "কিছু লোক (...) সময় (...) এ নিতে পারে না This এই ভুল ম্যাচটি (...) সবার কাছে প্রচুর সময় এবং প্রচেষ্টা ব্যয় করে। " সুতরাং তাদের (এখন) হারানোর সময় নেই, এবং এ কারণেই তারা (অনেক পরে) অনেক বেশি (আরও) হারাতে

— পেরেছিল