কিছু প্রোগ্রামাররা কেন ভাবেন যে তত্ত্ব এবং অনুশীলনের মধ্যে একটি বৈসাদৃশ্য রয়েছে? [বন্ধ]

Question

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

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

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

আমার অভিজ্ঞতা অনুসারে, আমি বলব যে একটি জটিল অ্যাপ্লিকেশন (10 তলা বিল্ডিং) বিকাশের জন্য আপনার যদি একটি 100-লাইনের স্ক্রিপ্ট (কুটির) একসাথে রাখার জন্য খুব বেশি তত্ত্বের প্রয়োজন হয় না তবে ভাল আপনার কাঠামোগত ডিজাইনের প্রয়োজন well - নির্ধারিত পদ্ধতি, একটি ভাল প্রোগ্রামিংয়ের ভাষা, ভাল পাঠ্য বই যেখানে আপনি অ্যালগরিদমগুলি দেখতে পারেন ইত্যাদি

সুতরাং আইএমও (সঠিক পরিমাণের) তত্ত্বটি জিনিসগুলি সম্পন্ন করার অন্যতম একটি সরঞ্জাম ।

আমার প্রশ্ন হ'ল কিছু প্রোগ্রামাররা কেন ভাবেন যে তত্ত্ব (আনুষ্ঠানিক পদ্ধতি) এবং অনুশীলনের (জিনিসগুলি সম্পন্ন করা) এর মধ্যে তফাত্ আছে?

সিভিল ইঞ্জিনিয়ারিং (বিল্ডিং হাউস) এর তুলনায় সফটওয়্যার ইঞ্জিনিয়ারিং (বিল্ডিং সফটওয়্যার) কি অনেকের দ্বারা সহজ হিসাবে বোঝা যায় ?

বা এই দুটি শাখা সত্যই আলাদা (মিশন-সমালোচনা সফ্টওয়্যার বাদে, সফ্টওয়্যার ব্যর্থতা বিল্ডিং ব্যর্থতার চেয়ে অনেক বেশি গ্রহণযোগ্য)?

---

আমি সংক্ষিপ্ত করার চেষ্টা করি, এখন পর্যন্ত উত্তরগুলি থেকে আমি কী বুঝতে পেরেছি।

1. সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের বিপরীতে, সিভিল ইঞ্জিনিয়ারিংয়ে এটি একটি নির্দিষ্ট কাজের জন্য কোন পরিমাণ তত্ত্ব (মডেলিং, ডিজাইন) প্রয়োজন তা অনেক পরিষ্কার।
2. এটি আংশিকভাবে সত্য যে সিভিল ইঞ্জিনিয়ারিং মানবজাতির মতোই পুরানো এবং এই কারণেই সফটওয়্যার ইঞ্জিনিয়ারিং কয়েক দশক ধরে রয়েছে।
3. আরেকটি কারণ হ'ল সফটওয়্যারটি একটি আরও অস্থির ধরণের প্রত্নসম্পদ, আরও নমনীয় প্রয়োজনীয়তা সহ (এটি ক্র্যাশ হতে পারে), বিভিন্ন বিপণনের কৌশল (দ্রুত নকশাকে বাজারে তাড়াতাড়ি তাড়াতাড়ি পেতে বলি দেওয়া যেতে পারে) ইত্যাদি etc.

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

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

Comments

না, 90% প্রোগ্রামার

— হ'ল

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

— নিরাপদ

তত্ত্বের মধ্যে তত্ত্ব এবং অনুশীলনের মধ্যে কোনও পার্থক্য নেই, তবে বাস্তবে এটি রয়েছে।

— জোরিস টিমারম্যানস

অ্যালোগ্রাথগুলি দেখার জন্য একটি ভাল বই? বেশিরভাগ সফ্টওয়্যার হ'ল সহজ সিআরইউডি যা কোনও অ্যালগরিদম কোর্স বা বইয়ের সাথে অন্তর্ভুক্ত থাকে তার কাছাকাছি ছাড়া।

— গিলস

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

— রোবট

Answer 1

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

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

Comments

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

— জর্জিও

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

— ব্লেশ

@blesh: আমি এটা মনে করি না। কড়া হার্ডওয়্যার সীমাবদ্ধভাবে ভাল এবং খারাপ ইঞ্জিনিয়ারিংকে সমানভাবে সীমাবদ্ধ করে।

