যখন কোনও টাইট ডেডলাইনের মুখোমুখি হয়ে অন্যের কোড পরিষ্কার করা কতটা গুরুত্বপূর্ণ? [বন্ধ]


38

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

আমি একটি দলের সিনিয়র ফ্রন্ট-এন্ড ডিজাইনার এবং আমাকে প্রায়শই আমার জুনিয়রদের আউটপুটটি শক্ত সময়সীমার মধ্যে পুনরায় কাজ করতে হয়।

আমি 2 সমস্যার মুখোমুখি হয়েছি:

  1. তাদের কোডিং স্টাইলটি কিছুটা গণ্ডগোল।
  2. নান্দনিকতা ভাল নয়।

তাদের কোডিং শৈলী, আমি সন্ধান করি যে কোনও মিশ্র ব্যাগ যা সঠিক কোনও কনভেনশন / মানসম্পন্ন নয়। আমি কোড সাফ করার জন্য বা কেবল তাদের কোড নিয়ে কাজ করার মধ্যে ছিঁড়ে গিয়েছি (এমনকি তারা কীভাবে কাজ করে তা অনুলিপি করে)।

আমি খারাপ কোডগুলি শিখতে পারি বলে আমার কোডিং স্টাইলটি অনুসরণ করা হতাশ বলে মনে হয়। তবে তারপরে, সময়সীমাটি পূরণের এটি দ্রুততম উপায়।

যারা আরও অনেক অভিজ্ঞতা আছে তাদের জন্য কোনটি বেশি কার্যকর? আমি কি পরে ক্লিন-আপ সংরক্ষণ করব? বা পরিবর্তনগুলি করার সাথে সাথে ক্লিন-আপ?

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


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


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

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

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

উত্তর:


79

আমি বিশ্বাস করি আপনি সমস্যাটিকে ভুল উপায়ে দেখছেন - আপনি জুনিয়রদের আরও ভাল কোড কীভাবে লিখবেন তা শেখানোর একটি দুর্দান্ত সুযোগ মিস করছেন।

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

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

যখন কোড-রিভিউিং টিম-সাথী আপনি হবেন তখন তারা আপনার দক্ষতা থেকে আরও অনেক কিছু শিখবেন যখন আপনি কেবল তাদের কোডটি পুনরায় লিখবেন ( কোডটি পরিবর্তন করার কারণটি শুনতে পেলেন ) এবং এতে কম অপরাধ নিতে পারে take

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

তারা অনেক কিছু শিখতে যদি আপনি তাদের পর্যালোচনা করার সুযোগ দিতে হবে আপনার কোড। আপনিও কিছু শিখতে পারেন - সুতরাং এটি কেবল প্রদর্শনের জন্য করবেন না!


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

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

23
@ ফিল যখন একটি সময়সীমা গণনা করার সময় কোড পর্যালোচনা সেশনের সময় বিবেচনা করা উচিত। এটি ডেলেলিওমেন্ট প্রক্রিয়াটির শীর্ষে কোনও অতিরিক্ত পদক্ষেপ নয় - এটি উন্নয়ন প্রক্রিয়ার একটি অবিচ্ছেদ্য অঙ্গ।
ডিজে

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

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

29

আমি এটি আগেও বলেছি এবং আবার এটিও বলব "কার্যকরী কোডটি সুন্দর কোডের চেয়ে মূল্যবান"।

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

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


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

7
এটি লক্ষ্য করার মতো বিষয় যে ক্রমাগত opালু কোড লিখতে "এটিকে কাজ করার জন্য" কাদা দিয়ে বড় বল নিয়ে যাবে । এটি ব্যতিক্রম হলে নিয়ম নয়, ঠিক আছে। যদি এটি নিয়ম হয়ে যায়, আপনি আপনার বসের সাথে কথা বলুন যে সময়সীমা বিবেচনা করার একমাত্র জিনিস নয়।
নীল

20
সমস্যাটি হ'ল কুৎসিত কোডটি দ্রুত ভাঙ্গা কোডে রূপান্তরিত হয়।
তেলস্তিন

1
@ আরামাউন্ড - নিশ্চিত, তবে ওপি (এবং প্রায় সবাই) কোডটি সম্পর্কে কথা বলছে না যা কেবল পুরানো মানগুলি ব্যবহার করে - তারা বিশ্রী, বেমানান, বেহাল কোড সম্পর্কে কথা বলছে।
তেলস্তিন

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

