ক্রমাগত সংশোধন করার প্রয়োজন হয় না এমন সফ্টওয়্যার লিখতে কি সম্ভব?


23

আমি অনেকগুলি বিভিন্ন ভাষায় প্রচুর সফ্টওয়্যার লিখেছি এবং আমি ভেরিলোগ এবং ভিএইচডিএল ব্যবহার করে এফপিজিএগুলিতে ব্যবহারের জন্য হার্ডওয়্যারটি "লিখিত" করেছি।

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

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

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

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


8
আপনি ওসিপি
ওদেড

এই উন্মুক্ত নীতিগত জিনিসগুলি দুর্দান্ত দেখাচ্ছে! কেউ কি সফলভাবে এটি ব্যবহার করেছে?
নাথান ফারিংটন

2
@ নাথানফারিংটন: বেশিরভাগ ডিজাইনের ধরণগুলি ( জিওএফ দ্বারা বর্ণিত ) ওসিপি অনুসরণ করে। একটি উদাহরণ টেম্পলেট পদ্ধতি প্যাটার্ন হবে
Spoike

2
@ নাথানফ্যারিংটন ওপেন-ক্লোজড নীতিটি সফ্টওয়্যার ডিজাইন করার সময় সফটওয়্যার বিকাশকারীদের দ্বারা ব্যবহৃত একটি সাধারণ নীতি।
জেস্পার

1
আমি কল্পনা করব যে আমরা আজ যে প্রোগ্রামগুলি ব্যবহার করি সেগুলি বিট এবং টুকরো ব্যবহার করে তৈরি করা হয় যা 20 বছর আগে লিখিত কোডে কার্বন অনুলিপি ছিল।
ম্যাল্লো

উত্তর:


16

হার্ডওয়ারের মতো ভাল সংজ্ঞায়িত ইন্টারফেস এবং পরীক্ষার সাথে এর কিছু থাকতে পারে?

ঠিক আমার চিন্তা!

পরিষ্কার ইন্টারফেসের সাথে সু-নকশিত মডিউলগুলি মূলত নিখুঁত হতে থাকে। Stringজাভা শ্রেণীর মতো কিছু চিন্তা করুন । এটি একটি কম্পিউটার প্রোগ্রাম, তবে এটিতে একটি স্ফটিক-স্বচ্ছ ইন্টারফেস রয়েছে। এটিতে কোনও ত্রুটি নেই। এটি যা করার কথা বলেছে তা নিখুঁতভাবে করে। অবশ্যই, এটি গত 15 বছরে ব্যাপকভাবে পরীক্ষা করা হয়েছে এবং যেহেতু কার্যত সমস্ত প্রোগ্রামগুলি Stringবেসিক বিল্ডিং ব্লক হিসাবে ব্যবহার করে , এতে কোনও ত্রুটি দ্রুত লক্ষ করা যায়। যে কোনও "quirks" - কঠোরভাবে বাগ নয়, তবে সচেতন হওয়ার যোগ্য ডিজাইনের বিশদগুলি - যেমন এখানে বর্ণিত http://www.jwz.org/doc/java.html এখনই সুপরিচিত, এবং সুতরাং এটি গ্রহণ করা যেতে পারে অ্যাকাউন্ট।

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

এমন কি কোনও ভাল সফ্টওয়্যার বিকাশ পদ্ধতি রয়েছে যা সর্বদা অগ্রগতি করার অনুমতি দেয় এবং বিদ্যমান কোডটি পুনরায় লেখার প্রয়োজন এবং নতুন বাগগুলি প্রবর্তন না করেই নতুন কার্যকারিতা যুক্ত করার অনুমতি দেয়?

কোনও রূপালী বুলেট সম্ভবত নয়, তবে সীমাবদ্ধ নয় তবে সেরা অনুশীলনের একটি ভাল সংমিশ্রণ:

  • সাধারণ, স্বায়ত্তশাসিত মডিউল। অন্য কথায়, কম সংযোগ এবং উচ্চ সংহতি।
  • অপরিবর্তনীয়তা। ক্রমবর্ধমান সম্মতি সঙ্গে বিশেষত গুরুত্বপূর্ণ।

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


1
jwz পুরোপুরি একমত নয় যে স্ট্রিং ক্লাসটি বাগফ্রি - jwz.org/doc/java.html

