আধুনিক সফ্টওয়্যার বিকাশে ভাল কোড কি অসম্ভব? [বন্ধ]


19

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

আমার প্রশ্নটি নিম্নলিখিত: আমাদের আরও শক্তিশালী ভাষা এবং সরঞ্জাম রয়েছে বিবেচনা করে।

  • কেন ভাল কোড লেখা আরও কঠিন?
  • কারণ, সময় এবং জটিলতা কি এতে অবদান রাখে?
  • পদ্ধতিগুলি কি সঠিকভাবে অনুশীলন করা হয় না?

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

উত্তর:


34

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

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

কেন ভাল কোড লেখা শক্ত?

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

এটি কেবল উল্লেখের কারণ, সময় এবং জটিলতার কারণে?

হ্যাঁ, আমাদের সরঞ্জামগুলির শক্তি বৃদ্ধির সাথে সাথে অর্জনযোগ্য জটিলতা অবশ্যই বেড়েছে (এবং বাড়তে থাকে)। অন্য কথায়, আমরা সীমানা ঠেলাতে থাকি। আমার কাছে কোনটি অনুবাদ করে যাতে আজকের সর্বাধিক চ্যালেঞ্জগুলি সমাধান করা সমান শক্ত যেমন সেদিনের সবচেয়ে বড় চ্যালেঞ্জগুলি সমাধান করা 30 বছর আগে ছিল।

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

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

পদ্ধতিগুলি কি সঠিকভাবে অনুশীলন হয় না?

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


2
ব্যাকরণ নাজি বা অন্য কিছু হতে হবে না তবে 'অবাস্তববাদী' (দ্বিতীয় অনুচ্ছেদে) কোনও শব্দ নয়। আমি মনে করি আপনার অর্থ 'অবাস্তব'।

আমি কেবল "জুনিয়র" ইস্যুটি সমর্থন করতে পারি। আমি তাদের একজন এবং আমি অবশ্যই আমার সাহায্য করার জন্য একজন পরামর্শদাতা থাকতাম wish এটি ধন্যবাদ যে ইন্টারনেট আজ সেখানে আছে, এবং অ্যামাজন এবং এসও সহায়তা, তবে এখনও ...
ম্যাথিউ এম।

1
+1: এছাড়াও দ্রষ্টব্য, সরঞ্জাম / প্রযুক্তি / পদ্ধতিগুলিতে দ্রুত পরিবর্তন এবং বর্ধনের কারণে একটি নির্দিষ্ট পরিমাণে আমরা সমস্ত জুনিয়র বছরে কমপক্ষে কয়েকবার আছি। অভিজ্ঞতা কেবল কিছু vets কিছু jrs এর চেয়ে দ্রুত গতিতে পেতে দেয়।
স্টিভেন ইভার্স

আমরা এই প্রশ্নটিকে গুরুত্ব সহকারে নিতে অস্বীকার করব না যদি না আমাদের কাছে কুৎসিত থেকে সুন্দর কোড আলাদা করার কোনও আনুষ্ঠানিক বিধি নেই।
shabunc

17

অবাস্তব সময়সীমার অধীনে কোডিং এবং প্রযুক্তিগত debtণ নিয়ে কাজ করার বিষয়গুলি ওয়েইনবার্গ '71 এবং ব্রুকস'72২ থেকে জানা যায়। তার আগে সাহিত্যগুলি অনলাইন খনন করা শক্ত হয়ে যায়, তবে আমি নিশ্চিত যে পুরানো সিডিসি, আইবিএম, এবং নাসা রিপোর্টগুলি একই কথা বলেছে।


1
"প্রযুক্তিগত debtণ" এবং রেফারেন্সের জন্য।
আমির রেজায়ে

10

আমি মনে করি "গুড কোড" এর জন্য আমাদের সবার নিজস্ব ধারণা এবং থ্রেশহোল্ড রয়েছে। যাইহোক, বেশ কয়েকটি সমস্যা রয়েছে যা সমস্তই অবদান রাখে:

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

শেষ পর্যন্ত, আমি মনে করি "ভাল" বা "সেরা" অনুসরণ করার চেয়ে ভাল অনুসরণ করা ভাল । যদি আমরা ওখানকার সেরা কোডটি দেখে থাকি তবে আমরা কি এটির মতো স্বীকৃতি দেব?


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

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

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

8

কেন ভাল কোড লেখা শক্ত?

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


+1 খুব ভাল পয়েন্ট, নতুন সরঞ্জামগুলি উত্পাদনশীলতা বাড়ায় যা আরও জটিলতার দিকে নিয়ে যেতে পারে।
আমির রেজায়ে

1
+1 টি। এটি "লিকি বিমূর্তির আইন" নামেও পরিচিত। :)
ববি টেবিল 1

6

আধুনিক সফ্টওয়্যার বিকাশে ভাল কোড কি অসম্ভব?

আসলে এটি সম্ভব নয়। তবে আপনি ইতিমধ্যে শুনেছেন এমন কোনও কারণে নয়।

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

আমরা এটি করেছি, আমরা জটিলতার সমস্যাটি সমাধান করেছি, তবে এটি আমাদের আগে যে বৃহত্তর সমস্যা ছিল তা সরিয়ে দেয়নি।

