কোডের মালিকানা কি কোডের গন্ধ?


27

বিতর্কিত প্রোগ্রামিং মতামত থ্রেডে আমি এই উত্তরটি পড়ার পর থেকেই এটি নিয়ে আমি ভাবছিলাম :

আপনার কাজ নিজেকে কাজ থেকে দূরে রাখা হয়।

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

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

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

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

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

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

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

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

সুতরাং এক অর্থে, আমি প্রকৃতপক্ষে মনে করি যে যদি উচ্চ স্তরের কোডের মালিকানা প্রয়োজনের জন্য একটি কাজের গন্ধ হিসাবে প্রকাশিত হয় (জনপ্রিয় প্রোগ্রামার কল্পনা) it কাজের ক্ষেত্রে এটিকে "দায়িত্ব গ্রহণ এবং গর্বিত" হিসাবে দেখানোর পরিবর্তে, এটি "নিজেকে জড়িত করা এবং প্রযুক্তিগত debtণের মাধ্যমে কৃত্রিম কাজের সুরক্ষা তৈরি করা" হিসাবে দেখা উচিত।

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


3
আপনার প্রশ্ন কি? এছাড়াও, "কোড গন্ধ" কি?
ক্যামেলব্লিউজ

2
@ ক্যামেলব্লুজ: " কোড গন্ধ কোনও প্রোগ্রামের উত্স কোডের এমন কোনও লক্ষণ যা সম্ভবত একটি গভীর সমস্যা নির্দেশ করে।" (উইকিপিডিয়া) কোড গন্ধ সম্পর্কিত এই সাইটে কয়েকটি প্রশ্নের কয়েকটি জন্য এই অনুসন্ধানটি দেখুন ।
কারসন 63000

4
কোডের মালিকানা কি কোডের গন্ধের ফলাফল নয়, কোডের মালিকানা কোনও কোড গন্ধ নয়? আমি মনে করি এটি এখনও অন্য প্রশ্নগুলির মতো একই প্রশ্ন: প্রোগ্রামার্স.স্ট্যাকেক্সচেঞ্জ
48697/…

1
আমার জন্য "দায়িত্ব নেওয়া / মালিকানা"! = "কোডের মালিকানা", আমি সম্প্রতি একটি ম্যানেজারের সাথে যুক্তি দিয়েছিলাম যে কোডের মালিকানা কিছুটা খারাপ এবং এটি মানুষকে দায়িত্ব ছাড়ার অনুমতি দেওয়ার মতো নয়। এই ম্যানেজারের কোডের মালিকানার অর্থ দায়বদ্ধ হওয়া একই জিনিস।
টমাস জেমস

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

উত্তর:


32

আমি মনে করি কোডের মালিকানার মধ্যে আমাদের অবশ্যই একটি পার্থক্য করতে হবে:

  • দায়িত্ব দৃষ্টিকোণ থেকে,
  • কোড শৈলী / হ্যাকস ইত্যাদি থেকে দেখুন of

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

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


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

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

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

এটি কি কোডের গন্ধ? ঠিক আছে, কোড গন্ধ দ্বারা আপনি কী বোঝাতে চান এটি নির্ভর করে depends আমার জন্য, এটি সমস্ত প্রকল্পের সামগ্রিক সংগতি এবং সঠিক পরিচালনা সম্পর্কে । একটি ভাল প্রকল্পে,

  • কোড শৈলী নির্দেশিকা কার্যকরভাবে পরে কোডটি বোঝার জন্য সহায়তা করা হয়,
  • আরও অভিজ্ঞ বিকাশকারীরা কেআইএসএস নীতি লঙ্ঘন করে না, এইভাবে কম অভিজ্ঞ সহকর্মীদের দ্বারা উত্স কোডটি বুঝতে পরে সহায়তা করে।

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


9

প্রথমে আমাদের "কোড-মালিকানা" কী তা নির্ধারণ করতে হবে।


কোডের একটি অংশ (অংশ) যখন বিকাশের প্রাথমিক প্রক্রিয়াতে থাকে, প্রায়শই একজন বা দুজন ব্যক্তিকে "মালিক" হিসাবে মনোনীত করা প্রয়োজন কারণ:

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

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

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


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

  • কে এই বিশেষজ্ঞ / কোডটির এই অংশ / কার্যকারিতার এই অংশ সম্পর্কে সমস্ত প্রশ্নের উত্তর দিতে পারে এমন বিশেষজ্ঞ কে?
  • প্রয়োজনীয়তা দলিল, ইউনিট পরীক্ষা, গ্রহণযোগ্যতা পরীক্ষা, পরিবর্তন লগ, প্রকল্পের উইকি ইত্যাদির মতো এই জ্ঞানটি কি স্থিতিযুক্ত নিদর্শনগুলিতে ধরা পড়েছে?

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

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

এর অর্থ এই নয় যে "বিশেষজ্ঞ" এর অস্তিত্ব খারাপ: বিশেষজ্ঞরা লিখিত জ্ঞানের "ক্যাশে" হিসাবে বিবেচনা করুন। বিশেষজ্ঞরা প্রায়শই লিখিত জ্ঞান সন্ধান এবং হজম করার চেয়ে দ্রুত প্রশ্নের উত্তর দিতে পারেন।


তবে, কখনও কখনও "কোড-মালিকানা" বলতে বাইরের লোকদের কোডটি পরিবর্তন করতে বাধা দেওয়ার জন্য কোনও প্রকল্পের সক্রিয় বিকাশকারীদের দ্বারা নির্ধারিত বাধাগুলি বোঝায়।

  • এই টুকরা কোডটিতে কে পরিবর্তন করতে পারে?
    • সুস্পষ্ট বাগগুলি ঠিক করতে?
    • কোডটি তৈরি করতে অন্য কিছু প্রয়োজনীয়তা পূরণ করতে?
    • কোডটি সম্পূর্ণরূপে কারও স্বাদে আবার লিখতে চান?

ভাল বাধা এবং খারাপ বাধা আছে:

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

এই ক্ষেত্রে, অন্যান্য প্রকল্পের উত্স কোড সম্পাদনা করার সুযোগ কোড-মালিকানার উপর ভিত্তি করে করা উচিত নয়, তবে এটি যোগ্যতা-ভিত্তিক হওয়া উচিত।


পরিশেষে, @ গ্রাহাম লি উত্তরটি বিভাগীয়করণের কারণে সৃষ্ট জ্ঞান এবং আর্কিটেকচারের বিভাজনকে নির্দেশ করে।

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


7

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

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

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


6

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

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

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

আমি মনে করি যে অন্যান্য ব্যবসায়ের সমস্যাগুলিকে গন্ধ হিসাবে বর্ণনা করা ভাল , তবে অবশ্যই এটি বোঝাতে হবে না যে কেবল একটি গন্ধ আছে , এটি কোডের সাথে বিশেষভাবে করা আছে।


1

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

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

কোড মালিকানার আপনার সংজ্ঞা অনুসারে, আমি সম্মত হই যে কোডটি থাকা খুব খারাপ যা কেবলমাত্র লেখক এতে কাজ করতে পারেন।


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