نصائح عملية لاستلام مشروع برمجي قائم وقواعد بياناته بفعالية

يُعد العمل كمطور برمجيات يتطلب إتقان مهارة الغوص في قواعد الأكواد البرمجية الموجودة مسبقًا. عندما تنتقل لاستلام مشروع قائم، ستواجه العديد من التفاصيل غير المعروفة، مثل الأسباب الكامنة وراء كتابة أجزاء معينة من الكود بطريقة محددة. لذا، عند حضور اجتماعات التسليم، من الضروري أن تكون مستعدًا بالأسئلة الصحيحة. تُعتبر هذه اللحظة هي الأنسب لجمع المعلومات اللازمة لبدء العمل بسلاسة. هذه الأسئلة تبرز في كل مشروع جديد، سواء كنت تبدأ وظيفة جديدة أو تنتقل للعمل على مشروع مختلف داخل شركتك الحالية. بغض النظر عن السيناريو، إليك بعض النقاط الأساسية التي يجب طرحها في اجتماعات تسليم المشروع.

فهم الغرض الأساسي للتطبيق ومن يستخدمه

ما هو الغرض الدقيق لهذا التطبيق ومن هم مستخدموه الفعليون؟ بدون هذا السياق الأساسي، سيكون من الصعب للغاية فهم كيفية تطوير ميزات جديدة أو إصلاح الأخطاء بفعالية. احرص على السؤال عن الاستخدام العام للتطبيق. تعرّف على سير العمل (workflow) لمختلف أجزاء التطبيق وكيفية تفاعل المستخدمين معه. إذا كانت هناك قائمة مهام (task list)، اطلب شرحًا تفصيليًا أو مزيدًا من المعلومات حول كل عنصر فيها. تُعد هذه الاجتماعات فرصة نادرة حيث يكون الجميع مستعدًا للتركيز على الإجابة عن أسئلتك المتعلقة بالمشروع. لذا، إذا كان هناك أي شيء غير واضح بالنسبة لك، فلا تغادر الاجتماع قبل الحصول على فهم أفضل له. بالطبع، ستظهر تفاصيل جديدة بمجرد البدء في التعمق، لكن هذه فرصتك لتجنب قدر كبير من الارتباك المستقبلي. حاول الحصول على فهم عام وشامل للتطبيق قبل الغوص في الأسئلة التفصيلية. يمكن أن يساعدك التعرف على الصناعة التي يعمل فيها التطبيق في الإجابة عن العديد من التساؤلات التي قد تظهر أثناء عملية التطوير.

إتقان إدارة التحكم بالمصادر (Source Control)

بينما تعتمد غالبية المشاريع على نظام Git، إلا أن ليس جميعها تستخدم GitHub. قد تُستضاف بعض المشاريع على منصات مثل BitBucket أو Azure DevOps، أو حتى على نظام SVN الأقدم. من الضروري أن تعرف مكان حفظ الكود في نظام التحكم بالإصدارات (version control) لتتمكن من سحبه إلى جهازك، وكذلك لإجراء استكشاف الأخطاء وإصلاحها (troubleshooting) عند ظهور الأخطاء الحتمية في بيئة الإنتاج.

تحديد نظام التحكم بالمصادر وموقعه

تأكد من حصولك على صلاحية الوصول إلى مستودع الكود (code repository) وأن لديك المستوى الصحيح من الأذونات (permissions) لأداء المهام المطلوبة. عند استلام بيانات الاعتماد الخاصة بك، اختبرها فورًا. كلما اكتشفت هذه المشكلات الصغيرة مبكرًا، سار المشروع بسلاسة أكبر على المدى الطويل.

التحقق من صلاحيات الوصول والعمل

حاول إصلاح خطأ صغير وقم بعملية إيداع (commit) سريعة للتأكد من قدرتك على دفع فروعك المحلية (local branches) إلى المستودع البعيد (remote repository).

مراجعة سجلات الوصول والمساهمين