এটি পরিচালনা করা এখনও আমাদের পক্ষে জটিল।

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

আমরা কখনই এটি করতে সক্ষম হব না।

এবং যদি আমরা না পারি তবে আমরা কখনই মানের কোড তৈরি করব না।

পরিচালকগণ মডিউলগুলির ছদ্মবেশ দেখতে পাবেন তবে মডিউলটির অভ্যন্তরীণ সমস্যা এবং সীমাবদ্ধতাগুলি জানতে পারবেন না।

মডিউল প্রোগ্রামাররা স্থানীয় সীমাবদ্ধতা জানবে তবে এটি কোনও বৃহত্তর চিত্রের প্রেক্ষাপটে অনুকূলিত করতে সক্ষম হবে না।

পরিচালক এবং প্রোগ্রামার (এবং এমনকি প্রোগ্রামারদের মধ্যে) এর মধ্যে বোঝাপড়া করার কোনও উপায় নেই। এবং সেখানে থাকলেও, মানুষের মস্তিষ্কের ক্ষমতা এটি পরিচালনা করতে পারে না।

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


আমি এই উত্তরটি পছন্দ করি, যদি কেবল এটি হতাশাবাদী,
মারাত্মক

1
@ টিমউই: আসলেই হতাশ নয় Not আপনার বোঝা থেকে মুক্তি দেওয়ার কথা ছিল। :)

4

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

আমি কোনও বিশেষ বিক্রেতাকে বেছে নিতে চাই না, তবে উইন্ডোজ 1.0 কে উইন্ডোজ 7 এর সাথে তুলনা করুন lat পরবর্তীটিতে হাজার হাজার গুণ বেশি কোড রয়েছে, তবে ক্র্যাশের মাঝামাঝি সময়টি একগুণ বেড়েছে। উইন্ডোজ ৩.১ থেকে আমাদের একটি ওয়ার্ড ডকুমেন্টে একটি এক্সেল স্প্রেডশিট এম্বেড করতে সক্ষম হবেন বলে মনে করা হয়েছিল, কিন্তু আজকাল এটি আসলে কমবেশি কাজ করে।

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


বিষয়টিকে ঘৃণা করার ঘৃণা, তবে ব্যক্তিগতভাবে আমি যুক্তি দেব যে উইন্ডোজ 1.0 থেকে 3.11 আসলে খুব স্থিতিশীল ছিল, সম্ভবত তাদের জটিলতার অভাবের কারণে। উইন্ডোজের ক্র্যাশতম সংস্করণগুলি ছিল 95, 98 এবং এমই। অবশ্যই, অন্যান্য সংস্করণগুলিতে কোন সংস্করণগুলি "ভাল" ছিল তা আলাদা বিষয়।
টিমভি

মিনি-কম্পিউটার বা মেইনফ্রেমে লো-পাওয়ার সিস্টেমগুলির পরিবর্তে কোডিং সম্পর্কে কী বলা যায়? আপনার উল্লেখ করা বিষয়গুলি ইন্টেল 8086 মডেলের সাথে সম্পর্কিত ...
পল নাথান

@ পল, ৮০৮৮ টি সমস্যা ছিল যার মধ্যে আমি সবচেয়ে বেশি জড়িত ছিলাম, তাই তারা মনে মনে বিশাল আকার ধারণ করেছে। তবে এমনকি মেইনফ্রেমে সফ্টওয়্যার লেখার সরঞ্জামগুলি আধুনিক মানের দ্বারা আশ্চর্যজনকভাবে অশোধিত ছিল। সম্পাদকরা সাধারণত ইমলকের তুলনায় এডলিনের খুব কাছাকাছি ছিল। 1982 সালের শেষের দিকে আমি আইবিএম হার্ডওয়্যারে নুরস (নেব্রাস্কা বিশ্ববিদ্যালয় রিমোট অপারেটিং সিস্টেম) ব্যবহার করছিলাম। কাজগুলি প্রোগ্রাম করা হয়েছিল এবং 'ভার্চুয়াল' পাঞ্চ কার্ড ব্যবহার করে চালানো হয়েছিল। এবং আসুন আমরা Y2K বাগগুলি ভুলে যাব না, যা বেশিরভাগ স্টোরেজে উপলব্ধিযোগ্য বাধা দ্বারা বড় লোহার উপরে উত্সাহিত।
চার্লস ই। গ্রান্ট

2

আধুনিক অ্যাপ্লিকেশন হয় আরো জটিল চেয়ে তারা 20-30 বছর পূর্বে ছিল, কারণ তাদের পরিবেশের সমৃদ্ধ এবং বহুমুখী বেশি।

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

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

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

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


+1 "আধুনিক অ্যাপ্লিকেশনগুলি 20-30 বছর আগের তুলনায় আরও জটিল"
আমির রেজায়ে

2

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

আমি মনে করি বিজ্ঞানের একটি প্রাচীন আইন মনে রাখা উচিত:

প্রকৃতি একটি শূন্যতা ঘৃণা করে।

