আমি কীভাবে আমার দলকে ছোট ক্লাস / পদ্ধতি ব্যবহার করতে রাজি করব?


27

দাবি অস্বীকার: আমি একজন নবাগত (এটি আমার কাজের তৃতীয় দিন), এবং আমার সতীর্থদের বেশিরভাগই আমার চেয়ে অভিজ্ঞ।

আমি যখন আমাদের কোডটি দেখি, তখন আমি নীচের মত কিছু কোডের গন্ধ এবং খারাপ ইঞ্জিনিয়ারিং অনুশীলন দেখতে পাই:

  • কিছুটা বেমানান নামকরণের নির্দেশিকাগুলি
  • সম্পত্তিগুলি যখন সম্ভব হয় তখন পঠনযোগ্য হিসাবে চিহ্নিত হয় না
  • বড় ক্লাস - আমি একটি ইউটিলিটি ক্লাস লক্ষ্য করেছি যা শত শত এক্সটেনশন পদ্ধতি (বহু ধরণের জন্য) নিয়ে গঠিত। এটি দীর্ঘ 2500 লাইনের বেশি ছিল!
  • বড় পদ্ধতি - আমি 150 লাইনের দীর্ঘ একটি পদ্ধতির রিফ্যাক্টর চেষ্টা করছি।

পরের দুটি মনে হয় একটি আসল সমস্যা। আমি আমার সতীর্থদের আরও ছোট ক্লাস এবং পদ্ধতি ব্যবহার করতে রাজি করতে চাই। তবে আমার তা করা উচিত? যদি হ্যাঁ, তবে কিভাবে?

আমার দলটি মূল দলটির একজন পরামর্শদাতা পেয়েছে (আমরা একটি উপগ্রহ দল)। আমি কি প্রথমে তার কাছে যাব?


আপডেট : যেহেতু প্রকল্প সম্পর্কে কিছু প্রতিক্রিয়া জিজ্ঞাসা করা হয়েছে, দয়া করে জেনে রাখুন যে এটি একটি কার্যকর প্রকল্প। এবং আইএমএইচও, বিশাল আকারের ক্লাস / পদ্ধতিগুলি সর্বদা খারাপ are

যাইহোক, আমি কখনই আমার দলকে ছাড়তে চাই না। সে কারণেই আমি জিজ্ঞাসা করেছি - আমার কি তা করা উচিত, এবং যদি হ্যাঁ, তবে আমি কীভাবে আলতোভাবে এটি করব?

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

ধন্যবাদ.


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

14
আপনি কেবলমাত্র 3 দিন চাকরীতে চলে আসার কারণে আপনি কেবল লোককে বিস্মিত করার সম্ভাবনা রয়েছে। দলটিকে প্রথমে জানুন এবং কিছুটা শ্রদ্ধা অর্জন করুন। জলটি অনুভব করার জন্য নৈমিত্তিক কথোপকথনে জিনিসগুলি আনুন। আপনি সঠিক ধারণা পেয়েছেন, তবে আপনি ফার্ম ঘোড়াগুলির স্থিতিতে একটি ঘোড়দৌড় হতে পারেন।
kirk.burleson

4
বাস্তব বিশ্বের আপনাকে স্বাগতম :)
ফ্রেটজে

ছোট ফাংশনগুলির সাথে জেআইটি সংকলক আরও সুখী হবে এবং কোডটি আরও দ্রুত হবে। কার্যকর সি # দ্বিতীয় সংস্করণ আইটেম 11. my.safaribooksonline.com/book/programming/csharp/9780321659149/…
চাকরী

3
আমি সাহায্য করতে পারছিলাম না কিন্তু ছলছল করতে দেখলাম যখন আপনি একটি ইউটিলিটি ক্লাস 2,500 লাইন দীর্ঘ দেখেছেন তখন আপনি কতটা হতাশ হয়ে পড়েছিলেন। আমি আমার কেরিয়ারে 25,000 এরও বেশি লাইনের ক্লাস দেখেছি। আমাকে ভুল করবেন না, যদিও, আমি মনে করি 500 ক্লাসের পরে একটি শ্রেণি খুব দীর্ঘ হয়ে যাচ্ছে।
পিটারআলেন ওয়েবেব 12:41

