প্রোটোটাইপ এবং একটি উত্পাদন স্তর সমাধানের মধ্যে পার্থক্য কী?


10

এই প্রশ্নটি নিখুঁতভাবে শেখার এবং আমার প্রযুক্তিগত বোঝার জন্য। আমি জানি যে কোনও নিখুঁত সমাধান নেই এবং এই প্রশ্নটি কখনই সমাধানের তালিকা শেষ করতে পারে না তবে আমি মনে করি যে প্রতিটি আর্কিটেক্টরের জন্য ডেমো এবং লাইভ প্রকল্পের মধ্যে পার্থক্য বোঝা খুব গুরুত্বপূর্ণ।

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

  1. ইউনিট প্রতিটি পদ্ধতি পরীক্ষা
  2. Coverage 100% কোড কভারেজ নিশ্চিত করা
  3. সমস্ত ব্যতিক্রম এবং সম্ভাব্য পয়েন্টকাটগুলি লগ করা - এওপি দিয়ে সম্ভব possible
  4. ইন্টারফেস ডিজাইন প্যাটার্ন, নির্ভরতা ইনজেকশন ব্যবহার করে সম্ভবত একটি ফ্রেমওয়ার্ক যেমন: স্প্রিংটনেট ব্যবহার করে
  5. যন্ত্রের জন্য পারফরম্যান্স কাউন্টার এবং প্রোফাইল ব্যবহার করে
  6. যথাযথ সুরক্ষা প্রয়োগ করা - যেমন উইন্ডোজ প্রমাণীকরণ (এটি যদি ক্লায়েন্টের প্রয়োজন হয় তবে)।
  7. প্রতিটি একক পদ্ধতিতে লেনদেন পরিচালনা
  8. সমাধানের নতুন স্থাপনার আগে ওয়েব অ্যাপ্লিকেশন ফাইলগুলির ব্যাক আপ

আর কি?

আমার প্রশ্নটি কার্যকরী / ডকুমেন্টেশনের পরিবর্তে প্রযুক্তিগত দিকের সাথে আরও সম্পর্কিত কারণ অন্যথায় আমরা অন্য পথে চলে যাব :-)

ধন্যবাদ.


5
দু: খজনক উত্তরটি "আপনার পরিচালক এটি দেখছেন" হবে।
পিটার টেলর

উত্তর:


11

আমি মনে করি যে সর্বাধিক গুরুত্বপূর্ণ পার্থক্যটি হ'ল একটি প্রোটোটাইপের উদ্দেশ্য:
১. কোনও সমস্যা একটি নির্দিষ্ট উপায়ে সমাধান করা যেতে পারে তা প্রমাণ করা বা
২. ক্লায়েন্ট / পরিচালনাকে পণ্যটি কেমন হবে এবং তার কেমন লাগবে তা অনুভব করুন 2.

যেখানে একটি লাইভ সিস্টেমের উদ্দেশ্য হ'ল:
১. একটি নির্দিষ্ট সমস্যা সমাধান করা / কোনও সমস্যা সমাধান করা।

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

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


2
মূল পয়েন্টটি পাওয়ার জন্য +1: প্রোটোটাইপগুলি ফেলে দেওয়ার জন্য তৈরি করা হয়। কোনও প্রোটোটাইপকে একটি প্রোডাকশন রিলিজে রূপান্তরিত করার চেষ্টা করা খুব সহজেই কোনও প্রকল্পের শুরু থেকেই ডুমকে দিতে পারে।
পিয়েটার টারিক

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

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

1
আমি দ্বিতীয় @ কিয়েরেন। প্রোটোটাইপটি কেন সম্ভাব্য উত্পাদনের অ্যাপ্লিকেশনটির একটি সঙ্কুচিত ও স্ট্রিপড সংস্করণ হিসাবে তৈরি করবেন না
প্রত্নতাত্ত্বিকভাবে

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

2

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

আমি বুঝতে পারি আপনি প্রযুক্তিগত দিকটি দেখছেন তবে আশা করি আপনি আমার বক্তব্যটি বুঝতে পারবেন, এটি অ প্রযুক্তিগত দিকের উপর নির্ভর করে পরিবর্তিত হয়। বা অন্তত এটা করা উচিত.

যন্ত্রের জন্য পারফরম্যান্স কাউন্টার এবং প্রোফাইলার ব্যবহার করা .. উপযুক্ত হতে পারে তবে ব্যাপকভাবে ওভারকিল হতে পারে। প্রয়োজন হতে পারে না।

আপনি এখানে যা অনুপস্থিত তা প্রকল্পের প্রসঙ্গ, সুযোগ এবং ব্যবসায়ের প্রয়োজনীয়তার জন্য অ্যাকাউন্টে ব্যর্থ হচ্ছে।

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

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

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