ألقِ نظرة سريعة أيضًا على جميع من لديهم صلاحية الوصول إلى المستودع. ستكون هذه المعلومات مفيدة عند الحاجة إلى طلبات السحب (pull requests) ومراجعات الكود (code reviews). هذا هو الوقت المناسب أيضًا للتأكد من أن الأشخاص الضروريين فقط هم من لديهم صلاحية الوصول إلى الكود. قم بتدوين أي مستخدمين غير مألوفين لك وتحقق مع مدير المشروع أو أي شخص مسؤول لمعرفة ما إذا كانوا لا يزالون بحاجة إلى هذا الوصول.

تشغيل المشروع وإعداده على بيئة التطوير المحلية

قد يكون الجزء الأصعب في استلام مشروع جديد هو إعداده وتشغيله على جهازك للمرة الأولى. هناك العديد من الأوامر التي تُنفذ لمرة واحدة فقط ويمكن أن تُفقد إذا لم تكن العملية موثقة جيدًا.

تحديد المتغيرات البيئية والإعدادات الأساسية

من بين الأمور التي تحتاج إلى التحقق منها وقد لا تكون واضحة هي المتغيرات البيئية (env variables) الخاصة بك، وإصدارات البرامج التي تستخدمها، وأسماء الملفات التي تشير إليها. قد تظهر أمور أخرى مثل إعداد قاعدة بيانات محلية جديدة وتحميل البيانات الأولية (seed data)، وتغيير أي سلاسل اتصال (connection strings) بواجهات برمجة التطبيقات (APIs) أو قواعد البيانات.

REACT_APP_NAME= "Boogaloo"
REACT_APP_API= "https://not-staging.morwl.com/api"
API_KEY=ij2i0r9j02tt904tn93

توثيق المشكلات والحلول لتبسيط عملية الإعداد

إذا واجهت مشكلات أثناء عملية الإعداد، تأكد من توثيقها لتسهيل الأمر على المطور التالي. بالإضافة إلى ذلك، لا تدري متى قد تحتاج إلى إعادة ضبط جهاز الكمبيوتر الخاص بك، وستكون هذه الملاحظات مفيدة للغاية. بمجرد تشغيل التطبيق، تحقق من أن كل شيء يعمل كما هو متوقع في بيئات التطوير أو الإنتاج. يجب أن تلاحظ نفس السلوك عبر جميع البيئات حتى يبدأ المطورون في دفع التغييرات.

فهم سير عمل عمليات الاختبار (Testing Process)

يمكن أن يمر تطبيقك بالعديد من أشكال الاختبارات المختلفة، ومن الضروري أن تعرف كيفية عمل هذه العملية.

أنواع الاختبارات الشائعة: Unit و Integration

تُعد اختبارات الوحدة (Unit tests) شائعة بدرجات متفاوتة في معظم المشاريع، لذا تحقق منها دائمًا. تقوم بعض الشركات بإجراء اختبارات التكامل (integration testing) للتأكد من عدم تسرب أي تغييرات قد تكسر الكود (breaking changes) إلى مسارات البناء أو النشر (build or deploy pipelines).

دور مختبري البرمجيات المتخصصين

تعتمد أماكن أخرى على مختبري برمجيات متخصصين (dedicated software testers) يقومون بتشغيل سيناريوهات المستخدم (user scenarios) لمعرفة كيفية عمل الأمور عندما يرى المستخدمون الحقيقيون التحديثات. يجب أن تكون على دراية بجميع الخطوات التي سيمر بها تطبيقك.

أهمية تغطية الكود بالاختبارات

عند بدء هذا المشروع الجديد، يمكن أن يمنحك النظر إلى الاختبارات فكرة جيدة عن كيفية عمل التطبيق. إذا لم تكن هناك أي اختبارات في المشروع، فهذه فرصتك للبدء في إضافتها. إن وجود بعض تغطية الكود (code coverage) يحدد نغمة التطبيق في المستقبل، مشيرًا إلى ضرورة إضافة المزيد من الاختبارات مع تطور الكود.

 import React from 'react' ;
 import ReactDOM from 'react-dom' ;
 import { configure, shallow } from 'enzyme' ;
 import Adapter from 'enzyme-adapter-react-16' ;
 import Items from '../src/components/Items' ;
 import CreateItemModal from '../src/components/CreateItemModal' ;

 configure({ adapter : new Adapter() });

 jest.mock( '../__mocks__/getAllItemsMockRequest.js' );

 describe( 'Items component works' , () => {
   it( 'Items renders without crashing' , () => {
     const div = document .createElement( 'div' );
     ReactDOM.render( < Items /> , div);
     ReactDOM.unmountComponentAtNode(div);
   });

   it( 'should toggle CreateItemModal' , () => {
     const div = document .createElement( 'div' );
     const ItemComponent = shallow( < Items /> , div);
     ItemComponent.find( '#add-item-icon' ).simulate( 'click' );
     expect(ItemComponent.contains( < CreateItemModal /> )).toBe( true );
     ReactDOM.unmountComponentAtNode(div);
   });
 });