উত্তর:


19

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


সত্যিই ভাল ধারণা। জিনিস এখনই লিখুন, পরে কিছু পরিবর্তন প্রস্তাব করুন।
রোমান গ্রেজদান

3
এটি তত্ত্ব হিসাবে কাজ করে, তবে বাস্তবে তারা কেবল ব্যাগটিকে তার বাইরে ফেলে দেবে।
কাজ

15

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

আপনি বইটির একটি অনুলিপি কিনতে পেরেছিলেন এবং আপনার সমবয়সীদের কিছু পড়াশুনা দেখাতে পারেন ... পরিসংখ্যান (যদিও তারা সর্বদা মিথ্যা থাকে) লোককে বোঝাতে ঝোঁক।


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

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

3
@ গ্রেজি: আমি নিশ্চিত এটি আপনার ব্যক্তিগত অভিজ্ঞতার উপর নির্ভর করে। আমি বিশদে যেতে চাই না, তবে আপনি যখন তাদের ঘাড় পর্যন্ত "প্রযুক্তিগত projectsণ" প্রকল্পগুলি দেখেন, তখন অভিব্যক্তিটি খুব উপযুক্ত হয়ে ওঠে। কোডাররা তাদের 90% সময় theণের জন্য "সুদ প্রদান" করতে পারেন। এই ক্ষেত্রে, এটি জানতে পেরে অবাক হওয়ার কিছু নেই যে দলের কেউ এই শব্দটির কথা শোনেনি।
বেন হকিং

ক্লিন কোডে এ সম্পর্কে প্রচুর তথ্য রয়েছে (যদিও, অনেক পরিসংখ্যান নয়)।
স্টিভেন এভার্স 12'11

আপনি যদি পৃষ্ঠা 173 একবার দেখুন, ম্যাককনেল রুটিন মাপের পক্ষে কিছু পরিসংখ্যানগত প্রমাণ উপস্থাপন করেছেন যা সম্ভবত সবচেয়ে চতুরতম উকিলকে বক্কর করে তুলবে। তিনি ঠিক আছে সুন্দর পরিষ্কারভাবে 150 লাইন রাখে (কিন্তু আদর্শ) কলাম, কিন্তু অনেক অতীত 200. যাচ্ছে বিরুদ্ধে একটি শক্তিশালী ব্যক্তিগত সুপারিশ দেয়
ড্যান Monego

13

দাবি অস্বীকার: আমি একজন নতুন আগত (এটি আমার কাজের তৃতীয় দিন), এবং আমার দলের বেশিরভাগই আমার চেয়ে অভিজ্ঞ।

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

এর পরে আপনার দেওয়া কোনও পরামর্শ অবশ্যই আরও ইতিবাচকভাবে দেখা হবে এবং কম প্রতিরোধের সাথে পূরণ করা হবে।

আপনি যদি সাফল্য অর্জন করেন, বা কমপক্ষে আপনার সহকর্মীদের প্রথমে সম্মানটি হারাবেন না তবে সফলতার সাথে পরিচয় করার পরিবর্তনের সম্ভাবনা আপনার পক্ষে যথেষ্ট বেড়ে যায়।

কিভাবে এটা কোনদিকে? "একবার দুবার কাটা পরিমাপ করুন .." এরকম কিছু।


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

12

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

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

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

ভাগ্য সুপ্রসন্ন হোক.