— মাইকেল বর্গওয়ার্ট

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

— পল নাথান

ইউএমএল সম্পর্কে অবশ্যই কিছু "তাত্ত্বিক" আছে ... ... এর ইউটিলিটি!

— অস্পষ্টরবোট

Answer 2

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

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

Comments

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

— জর্জিও

তিন লাইনের হাস্কেল কোকোয়ার্স্ট? হুঁ ... এমন কি এমন ভাষায় কুইকসোর্ট বাস্তবায়ন করা সম্ভব যেখানে নকশার মাধ্যমে সবকিছু অপরিবর্তনীয়?

— ম্যাসন হুইলারের

: Google এর @MasonWheeler প্রথম ফলাফলের মধ্যে Haskell Quicksort ।

— খ্রিস্টিয়াকক

@ মেসন: রানটাইমটি এখনও ও (এন লগ এন)। এর জন্য ও (এন লগ এন) মেমরির দরকার হয়, কোনও স্থানের কুইকোর্টের বিপরীতে, যা পুনরাবৃত্তির জন্য কেবল ও (লগ এন) অতিরিক্ত মেমরির প্রয়োজন।

— কেভিন cline

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

— ফিলোসোডাড

Answer 3

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

প্রথাগত ইঞ্জিনিয়ারিংয়ে

• আপনি আপনার গণিত এবং বিজ্ঞান জানতে হবে কারণ আপনি যা কিছু করেন তার উপর ভিত্তি করে
• ক্ষেত্রের "বীরাঙ্গন" হ'ল এমন ব্যক্তিরা যারা নতুন জিনিস আবিষ্কার করেন, নতুন ধারণা আবিষ্কার করেন, অযোগ্য হিসাবে বিবেচিত সমস্যা সমাধান করেন

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

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

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

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

Comments

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

— গাই স্যারটন

@ গুয়াসিরটন "সিএস আপনাকে বলেছে যে প্রদত্ত প্রোগ্রাম নির্দিষ্ট ইনপুট দেওয়া বন্ধ হবে কিনা তা আপনি বলতে পারবেন না।" আপনারা যদি সিএসের

— মতই

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

— ফিলসোডাড

পঠনযোগ্যতা সম্পর্কে ক্র্যাক বাদে আমি আপনাকে একটি +1 দিই। রক্ষণাবেক্ষণযোগ্যতা সফ্টওয়্যারটির 80% ব্যয়ের তাই পাঠযোগ্যতা কোনও ছোট বিষয় নয়। তদ্ব্যতীত, যখন অ্যারোনটিকাল বা পারমাণবিক প্রকৌশলী এমন কিছু তৈরি করেন যা তৈরি করা হবে যা অন্য লোকেরা বুঝতে পারে তা গুরুত্বপূর্ণ। সামরিক, সরকার বা এমনকি বৃহত্তর প্রতিষ্ঠানগুলি এমন যাদু আবিষ্কারের সাথে সন্তুষ্ট নয় যা উদ্ভাবক ব্যতীত অন্য কারও দ্বারা প্রতিলিপি করা বা বোঝা যায় না।

— টমাস

@ থমাস - "সাব্পিয়ার মাইন্ডস" দ্বারা "পাঠযোগ্যতা" -এর পরিবর্তনে ব্যবহারযোগ্য সমাধানগুলি প্রায়শই বাতিল করা হয় বলে যে দৃ as় বক্তব্য রয়েছে তা অগত্যা বোঝাতে পারে না যে সমাধানগুলি যতটা হওয়া উচিত ততটা সুবচ্য নয়। আমি এটা ঘটতে দেখেছি। হেইল, আমি এটা করতে গিয়ে নিজেকে ধরে ফেলেছি।

— এরিক রেপেন

Answer 4

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

আমি নিরাপদে এবং সহজেই কোনও অ্যাপ্লিকেশন যুক্ত করতে পারি। আপনি 10 তলা বিল্ডিংয়ের নতুন তৃতীয় তলায় সহজে টস করতে পারবেন না (এটি 11 করে)। আমি চাইলে প্রতিদিন একটি নতুন বৈশিষ্ট্যে টস করতে পারি।