العمل مع مختبري البرمجيات عادة ما يكون عملية أكثر تعقيدًا. عادة ما يكون هناك نوع من الأنظمة المعمول بها مثل Jira أو Basecamp حيث يمكن مناقشة الأخطاء والميزات وتتبعها عبر الدورات السريعة (sprints). اتبع العملية المعمول بها، وسيساعدك ذلك في نقل الكود الخاص بك إلى مرحلة النشر (deploy phase) بشكل أسرع وأكثر اتساقًا.

إتقان عملية النشر (Deployment Process)

على الرغم من أن الخدمات السحابية (cloud services) قد سيطرت تقريبًا على احتياجات الاستضافة لمعظم الشركات، إلا أنك قد تحتاج أحيانًا إلى التعامل مع خادم مادي (physical server).

فهم استراتيجيات النشر: السحابية مقابل الخوادم المادية

سيساعدك الحصول على هذه المعلومات في فهم استراتيجية النشر (deploy strategy) التي ستعمل بها. هل توجد عملية بناء/نشر مستمرة (continuous build/deploy process) مطبقة، أم ستحتاج إلى إجراء عمليات نشر يدوية (manual deploys) من جهازك؟

التعامل مع ترحيل قواعد البيانات (Migrations)

تعرف على كيفية التعامل مع ترحيل قواعد البيانات (migrations) عبر البيئات المختلفة. احصل على توضيح لجميع الأجزاء الشائعة لنشر التطبيق لهذا التطبيق بالذات. تحدث بعض الأمور الغريبة مع الخدمات السحابية التي لا يعرفها إلا الأشخاص الذين تعاملوا مع عمليات النشر سابقًا، لذا تأكد من السؤال عما إذا كان هناك أي سلوك غريب يجب الانتباه إليه.

اختبار النشر في بيئة التطوير

بما أنك قمت بالفعل بإصلاح خطأ صغير للتحقق من قدرتك على دفع تغييراتك، فامضِ قدمًا وقم بنشر هذا الإصلاح الصغير في بيئة التطوير (development environment).

 version: 2
 jobs:
   build:
     docker:
       - image: circleci/<language>:<version TAG>
     steps:
       - checkout
       - run: <command>
   test:
     docker:
       - image: circleci/<language>:<version TAG>
     steps:
       - checkout
       - run: <command>

 workflows:
   version: 2
   build_and_test:
     jobs:
       - build
       - test

يُعد هذا بمثابة اختبار لك لترى ما إذا كنت تفهم حقًا كيفية عمل عمليات النشر. نأمل ألا تضطر إلى إجراء العديد من عمليات النشر اليدوية وأن تعمل مع مسارات التكامل المستمر/النشر المستمر (CI/CD pipelines) لتبقى العملية متسقة.

تحديد نقاط الاتصال الرئيسية وفريق العمل

ما لم تكن مسؤولاً عن التطبيق بأكمله، من الواجهة الأمامية (front-end) وصولاً إلى قاعدة البيانات، فمن المحتمل أن يكون هناك أشخاص آخرون يغطون أجزاءً من الكود أو النظام قد لا تتعامل معها أبدًا. من المهم معرفة هؤلاء الأشخاص لتحديد من تتجه إليه بالأسئلة. بالإضافة إلى ذلك، هذه طريقة رائعة للتعرف على الفرق الأخرى التي تعمل على المشروع ومعرفة ما يقومون به. إذا كنت أنت الوحيد الذي يعمل على كل جزء من المشروع، فتأكد من الحصول على جميع بيانات الاعتماد (login credentials) الممكنة، لأنه سيكون عليك الإجابة عن جميع الأسئلة.