16
  • সংক্ষিপ্ত উত্তর হলো 'না. যখন সময়গুলি শক্ত হয়, কখনও কখনও আপনাকে কেবল নিজের মাথা নীচু করে নান্দনিক বুলেট নিতে হয়। ;)

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

  • কখনও কখনও, যদিও, কিছুটা সাফ করা কাজ দ্রুত করে তোলে। এমনকি কিছু দ্রুত অনুসন্ধান এবং প্রতিস্থাপনের ধরণের পরিবর্তনগুলি সবকিছুকে অনেক বেশি অ্যাক্সেসযোগ্য করে তুলেছে।

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

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


9

কোড ঠিক করার সময় এবং সময়সীমা থাকাকালীন আমি সাধারণত দুটি নিয়ম ব্যবহার করি:

কোডটি ভয়াবহ তবে যুক্তিসঙ্গত সময়ে কোনও সমস্যা খুঁজে পাওয়া এবং এটি সমাধান করা সম্ভব

আমি কোনও সমস্যা সমাধান করেছি এবং বাকী অক্ষত রেখেছি ।

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

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

সীমান্তরেখা ক্ষেত্রে দেখা যায়:

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

সেক্ষেত্রে কোডটি ঠিক করতে হবে, তবে কেবল তখনই যখন নিষ্ক্রিয় সময়ে নতুন বৈশিষ্ট্যগুলি প্রয়োগ করা হয়, কখনই সময়সীমার সামনে বাগ-ফিক্সিংয়ের সময় হয় না!


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

6

আমি আপনার প্রক্রিয়াটির কোন পর্যায়ে আপনি এই সমস্যাটি খুঁজে পাচ্ছেন তা জানতে আগ্রহী হব?

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

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

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


4

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


3

ভবিষ্যতে সমস্যাটি নিয়ন্ত্রণে সহায়তার জন্য, একটি অভ্যন্তরীণ কোডিং স্ট্যান্ডার্ড এবং অনুশীলন নথি তৈরি করুন যা সমস্ত কর্মচারীদের অনুসরণ করতে হবে।

বর্তমান ব্যাচের জন্য, এসএন্ডপি ডকুমেন্ট অনুযায়ী কোড পরিষ্কার করুন আপনি কোডটি রিফ্যাক্টর হিসাবে কেবল তখনই যখন আপনি রিফেক্টর করেন।


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

@ ডাঙ্ক মার্কিন সেনা "বড় এবং প্রক্রিয়া ভিত্তিক" হিসাবে গণ্য না? তারা সর্বদা এস ও পিএস ব্যবহার করে: stroustrup.com/JSF-AV-rules.pdf
কেসি

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

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

@Dunk দ্য JSF-এভি দল এই স্বীকৃত আছে আবশ্যক, ডকুমেন্ট বিশেষভাবে একটি উপায়, S & গীত (2005 ফিরে) জোরদার করা যেমন স্বয়ংক্রিয় সরঞ্জামের ব্যবহার উল্লেখ
ক্যাসি

2

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

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


2

বৃহত্তর গ্রুপের জন্য "একজন ফিল্টার" হিসাবে একজন ব্যক্তিকে ব্যবহার করার ক্ষেত্রে সামগ্রিক গুণমানের উন্নতি করা যথেষ্ট উন্নত। ঐ নোটে:

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

2

সর্বোত্তম অনুশীলনটি হ'ল কোডিং শৈলীর গাইড এবং নিয়মিত পর্যালোচনা করা উচিত, যাতে আপনি যখন একটি সময়সীমার কাছে পৌঁছে যান তখন আপনি এই সমস্যার মুখোমুখি হন না।

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

আপনার লোকদের জন্য অনেকগুলি সুবিধা রয়েছে, কে হবেন:

  • আরও ভাল স্টাইল শিখুন
  • আরও ভাল অভ্যাস অনুসরণ করুন
  • তারা কী করছে তা গবেষণা করতে শিখুন

এবং নিজের জন্য কিছু সুবিধা, আপনি হবেন:

  • শেষ মিনিটের ডিবাগগুলির সময় আরও কার্যকর (যা সর্বদা ঘটবে)
  • আপনার দল এবং পরিচালনা উভয় দ্বারা বিশেষজ্ঞ এবং নেতা উভয় হিসাবে স্বীকৃত

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

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

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

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

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

2

আমি "কী কাজ করছে তা স্থির করবেন না" এবং "ক্লায়েন্টের পক্ষে গুরুত্বপূর্ণ নয় এমন বিষয়ে আপনার সময় নষ্ট করবেন না" এর কারণগুলি দেখতে পাচ্ছি। প্রধানমন্ত্রীরা ঝুঁকি নিয়ে উদ্বিগ্ন এবং এটি ঠিক আছে।

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

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

টেক debtণ শব্দ। এটি কোনও দিন ফিরে আসবে এবং কেউ এর জন্য অর্থ প্রদান করবে।

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


0

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

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

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

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

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

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

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

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


0

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

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

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

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

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


0

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

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

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