এখন, ভাল ডিজাইন প্রোগ্রামিং এ এই সব সহজ করে তোলে। তবে দুর্বল নকশা, এবং ঝুঁকিগুলি সহ এটি অসম্ভব নয় ... বগি সফ্টওয়্যার। সাধারণত মৃত্যু হয় না।

Comments

ওয়েল আপনি আশা করেন যে তারা মারা যাবেন না ... আপনার সফ্টওয়্যার এর উপর নির্ভর করে;)

— রিগ

@ রিগ, এজন্যই আমি 'সর্বাধিক' এবং 'সাধারণত' বলেছি। কিছু সফ্টওয়্যার অনেক বেশি সমালোচনামূলক।

— ক্যাফগীক

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

— ভুলটি

Answer 5

এই এক সাথে আমার সহ্য। আমার একটা কথা আছে

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

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

আমি সেই দরিদ্র, দুর্ভাগ্যাত্মক আত্মা হয়েছি এবং সম্ভবত আপনারা অনেকেই রয়েছেন। আমি আপনাকে সব অনুরোধ। সহজ উপায় গ্রহণ করবেন না! :)

Comments

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

— জর্জিও

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

— ক্যাফগীক

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

— ফিশব্যাসকেট গর্ডো

@ এফবিজি: উজ্জ্বলভাবে বলেছেন।

— কুবা ওবার

@ চাদ, ভাল পয়েন্ট। মার্টিন ফওলার মার্টিনফাউলারের উপর একটি অনুরূপ বিন্দু তৈরি করেছেন / বিলিকি / টেকনিক্যালডেবিটি এইচটিএমএল । কখনও কখনও এটি একটি উপযুক্ত বাণিজ্য।

— জন এম গ্যান্ট

Answer 6

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

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

সাধারণ ফ্যাক্টরটি ব্যয় হয়। একটি traditionalতিহ্যবাহী সিভিল ইঞ্জিনিয়ারিং প্রকল্পের নকশা ব্যয় হ্রাস করে (উভয় প্রকৃত, পদার্থের দিক দিয়ে এবং দায়বদ্ধতার ক্ষেত্রে সম্ভাবনা), যেখানে সফ্টওয়্যার বিকাশের একটি পয়েন্ট আসে যেখানে নকশার ব্যয় ফিরে আসা মানের বাইরেও বৃদ্ধি পায়।

Comments

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

— জর্জিও

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

— gman

দুঃখিত, আমাকে টাইপগুলি উল্লেখ করতে হবে: আমি মনে করি না সিভিল ইঞ্জিনিয়াররা কোনও অভিশাপ তৈরি করে। ;-)

— জর্জিও

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

— ইমোরি

@ রেক্সার কের: আপনি তার বিবৃতি অর্ধেকটা কেটে দিয়েছেন: "... যা প্রয়োজনীয় সুরক্ষা মানকে সন্তুষ্ট করে"

— লাই রিয়ান

Answer 7

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

Answer 8

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

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

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

Comments

সফটওয়্যার বিকাশে আরও অনেক অজানা অজানা - আপনি আকাশচুম্বী নির্মাণ শুরু করতে পারেন, কিন্তু ক্লায়েন্ট যখন এটিকে দেখবে তখন তারা আপনাকে বলে দেয় "আসলে আমি দশতলা বিশিষ্ট রুবিক্স কিউব চেয়েছিলাম"।

— টাক্রয়

@ ট্যাক্রয়: মজার ব্যাপার হল, একজন সিভিল ইঞ্জিনিয়ার সম্ভবত এটির খারাপ ক্লায়েন্ট হিসাবে বিবেচনা করবেন যারা আপনার সময় এবং সংস্থান নষ্ট করছেন, একজন সফ্টওয়্যার ইঞ্জিনিয়ার তাকে সন্তুষ্ট করার জন্য একটি নতুন পদ্ধতি বিকাশের চেষ্টা করবেন। :-)

— জর্জিও

@ জর্জিও, বা তদনুসারে বিল দিন ...

— ক্যাফজিক

Answer 9

পার্থক্যটি মূলত জানা প্রয়োজনীয়তার কারণে:

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

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

আমরা যথাসম্ভব এই জাতীয় জিনিসের জন্য গ্রন্থাগারগুলি ব্যবহার করি।

Comments