2

মজার বিষয় হল, আমি মনে করি 1, 2, 4 এবং 7 পয়েন্টগুলি ইতিমধ্যে আপনার প্রোটোটাইপ ধারণার সময় সম্পন্ন করা উচিত, ব্যতীত আমি মনে করি না যে প্রতিটি ক্লাসে আপনার প্রতিটি পদ্ধতি পরীক্ষা করা উচিত । সমালোচনা কোডটি পরীক্ষা করুন, পান / সেট পদ্ধতিগুলি সঠিকভাবে আচরণ করে কিনা তা নয়।

আপনার অ্যাপ্লিকেশনটির উদ্দেশ্য অনুসারে যেখানে সুরক্ষা একটি বড় সমস্যা, point দফার প্রোটোটাইপটিতে এটি অর্জনের জন্য আপনার পক্ষে যথেষ্ট সমালোচনা হতে পারে। আপনার অ্যাপ্লিকেশনটির উদ্দেশ্য অনুসারে, যেখানে কার্য সম্পাদনই মূল, পয়েন্ট 5 গুরুত্বপূর্ণ হতে পারে ... আপনি কী জানেন আমি কী বলতে চাইছি। আমার মতামতটি 3, 5, এবং 6 পয়েন্টগুলি প্রোটোটাইপগুলিতে সমালোচনামূলক হিসাবে বিবেচিত হলে প্রয়োজনীয় হতে পারে (8 নং উত্পাদন অ্যাপ্লিকেশনগুলির জন্য সত্যই বৈধ)

সম্পাদনা: দেখে মনে হচ্ছে আমার মতামত sJhonny এর থেকে সম্পূর্ণ পৃথক পৃথক কারণ আমি বোঝাচ্ছি যে আমি প্রোটোটাইপটিকে আপনার ভবিষ্যতের উন্নয়নের ভিত্তি / শেল / কঙ্কাল হিসাবে বিবেচনা করি, তাই আমার কাছে প্রোটোটাইপটি ফেলে দেওয়া উচিত নয়।


1

ইতিমধ্যে যা উল্লেখ করা হয়েছে তা ছাড়াও, একটি প্রোডাকশন প্রকল্পে আপনার নিম্নলিখিতগুলি (অন্যদের মধ্যে) প্রয়োজন

0-একটি বাস্তবায়ন পদ্ধতি চয়ন করুন

1-চূড়ান্তকরণ এবং প্রধান প্রয়োজনীয়তা প্রকাশ করুন (ব্যবহারের ক্ষেত্রে, ইত্যাদি সহ)

2-আর্কিটেকচারটি সঠিকভাবে পান

3-সঠিক সরঞ্জাম নির্বাচন করুন

পারফরম্যান্সের জন্য 4-ডিজাইন ডাটাবেস

5-আপনার শ্রেণি নকশা এবং কর্মপ্রবাহ নকশা উত্পাদন

6-ব্যাকড ডাটাবেস / ডেটা উত্স / ফিড একীকরণের কৌশল নির্ধারণ এবং বাস্তবায়ন করুন

7-সংজ্ঞা এবং সুরক্ষা প্রয়োজনীয়তা প্রয়োগ করুন

8-শারীরিক বাস্তবায়নের জন্য ব্যবস্থা করুন (সার্ভার, সংযোগ, লাইসেন্স ইত্যাদি)

9-স্টোরেজ প্রয়োজনীয়তা জন্য পরিকল্পনা এবং কর্মক্ষমতা ব্যবস্থা নির্ধারণ

10-সমস্ত শিল্পকলা উত্পাদন এবং উত্পাদন পরিবেশে ইনস্টল

11 টেস্ট

12-চূড়ান্ত সমাধান বিতরণ এবং প্রতিক্রিয়া প্রয়োগ


1

উত্পাদন মানের সমাধানগুলির সবচেয়ে গুরুত্বপূর্ণ বৈশিষ্ট্যটি - আমার মতে - দৃust়তা

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


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

0

প্রোটোটাইপ দুটি ধরণের রয়েছে:

  • দ্রুত এবং নোংরা "ধারণার প্রমাণ" অ্যাপ্লিকেশনগুলি "ক্লিন আপ" হয়ে যায় এবং উত্পাদন কোড হয়ে যায়। "ক্লিন আপ" পর্যায়টি হয় দুঃস্বপ্নের মতো হয়ে থাকে, বা এটি সত্যই "রাগের নীচে সমস্যাগুলি ঝাড়ু" করে, যার ফলে বিশাল প্রযুক্তিগত debtণ আসে।

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

আমি দ্বিতীয় ধরণের পছন্দ। তারা ফেলে দেওয়া হয়, কারণ সত্যই কোনও পছন্দ নেই।


0

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

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.