স্বতন্ত্র কোড মালিকানা কি গুরুত্বপূর্ণ? [বন্ধ]


48

পুরো কোডবেজের টিমের মালিকানা এর উপাদানগুলির স্বতন্ত্র মালিকানার চেয়ে ভাল কিনা তা নিয়ে আমি কিছু সহকর্মীদের সাথে তর্ক করার মধ্যে আছি।

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

এটি বাগ ফিক্সগুলি আরও সহজ করার সাথে সাথে এক (বা দুই) টিমের সদস্যদের সাথে নির্দিষ্ট কার্যকারিতা জ্ঞানকে কেন্দ্রীভূত করে।

সর্বোপরি, এটি কোনও ব্যক্তির সাথে বড় সিদ্ধান্তের বিষয়ে চূড়ান্ত বক্তব্য রাখে যার কাছে কমিটির পরিবর্তে প্রচুর ইনপুট থাকে।

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

তবে আমার সহকর্মীদের এই পরামর্শ দেওয়ার সময়, আমি এক টন পুশব্যাক পেয়েছি, অবশ্যই আমি যা আশা করেছিলাম তার চেয়ে অনেক বেশি।

সুতরাং আমি সম্প্রদায়কে জিজ্ঞাসা করছি: একটি বৃহত কোডবেসে টিমের সাথে কাজ করার বিষয়ে আপনার মতামত কী? সতর্কতার সাথে সম্মিলিত মালিকানা বজায় রাখার বিষয়ে আমি কি কিছু মিস করছি?


"ভাঙা উইন্ডো সিন্ড্রোম" কী? আমি এই শব্দটির সাথে পরিচিত নই।
uman

1
ভাঙা জানালা সিন্ড্রোম: en.wikipedia.org/wiki/Broken_windows_theory
Pemdas

1
"এটি এক (বা দুই) টিমের সদস্যদের সাথে নির্দিষ্ট কার্যকারিতার জ্ঞানকেও কেন্দ্রীভূত করে" ... "আমি জ্ঞানের সিলো তৈরির পরামর্শ দিচ্ছি না"। এটা কি দ্বন্দ্ব নয়? আমার কাছে, দু'জন সদস্যের সাথে জ্ঞানকে কেন্দ্রীভূত করা হল একটি জ্ঞানের সিলো সংজ্ঞা।
স্লেসকে

এটি কয়েক বছরের পরে আসা অন্য একটি প্রশ্নের সাথে খুব মিল বলে মনে হচ্ছে ।
এরিক কিং

উত্তর:


46

আমি বিশ্বাস করি যে দীর্ঘমেয়াদে টিমের মালিকানা অনেক বেশি উপকারী।

ন্যূনতম সংখ্যক লোকের মধ্যে জ্ঞান কেন্দ্রীকরণ আদর্শের চেয়ে কম কেন তা বোঝার জন্য আপনাকে কেবল নিম্নলিখিত 2 টি দৃশ্য দেখার প্রয়োজন:

  • দুর্ভাগ্যজনক দুর্ঘটনার মুখোমুখি হন টিমের সদস্য
  • দলের সদস্যরা আরও উন্নত কর্মসংস্থানের সুযোগ পান

স্বভাবতই, যে ব্যক্তি / লোকেরা নির্দিষ্ট বিভাগগুলি লেখেন তাদের এটি সম্পর্কে আরও বেশি জ্ঞান থাকবে তবে তাদের একমাত্র জ্ঞানের সিলো করার প্রলোভনে ফেলবেন নাসিলোস আপনাকে দীর্ঘমেয়াদী ব্যথা দ্বারা স্বল্পমেয়াদী বিজয় দেবে।

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


7
ওও দৃষ্টিকোণ থেকে উভয় দৃশ্যপটে পরিণত হয়: "দলের সদস্যরা প্রায় কোনও মোড় নেই।" "দুর্ভাগ্যজনক দুর্ঘটনা" এর "উন্নত কর্মসংস্থান" কি কেবল একটি সাবক্লাস নয়?
ড্যান রোজনস্টার্ক

4
@ ইয়ার: হ্যাঁ, যদিও আমার ধারণা আপনি এখনও "আরও ভাল কর্মসংস্থান" পাওয়া কাউকে আরও অর্থের জন্য ফিরে আসতে বলতে পারেন ... কোনও বাসের আওতায় তাকে কোনও অর্থের পরিমাণ ফিরিয়ে আনতে হবে না :-)
ডিন হার্ডিং

4
আমি আমার গ্রুপের ডেভসগুলিকে মূল লেখকের সাথে জিজ্ঞাসা করতে / যুক্ত করতে উত্সাহিত করি যাতে আপনি কিছু জ্ঞানের বিতরণের পাশাপাশি দ্রুত বাগ ফিক্সটি পান।
ডায়েটবুদ্ধ

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