"তত্ত্বের বিষয়ে কথা বলার জন্য +1" এর অর্থ সাধারণত কম্পিউটার বিজ্ঞানের তত্ত্বের দিকটি বোঝায় "।

— জোশুয়া ড্রাক

Answer 10

আপনি যে সফ্টওয়্যারটি তৈরি করছেন তার উপর নির্ভর করে সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের বেশ কয়েকটি স্তর রয়েছে।

মহাকাশে মানবজাত শাটলগুলি নিয়ন্ত্রণ করতে নাসার সফ্টওয়্যার দরকার তাই স্বাভাবিকভাবেই রকেটের ছবি দেখানোর জন্য একটি ওয়েবসাইট তৈরির চেয়ে প্রকৌশল প্রক্রিয়ার স্তরটি আরও কঠোর।

আমার এক সহকর্মী যিনি নাসার হয়ে কাজ করেছিলেন তাদের সফ্টওয়্যার ইঞ্জিনিয়ারিং প্রক্রিয়াটি একক লাইনের কোডের লেখার ন্যায্যতা প্রমাণ করার জন্য শত শত পৃষ্ঠা ন্যায্যতা এবং কয়েক ঘন্টা বৈঠক হিসাবে বর্ণনা করেছিলেন!

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

এমনকি সিভিল ইঞ্জিনিয়াররাও জানেন যে তারা যে কোনও তত্ত্বকে কোনও ডিজাইনে রেখেছিল তা শেষ পর্যন্ত এটিকে ভেঙে দেবে তাই তাদেরও জরুরী পরিকল্পনা তৈরি করা দরকার।

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

সংক্ষেপে বলা যায়, Premature optimization is the root of all evil বা আমার বস হিসাবে সর্বদা বলতেনShipping is a feature!

Comments

"শিপিং একটি বৈশিষ্ট্য" এর জন্য +1! একবার আমি একটি অনুরূপ বাক্য শুনেছিলাম: "নিখুঁততার অস্তিত্ব নেই This এই সফ্টওয়্যারটির সুবিধা রয়েছে যে এটি বিদ্যমান" " অবশ্যই এটি কিছুটা রসিকতা। মিশন-সমালোচনামূলক সফ্টওয়্যার সম্পর্কিত: একটি অব্যাহত ব্যতিক্রম রকেট ক্র্যাশ করতে পারে।

— জর্জিও

this software has the advantage that it exists... আমি এখনও এটি শুনিনি তবে এটি আমার দুর্দান্ত সফ্টওয়্যার উদ্ধৃতিগুলির তালিকায় চলেছে। আমি এটি পছন্দ করি

— অ্যালবার্ট ল্যাং

@ জর্জিও: জেএসএফ এবং মিস্রা সি লিখেছেন যাতে কোনও ব্যতিক্রম না হয়। ব্যতিক্রম এবং রকেট মিশ্রিত হয় না।

— কোডার

Answer 11

এখানে অনেক ভাল উত্তর, তবে আমি মনে করি কম্পিউটার বিজ্ঞান এবং সিভিল ইঞ্জিনিয়ারিংয়ের মধ্যে তুলনা ত্রুটিযুক্ত।

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

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

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

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

Comments

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

— জর্জিও

অবশ্যই, তবে আপনার ব্রিজের প্রতিটি উপাদানগুলির জন্য আপনাকে একটি তরঙ্গ সমীকরণ উত্পন্ন করার দরকার নেই এবং তারপরে তারা কীভাবে ইন্টারঅ্যাক্ট করে তা ব্যাখ্যা করার দরকার নেই।

— অস্পষ্টরবোট

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

— জর্জিও

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

— অস্পষ্টরবোট

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

— জারসেন

Answer 12

সুতরাং আমার প্রশ্ন হ'ল কেন কিছু প্রোগ্রামাররা মনে করেন যে তত্ত্ব (আনুষ্ঠানিক পদ্ধতি) এবং অনুশীলনের (জিনিসগুলি সম্পন্ন করা) এর মধ্যে একটি বৈসাদৃশ্য রয়েছে?

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

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

সিভিল ইঞ্জিনিয়ারিং (বিল্ডিং হাউস) এর তুলনায় সফটওয়্যার ইঞ্জিনিয়ারিং (বিল্ডিং সফটওয়্যার) কি অনেকের দ্বারা সহজ হিসাবে বোঝা যায়?

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

