سعر إعادة البيع

ذاتيًا: إعادة البناء هي "مرض" شبابي. وفقًا للملاحظات الشخصية ، يبدأ مكان ما بعد 26 عامًا في التخلي عنه. كما في تلك العبارة القديمة: "من لم يكن ثوريًا في شبابه - ليس لديه قلب ، ومن لا يصبح محافظًا في النضج - ليس لديه عقل". لذلك ، حتى أتركه أخيرًا ، سأحاول أن أصف حالات إعادة هيكلة المستخدم والأهداف المحتملة التي يمكن تحقيقها معها.

إلهام

لقد بدأت في الكتابة بعد العرض التالي لطلب السحب لأكثر من 150 ملفًا ، حيث تم إشراك الوظائف الجديدة وإعادة هيكلة الملف الحالي بشدة. لم يكن إعادة البناء مجرد مستحضرات تجميل ، بل كان منطقيًا أيضًا ، مما تسبب في ألم كبير. على سبيل المثال ، في Ruby ، amount == 0 استبدال amount == 0 بجرأة بـ amount.zero? دون الأخذ في الاعتبار أنه في حالة nil amount هذه الإنشاءات ليست متكافئة. تم شرح كل هذا تقريبًا على النحو التالي: "ولكن وفقًا للكود ، فإن المعيار يفترض ذلك!" إلى السؤال المنطقي "ما هو الغرض من اتباع التعليمات البرمجية إلى المعيار وبشكل عام ، ما هو هدفك كمطور؟" الرجل حبس نفسه وكرر مذنبًا قليلًا "ولكن وفقًا لمعيار الشفرة ، عليك أن تكتب مثل هذا ..." وبدا أشقرًا في متجر ملابس لا يمكنه التعامل مع الرغبة إعادة التصنيع شراء كل شيء.

التعريف

الموضوع حساس ، لذلك عليك أن تولي اهتمامًا خاصًا للسؤال "من هو؟" لذلك ، وفقًا لويكي ، إعادة الهيكلة هي عملية تغيير الهيكل الداخلي لبرنامج لا يؤثر على سلوكه الخارجي ويهدف إلى تسهيل فهم عمله.

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

أي ، لا أريد أن أتحدث عن التغيير المخطط له في قاعدة الكود ، والذي تم تحديد نطاق العمل من أجله وتم تحديد أهداف محددة ، ولكن حول التعديلات التلقائية التي تحدث أثناء التطوير.

قيمة المنتج

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

قيم المنتج المباشرة

كل شيء بسيط هنا. يستخدمون المنتج ، لذا فإن القيم المباشرة هي ما يشعر به المستخدم بوضوح أو يراه / يشعر به. وهي:

1. جميع أنواع وظائف المنتج ؛
2. سهولة الاستخدام (UI / UX ، والأداء ، والتسامح مع الخطأ ، وما إلى ذلك).

قد تتسبب النقطة الثانية في بعض المناقشة. بعد كل شيء ، يعتقد الكثيرون أن هذا ليس هو الشيء الرئيسي. نظرًا لأنه إذا كانت الوظيفة جيدة ، فلا يهم ما يتم تغليفها به. أمثلة جيدة على الوظائف بدون واجهة مستخدم / UX سليمة: Redmine و SAP . ومع ذلك ، أنا اختلف مع هذه النظرة وأقرب في الرأي إلى الرفيق آلان كوبر و "مستشفى الطب النفسي في أيدي المرضى".

قيم المنتج غير المباشرة

هذه هي القيم التي لا تؤثر في حد ذاتها على المستخدم. ولكن يمكنهم "إطلاق النار" أو "التراكم" ويكون لهم تأثير (بدرجات متفاوتة) على المنتج أو وظائفه.

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

قيم المطور

فئة مهمة جدًا يتجاهلها الكثيرون ولكنها تؤثر دائمًا على النتيجة.

1. كود بالمعيار.
2. المسافة البادئة على فنغ شوي.
3. معاملات أخرى بضمير. بعد كل شيء ، تم كتابة الرمز ، لذلك هناك نتيجة لهذا اليوم ، وبالتالي هناك فائدة.
4. الامتثال للقانون مع العالم الداخلي.

لكن لنكن صادقين. كل هذا لا يتعلق بالقيم المرتبطة بالمنتج والمستخدم النهائي. هذا عن علم النفس والصراصير الشخصية.

عرض من جانب الأعمال

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

على سبيل المثال.

• ميزة جديدة مع ثبات OAuth زادت عدد التسجيلات بنسبة 10٪ وحصلنا على + 1 ألف دولار.
• قمنا بتقسيم وحدة الفوترة إلى عدة أجزاء مستقلة ، بناءً على نمط المسؤولية الفردية. يبدو أنه أصبح من الأسهل الحفاظ عليها ، ولكن لم يكن من الممكن قياسها.
• جلبنا قاعدة الكود بما يتماشى مع معيار الكود ولم نتلق أي شيء.

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

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

وماذا عن إعادة البناء؟

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

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

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

لذلك ، إذا اعتبرنا إعادة الهيكلة جزءًا من عملية صيانة البرنامج ، فكلما قل حجم إعادة الهيكلة ، زادت مدة بقاء الشفرة دون إعادة الكتابة.

ما هي الأهداف التي يمكن إعادة بنائها؟

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

من أجل الكون!

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

للتوثيق!

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

للسرعة!

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

يقع كل شيء في هذه الفئة: من التصحيح غير الضار لـ N + 1 إلى التسارع الخطير بسبب التغيرات في خوارزميات التشغيل. تكمن المشكلة برمتها في أن "تماثل" الحشرات يكمن دائمًا في السرعة. في ما يلي مثال على ذلك: في بيانات المعاملة في قاعدة البيانات يتم دفعها وفي نفس المعاملة يتم تعيين مهمة في Sidekiq ؛ طابور Sidekiq في Redis والمعاملة لا تنطبق عليه ؛ عندما تزداد سرعة قائمة الانتظار ، يتم تنفيذ المهمة أحيانًا للتنفيذ قبل الالتزام بالبيانات ؛ يمكنك تخيل العواقب وعملية التصحيح بنفسك.

لإعادة هيكلة!

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

أتمنى أن تفهم أنك لا تحتاج إلى التفكير في نفسك ، بل في من تفعل ذلك.

التواضع والقبول

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

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

شرح صغير.

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

ومرة أخرى: إذا كنت لا توافق على واحدة على الأقل من النقاط - لا تبدأ إعادة بيعها. من الأفضل قراءة هابر ، لورك ، شرب الشاي أو ، في أسوأ الأحوال ، قم بتحطيم الميزة التالية من لوحة القيادة.

النهاية

لا تحكم بدقة. إذا كان ذلك ممكنًا ، انتقد بشكل بناء. وفكر دائمًا في الغرض من أفعالك. شكرا لك