التعرف على الخدمات الخارجية (Third-Party Services)

عندما تبدأ في تصحيح الأخطاء (debugging issues)، فإن معرفة مكان البحث عن التوثيق (documentation) هو أسرع طريقة لإصلاح المشكلات. هذا يعني معرفة الخدمات التي يستخدمها التطبيق وأين تُستخدم.

فحص ملفات التكوين لتحديد التبعيات

إحدى الطرق للعثور على هذه المعلومات هي فحص ملف package.json أو App.config الخاص بمشروعك لمعرفة ما هو مثبت.

{
  "name" : "dog-finder" ,
  "version" : "0.1.0" ,
  "scripts" : {
    "build" : "npm install" ,
    "start" : "npm run build && concurrently --kill-others \"node ./server.js\" \"http-server\""
  },
  "dependencies" : {
    "concurrently" : "^5.1.0" ,
    "cors" : "^2.8.5" ,
    "express" : "^4.17.1" ,
    "johnny-five" : "^1.4.0" ,
    "path" : "^0.12.7"
  }
}

سيساعدك هذا في حل الكثير من المشكلات التي تظهر في بيئة الإنتاج (production) وسيساعدك على طرح أسئلة أفضل. ستحتاج أيضًا إلى بيانات اعتماد (credentials) لمعظم الخدمات، ومن المرجح أن يظهر ذلك عندما تحاول تشغيل المشروع للمرة الأولى.

أهمية فهم التوافقية والإصدارات

من المزايا الكبيرة للنظر في خدمات الطرف الثالث (third-party services) مبكرًا هي التعرف على أي تغييرات في توافقية الإصدارات (version compatibility) وأي مشكلات معروفة. شكوى شائعة ستواجهها في المشاريع القديمة هي أن التطبيق لا يعمل كما كان من قبل ولا أحد يعرف السبب. يُعد النظر في هذه الخدمات مكانًا سريعًا وسهلاً للبدء في البحث بينما تستعد لاستلام المشروع.

التواصل الفعال مع صناع القرار

على الرغم من أنك تتولى التطوير الأساسي للمشروع، إلا أنه سيظل هناك شخص مثل مدير المشروع (project manager) يوجه المهام التي تعمل عليها. احصل على معلومات الاتصال الخاصة بهم بمجرد حصولك على الموافقة للبدء في المشروع. هذا هو أحد الأشخاص الذين سيكونون قادرين على الإجابة عن أسئلتك ذات المستوى العالي. إذا كنت تعمل مع شركة أصغر، فسيكون من الجيد أيضًا الحصول على معلومات الاتصال لشخص مثل الرئيس التنفيذي (CEO) أو المدير التنفيذي للتقنية (CTO)، لأنهم سيكونون قادرين على إعطائك إجابة مباشرة بنعم أو لا على العديد من الأسئلة التي لديك. على سبيل المثال، إذا بحثت عن خدمة قاعدة بيانات جديدة ستقلل فاتورتهم بنسبة 10% وتزيد من الأداء العام للتطبيق، فأنت تريد معرفة ما إذا كان يمكنك إجراء هذه التغييرات أم لا. تعرف على الأشخاص الذين يمكنهم منحك الموافقة أو التوجيه للخطوات التالية التي تتخذها، ثم احفظ عناوين بريدهم الإلكتروني وأرقام هواتفهم. إحدى الحالات التي يكون فيها هذا الأمر بالغ الأهمية هي إذا حدثت مشكلة طارئة (fire) في بيئة الإنتاج. عندما تتمكن من الحصول على تلك القرارات السريعة فورًا، يمكن أن يوفر ذلك على الشركة آلاف الدولارات، لذا سيتفهمون إذا اتصلت بهم.

فهم الجدول الزمني للمشروع ووضع تقديرات واقعية