4
আমি @ জেসনের বিরুদ্ধে তর্ক করব। যদি এটি হয় তবে আপনার আরও ভাল কর্মী, আরও ছোট দল দরকার। পিয়ার চাপটি যতক্ষণ না দলকে একগুচ্ছ ঝাঁকুনি না করে ততক্ষণ তা ধরে রাখতে সক্ষম হওয়া উচিত। টিমের মালিকানা ব্যক্তিগত দায়বদ্ধতার অভাব বোধ করে না।
ড্যান ম্যাকগ্রা

27

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

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

আমি দলীয় পরিবেশে কাজ করেছি যে, লোকেরা যা লিখেছে তাতে মালিকানার বোধ অনুভব করতে পারে নি, তারা চমৎকার কোড লিখতে বাধ্য হয় নি, তবে কেবল গড় কোড ছিল।


5
মালিকানা বোধের কারণে আরও ভাল কোড গুণমান সম্পর্কিত পয়েন্টের জন্য +1। এটা অবশ্যই আছে।
23 শে

+1 (+10 যদি আমি পারতাম): মালিকানা কোডের মানকে প্রভাবিত করে, এটি কেবল গর্বের অনুভূতি দেয় না এবং এটির সাথে আরও দৃ stronger় প্রেরণা, কারণ এটি কোড জটিলতা পরিচালনা করতে সহায়তা করে, যেমনটি প্রবন্ধে খুব ভালভাবে ব্যাখ্যা করা হয়েছে "একের মাথায় একটি প্রোগ্রাম রাখা", পলগ্রাহাম . com/ হেড এইচটিএমএল দেখুন
জর্জিও

19

যদিও আমি পণ্য সম্পর্কে জ্ঞান ছড়িয়ে দেওয়ার কারণে ব্যবসায়ের অবস্থান থেকে সম্মত হই; বাস্তবতা হ'ল কোনও ব্যক্তি প্রদত্ত যে কোনও কিছুর ক্ষেত্রে তাদের প্রয়াসকে কেন্দ্র করে, সময়ের সাথে সাথে প্রদত্ত অঞ্চলে আরও বেশি দক্ষ হয়ে উঠবে।

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

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

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


5
প্রো টিমগুলির ব্যাকআপ কোয়ার্টারব্যাক রয়েছে
স্টিভেন এ। লো

1
@ স্টিভেন আমি ইতিমধ্যে বলেছি; তবে পুনরাবৃত্তি করার জন্য ধন্যবাদ ... "আপনার কি ব্যাকআপ আছে? নিশ্চয়ই আপনি করছেন ... তবে দলের সদস্যদের দলের মধ্যে একটি পরিচয় থাকা উচিত। প্রত্যেকে বিশ্বাস করা একইরকম, অন্যরকমের ব্যথার জন্য জিজ্ঞাসা করছে।"
অ্যারন ম্যাকআইভার

এনএফএল দলের তিনটি কোয়ার্টারব্যাক রয়েছে, ক্রস প্রশিক্ষণপ্রাপ্ত খেলোয়াড় নয়। স্পোর্টস অ্যানালজিস খুব কমই আইটি মধ্যে ;-) কাজ
স্টিভেন উ লো

3
@ স্টিভেন আমি এনএফএল কীভাবে কাজ করে সে সম্পর্কে সচেতন, আবার আমি বলিনি ব্যাকআপের অস্তিত্ব নেই বরং পুরো টিম জুড়ে সেই জ্ঞান ছড়িয়ে দেওয়ার চেষ্টা করা অর্থহীন। বিকাশকারী == খেলোয়াড়। আমরা যদি কোয়ার্টারব্যাক == আর্কিটেক্টের মতো শিরোনামগুলি পরিচয় করিয়ে দিতে চাই তবে এটি একক লক্ষ্য অর্জনের চেষ্টা করে এমন একটি দলকে ফোটায়। প্রতি সপ্তাহে ৪ players জন খেলোয়াড় মামলা করে এবং এই ৪ 45 জন খেলোয়াড়ের মধ্যে .6..6% কোয়ার্টারব্যাক পজিশনটি কীভাবে পরিচালনা করতে হবে তা সম্পর্কে জ্ঞান রয়েছে। আমার কাছে আদর্শ মনে হচ্ছে; এই পোস্টগুলির বেশিরভাগ বনাম 75% টিম কোয়ার্টব্যাক পজিশনটি কীভাবে পরিচালনা করতে হবে তা সম্পর্কে জ্ঞান অর্জন করতে চায়।
অ্যারন ম্যাকআইভার

