সহকর্মী বিজ্ঞপ্তি ছাড়াই অপ্রয়োজনীয় উন্নতি করে যখন আমি আমার কোডটির জন্য কীভাবে দায়িত্ব নেব?


71

আমার সতীর্থদের একজন হ'ল আমাদের আইটি শপের সমস্ত ব্যবসায়ের একটি জ্যাক এবং আমি তার অন্তর্দৃষ্টি সম্মান করি।

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

অন্যান্য সময়, তিনি আমার কোডগুলিতে 3+ মাস পুরানো কিছুতে অপ্রয়োজনীয় উন্নতি করেছেন।

এটি কয়েকটি কারণে আমাকে বিরক্ত করে:

  1. আমাকে সবসময় আমার ভুলগুলি সংশোধন করার সুযোগ দেওয়া হয় না
  2. তিনি যখন বিভ্রান্ত হয়েছিলেন তখন আমি কী অর্জন করতে চাইছিলাম তা জিজ্ঞাসা করার জন্য তিনি সময় নেননি, যা তার পরীক্ষা বা পরিবর্তনগুলিকে প্রভাবিত করতে পারে
  3. আমি সবসময় তার কোডটি পঠনযোগ্য বলে মনে করি না
  4. সময়সীমা কোনও সমস্যা নয় এবং তার বর্তমান কাজের চাপের জন্য আমার কোড পরিবর্তনগুলি পর্যালোচনা করা ছাড়া আমার প্রকল্পগুলিতে কোনও কাজের প্রয়োজন নেই।

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

আমি আশঙ্কা করি যে আমি যখন তাকে আমার কাছে তার পরিবর্তনগুলি ব্যাখ্যা করতে বলি তখন আমি আক্রমণাত্মক হয়ে উঠতে পারি।

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

যোগ করা স্পষ্টতা:

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

20
আপনি কি আপনার কোড রেপোর জন্য গিট, সিভিএস, বা টিএফএস ব্যবহার করেন? শুধু তার প্রতিশ্রুতি ফিরে। তিনি অবশেষে এটি পেয়ে যাবেন :)

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

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

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

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

উত্তর:


81

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

আমার জন্য, এই পরিস্থিতিতে সংঘাত এড়ানো দু'টি বিষয়তে নেমে আসে:

  1. সৌজন্যে । তার কোড সম্পর্কে কারও সাথে কথা বলা কোনও দেবকে জানতে আগ্রহী যে আপনি আগ্রহী এবং আপনি এটি প্রাপ্তবয়স্ক পেশাদার হিসাবে আলোচনা করতে পারেন।

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

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


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

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

7
@ জেসলিন, যদি তিনি আপনার সাথে এটি করছেন তবে সম্ভাবনা আছে যে তিনি সবার সাথে এটি করছেন। আমি সন্দেহ করি যে কেউ আপনার বিরুদ্ধে এটি গণনা করছে। (যদি তিনি এটি সবার সাথে না করেন তবে আপনার অন্যরকম সমস্যা হতে পারে)
ব্যবহারকারী 606723

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

2
হ্যাঁ আমি এমন সময়গুলির কথা ভাবছিলাম যখন আমি রাত ১১ টায় ডেড লাইনের আগে অন্যদের কোড ঠিক করে দিয়েছিলাম তবে তারপরেও টিমকে একটি মেল পাঠাতেন যাতে তারা এটি আমাদের কিউএ সহ আরও পরীক্ষা করতে পারে ....
tgkprog

86

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

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

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

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

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

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

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

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

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


7
আমি পারলে +1 এবং আরও অনেক কিছু। দুর্দান্ত উত্তর যা এই জাতীয় প্রক্রিয়াটির উন্নতির সর্বোত্তম উপায়গুলিকে সম্বোধন করে।
ওয়াল্ডিফি

