আমার দলটি "আধুনিক" হয়ে কোথায় শুরু করা উচিত? [বন্ধ]


106

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

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

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

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

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


92
"আধুনিক"? আপনার তালিকা থেকে "চটজলদি" বুজওয়ার্ডটি স্ট্রিপ করুন এবং আমি 20 বছর বয়সের সাথে কেবল জিনিসগুলি দেখতে পাচ্ছি।
ডক ব্রাউন

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

41
আমি আপনাকে আশ্বাস দিচ্ছি, আপনি, ইউনিট টেস্টিং, লগিং, ডাটাবেস নরমালাইজেশন, কোডিং স্টাইল গাইড, কোড পরিদর্শন (= পর্যালোচনা) সবই 30 বছরের চেয়ে পুরানো। "রিফ্যাক্টরিং" শব্দটি কমপক্ষে 15 বছর বয়সী (ফওলার 2000 সালে তাঁর বই লিখেছিলেন)। এবং কোনও আনুষ্ঠানিক ডকুমেন্টেশন বা লিখিত প্রয়োজনীয়তা থাকা "আধুনিক প্রযুক্তি" নয়, এটি আইএমএইচও এমনকি "কৌশল "ও নয়।
ডক ব্রাউন 13

69
@ ডকব্রাউন এটি স্বীকার করেছেন, আপনি নিজের মন্তব্য করার আগে এই সমস্ত জিনিস তৈরির জন্য আপনাকে ঠিক সময়মতো মার্টিকে প্রেরণ করেছিলেন।
নাল

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

উত্তর:


165

আমার কাছে মনে হচ্ছে আপনি ঘোড়ার আগে কার্টটি রাখছেন।

আপনার দলটি যে বড় সমস্যার মুখোমুখি হচ্ছে এবং কোনটি প্রযুক্তিগুলি এটির সমাধান করতে সহায়তা করবে?

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

মনে রাখবেন আপনি যে ব্যবসায়ের জন্য কাজ করছেন তার উদ্দেশ্য কোড তৈরি করা নয়, অর্থোপার্জন।


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

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

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

5
দুর্দান্ত উত্তর। আপনার কেবল সমস্যা সমাধানের জন্য এই বিষয়গুলি প্রয়োগ করা উচিত, সমস্যা তৈরির জন্য নয়।
কিক

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

77

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

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

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

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


4
খুব সুন্দর উত্তর (+1), বিশেষত শেষ অনুচ্ছেদ। একটি খুব আধুনিক বই (আমি আজ এটি খুব প্রাসঙ্গিক বলে মনে করি আধুনিক) আমি সম্প্রতি যা পড়ছি তা হ'ল এস আই সি পি।
জর্জিও

1
এই বুজওয়ার্ডগুলি এবং জনপ্রিয় ভাষাগুলি কত দ্রুত পরিবর্তিত হয় তার উল্লেখের জন্য +1। একটি ভাল দেব ভাল কোড রাখে যে কোনও পদ্ধতিতে ট্রাম্প করে। কি কাজ করে এবং ভাল কাজ করে!
ওয়েলেলিক

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

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

2
একটি সরঞ্জাম সহ একটি বোকা এখনও বোকা।
পিট বেকার

40

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

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

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

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


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

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

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

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

18

আমি আশা করি আপনি আপনার সহকর্মীদের কাছে আপনার পোস্টে যেমন আমাদের মতো কাজ করেছেন তেমন সমস্যাগুলি উপস্থাপন করেন নি। এটি পেশাদার আত্মহত্যা হবে।

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

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

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

এখন, এই "সেরা অনুশীলনগুলি" উপস্থাপনের জন্য, আপনার দলে তাদের বোঝানোর দুটি উপায় রয়েছে:

  • কারণ আমি বলি যে এগুলি সর্বোত্তম অনুশীলন এবং এটি যথেষ্ট।
  • কারণ তারা দরকারী এবং সমস্যা সমাধানে সহায়তা করে।

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

কাজের দ্বিতীয় পদ্ধতির জন্য, উপলব্ধি হওয়া দরকার যে কোনও সমস্যা রয়েছে । তাই:

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

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

আইটি, এন্টারপ্রাইজ বিশ্বে আপনাকে স্বাগতম! :-p

1 : ঠিক আছে, আমি হয়তো একটু এক্সেজ করছি, তবে খুব বেশি না।


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

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

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

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

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

12

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

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


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

10

উৎস নিয়ন্ত্রণ.

আপনি এটি উল্লেখ করেননি, আশাকরি যে এটি ইতিমধ্যে রয়েছে, তবে এটি যদি না হয় তবে শুরু করুন।

উত্স নিয়ন্ত্রণের জন্য সবচেয়ে বড় ধাক্কা রয়েছে, বিরল পরিস্থিতিতে ছাড়া রোগগতভাবে অন্য কোনও কিছুর প্রয়োজন রয়েছে।