10

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

এর কারণ হ'ল যদি এটি সবার দায়িত্ব হয় তবে তা কারওই দায় নয়।


+1 এর জন্য "এর কারণ হ'ল যদি এটি সবার দায়িত্ব হয় তবে তা কারওই দায় নয় responsibility"
কার্তিক শ্রীনীভাসন

@ কার্তিকস্রিনিবাসাসন: ঠিক তখনই, এবং তারপরে কিছু অকার্যকর টিম সদস্যরা (1) কোডটিতে এলোমেলো পরিবর্তন করা শুরু করবে "কারণ পুরো দলটি কোডের মালিক" এবং (২) তারা যে ত্রুটিগুলি প্রবর্তন করে তা সংশোধন করছে না "কারণ এটি সম্পূর্ণ দলের দায়িত্ব is ওগুলি ঠিক করুন". আমি স্বতন্ত্র মালিকানা এবং দলের মালিকানার মধ্যে কোথাও আদর্শ সমাধান বলে মনে করি।
জর্জিও

8

নিম্নলিখিত কারণে আমি স্বতন্ত্র দলের উপর মালিকানা রক্ষা করব:

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

6

বিশেষায়িতকরণ ঠিক আছে - একটি বৃহত কোডবেসের জন্য এটি দীর্ঘ সময়ের মধ্যে যোগাযোগের বেশ কিছুটা সময় সাশ্রয় করতে পারে - তবে মালিকানা তা নয়।

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


5

আমাকে আপনার সাথে একমত হতে হবে: একটি কোডবেসের টিমের মালিকানা স্বতন্ত্র মালিকানার চেয়ে অনেক ভাল বিকল্প।

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

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

পরিশেষে, আমি মনে করি যে যদি কোনও কোডবেসের একটি অংশ ভেঙে যায়, তবে তার পক্ষে দায়বদ্ধ ব্যক্তিকে দোষ দেওয়া খুব সহজ এবং এটি আরও বেশি সমস্যার কারণ হয়ে দাঁড়ায়।


5

আমি মনে করি আপনার উভয়ের প্রয়োজন, কারণ উভয় পদ্ধতির মধ্যে একটি উত্তেজনা রয়েছে।

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

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


4

আমি মনে করি সম্মিলিত কোডের মালিকানা পৃথক কোডের মালিকানার চেয়ে তুলনামূলকভাবে ভাল।

আমি ট্রাক তর্ক দিয়ে বিরক্ত নই - একটি স্বতন্ত্র মালিকানার মডেল হিসাবে, অন্য কারও দায়িত্ব নেওয়ার জন্য প্রয়োজনীয় সময়ের ক্ষেত্রে একজন মালিকের ক্ষতি ব্যয়বহুল, তবে ঘটনাটি বিরল that

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

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

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


1

আমি মনে করি না যে টিম কোডের মালিকানা প্রচলিত সাবসিস্টেমগুলির মূল আর্কিটেকচারটি একাধিক অবদানকারীকে বোঝার মতো গুরুত্বপূর্ণ।

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


0

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

আরও দায়িত্ব এবং কম মালিকানা চিন্তা করুন। সর্বোপরি, যে কেউ চেক লিখছে সে যাইহোক প্রকৃত মালিক।


0

জিম, আমি আপনার সাথে 100% আছি। আমি আমার কাজের জায়গায় ঠিক একই লড়াইয়ের মাঝে আছি - এই কারণেই আমি আপনার প্রশ্নটি নিয়ে হোঁচট খেয়েছি।

আমি যেভাবে দেখছি তা হ'ল: "যখন প্রত্যেকে এর মালিক হয় তখন কেউই এর মালিক হয় না"।

আমার কাছে, কোডের মালিকানা ও দায়িত্বের চেয়ে গুরুত্বপূর্ণ মানের কোনও আর কারণ নেই।

বাস্তব জীবনের উদাহরণ এটি ভালভাবে চিত্রিত করে। আপনি আরও ভাল কেয়ার করবেন: আপনার ব্যক্তিগত লন বা সম্প্রদায়ের পার্ক? বেশ স্পষ্ট.

এটি যেভাবে হয় না, অগত্যা "দলের নমনীয়তা" এর জন্য লেনদেন করতে হয়। এটি কেবলমাত্র এর অর্থ হ'ল যে কোনও ব্যক্তি যখন কোনও কিছুর মালিক হন তখন সে তা নিজের করে দেয় - এবং যদি কেবল দিনের জন্য।


0

আমার কাছে এটি আপনার দলের গতিশীলতার উপর নির্ভর করে।

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

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

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

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

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

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

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