1
এটি নকশাযুক্ত হিসাবে কাজ করতে পারে, সুতরাং অন্তর্নিহিত নকশাটি ভাঙ্গা থাকলে প্রশ্ন is তবে আমি একমত যে স্ট্রিং একটি খুব নির্ভরযোগ্য শ্রেণি।

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

1
@ জুনাসপুল্ক্কা: হ্যাঁ, যদি সফ্টওয়্যারটির এক-লাইন সংক্ষিপ্তসার থাকে তবে এটি "সর্বদা অন্য বাগ রয়েছে" হতে পারে। :-) এবং আমি মনে করি এটি নাথানের একটি বিষয়।
রস প্যাটারসন

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

9

পার্থক্যটি হার্ডওয়্যারের তুলনায় সফটওয়্যারটি পরিবর্তন করা ঠিক কতটা সহজ এবং সস্তা। হার্ডওয়্যারটি যদি গ্রাহকদের কাছে পরিবর্ধন ও শিপিংয়ের মতো সহজ এবং সস্তা ছিল তবে তারা করবে।

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

আপনার অবশ্যই পরীক্ষা -চালিত বিকাশ পরীক্ষা করা উচিত ।


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

1
@ নাথানফারিংটন: আমি বিশ্বাস করি যে হার্ডওয়্যার / সফ্টওয়্যার স্পেসিফিকেশন এবং ডিজাইন কীভাবে তৈরি করা হয় তার মধ্যে একটি বিশাল পার্থক্য রয়েছে। বেশিরভাগ হার্ডওয়্যার নির্মাতাদের কাছে এমন সফ্টওয়্যার বিকাশকারী যাঁর ক্লায়েন্ট কেবল "এটি করতে পারে এমন একটি প্রোগ্রাম চাই!" এটি নতুন বৈশিষ্ট্যগুলি পাওয়ার কী গ্যারান্টিযুক্ত এবং কী না।
আরসিই

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

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

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

6

আমি এই মন্তব্যগুলির উত্তর পেয়েছি আশা করি, আপনার কয়েকটি মন্তব্যে মন্তব্য করব।

সফ্টওয়্যার নিয়ে আমার অন্যতম প্রধান হতাশা এটি কখনও "সম্পন্ন" হয় না।

এটি কারণ সমাধানের নির্দিষ্টকরণ অসম্পূর্ণ বা বর্ধিতকরণ সরবরাহ করার পরিকল্পনাটি সঠিক নয়। এটি কোনও প্রকল্প সফ্টওয়্যার, হার্ডওয়্যার বা অন্য কোনও ক্ষেত্রে ঘটতে পারে।

এমন কি কোনও ভাল সফ্টওয়্যার বিকাশ পদ্ধতি রয়েছে যা সর্বদা অগ্রগতি করার অনুমতি দেয় এবং বিদ্যমান কোডটি পুনরায় লেখার প্রয়োজন এবং নতুন বাগগুলি প্রবর্তন না করেই নতুন কার্যকারিতা যুক্ত করার অনুমতি দেয়?

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

"কীভাবে বাগ কোডটি কোডিংয়ের সাথে পরিচয় না করে এবং সর্বদা অগ্রগতি না করে আমি আরও মজা লেখার সফটওয়্যার পেতে পারি?"

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

2-আপনার ব্যবহারকারীকে এই দীর্ঘমেয়াদী দর্শন বোঝার জন্য করুন।

3-পরিকল্পনা বাস্তবায়ন সাবধানতার সাথে

4-কোড আগে ডিজাইন।

5-উপযুক্ত হলে জেনেরিক ডিজাইন ব্যবহার করুন।

6-নকশা নিশ্চিতকরণ সরঞ্জাম হিসাবে প্রোটোটাইপগুলি ব্যবহার করুন।


এগুলি সমস্ত পরামর্শের টুকরো টুকরো। এ পর্যন্ত আমার চিন্তাভাবনার সংক্ষিপ্তসার হিসাবে: (1) রিলিজগুলি একটি বড় ডিল করুন এবং রিলিজের আগে প্রচুর টেস্টিং করুন এবং কিউএ করুন, (২) মডিউলগুলি একটি বিগ ডিল করুন এবং নিশ্চিত করুন যে পরীক্ষাগুলির সাথে তাদের ভাল-সংজ্ঞায়িত ডকুমেন্টেড ইন্টারফেস রয়েছে make ইন্টারফেসগুলি এবং ইন্টারফেসটি লঙ্ঘিত হয়েছে কিনা তা দেখার জন্য এবং মডিউলটি একবার "মুক্তি" দেওয়া হলে তা কখনই সংশোধিত হয় না (ওসিপি)।
নাথান ফারিংটন