আর কেউ শুরুতে না কিনে আপনি একা শুরু করতে পারেন।


1
সবচেয়ে বড় ব্যাং-বক হ'ল সঠিক জায়গায় কয়েকটি এসএসআরটি-র মতো।
পিটার মর্টেনসেন 20'15

@ পিটারমোরটেনসেন সত্য, তবে কেবল যদি আপনি জানেন তবে সঠিক স্থানগুলি কী।
এমিলিও এম বুমাচার

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

6

একটি সরাসরি উত্তর

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

  1. উৎস নিয়ন্ত্রণ
  2. ইস্যু ট্র্যাকিং (প্রকল্প এবং কার্য পরিচালনা)
  3. অটোমেটেড বিল্ডস 1
  4. স্বয়ংক্রিয় মোতায়েন

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

অন্য সবকিছু

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

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

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

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

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

কোড পর্যালোচনাগুলিও খুব সহায়ক হতে পারে - আপনি কি আপনার সহকর্মীদের আপনার কোডটি পর্যালোচনা করতে বলেছেন? মনে রাখবেন ভাল অভ্যাসগুলি গ্রহণ করার জন্য আপনার কোনও আনুষ্ঠানিক প্রক্রিয়া দরকার নেই!

ডকুমেন্টেশন দুর্দান্ত - আপনার কিছু আছে কি? যদি তাই হয়, আপনার জন্য ভাল! আপনি কি অতিরিক্ত অতিরিক্ত কাজের মুখোমুখি হয়ে যাচ্ছেন (আরও) "মানকৃত" ডকুমেন্টেশন দিয়ে বাধা দেওয়া যেতে পারে? আপনি যদি হন, তবে সম্ভবত এটি করার মতো কিছু। তবে, বলুন যদি আপনার সফ্টওয়্যারটি একটি ক্ষুদ্র লোকের দ্বারা ব্যবহৃত হয়, তবে আপনার কোনও ডকুমেন্টেশনের প্রয়োজন হতে পারে না । (অথবা আপনি সরাসরি আপনার সফ্টওয়্যারটিতে ডকুমেন্টেশন অন্তর্ভুক্ত করতে পারেন That's এটি সর্বদা আমার পছন্দ))

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


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

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

5

আপনি যে দলের একটি দলের আশেপাশে দেখুন। পরীক্ষা চালিত বিকাশ বা ডাটাবেস স্বাভাবিককরণ আপনি যে সফ্টওয়্যারটি লিখছেন তার মান উন্নত করবে বা লোককে আরও উত্পাদনশীল করবে এমন কোনও প্রমাণ আপনি দেখতে পাচ্ছেন?

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

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


5

একটি ত্রুটি খুঁজুন। একটি ত্রুটি ঠিক করুন। ফিক্সটি দেখান।

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

এটি একটি ভাল বাজি যে আপনি বেমানান তথ্যের প্রকৃত কেসটি সন্ধান করতে সক্ষম হবেন। আপনি এখন দুটি জিনিস খুঁজে পেয়েছেন:

  1. আপনার ডেটাতে একটি বাগ।

  2. আপনার ডাটাবেস স্কিমাতে একটি বাগ।

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

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

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

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

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


4

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


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


1

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

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

আছে: এক দৃষ্টান্ত যে বিতর্কিতভাবে 1960 সালে চালু করা হয় হয় প্রোগ্রামিং কাঠামোবদ্ধ : শুধুমাত্র "উচ্চ স্তর" মত নির্মান ব্যবহার while, for, repeat, if/ then/ else, switch/ caseপ্রচন্ডভাবে ব্যবহৃত পরিবর্তে বিবৃতি gotoবিবৃতি যা ডিফল্টভাবে গৃহীত হয়েছে। আছে এখনও বিতর্ক কিনা সম্পর্কে gotoসব সময়ে কোন বৈধ ব্যবহার আছে।

আমি স্বীকার করি যে কমানোর ব্যবহার gotoহ'ল একটি ভাল জিনিস, তবে সমস্ত ভাল জিনিসের মতোই খুব বেশি দূর যাওয়া সম্ভব।

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

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


অ্যান্টি-গোটো রিংলিডার এডসগার ডিজকস্ট্রার একটি লেখা থেকে:

প্রোগ্রামিংয়ের শিল্প হ'ল জটিলতা সংগঠিত করা, বহু লোককে দক্ষ করা এবং যতটা সম্ভব কার্যকরভাবে এর জারজ বিশৃঙ্খলা এড়ানোর শিল্প।

Ijডিজকসট্রা, ইন: দহল, ডিজকস্ট্রা এবং হোয়ারে 1972, পৃষ্ঠা। (. ( এখানে পৃষ্ঠা দেখুন ))

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