"আপনার উত্সাহকে মাঝারি করুন" এর জন্য ++। আইএমএইচও, এই নীতিগুলি যে প্রগা with়তার সাথে প্রচারিত হয়েছে তা তাদের ন্যায্যতার পক্ষে বিপরীত অনুপাত। (
ধর্মগুলি

11

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

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

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

এবং হ্যাঁ, কোড কমিট থেকে শুরু করে প্রত্যেককে স্টাফ প্রদর্শন করুন।


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

8

এখানে কয়েকটি কৌশল:

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

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

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

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

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

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

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


6

আমি কীভাবে আমার দলকে ছোট ক্লাস / পদ্ধতি ব্যবহার করতে রাজি করব?

না।

নিজেকে পুনঃনির্মাণ লাইসেন্স কিনুন এবং উদাহরণ দিয়ে নেতৃত্ব দিন। [' এক্সট্র্যাক্ট মেথড ' রিফ্যাক্টরিংয়ের উপর প্রচুর ঝুঁকুন]]

সময়ের সাথে সাথে অন্যদের আপনার আরও পঠনযোগ্য কোডের প্রশংসা করা উচিত এবং একইভাবে তা করতে প্ররোচিত করা উচিত *


  • হ্যাঁ - এমন একটি সুযোগ রয়েছে যে তাদের রাজি করা হবে না ; তবে এটি এখনও আপনার সেরা বাজি

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

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


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

4

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

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


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

4

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

ভিজ্যুয়াল স্টুডিওতে "কোড বিশ্লেষণ" রয়েছে যা নামকরণের সম্মেলনে সহায়তা করতে পারে।

সাইক্লোমেটিক জটিলতার মতো কোড মেট্রিকও ব্যবহার করা যেতে পারে। এটি অত্যন্ত জটিল এবং ক্লাস এবং পদ্ধতিগুলি নির্দেশ করতে সহায়তা করে।

রেকর্ড রাখাও ভাল ধারণা। যদি দলের সদস্যরা কেবল কী করার দরকার তা মৌখিকভাবে প্রকাশ করে, তবে লোকেরা ভুলে যেতে বাধ্য। মানুষের খুব ক্ষীণ স্মৃতি! =)

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


3

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

আপনি কোড খুঁজে পেয়েছেন তার চেয়ে সর্বদা কোড ছাড়ার জন্য আমি আঙ্কেল ববের পরামর্শ অনুসরণ করি। সুতরাং আমাদের যদি বাগগুলি ঠিক করার জন্য বা ছোট বর্ধনগুলি থাকে তবে আমি আশা করি আমরা তখন পরিষ্কার-পরিচ্ছন্নতার কিছু করছিলাম।

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

সুতরাং, যদি এটি কাজ করে, আপনি যতটা ঘৃণা করতে পারেন, আপনাকে এটি একা ছেড়ে যেতে হতে পারে।

এখন নতুন কোড, এটি ভিন্ন। এটি ভাল কোড হওয়া উচিত।


2

150 লাইনের পদ্ধতিগুলি ... আমি কোডের 10.000 লাইনের সাথে পদ্ধতিগুলি দেখেছি।

আপনার দুটি সমস্যার সমাধান বাহ্যিক সরঞ্জামগুলির সাথে সমাধান করা যেতে পারে :

  • কিছুটা বেমানান নামকরণের নির্দেশিকাগুলি
  • বৈশিষ্ট্যগুলি যখন সম্ভব তখন পঠনযোগ্য হিসাবে চিহ্নিত করা হয় না

সি # রেশার্পারে দুটি সমস্যাই পরীক্ষা করতে পারবেন। আপনার নির্দেশিকাগুলি অনুসরণ করে না এমন নামগুলি ত্রুটি হিসাবে চিহ্নিত হয়েছে। বৈশিষ্ট্যগুলি ত্রুটি হিসাবে কেবল পঠনযোগ্য শো হিসাবে চিহ্নিত করা হয়নি। FxCop এছাড়াও সাহায্য হতে পারে।

এই সরঞ্জামগুলি এর পুনর্নির্মাণের জন্য বিশাল পদ্ধতিগুলি একাধিক ছোটগুলিতে বিভক্ত করতে সহায়তা করতে পারে।


2

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


1

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


1

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

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


1

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


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