ফ্রাঙ্কোইস রাবেলাস (ফরাসী সন্ন্যাসী এবং ব্যঙ্গাত্মক 1494-1553)


1

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

তাহলে আমরা কেন করব না?

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


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

টিমউই: আমি উদ্ভাবনের বিরুদ্ধে তর্ক করছি না। এটি কেবলমাত্র কারণ যা ভাল কোড লিখতে খুব কঠিন বলে মনে হচ্ছে।
ব্যবহারকারী 281377

1

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


এম্বেড থাকা সিস্টেমের ছেলেরা সমাবেশের একটি শালীন পরিমাণ লেখেন।
পল নাথান

@ পল নাথান সত্য
রোবটহুমানস

0

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

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

এগুলি সমস্ত অভ্যন্তরীণ (আমাদের নিজস্ব প্রত্যাশা) এবং আমাদের সংস্থাগুলির প্রত্যাশায় নেমে আসে। আমরা যতটা সম্ভব সংক্ষিপ্ত সময়ে যতটা সম্ভব সম্ভব করার চেষ্টা করি। এবং ত্রুটি অনিবার্যভাবে ফলাফল।

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


একটি তরুণ সংস্থার মতো মনে হচ্ছে যা এখনও

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

0

কীভাবে লোকেরা ভাল কোড তৈরিতে খারাপ হয়ে উঠেছে?

উদাহরণস্বরূপ, যদি আপনি নেট এবং সি # এর মতো ভাষা গ্রহণ করেন (এবং আমি বুঝতে পারি যে এটি একমাত্র প্ল্যাটফর্ম / ভাষা নয়) তবে আমি যুক্তি দেব যে ভিজ্যুয়াল স্টুডিওতে অনেকগুলি জিনিস অটোমেশনের কারণে কোডিং ভাল হয়ে যাওয়া অনেক বেশি সহজ হয়েছে I'd পরিবেশ।

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

প্রোগ্রামাররা এখন কেবলমাত্র বন্ধনী এবং ধনুর্বন্ধনী এবং নতুন লাইন টাইপ করতে এবং পদ্ধতি কল এবং শ্রেণীর নামগুলি মনে রাখার পরিবর্তে আসলে ভাল কাঠামো তৈরির দিকে মনোনিবেশ করতে পারে।

আমার দুই সেন্ট.


0

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


-2

কোডের মান আরও ভাল হয় নি

দয়া করে "ভাল কোড" এর ব্যাখ্যায় আটকে যাবেন না

দুর্দান্ত যৌক্তিক টাউটোলজি।

কোডটি ভাল হয় না কারণ লোকেরা "ভাল" এর সংজ্ঞাটি চালিয়ে যায়।

আপনি যদি "ভাল কোড" নিয়ে আলোচনা করতে পারেন, তবে আপনি তুলনা করতে পারবেন না এবং এটি "চ্যালেঞ্জ" কিনা তা আপনি সত্যিই সিদ্ধান্ত নিতে পারবেন না।


আমার জন্য "ভাল কোড" এমন যে এটি বাগের সংখ্যা হ্রাস করে। এখন যে বিভিন্ন উপায়ে সম্পন্ন করা যেতে পারে।
আমির রেজায়ে

@ আমির রেজায়ে: "" ভাল কোড "এর সংজ্ঞাটি স্বতন্ত্র"। "'ভাল কোড' এমনটি হ'ল এটি বাগের সংখ্যা হ্রাস করে" দয়া করে একটি মাত্র সংজ্ঞা বেছে নিন এবং কেবলমাত্র একটি সংজ্ঞা অন্তর্ভুক্ত করতে আপনার প্রশ্ন আপডেট করুন ।
এস .লট

আচ্ছা "'ভাল কোড' এমন যে এটি বাগের সংখ্যা হ্রাস করে" "" ভাল কোড "সম্পর্কে আমার ব্যক্তিগত ধারণা। আমি মনে করি প্রকল্পটি কখন পরিষ্কার করা উচিত বা না দরকার তা সবাই জানে ।
আমির রেজায়ে

@ আমির রেজায়ে: এটি আমার বক্তব্য। আপনি যদি প্রশ্নটিতে "ভাল" সংজ্ঞায়িত করতে (বা না) করতে পারেন, তবে আমরা তুলনা করতে পারি না। আপনি দাবি করতে পারেন যে বাগের সংখ্যা একই। অন্য কেউ দাবি করতে পারেন যে বাগের ব্যয় হ্রাস পেয়েছে। অন্য কেউ দাবি করতে পারে যে বাগের জন্য পরিকল্পনার কারণে ব্যবসায়ের ঝুঁকি বেড়ে যায়। "ভাল" এর একক সংজ্ঞা ব্যতীত আমরা সকলেই বিভিন্ন বিষয়ে কথা বলতে পারি। দয়া করে আপডেট প্রশ্ন।
এস .লট

ভাল কোড: এটি সংকলিত, পরীক্ষা পাস, ব্যবহারকারীর অনুমোদন পেয়েছে এবং উত্পাদনে রাখা হয়েছিল put শুধু আশা করি কেউ এটি পরিবর্তন করতে চায় না।
জেফো
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.