কোনও সফ্টওয়্যার সংস্থার গবেষণা এবং / অথবা ইউটিলিটি লাইব্রেরির জন্য একটি নিবেদিত দল থাকা উচিত?


15

আমি এমন একটি সংস্থায় কাজ করি যা বিভিন্ন ব্যাংক এবং কিছু ছোট ই-শপের জন্য ওয়েব অ্যাপ্লিকেশন করে আমরা প্রায় ২০ জন বিকাশকারীকে নিয়োগ করি এবং যে কোনও সময়ে বিকাশে 4-5 প্রকল্প রয়েছে। আমাদের উন্নয়ন দলগুলি খুব বেশি ইন্টারঅ্যাক্ট করে না এবং একই রকম সমস্যাগুলি বিভিন্ন উপায়ে করা হয় (ভাল থেকে খারাপ)।

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

এর মতো একটি দল কত বড় হওয়া উচিত?

এছাড়াও এটির স্থায়ী সদস্য থাকা উচিত যা অন্যদের প্রশিক্ষণ দেয় বা এটি লোককে ঘোরানো উচিত?

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


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

উত্তর:


19

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

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


2
জৈবিকভাবে জন্মানোর জন্য +1। এই জিনিসগুলি দলে চাপানো খুব কঠিন।
জন হপকিনস

আমি জৈব কাঠামোর সাথে একমত, এটাই আমি আসলে ভাবছিলাম :) এটি উচ্চারণের জন্য আপনাকে ধন্যবাদ।
লিভিউ টি।

+1 টি। আপনি সর্বদা ফ্রেমওয়ার্কটি রিফ্যাক্টর করতে পারেন, তবে এটিকে সামনে রেখে ডিজাইনের ফলে জিনিসগুলি ব্যবহৃত হওয়ার কারণ হতে পারে কারণ কাজের জন্য সঠিক সরঞ্জাম না হলেও তারা সেখানে রয়েছে।
ল্যারি কোলম্যান

আসল প্রয়োজনগুলির জন্য কাঠামো তৈরি করুন, জালগুলি নয়।
তুলাইনস কর্ডোভা

9

আমার অনুভূতি না।

আপনি যদি সন্দেহ করেন তবে আপনি যা খুঁজে পেয়েছেন তা হ'ল সেই দলের বাইরে যে কেউ ব্যবহার করেন না এমন লাইব্রেরি তৈরির পরিবর্তে আপনার কাছে এমন একটি বিশেষ দল থাকবে যা লাইব্রেরি তৈরি করছে যা দলের বাইরে কেউ ব্যবহার করেনি (এবং তা করছে) যথেষ্ট অতিরিক্ত ব্যয়)।

আপনি যে ধরণের দলটি বর্ণনা করেছেন তাতে বিভিন্ন ধরণের সমস্যা রয়েছে, তবে আমার কাছে প্রধান কারণটি হ'ল এটি আপনার আসলে সমস্যাটি সমাধান করে না।

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

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

আমি পরামর্শ দেব:

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

আমার মনে হয় একটি লাইব্রেরি দল হবে, কোনও উপকার ছাড়াই ওভারহেড।

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

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


3

এটি একটি স্থপতি কাজ

সফ্টওয়্যার আর্কিটেক্টের প্রধান দায়িত্বগুলির মধ্যে রয়েছে:

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

সম্পর্কে আরও পড়ুন: - সফটওয়্যার স্থপতি - সলিউশন আর্কিটেক্ট - এন্টারপ্রাইজ স্থপতি


প্রতিটি প্রকল্পের জন্য কোনও সফ্টওয়্যার আর্কিটেক্ট থাকা উচিত, কেবল একক দম্পতি যা একাধিক প্রকল্প পরিচালনা করে বা প্রতি কোম্পানিতে একজন করে?
Liviu টি।

প্রকল্পগুলি কত বড় তার উপর নির্ভর করে। যদি আরও বেশি ভাড়া নেওয়া হয় তবে তার যদি আরও সহায়তা প্রয়োজন হয় তবে একটি এন্টারপ্রাইজ আর্কিটেক্ট দিয়ে শুরু করুন। একটি এন্টারপ্রাইজ আর্কিটেক্টের প্রকল্পগুলি জুড়ে কৌশলগত চিন্তাভাবনা রয়েছে। স্থপতি ধরনের সম্পর্কে আরও পড়ুন দয়া করে। আপনার প্রয়োজন স্থপতি একটি মিশ্রণ প্রয়োজন। en.wikedia.org/wiki/Software_architect
আমির রেজায়ে

3

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

কাঠামোগত কার্যকারিতা বিকাশের প্রধান কারণ হ'ল

1. এটি বিকাশকারীদের জন্য দরকারী
2. কয়েকটি ক্ষেত্রে এটি কার্যকর হয়েছে
3.. এটি অন্যের পক্ষে দরকারী হতে পারে

আপনি যখন 2 টি আঘাত করেছেন, কার্যকারিতা ইতিমধ্যে সেখানে রয়েছে, আপনি এটি অন্য কারও কাছে কীভাবে পাঠাতে পারেন?


3

আমি গেমটি থেকে একটু দেরি করেছি তবে আমার মনে হয়েছিল যে কেউ এটি সম্বোধন করছে না:

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

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


2

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

অন্যথায় আপনি একটি "তাত্ত্বিকভাবে" খুব ভাল লাইব্রেরি দিয়ে শেষ করতে পারেন!


1

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

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

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


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

0

কাঠামো ব্যবহার সব ক্ষেত্রেই সুবিধা হতে চলেছে কি না তা নিয়ে আপনি কতটা সময় ব্যয় করতে চলেছেন? ফ্রেমওয়ার্কটি আপগ্রেড হওয়ার অপেক্ষায় কোনও প্রকল্প কি বিলম্ব হয়? এক পর্যায়ে কাঠামোর ব্যবহারের প্রয়োজন তার অস্তিত্বের ন্যায্যতার জন্য।

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