2
হ্যাঁ ওপি-র একটি কোড পর্যালোচনা সরঞ্জামের প্রয়োজন, আপনি এইভাবে একসাথে কোডটি পর্যালোচনা করতে পারেন, এটি কেবল কোড পরিবর্তন করা নয়, কারণ তারা এটিকে পছন্দ করে। আমরা সবেমাত্র স্মার্টবায়ার / প্রোডাক্ট / সাফটওয়্যার-ডেভলপমেন্ট / কোড / পর্যালোচনা কাজে ব্যবহার শুরু করেছি
জুয়ান মেন্ডেস

19

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

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


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

4

এটি পুরো পরিস্থিতি সমাধান করবে না এমন নয়, তবে আপনি নিজের উত্স কোডে আরও মন্তব্য যুক্ত করার চেষ্টা করতে পারেন।

  1. কোডটি সম্পূর্ণ না হলে এটিকে হিসাবে চিহ্নিত করা যেতে পারে।
  2. কোডের ব্লকের উদ্দেশ্য যদি স্ব-ডকুমেন্টিং না হয় তবে আপনার এটি নথী করা উচিত।

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

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


3
ছেলে যে বিভ্রান্ত হতে পারে। ভাবুন - "এই কোডটি সম্পূর্ণ নয়" বলে মন্তব্য করে একটি মন্তব্য যুক্ত করুন এবং তারপরে আপনি কোডটি সম্পূর্ণ করার পরে এটি সরিয়ে দিতে ভুলে যাবেন।
রিওয়ালক

1
@ স্টারগাজের 12১২, শাখায় অসম্পূর্ণ কোড থাকার চেয়ে আরও বিভ্রান্তিকর?
ব্যবহারকারী 606723

শেল্ফসেটগুলি এটাই। অসম্পূর্ণ কোড চেক করবেন না।
রিওয়ালক

2
না। যদি আপনি যদি অসম্পূর্ণ কোডটিতে চেক করেন তবে এর মতো লেবেল দেওয়ার জন্য কোনও মন্তব্যের প্রয়োজন হয়, তবে আপনি ইতিমধ্যে নরকে গেছেন। মন্তব্যগুলি আপনাকে জাহান্নামের এক অন্য কোণে নিয়ে যায়।
রিওয়ালক

1
তাদের TODOs বলা হয়, তারা সারাক্ষণ ওয়ার্কিং কোডে ছেড়ে যায়
জুয়ান মেন্ডেস

4

রাজনীতি, আইনশাস্ত্র বা অর্থনীতি নির্বিশেষে প্রত্যেকেই 'নিজস্ব কোডের মালিক' - এটি 'জিনিসের প্রকৃতি' - আপনি স্বাভাবিকভাবেই নিজের কাজের সাথে একটি ব্যক্তিগত সংযোগ অনুভব করেন।

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

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

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


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

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

1
@ জেসলিন - আমার বক্তব্য "প্রত্যেকে প্রত্যেকেই নিজের কোডের মালিক" বলে আমার বক্তৃতার কারণেই আমি অবাক হয়েছি। এটি একটি দার্শনিক প্রশ্ন, নীতিগত প্রশ্ন নয়। :-)
ভেক্টর

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

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

1

আপনি যদি কোড লিখেন তবে আমার এটি পর্যালোচনা করা উচিত।

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

যদি কেউ আমার পরিবর্তনগুলি পর্যালোচনা না করেই আমার পরিবর্তনের সাথে যদি আপনার নতুন কোডটি করে থাকে তবে আমি (1) একটি পর্যালোচনা না করা পরিবর্তন এবং (2) কোড পর্যালোচনাটিকে গুরুত্ব সহকারে বিবেচনা করা হলে সবচেয়ে খারাপ পাপ করেছি।


0

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

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

(যদি এটি কর্মক্ষেত্রের স্থানে থাকে তবে সম্পূর্ণ ভিন্ন উত্তর রয়েছে st

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