আমি কীভাবে আমার দলের জন্য রিফ্যাকচারিংকে অগ্রাধিকার দিতে পারি?


57

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

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

আমি কীভাবে এমন রিফ্যাক্টরিংয়ের মানটি প্রদর্শন করতে পারি যে এটি আমাদের কার্য তালিকায় যুক্ত হয়? অনুমতি দেওয়ার পরিবর্তে ক্ষমা চাওয়ার জন্য যেমন আমি যাচ্ছি ঠিক তেমনি চুল্লিটি কি মূল্যবান?


ইনস্টিটিউট কোড-পর্যালোচনা এবং সমস্যাটি নিজের যত্ন নেবে (প্রায়)
ডিউকোফেমিং

4
রিফ্যাক্টরিংকে আলাদা কাজ হিসাবে বিবেচনা করবেন না - এটি নয়।
ভেটল

2
ইন-কোড চেঞ্জলগগুলি আমাকে কাঁদতে চায় ... আপনার ক্ষতির জন্য আমি দুঃখিত।
চিহ্নিত করুন las

@ মার্ক ক্যানলাস আমি উত্স নিয়ন্ত্রণে আক্ষরিকভাবে শত শত পরিবর্তন সহ 20 বছরের পুরানো কোড বেসের মুখোমুখি না হওয়া পর্যন্ত আমি একইভাবে ভাবতাম। সৌভাগ্য যে সুনির্দিষ্ট কোড ব্লকটি কেবল উত্স নিয়ন্ত্রণের ইতিহাস ব্যবহার করে পরিবর্তিত হয়েছিল তা খুঁজে পাওয়ার সৌভাগ্য
মাইকেল জে

@ মিশেল কি এত কঠিন করে তুলেছে? সাধারণভাবে, কয়েকটি দোষারোপ / টীকাগুলি অপারেশনগুলি আপনাকে কতগুলি পরিবর্তন করা হয়েছিল তা বিবেচনা করে প্রাসঙ্গিক প্রতিশ্রুতিবদ্ধ করে তোলা উচিত। (20 বছরেরও বেশি সময় ধরে "কয়েকশ" পরিবর্তন খুব ছোট,
বিটিডাব্লু

উত্তর:


51

"অনুমতি চেয়ে ক্ষমা চাওয়া ভাল" সত্য।

কেন এটা নিয়ে চিন্তা করবেন? সর্বাধিক ভয়াবহ অংশগুলি কেবল রিফ্যাক্টর।

আপনি ইতিমধ্যে জানেন যে সবচেয়ে ব্যয়বহুল ত্রুটিগুলি কী, তাই না?

যদি আপনি এটি না করেন তবে প্রথম পদক্ষেপটি হ'ল ধনাত্মক এবং নির্বিঘ্নে সর্বাধিক ব্যয়বহুল, জটিল, ত্রুটি-বিহীন, বাগ-সংক্রামিত সমস্যা কোডটি সংজ্ঞায়িত করা।

সমস্যার টিকিট সংখ্যা, ডিবাগিংয়ের ঘন্টা এবং অন্যান্য খুব নির্দিষ্ট, খুব পরিমাপযোগ্য ব্যয়ের শনাক্ত করুন ।

তারপরে উচ্চ ব্যয়ের সমস্যার তালিকায় কিছু ঠিক করুন ।

যখন আপনাকে ক্ষমা চাইতে হবে, আপনি ব্যয় হ্রাসকে নির্দেশ করতে পারেন।


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

এর অর্থ একটি জিনিস বাছাই করা । একটি ইউনিট পরীক্ষা লিখুন। একটি জিনিস ঠিক করুন। আপনি দুটি উন্নতি করেছেন। (1) একটি পরীক্ষা লিখেছিল এবং (2) কোডটি স্থির করেছে।

পুনরুক্তি।


4
আপনি যদি এটি করেন, শুরু করার আগে মেট্রিকগুলি পান, তারপরে ক্ষমা চাওয়ার সময়, আপনার নিজের চাকরি রাখার প্রয়োজনীয় প্রমাণ আপনার কাছে রয়েছে।
mattnz

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

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

8
বেশিরভাগ সময়ই উত্তরটি মনে হয় "ছেড়ে চলে যান এবং এমন যোগ্য লোকদের সন্ধান করুন যারা হ্যাক না হয়ে কীভাবে সত্যিকারের পেশাদার হতে পারবেন তা বোঝেন।" :)
ওয়েইন মোলিনা

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

32

বয় স্কাউট নিয়মটি অনুসরণ করুন: ক্যাম্পসাইটের (কোড) আপনি খুঁজে পেয়েছেন তার থেকে কিছুটা ভাল রাখুন। "ছোট ছোট কোডের উন্নতি করার জন্য কেউ লিখে রাখার কথা আমি কখনও শুনিনি" যখন তারা সেখানে ছিল "।


