উত্তরাধিকার ব্যবস্থাকে পুশ করার ব্যবস্থাপনাকে কীভাবে পরিচালনা করবেন?


14

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

পরিচালন এখন প্রকল্পটি আরও এক বছরের জন্য বাড়িয়ে দিতে চায় এবং প্রক্রিয়াটিতে ব্যবহারকারীর বেস প্রায় ত্রিগুণ হয়।

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

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

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

3
@ জেমস, আপনার প্রসঙ্গে দস্তাবেজের ফর্ম্যাটটি সম্পূর্ণ অপ্রাসঙ্গিক। গুরুত্বপূর্ণ বিষয়গুলি হল আপনি 1) আপনার প্রয়োজনীয় পরিবর্তনগুলি চিহ্নিত করুন, 2) সেগুলি বাস্তবায়নের জন্য একটি কংক্রিট পরিকল্পনা বর্ণনা করুন এবং 3) জড়িতদের পরিকল্পনার সাথে একমত হতে রাজি করুন। এমন পরিবেশে যেখানে জিনিসগুলি "অ্যাড-হক" প্রথাগত নথির কাঠামোর অর্থ কিছুই না।
অ্যাঞ্জেলো

7
সক্রিয় বিকাশের অধীনে কোনও প্রতিস্থাপন ব্যবস্থা না থাকলে আমি যুক্তি দেব যে বর্তমানটি "লাইফ সাপোর্টে" নয়। বিশেষত যদি ভবিষ্যতে পরিকল্পনাগুলিতে সংস্থাটি এতে অন্তর্ভুক্ত থাকে।
TMN

7
5 বছরের পুরনো সিস্টেমটি "উত্তরাধিকার" কখন থেকে?
মার্জন ভেনেমা

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

উত্তর:


23

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

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

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

পরিচালন এখন প্রকল্পটি আরও এক বছরের জন্য বাড়িয়ে দিতে চায় এবং প্রক্রিয়াটিতে ব্যবহারকারীর বেস প্রায় ত্রিগুণ হয়।

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

আমার কাছে, মনে হচ্ছে এটি আসলে জীবনের শেষ নয়, বরং এটি একটি রক্ষণাবেক্ষণের পর্যায়ে রয়েছে এবং যতক্ষণ না সিস্টেমটি আর ব্যবহারকারীর প্রয়োজনবোধ না করে ততক্ষণ সেখানে থাকবে be

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

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

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

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

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

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


9
I've worked with code that was 10 years old before কিভাবে প্রায় 25 বছর বয়সী :) এখনও কোম্পানির প্রয়োজনগুলি পূরণ করেছে এবং কোডটি স্পর্শ করা আর্কটিকের সাঁতারের মতোই আনন্দদায়ক ছিল তা সত্ত্বেও, এটি করার জন্য কীভাবে নকশা করা হয়েছিল তা একটি দুর্দান্ত কাজ করেছে।
ম্যাপেল_শ্যাফ্ট

@ ম্যাপেল_শ্যাফ্ট 25 বছর বয়সী কিছুই নয়। আমার মনে হয় আমি যে প্রাচীনতম কোডটি দেখেছি সেটির বয়স প্রায় 10-15 বছর ছিল। এটি মনোরম নয়, তবে ব্যবহারকারী ক্লিন কোড সম্পর্কে চিন্তা করে না। তারা এমন সফ্টওয়্যার ব্যবহার করে যা তাদের ব্যবসায়ের সহায়তা করে এমনভাবে করার জন্য তাদের যা প্রয়োজন তা করে need
টমাসের মালিক

1
@ জেমস সত্যই নয়। যদি এটি কোনও সফ্টওয়্যার বর্ধন বা ত্রুটির জন্য বিদ্যমান সিস্টেমে কিছু পরিবর্তন প্রয়োজন, এটি একটি ত্রুটিযুক্ত ট্র্যাকারে ট্র্যাক করা হয়, যেখানে এটি অগ্রাধিকারপ্রাপ্ত এবং নির্ধারিত হয়। যদি এটি কোনও প্রক্রিয়া, পদ্ধতি বা কোনও ভবিষ্যতের প্রকল্পের জন্য বিজ্ঞপ্তি হয় তবে তা সম্ভব হয় এমন একটি সম্ভাব্যতা প্রকল্পের মাধ্যমে যা সমাধান বা ইঞ্জিনিয়ারিং মেমোকে প্রোটোটাইপ করে।
থমাস Owens

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

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

7

আমি আমার উদ্বেগ জানিয়ে ইতিমধ্যে একটি প্রতিবেদন লিখেছি

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

পরিচালন এখন প্রকল্পটি আরও এক বছরের জন্য বাড়িয়ে দিতে চায় এবং প্রক্রিয়াটিতে ব্যবহারকারীর বেস প্রায় ত্রিগুণ হয়

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

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

বিগত ৫ বছরে একাধিক বিকাশকারী (বিভিন্ন সময়ে) দ্বারা বিকাশিত একটি অপ্রচলিত সিস্টেম বজায় রাখা

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

ইন্টার্ন হিসাবে (বা কোনও প্রবেশিকা স্তরের অবস্থান) আমি কীভাবে "পিছনে ধাক্কা" দেব?

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


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

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

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

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

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

5

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

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

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

আপনার কাজটি সিস্টেমকে কাজ করে রাখা, চকচকে নতুন প্রতিস্থাপনের পরামর্শ না দেওয়া।

আমার কাছে মনে হয় যে প্রচুর তরুণ প্রোগ্রামাররা বুঝতে পারেন না যে চকচকে নতুন সিস্টেমগুলি ডিজাইনের চেয়ে পুরানো সিস্টেমগুলি রক্ষণাবেক্ষণ করা প্রোগ্রামিং কাজের একটি বড় অংশ /


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

4

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

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

তুমি কি করতে পার:

ক্লিনার ছেড়ে দিন

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

ডকুমেন্টেশন তৈরি করুন

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

এটি কম বেদনাদায়ক করুন

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


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

3

আপনি করবেন না !!! এই একটি বড় সুযোগ!

আপনি শিখতে ইন্টার্নশিপ! এই প্রকল্পটি বাস্তবের হিসাবে এটি পায় world

এটি পেয়ে আপনি খুব ভাগ্যবান। আপনি অযোগ্য হওয়ার বিষয়টি আপনার উদ্বেগের বিষয় নয়। (যদি management পরিচালন এটি বুঝতে পেরে আপনি পুরোটা অর্জন করতে পারেন)

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

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


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

3

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

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

আপনার যা করা উচিত তা আমি এখানে পেশ করেছি:

  1. প্রথমে আপনার "লিগ্যাসি সিস্টেম" এর অপছন্দ ছেড়ে দিন। এটি আপনাকে খুব পাল্টা উত্পাদনশীল করে তুলবে।

  2. আপনি এখন কী করেন এবং আপনি কী মনে করেন ডকুমেন্টিং শুরু করুন। এক ধাপে ধাপে যাই হোক। ডকুমেন্টেশন করার চেয়ে ভাল সময় আর নেই যেখানে আপনি বুঝতে পারছেন যে আপনার একটি প্রয়োজন need

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

Dipan।


2

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

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

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


1

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

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