في بعض الأحيان، من السهل جدًا الانغماس في التفاصيل الدقيقة، وعندما يُطرح جدول زمني (timeline)، يبدو الموافقة عليه منطقية. قبل الالتزام الكامل بأي فترة عمل، تأكد من أنك قمت بتقييم مناسب لما يُطلب منك القيام به بالموارد المتاحة لك. قم بمسح سريع للكود (code sweep) للحصول على فكرة عما ستعمل عليه، ولاحظ المدة التي يستغرقها الأشخاص للرد على أسئلتك الأولية. بهذه الطريقة، عندما تُعطى موعدًا نهائيًا (deadline)، يمكنك شرح سبب كونه معقولًا أو غير معقول لكمية العمل المطلوبة.

وضع تقديرات واقعية وتجنب التوقعات غير المنطقية

عليك دائمًا تقديم تقديرات واقعية حتى لا يرفع عميلك أو مدير المشروع آمال الآخرين. من الأفضل إخبارهم مقدمًا إذا كان شيء ما سيستغرق وقتًا أطول أو أقصر مما يتوقعون. عندما تكون لديك توقعات معقولة، فإن ذلك يجعل المشروع بأكمله يسير بشكل أفضل للجميع. لن تكون هناك العديد من جلسات البرمجة المذعورة، وستتمكن من تقديم كود عالي الجودة لن يحتاج إلى تصحيح أخطاء (debugged) في بيئة الإنتاج.

تحديد نطاق العمل (Scope of Work) بدقة

يميل نطاق المشاريع (scope of projects) إلى التوسع ببطء مع تقدمك. تبدأ في تلقي بعض الملاحظات هنا وهناك حول “تعديلات صغيرة” يجب إجراؤها. ثم يتحول الأمر إلى مسألة تحديد الأولويات، ويصبح العمل مختلفًا عن العمل الأصلي الذي بدأت به.

استراتيجيات منع زحف النطاق (Scope Creep)

إحدى طرق منع زحف النطاق (scope creep) هي الاتفاق على قائمة محددة من المهام أو وظيفة معينة تحتاج إلى تنفيذها. يمكن تدوين أي شيء آخر وطرحه في جزء آخر من عمل المشروع، ولكن ليس في الوقت الحالي. بمجرد الاتفاق على العمل، يجب أن تكون هناك حالة نهائية واضحة سيكون عليها المشروع في النهاية.

يُعد استلام مشروع قائم مهارة خاصة لأنه ليس شيئًا تفعله طوال الوقت. يعمل بعض المطورين على منتج واحد أو خط إنتاج واحد لجزء كبير من حياتهم المهنية، لذا فإن إعداد مشاريع جديدة يحدث فقط بين الحين والآخر. ومع ذلك، إذا كنت تعمل في مجال الاستشارات أو العمل الحر (freelance)، فستحتاج إلى معرفة كيفية القيام بذلك بثقة وبشكل منتظم. عادة ما تكون هناك تغييرات صغيرة في التكوين (configuration changes) يجب عليك اكتشافها، وبمجرد إعدادها، لن تضطر إلى القلق بشأنها مرة أخرى. هذه مجرد بعض الأمور التي أحاول التحقق منها عند إعداد مشروع جديد. تنطبق بعض هذه النصائح على مشاريع المصادر المفتوحة (open source projects) أيضًا.

الخلاصة التقنية

إن استلام مشروع برمجي قائم بنجاح يتطلب أكثر من مجرد مهارات برمجية؛ إنه يتطلب نهجًا منظمًا، وفضولًا استباقيًا، ومهارات تواصل قوية. من خلال التركيز على فهم الغرض الأساسي للتطبيق، وإتقان أنظمة التحكم بالمصادر، وتبسيط عملية الإعداد، واستيعاب سير عمل الاختبارات والنشر، وتحديد نقاط الاتصال الرئيسية، والتعرف على الخدمات الخارجية، والتواصل الفعال مع صناع القرار، ووضع تقديرات واقعية، وتحديد نطاق العمل بدقة، يمكن للمطورين ضمان انتقال سلس وفعال. هذه الخطوات لا تقلل فقط من المخاطر المحتملة، بل تضع أيضًا أساسًا متينًا للتطوير المستقبلي، مما يضمن جودة الكود واستمرارية المشروع.