7
আপনি একটি সময়সীমার সাথে কতটা কাছাকাছি আছেন তার উপর দৃ on়ভাবে নির্ভর করে depends একটি লাইব্রেরি পরিবর্তন পূর্ববর্তী সমস্ত পরীক্ষাকে অবৈধ করতে পারে।

3
ভাল পয়েন্ট, @ থরবজর্ন। এরকম কিছু আমি সম্ভবত "ছোট" উন্নতি হিসাবে শ্রেণিবদ্ধ করব না কারণ এর প্রভাবের বিশাল পরিমাণ রয়েছে।
কার্ল বিলেফেল্ট

যদি আপনি কেবল এমন কোনও ফাংশনটি পাস করেন যা কিছুটা উন্নতি করা যায়। আপনি কেবল জানেন না যে এটি একটি সাধারণ লাইব্রেরিতে রাখা হয়েছে?

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

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

23

আমি সম্ভবত অত্যধিক চঞ্চল দৃষ্টিভঙ্গি নেব।

রিফ্যাক্টরিং গিলে ফেলার মতো শক্ত পিল। আপনি দায়িত্ব এবং দোষ পেয়ে যান এবং আপনার শ্রমের ফল প্রায়শই অন্য কারও কাছে যায় যারা আপনার ক্লিন কোড বেস তৈরি করে build

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

একটি আলাদা সংস্থায় যোগদানের কথা বিবেচনা করুন যেখানে তারা ইঞ্জিনিয়ারিং অনুশীলনগুলিকে আরও গুরুত্ব সহকারে গ্রহণ করে।


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

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

17

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

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

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

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


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

বিকাশের দলে আপনার সবচেয়ে বড় দৃষ্টিভঙ্গি পরিবর্তনের দরকার যা হ'ল "গুণমান" হ'ল কিছু সময় আপনি একটি নির্দিষ্ট মুহুর্তে করেন ("যখন আমাদের কাছে রিফ্যাক্টর করার সময় থাকে") - এটি আপনাকে সমস্ত সময় করতে হবে।

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

গল্পটির নৈতিকতা: প্রায়শই জিনিসগুলি যতটা মনে হয় তত প্রায় ভাঙা হয় না এবং 'আরম্ভ' করার অর্থ সাধারণত আপনি ইস্যুগুলির একটি স্বল্প অল্প অল্প অল্প অল্প অল্প সংখ্যক সমস্যা নিয়ে সেট করে বাণিজ্য করবেন। রিফ্যাক্টর এক সময় এক অংশ!


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

এই নিবন্ধটি খুব উপযুক্ত: ব্লগ.অবজেক্টমেন্টর
গ্যারেট হল

জোয়েল স্পলস্কির কাছ থেকে আপনার কখনই করা উচিত নয় See
জান হুডেক

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

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

12

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


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

5
@ ওয়াইন এম: সেক্ষেত্রে তাত্ক্ষণিকভাবে একটি নতুন চাকরীর সন্ধান শুরু করুন। যদি তারা আপনাকে সাক্ষাত্কারে মিথ্যা বলে তবে তারা পরে আপনার সাথে কীভাবে আচরণ করবে?
ডেভিড থর্নলি

1
সম্মত হন, তবে দুঃখের বিষয় প্রায়শই সহজ হয়ে গেছে বলে।
ওয়েইন মোলিনা

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

6

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

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

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


5

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

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

প্রথমে বড় / জটিল কোড অংশগুলি প্রতিশ্রুতিবদ্ধ করার সময় আপনাকে সিস্টেমে কোড রিভিউগুলি করতে হবে না।

অবশ্যই যদি আপনি কোড পর্যালোচনা প্রবর্তনের আগে আপনার আধিকারিক অনুমোদনের প্রয়োজন মনে করেন তবে আপনাকে প্রথমে আপনার বসকে বোঝাতে হবে যে জিনিসগুলি যেমন রয়েছে তেমন রেখে দিলে কোড বেসটি ধসে পড়তে পারে likely


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

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

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

4

এই জাতীয় পরিস্থিতিতে আমি যা করি তা এখানেই রয়েছে (একজন বিকাশকারী হিসাবে আমার কেরিয়ারের 15 বছরে আমি প্রায় প্রতিদিন এই জাতীয় কোডটি দেখতে এসেছি)

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

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


কোড রি-ফ্যাক্টরিংয়ের সময় এক থেকে দুটি বাগ ক্রাইপ করলেও আমার আপত্তি নেই, এই জাতীয় ত্রুটিটি ক্লিনার / লেনার কোডে খুব দ্রুত এবং সহজেই সংশোধন করা হয় এবং ঠিক করা হয়!
কৌতুহল

3

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

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

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


3

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

সফটওয়্যার লিড এবং টিম দলের সময় বরাদ্দ করে

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

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

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

