سؤال

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

# app\controller\reports_controller.rb

 @report_lines  = []
   @sum_wp, @sum_projcted_wp, @sum_il, @sum_projcted_il, @sum_li,@sum_gross_profit ,@sum_opportunities = [0,0,0,0,0,0,0]    
 date = @start_date

 num_of_months.times do
    wp,projected_wp, invoice_line,projected_il,line_item, opp = Report.data_of_invoicing_and_delivery_report(@part_or_service,date)
    @sum_wp += wp
    @sum_projcted_wp +=projected_wp
    @sum_il=invoice_line
    @sum_projcted_il +=projected_il
    @sum_li += line_item
    gross_profit = invoice_line - line_item
    @sum_gross_profit += gross_profit
    @sum_opportunities += opp
    @report_lines << [date.strftime("%m/%Y"),wp,projected_wp ,invoice_line,projected_il,line_item,gross_profit,opp]
    date = date.next_month
 end

أنا أتطلع إلى استخدام بعض الأسلوب مثل

@sum_a,@sum_b,@sum_c += [1,2,3] 
هل كانت مفيدة؟

المحلول

فكرتي الفورية هي: حرك الرمز إلى نموذج.

يجب أن يكون الهدف "وحدات تحكم رقيقة"، لذلك يجب ألا تحتوي على منطق الأعمال.

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

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

سيصبح رمز تحكم الخاص بي شيءا مثل هذا:

@report_lines, @report_totals = Report.summarised_data_of_inv_and_dlvry_rpt(@part_or_service, @start_date, num_of_months)

تحرير: (بعد يوم واحد)

بالنظر إلى أن إضافة شيء المتراكم إلى حد صفيف، وصلت إلى هذا:

require 'test/unit'

class Array
  def add_corresponding(other)
    each_index { |i| self[i] += other[i] }
  end
end

class TestProblem < Test::Unit::TestCase
  def test_add_corresponding
    a = [1,2,3,4,5]
    assert_equal [3,5,8,11,16], a.add_corresponding([2,3,5,7,11])
    assert_equal [2,3,6,8,10], a.add_corresponding([-1,-2,-2,-3,-6])
  end
end

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

قد تقلل طريقة صفيف جديدة لدينا من التعليمات البرمجية الأصلية إلى شيء مثل هذا:

totals = [0,0,0,0,0,0,0]    
date = @start_date

num_of_months.times do
  wp, projected_wp, invoice_line, projected_il, line_item, opp = Report.data_of_invoicing_and_delivery_report(@part_or_service,date)
  totals.add_corresponding [wp, projected_wp, invoice_line, projected_il, line_item, opp, invoice_line - line_item]
  @report_lines << [date.strftime("%m/%Y"),wp,projected_wp ,invoice_line,projected_il,line_item,gross_profit,opp]
  date = date.next_month
end

@sum_wp, @sum_projcted_wp, @sum_il, @sum_projcted_il, @sum_li, @sum_opportunities, @sum_gross_profit = totals 

... أي ما إذا كان التقرير # Data_of_invoice_and_delivery_report قد يحسب أيضا gross_profit من شأنه أن يقلل كذلك إلى:

num_of_months.times do
  totals.add_corresponding(Report.data_of_invoicing_and_delivery_report(@part_or_service,date))
end

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

نصائح أخرى

قم بإنشاء كائن ملخص يحتوي على كل هذه الحقول، وجعل الصفيف بأكمله إلى @ sum.incrent_sums (report.data_of ...)

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top