বা এই দুটি শাখা সত্যই আলাদা (মিশন-সমালোচনা সফ্টওয়্যার বাদে, সফ্টওয়্যার ব্যর্থতা বিল্ডিং ব্যর্থতার চেয়ে অনেক বেশি গ্রহণযোগ্য)?

আমি ইতিমধ্যে বলেছি যে কারণে ট্র্যাডিশনাল ইঞ্জিনিয়ারিং এবং সফটওয়্যার ইঞ্জিনিয়ারিং খুব আলাদা।

Answer 13

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

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

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

Comments

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

— জর্জিও

Answer 14

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

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

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

Answer 15

আমার কাছেও এটি একই রকম মনে হচ্ছে। আপনি স্ট্যান্ডার্ড স্ট্রোক কংক্রিট, স্ট্যান্ডার্ড স্টিলের বাইরে একটি বড় বিল্ডিং তৈরি করেন। আপনি স্ট্যান্ডার্ড লাইব্রেরির বাইরে একটি বড় অ্যাপ তৈরি করেছেন।

আপনি চেষ্টা করবেন না এবং গাণিতিকভাবে আনুষ্ঠানিকভাবে একটি বড় অ্যাপ্লিকেশনটিকে ঠিক একই পদ্ধতিতে প্রমাণ করতে পারবেন না যেমন আপনি 100 তলা বিল্ডিংয়ের জন্য তরঙ্গসংশোধন চেষ্টা করে এবং লেখেন না

Comments

সুতরাং 100 তলা বিল্ডিংয়ের একটি সীমাবদ্ধ উপাদান বিশ্লেষণের সমতুল্য সফ্টওয়্যারটি কী? তাপ / ক্রাশে কতটি উঁচু ভবনের বাগ রয়েছে? :-)

— গাই স্যারটন

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

— মার্টিন বেকেট

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

— গাই স্যারটন

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

— মার্টিন বেকেট

@ মার্টিনবকেট এবং অভিকর্ষণের সহগ ঘন্টা থেকে ঘন্টার পর ঘন্টা এলোমেলোভাবে পরিবর্তিত হয় ... যেমন যখন আপনার সিস্টেম অ্যাডমিন এলোমেলোভাবে কাউকে না বলে কোনও সার্ভার আপগ্রেড করার সিদ্ধান্ত নেয় কারণ "এটি স্বচ্ছ হবে"।

— ক্যাফগিকে

Answer 16

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

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

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

কোনও যুক্তি নেই - এমন প্রকল্প রয়েছে যা 17 টি সফ্টওয়্যার আর্কিটেক্টের একটি কমিটি দিয়ে শুরু করা দরকার। সত্যিকার অর্থে তারা 20 ক্যারেট হীরার মতো প্রায় বিরল।

Answer 17

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

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

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

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

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

Comments

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

— অস্পষ্টরবোট

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

— জর্জিও

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

— জারসেন

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

— জারসেন

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

— জর্জিও

Answer 18

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

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

Answer 19

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

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

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

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

Answer 20

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

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

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

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

শেষ পর্যন্ত, এটি রাজনীতি এবং ব্যক্তিগত অখণ্ডতার একটি বড় গণ্ডগোল যা বিশ্বের 75% প্রোগ্রামারদের পেট থাকে না। আমি নিজে সবেই এটি দাঁড়াতে পারি।

Answer 21

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

দু'টিকে উপমা হিসাবে তুলনা করার চেষ্টা করার সমস্যাটি আমি মনে করি, প্রোগ্রামিং এমন একটি মডেলিং প্রক্রিয়া যা আপনার ইচ্ছামত বিমূর্ত বা কংক্রিটের সাথে দৃ bound়ভাবে আবদ্ধ হতে পারে।

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

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

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

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

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

Answer 22

গ্লেন ভ্যান্ডারবার্গ সফটওয়্যার ইঞ্জিনিয়ারিং এবং আরও প্রচলিত ইঞ্জিনিয়ারিং শাখার মধ্যে পার্থক্য সম্পর্কে দুর্দান্ত ধারণা উপস্থাপন করেছেন: http://www.youtube.com/watch?v=NP9AIUT9nos

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

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

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