4

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

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

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

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

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


আমি কৌতূহলী, আপনি লেখেন যে পরীক্ষাটি গুরুত্বপূর্ণ তবে মন-মাতালও।
নাথান ফারিংটন

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

3

সফ্টওয়্যার নিয়ে আমার অন্যতম প্রধান হতাশা এটি কখনও "সম্পন্ন" হয় না। যুক্ত করার জন্য আরও একটি বৈশিষ্ট্য রয়েছে।

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

বিন্দু সফ্টওয়্যার বৈশিষ্ট্য যুক্ত করতে সক্ষম হতে হয়। প্রথমে "সফ্টওয়্যার" আবিষ্কারের পুরো কারণটি ছিল যাতে আমরা বৈশিষ্ট্যগুলি যুক্ত করতে পারি।

প্রায়শই কোনও বৈশিষ্ট্য যুক্ত করার সময় এটি অন্য কোথাও বাগের পরিচয় দেয় যা ঠিক আগে কাজ করছিল working

এটি কিউএ সমস্যা।

ইন্টারফেসগুলি লঙ্ঘিত না হওয়া পর্যন্ত এটি হার্ডওয়ারে ঘটবে না।

এটি সফ্টওয়্যার ক্ষেত্রেও সত্য।

এমন কি কোনও ভাল সফ্টওয়্যার বিকাশ পদ্ধতি রয়েছে যা সর্বদা অগ্রগতি করার অনুমতি দেয় এবং বিদ্যমান কোডটি পুনরায় লেখার প্রয়োজন এবং নতুন বাগগুলি প্রবর্তন না করেই নতুন কার্যকারিতা যুক্ত করার অনুমতি দেয়?

হ্যাঁ। আপনাকে আসলে গুণগত নিশ্চয়তার অনুশীলন করতে হবে।


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

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

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

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

আমরা অবশ্যই প্রসঙ্গ বন্ধ করছি। এই লিঙ্ক অনুসারে , টিউরিং এর কলসাস ইউনিভার্সাল ছিল না (কম্পিউটিং অর্থে) এবং সঞ্চিত প্রোগ্রামগুলি (সফ্টওয়্যার) ব্যবহার করেনি।
নাথান ফারিংটন

2

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

আমি আপনাকে ডিজাইন এবং সফ্টওয়্যারটির যথার্থতা যাচাই করার জন্য " আনুষ্ঠানিক পদ্ধতিগুলি " সন্ধান করার পরামর্শ দিচ্ছি । আপনি হার্ডওয়্যার ডিজাইনের জন্য যে সিমুলেটর সরঞ্জামগুলি ব্যবহার করেন সেগুলি কিছু ঘনিষ্ঠ করার চেষ্টা করা হচ্ছে। আমি বিশ্বাস করি না যে আনুষ্ঠানিক পদ্ধতির সরঞ্জামগুলি এই সময়ে শিল্পে কার্যকর হওয়ার কাছাকাছি যে কোনও জায়গায় এবং ত্রুটিমুক্ত থাকার জন্য দৃ industries ় প্রেরণা পাওয়া একমাত্র শিল্পগুলি হ'ল এভিনিওকস এবং মেডিসিন (আকর্ষণীয়ভাবে যথেষ্ট, এফডিএ পরিষ্কারভাবে বলেছে "সফ্টওয়্যার আলাদা হার্ডওয়ার থেকে "সেই লিঙ্কটিতে)। তদ্ব্যতীত, আপনি যদি ভেরিলোগ / ভিএইচডিএল দ্বারা বিকাশ করছেন তবে আপনি বাইনারি যুক্তি দিয়ে স্টিক করছেন। এটি মারাত্মক জটিলতা হ্রাস করে। Y2K ইস্যুটির সমতুল্য কোনও হার্ডওয়্যার হতে পারে না।