প্রারম্ভিক প্রকল্পের পছন্দগুলি রিফ্যাক্টরিংয়ের জন্য একটি চতুর চক্র তৈরি করে

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

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

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

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

কুইক অ্যান্ড ডার্টি প্রায়শই জাস্ট ডার্টি

বোহেম রক্ষণাবেক্ষণকারী দলের বিকাশকারীদের পক্ষে জিনিসগুলি এত দু: খজনক হওয়ার কারণটি উল্লেখ করে এগিয়ে চলেছেন।

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

আমার সমাধানটি হ'ল মূল উন্নয়ন দলকে (বা কমপক্ষে মূল সীসা) প্রকাশ না করা যতক্ষণ না কোডটি কমপক্ষে কোডিং মানগুলি পূরণ করার জন্য সংশোধন না করা হয়।

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

রিফ্যাক্টরিং আলোচনা সাপেক্ষে নয়

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


2

আপনি সর্বদা এটি অপেক্ষা করতে পারে। অবশেষে, দলটি পর্যাপ্ত সময়সীমা মিস করবে এবং বাগি-পর্যাপ্ত সফ্টওয়্যার তৈরি করবে, সেই ব্যবস্থাপনার হাত বাড়িয়ে বলবে যে byশ্বরের দ্বারা কিছু ভাল পরিবর্তন হয়েছিল!

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

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


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

1

আমি মনে করি কিভাবে আপনি কীভাবে রিফ্যাক্টর কোডটি করতে চান তার উপর নির্ভর করে সময় কীভাবে পাওয়া যায় তার উত্তর depends

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

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

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


1

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

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

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

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


1

আপনার মূল সমস্যাটি হ'ল কোডগুলি পর্যাপ্ত পরিমাণে দৃশ্যমানতা পাচ্ছে না।

আমি জেনকিন্সের মতো অবিচ্ছিন্ন একীকরণ সরঞ্জাম এবং এর সাথে একীভূত একটি স্ট্যাটিক কোড অ্যানালিসিস সরঞ্জাম ব্যবহার করে যা চক্রবৃত্তীয় জটিলতা, নামকরণের মান, কোডের দৈর্ঘ্য ইত্যাদির পরিমাপ করে using

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

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


1

কোডটি বেশ কয়েকটি ছোট ছোট পরিবর্তনের মাধ্যমে ধীরে ধীরে পেয়েছে। এটিও সেভাবে স্থির করতে হবে।

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

একটি সভা করুন এবং সংমিশ্রিত কোডিং মান নির্ধারণ করুন।

আপনি পাশাপাশি যেতে ব্যবহার করার জন্য বেসিক বিধিগুলি প্রবর্তন করুন:

যখনই ক্লাসে নতুন কোড প্রবর্তিত হয় স্বয়ংক্রিয় পরীক্ষাগুলি শ্রেণীর কাজ প্রমাণ করার জন্য লিখতে হয় (কেবলমাত্র নতুন কোড নয়)।

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

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

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

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


0

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

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

ক্র্যাপ কোডগুলি প্রায়শই ঠিক করা খুব ব্যয়বহুল না। কোনও স্বয়ংক্রিয় রেগ্রেশন পরীক্ষা ছাড়াই, রিফ্যাক্টর কোড পরীক্ষার জন্য ব্যয় অত্যন্ত বেশি।

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

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


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

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

1
আমার উপরের মন্তব্য দেখুন, এজন্য।
ওয়েইন মোলিনা

2
@ ওয়াইন এম: আমি মনে করি না ম্যাটনজ "এটি ঠিক করুন না, কখনও" বলছেন, আমি মনে করি তিনি যা বলছেন তা "সংস্থার পক্ষে ভাল না হলে এবং আপনি সমর্থন তৈরি করতে না পারলে এটি ঠিক করবেন না" যা অনেক বেশি আইএমও ভিন্ন এবং বেশ যুক্তিসঙ্গত।
পিটারএলেন ওয়েবেব

3
@ ওয়াইন এম: ভাল বলেছেন! "এটি যদি ভেঙে না যায় তবে এটিকে ঠিক করবেন না" এই উক্তিটি এবং "রিফ্যাক্টরিং" শব্দটি একসাথে খাপ খায় না। Refactoring খুব সারাংশ যে সফটওয়্যার উন্নয়ন কেবল হয় না একটি কালো এবং সাদা বিশ্বের যেখানে "কপর্দকশূন্য" এবং "fixed" পরম আছে।
কারসন 63000

0

আশ্চর্যজনকভাবে কেউ এর উল্লেখ করে না:

বিষয়গুলিকে অগ্রাধিকার দেওয়ার জন্য এগুলি সহজ করুন: একটি ভাল সংশোধনকারী সরঞ্জাম পান।

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

শুভকামনা!

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