বড় সমস্যা হ'ল বিষয়গুলি জটিল। এবং আপনি জটিলতা দূর করতে পারবেন না, আপনি কেবল এটিকে ঘুরিয়ে নিতে পারেন।


1

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

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

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

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

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

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

একটি শেষ পয়েন্ট: সফ্টওয়্যারটির হার্ডওয়্যার, এমনকি প্রোগ্রামড হার্ডওয়্যার থেকে আলাদা আর্থিক মডেল রয়েছে। বেশিরভাগ অ-গ্রাহক সফ্টওয়্যার এবং কিছু গ্রাহক সফ্টওয়্যারও এমনভাবে বিক্রি হয় যা পরিবর্তনের জন্য উত্সাহ দেয়। আপনি যখন কোনও ব্যবসায়কে বলতে পারেন "এখন আমাদেরকে 10,000 ডলার এখন একত্রে 18% প্রদান করুন", আপনি প্রতি কয়েক বছর পরে মূলত পণ্যটি পুনরায় বিক্রয় করতে পারেন। তবে এই ফিটিকে ন্যায়সঙ্গত করার জন্য আপনার গ্রাহককে তাদের যে পরিবর্তনগুলি চান তা দেওয়া দরকার। হুম ... অ্যাপলের হার্ডওয়্যার-অপ্রচলিত বক্ররেখার কথা ভাবা, সম্ভবত এটি পরে কোনও পার্থক্য নয় - হার্ডওয়্যার আপনাকে সত্যিকার অর্থে এটি আবার কিনে দেয়!


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

0

ওয়ার্কিং কোডে বাগগুলি প্রবর্তন না করে এবং সর্বদা অগ্রগতি না করে কীভাবে আমি আরও মজাদার সফটওয়্যার উপভোগ করতে পারি?

আমি আপনার প্রশ্নের চূড়ান্ত উত্তর খুঁজে পেতে চাই। তবে বাস্তবতাটি হ'ল এটি করার সহজ কোনও উপায় নেই, চরম প্রোগ্রামিং এবং টিডিডি প্রযুক্তিগুলি কেন এত জনপ্রিয় হয়ে উঠছে তা নিশ্চিত। আপনি পরিবর্তন আলিঙ্গন করা প্রয়োজন, কারণ ঘটতে চলেছে। আমি জানি না এটি এর মজাদার যদি এইরকম হয় তবে নিশ্চিতভাবে অনেক কম চাপের ;-)

http://en.wikipedia.org/wiki/Extreme_Programming

আপনি যখন হার্ডওয়ারের সাথে ইন্টারঅ্যাক্ট করেন, তখন হার্ডওয়্যারটির x মান প্রয়োজন এবং এটি সকলের (তত্ত্ব অনুসারে) থাকে তবে আজ আপনি যখন মানুষের সাথে আলাপ করেন তখন তাদের x দরকার হয়, এবং আগামীকাল তাদের y প্রয়োজন হতে পারে It । কারণ ব্যক্তি! = মেশিন, তাই কোড যে বেশিরভাগ সময় কখনও পরিবর্তন করা সম্ভব নয়।

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


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

আমি যেমন সবসময় বলি, সেরা কোডটি কোনও কোড নয়। :-)
এইচ

0

সফটওয়্যারটি কি একইভাবে লেখা সম্ভব?

হ্যাঁ, তাই আপনি যেমন হার্ডওয়্যার বিকাশ করছেন ঠিক তেমন সাবধান হন, যা কিছু আপনি পারেন পরীক্ষা করুন এবং আপনার সফ্টওয়্যারটি একই মানের হবে।

যাইহোক, আপনি কি এইচডাব্লু বাগগুলি শুনেছেন? এরপরেও খুব সহজেই কোনও এসডাব্লু বাগ এবং এটি ঠিক করা কঠিন (কেবলমাত্র সফ্টওয়্যার আপগ্রেড নয়)


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

1
@ নাথানফারিংটন সফ্টওয়্যারটি সাধারণত এইচডব্লিউ বেশি জটিল হয়। এইচডাব্লু আরও ভাল পরীক্ষা করা হয়। এসডাব্লু সহজ পরিবর্তন করতে পারে, তাই লোকেরা ততটা মনোযোগ দেবে না।
BЈовић

0

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

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


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

-1

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

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