การวิเคราะห์แบบอัตนัยและวัตถุประสงค์ของ Kotlin และ Java

Kotlin

Kotlin เป็นภาษา JVM ที่ค่อนข้างใหม่และ Jetbrains ได้รับการพัฒนาอย่างแข็งขันมาตั้งแต่ปี 2011

ในช่วงหลายปีที่ผ่านมาภาษาได้รับความสนใจเพิ่มขึ้นในชุมชน Android และได้กลายเป็นหัวข้อที่ร้อนแรงที่สุดในการพัฒนา Android หลังจากการประชุม Google IO 2017 การประชุมประกาศว่า Android สนับสนุน Kotlin อย่างเป็นทางการ

น่าเสียดายที่ในขณะที่มีบทความมากมายเกี่ยวกับ Kotlin แต่ก็มีข้อมูลที่มีวัตถุประสงค์ไม่มากนักและนักพัฒนาหลายคนยังคงคิดว่าการย้ายไปที่ Kotlin เป็นเส้นทางที่ถูกต้องหรือไม่

ในส่วนที่เหลือของบทความนี้ฉันจะพยายามจัดทำรายการสิ่งต่าง ๆ ที่สมบูรณ์ยิ่งขึ้นเมื่อประเมิน Kotlin เป็นทางเลือกแทน Java

การเปรียบเทียบอัตนัยระหว่าง Kotlin และ Java

"Kotlin ดีกว่า Java", "Kotlin อ่านง่ายกว่า Java", "ความเร็วในการพัฒนา Kotlin เร็วกว่า Java" ข้อความเช่นนี้ขาดการสนับสนุนของข้อมูลที่ถูกต้องที่เกี่ยวข้องดังนั้นพวกเขาจึงถูกจัดประเภทเป็นมุมมองส่วนตัว

มุมมองอัตนัยเกิดขึ้นเมื่อนักพัฒนาแต่ละคนทำการตัดสินแบบอัตนัยอย่างน้อยหนึ่งเรื่องเกี่ยวกับหัวข้อที่เกี่ยวข้องกับ Kotlin หรือ Java

มีปัญหาเกี่ยวกับการตัดสินอัตนัยของนักพัฒนาต่อไปนี้:

ไม่มีตัวชี้วัดเชิงปริมาณที่เกี่ยวข้องกับการตัดสินแบบอัตนัย
มีอคติที่ดีในการตัดสินอัตนัย
อคติของการตัดสินแบบอัตนัยแตกต่างกันอย่างมากในหมู่นักพัฒนา
เนื่องจากไม่มีตัวชี้วัดเชิงปริมาณที่เกี่ยวข้องกับการตัดสินเชิงอัตวิสัยมุมมองที่อยู่บนพื้นฐานของการตัดสินเหล่านี้สะท้อนให้เห็นถึงอคติที่นักพัฒนาเคยมีมาก่อน นักพัฒนาที่แตกต่างกันอาจมีอคติที่แตกต่างกันมากดังนั้นจึงไม่ได้หมายความว่านักพัฒนาคนอื่น ๆ ก็คิดเช่นกัน

ยิ่งกว่านั้นเนื่องจากไม่มีตัวชี้วัดที่มีวัตถุประสงค์ความแตกต่างส่วนตัวจึงไม่สามารถกำจัดได้อย่างเป็นกลางซึ่งมักจะนำไปสู่ "สงครามคำพูด"

การเข้าใจผิดของการตัดสินแบบอัตนัย

เพื่อแสดงให้เห็นถึงความเข้าใจผิดที่การตัดสินอัตนัยสามารถนำไปสู่ให้เราดูมุมมองเชิงอัตวิสัยที่พบบ่อยมากขึ้น:

 Kotlin สามารถอ่านได้มากกว่า Java - บทความนับไม่ถ้วนบนเว็บ

ในทางทฤษฎีมีความเป็นไปได้ที่จะพยายามออกแบบการทดลองที่วัดความแตกต่างในการอ่านระหว่าง Kotlin และ Java แต่เท่าที่ฉันรู้ไม่มีใครทำการทดลองเช่นนี้ ดังนั้น ณ ตอนนี้มุมมองนี้ไม่มีการสนับสนุนข้อมูล

ไวยากรณ์ของ Kotlin เป็นเหตุผลหนึ่งที่นักพัฒนาหลายคนชื่นชมความสามารถในการอ่าน ตรรกะของพวกเขามีดังนี้:

 Kotlin มีไวยากรณ์ที่ดีกว่าดังนั้นจึงสามารถอ่านได้มากขึ้น - บทความนับไม่ถ้วนบนเว็บ

ในประโยคนี้ "Better Grammar" เป็นคำพิพากษาที่เป็นอัตวิสัยอีกประการหนึ่งซึ่งเป็นที่ถกเถียงกันอยู่ แต่เพื่อหลีกเลี่ยงข้อโต้แย้งเราคิดว่าไวยากรณ์ของ Kotlin นั้นดีกว่า อย่างไรก็ตามนี่หมายความว่า Kotlin อ่านง่ายขึ้นหรือไม่?

หากต้องการสังเกตผลของไวยากรณ์ต่อความสามารถในการอ่านอ่านย่อหน้านี้ของ "ข้อความ":

ในตอนแรก "ข้อความ" นี้ยากที่จะเข้าใจ แต่ช้ามันจะอ่านง่ายขึ้น หากคุณอ่านสองหรือสามครั้งคุณจะไม่สังเกตว่ามันประกอบด้วยตัวอักษรที่ไม่ได้มาตรฐาน เพื่อความแม่นยำการเปลี่ยนจดหมายไม่ใช่การเปลี่ยนแปลงทางไวยากรณ์ แต่มันแสดงให้เห็นว่าลักษณะที่ปรากฏไม่ค่อยกลายเป็นอุปสรรคต่อการอ่านสำหรับผู้อ่านที่มีทักษะ

นอกจากนี้เรายังสามารถขยายตัวอย่างนี้เป็นภาษาธรรมชาติ ฉันเข้าใจสามภาษาที่แตกต่างอย่างสิ้นเชิง แม้ว่าพวกเขาจะแตกต่างกันอย่างมาก แต่ฉันพบว่ามันยากมากที่จะอ่านข้อความในภาษาทั้งสองเมื่อฉันไม่เข้าใจคำที่ใช้ในข้อความ เมื่อฉันรู้คำพูดที่ประกอบขึ้นเป็นข้อความและคุ้นเคยกับบริบท - ไม่ว่าจะเป็นภาษาใดฉันก็ไม่ได้อ่านมันยาก

ดังนั้นสำหรับฉันการเลือกภาษาไม่ส่งผลกระทบต่อความสามารถในการอ่านเพียงแค่เข้าใจเนื้อหาและบริบท

เช่นเดียวกับภาษาการเขียนโปรแกรม

เมื่อเราเริ่มใช้ภาษาใหม่เราจะมีความยากลำบากในการทำความเข้าใจซอร์สโค้ดและจำเป็นต้องเข้าใจโครงสร้างวากยสัมพันธ์แต่ละอย่างอย่างรอบคอบ อย่างไรก็ตามในขณะที่เราอ่านและเขียนโค้ดสำหรับภาษาที่เฉพาะเจาะจงมากขึ้นเรื่อย ๆ เราค่อยๆคุ้นเคยกับไวยากรณ์ของภาษานั้นและในบางจุดเราจะไม่ให้ความสนใจกับโครงสร้างวากยสัมพันธ์อีกต่อไป

ฉันมีประสบการณ์นี้ในหลายภาษาด้วยตัวเอง: Verilog, Bash, Perl, TCL, Lisp, Java

จากประสบการณ์ของฉันกับภาษาข้างต้นฉันสามารถบอกคุณได้ว่า: หากบุคคลใดปรับให้เข้ากับรหัสของ Lisp และไม่ได้สังเกตวงเล็บอีกต่อไปแล้วไวยากรณ์ของ Kotlin จะไม่สามารถส่งผลกระทบต่อการอ่านได้เมื่อเทียบกับ Java แม้ว่าจะเป็น "ดีกว่า"

เนื่องจากเรากำลังพูดถึงหัวข้อนี้ฉันจะแบ่งปันการตัดสินส่วนตัวของฉันเกี่ยวกับปัจจัยที่มีผลต่อความสามารถในการอ่านซอร์สโค้ด

หลังจากอ่านรหัสที่เขียนโดยนักพัฒนาอื่น ๆ ในหลายภาษา (รายการข้างต้นเฉพาะภาษาที่ฉันมีความเชี่ยวชาญในบางขั้นตอนฉันใช้ภาษามากกว่านี้) ฉันมาถึงข้อสรุปต่อไปนี้: หากนักพัฒนาสามารถเขียนโค้ดที่สามารถอ่านได้และเข้าใจได้ในภาษาเดียว

ดังนั้นการตัดสินเชิงอัตวิสัยที่ฉันทำตามประสบการณ์ของฉันเองคือการอ่านของซอร์สโค้ดไม่มีส่วนเกี่ยวข้องกับภาษาที่เลือกและขึ้นอยู่กับทักษะของผู้เขียนโค้ดและทักษะของผู้อ่าน (ทักษะของนักเขียนมีความสำคัญมากกว่า)

หากคุณยังคิดว่ามุมมองอัตนัยเป็นตัวแทนอย่างน้อยก็อ่านและคิดว่าโรเบิร์ต“ ลุงบ๊อบ” มาร์ตินคิดอย่างไรในโพสต์บล็อกนี้

การเปรียบเทียบวัตถุประสงค์ระหว่าง Kotlin และ Java

ตรงกันข้ามกับการเปรียบเทียบแบบอัตนัยการเปรียบเทียบวัตถุประสงค์ใช้ตัวชี้วัดเชิงปริมาณเพื่อวัดหรือประเมินว่า Kotlin มีข้อได้เปรียบมากกว่า Java

แนวคิดของการพิสูจน์อย่างเป็นกลางว่าภาษาการเขียนโปรแกรมดีกว่าอีกชุดหนึ่งที่มีมาตรฐานหนึ่งนั้นน่าสนใจมาก แต่มีปัญหาหรือไม่เท่าที่ฉันรู้ไม่มีตัวบ่งชี้วัตถุประสงค์ทั่วไปที่เกี่ยวข้องกับภาษาการเขียนโปรแกรม

เนื่องจากเราไม่สามารถทำการเปรียบเทียบที่แม่นยำและตรงไปตรงมาเราสามารถเปรียบเทียบ Kotlin และ Java ได้อย่างเป็นกลางหรือไม่? สามารถ! เรายังสามารถประเมินขอบเขตของผลกระทบเชิงบวกและการส่งข้อความของการสลับจาก Java เป็น Kotlin จากนั้นเปรียบเทียบผลลัพธ์และหารือเกี่ยวกับผลกระทบของพวกเขา

ในการประเมินผลลัพธ์ที่ดีที่สุดที่ Kotlin สามารถผลิตได้เราจะทำสมมติฐานดังต่อไปนี้:

นักพัฒนาสามารถเปลี่ยนเป็น Kotlin ได้ทันที

หลังจากเปลี่ยนมาใช้ Kotlin นักพัฒนาไม่สูญเสียทักษะใด ๆ (ตัวอย่างเช่นนักพัฒนาที่มีประสบการณ์การพัฒนา Java สองปีสามารถได้รับประสบการณ์การพัฒนา Kotlin สองปีอย่างน่าอัศจรรย์);
Kotlin มีความมั่นคงเท่ากับ Java;
เครื่องมือ KOTLIN นั้นครบกำหนดเหมือนเครื่องมือ Java

ในความเป็นจริงไม่มีสมมติฐานข้างต้นมีเหตุผล แต่ในตอนแรกมีการตั้งค่าที่เหมาะสำหรับคำอธิบายที่ง่าย จากนั้นเราจะวางสมมติฐานเหล่านี้และหารือเกี่ยวกับผลกระทบของผลกระทบในโลกแห่งความเป็นจริง

Kotlin ผลลัพธ์ที่ดีที่สุด

ตามแบบจำลองที่เสนอโดย Steve McConnell ใน Code Complete เราสามารถแบ่งกิจกรรมการก่อสร้างซอฟต์แวร์ออกเป็นสามกิจกรรมย่อย: การออกแบบโดยละเอียดการเข้ารหัสและการดีบักและการพัฒนาและการทดสอบ

Kotlin มีผลเพียงเล็กน้อยต่อการออกแบบกิจกรรมย่อยในรายละเอียด (กิจกรรมนี้มักจะเป็นอิสระจากภาษาการเขียนโปรแกรมเชิงวัตถุที่เลือกโดยเฉพาะ) ดังนั้น Kotlin และ Java จึงจำเป็นต้องใช้ความพยายามเดียวกันในส่วนนี้

เท่าที่ฉันรู้ Kotlin ยังไม่ได้เสนอสิ่งที่ปฏิวัติเกี่ยวกับกิจกรรมย่อยการทดสอบการพัฒนา ดังนั้นจึงเป็นจริงสำหรับการพัฒนาการทดสอบ

การเข้ารหัสและการดีบักกิจกรรมย่อยทั้งหมดจะถูกทิ้งไว้

ถ้าเราแทนที่ Java ด้วย Kotlin ฉันจะประหยัดงานได้มากแค่ไหนในการเขียนโค้ดและการดีบัก คำถามนี้ตอบยากและค่านี้แตกต่างกันอย่างมากระหว่างโปรแกรมเมอร์ (โปรแกรมเมอร์บางคนใช้ Java ได้อย่างมีประสิทธิภาพมากขึ้น) อย่างไรก็ตามตอนนี้เรากำลังประเมินสถานการณ์ที่ดีที่สุดเราอาจสันนิษฐานได้ว่าการเปลี่ยนจาก Java เป็น Kotlin สามารถเพิ่มผลผลิตของนักพัฒนาได้โดยเฉลี่ย 10% ในระหว่างการเข้ารหัสและการดีบัก

การเพิ่มผลิตภาพ 10% เป็นค่าที่ไม่สมจริงอย่างน่าประหลาดใจ แม้ว่าเราจะป้อนรหัสทั้งหมดด้วยตนเองในตัวแก้ไขข้อความนั่นก็ไม่สมจริง เมื่อพิจารณาถึงฟังก์ชั่นปัจจุบันของ IDEs ค่านี้ไม่สมจริงยิ่งขึ้น เมื่อพิจารณาว่านักพัฒนาบางคนใช้ Java ได้อย่างมีประสิทธิภาพมากขึ้นค่านี้ไม่สมเหตุสมผล

ฉันไม่รังเกียจที่จะใช้คุณค่าที่ไม่สมจริงและเป็นประโยชน์ต่อการประเมินของ Kotlin เพราะฉันรู้ว่าไม่ว่าจะเป็นผลบวกที่ไม่สมจริงในผลการประเมินเมื่อเราวาง "สมมติฐานในอุดมคติ" บางอย่างผลกระทบเชิงลบที่เกิดขึ้นจะชดเชยผลกระทบเชิงบวกเหล่านั้น

ดังนั้นในแง่ของการเข้ารหัสและการดีบักเราเพิ่มขึ้น 10% - เราส่งมอบผลิตภัณฑ์ของเราให้กับลูกค้าของเราเร็วแค่ไหน?

ภาพต่อไปนี้มาจากรหัสหนังสือที่สมบูรณ์โดยแสดงสัดส่วนของกิจกรรมต่าง ๆ ของโครงการซอฟต์แวร์:

โครงการขนาดเล็กของภาพมุ่งเน้นไปที่กิจกรรมการก่อสร้าง โครงการขนาดใหญ่ต้องการสถาปัตยกรรมการรวมและการทดสอบระบบมากขึ้นเพื่อให้แน่ใจว่าโครงการประสบความสำเร็จ ภาพนี้ไม่ได้แสดงข้อกำหนดเนื่องจากไม่เหมือนกับกิจกรรมอื่น ๆ ความต้องการงานไม่ใช่ฟังก์ชั่นโปรแกรมโดยตรง (Albrecht 1979; Glass 1982; Boehm, Grey และ Seewaldt 1984; Boddie 1987; Card 1987; McGarry, Waligora และ McDermott 1989; Brooks 1995; Jones 1998; Jones 2000; Boehm et al. 2000))
Code Complete, Second Edition

จากภาพนี้จากรหัสเสร็จสมบูรณ์ในโครงการซอฟต์แวร์ขนาดใหญ่ (มากกว่า 10k บรรทัด) การเข้ารหัสและการดีบักบัญชีน้อยกว่า 20% ของภาระงานโครงการทั้งหมด

ดังนั้นในโครงการซอฟต์แวร์ขนาดใหญ่การเข้ารหัสและประสิทธิภาพการดีบักที่เราสันนิษฐานคือ 10%ซึ่งสามารถลดปริมาณงานทั้งหมดที่จำเป็นเพื่อให้โครงการเสร็จสมบูรณ์ 2%

ตัวอย่างเช่นโครงการที่ใช้เวลา 5 คนในการดำเนินการมาหลายปี (นี่เป็นโครงการ Android ที่ค่อนข้างใหญ่) 2% ของปริมาณงานทั้งหมดคือ:

5 คน - ปี * 12 * 4 * 5 * 0.02 = 24 (คน - วัน)
หากเราสามารถลดภาระงานของโครงการได้ 24 วันต่อวันมันจะเป็นเหตุผลที่ดีที่จะเปลี่ยนจาก Java เป็น Kotlin อย่างไรก็ตามเราควรจำไว้ว่าการประเมินเชิงบวกข้างต้นนั้นได้มาในสถานการณ์ในอุดมคติและขึ้นอยู่กับสมมติฐานที่ไม่สมจริง

ในโลกแห่งความเป็นจริงการเปลี่ยนไปใช้ภาษาการเขียนโปรแกรมอื่นมีผลกระทบอย่างหลีกเลี่ยงไม่ได้ซึ่งเราจะประเมินและเปรียบเทียบกับการประเมินในอุดมคติที่กล่าวถึงข้างต้น

การเตรียมนักพัฒนา

ในการประเมินสถานการณ์กรณีที่ดีที่สุดเราคิดว่านักพัฒนาสามารถเปลี่ยนจาก Java เป็น Kotlin ได้ทันที

ในความเป็นจริงในขณะที่ Kotlin คล้ายกับ Java นักพัฒนายังคงต้องใช้เวลาเรียนรู้และใช้เวลาในการปรับแต่งการพัฒนาและเครื่องมือ เวลาการเตรียมการแตกต่างกันไปในแต่ละบุคคล: นักพัฒนาบางคนสามารถสลับระหว่างสามหรือสี่วันในขณะที่คนอื่นอาจใช้เวลา 10 วันหรือมากกว่า

โดยเฉลี่ยแล้วนักพัฒนาแต่ละคนสามารถเปลี่ยนจาก Java เป็น Kotlin ในเวลาเพียง 5 วัน

โครงการที่ใช้เวลา 5 ปีในการดำเนินการให้เสร็จสมบูรณ์จะมีนักพัฒนา 3 ถึง 5 คน (ในกรณีที่ดีที่สุด) เวลาสลับเฉลี่ยสำหรับนักพัฒนาแต่ละคนคือ 5 วันดังนั้นโครงการใช้เวลาทั้งหมด 15 ถึง 25 วันสลับต่อวัน

ความพยายามที่บันทึกไว้โดยการเปลี่ยนไปใช้ Kotlin (การประเมินในแง่ดี) ดูเหมือนจะเป็นเรื่องเดียวกันกับความพยายามทั้งหมดที่จำเป็นสำหรับการสลับ

การสูญเสียทักษะการพัฒนา

ความสามารถในการทำงานอย่างมีประสิทธิภาพในภาษาการเขียนโปรแกรมที่เฉพาะเจาะจงเป็นทักษะ

เราได้พูดถึงแง่มุมหนึ่งของทักษะนี้ (ความสามารถในการอ่านรหัส) แต่มีคนอื่น ๆ อีกมากมาย เมื่อเปลี่ยนจากภาษาหนึ่งไปอีกภาษาหนึ่งทักษะบางอย่างที่เกี่ยวข้องกับภาษาการเขียนโปรแกรมเก่าสามารถนำไปใช้กับภาษาใหม่ได้ แต่ส่วนอื่น ๆ ของทักษะจะหายไป

เพื่อประเมินผลกระทบของการสูญเสียทักษะการเขียนโปรแกรมต่อภาระงานของโครงการเราจะใช้ปัจจัย "ประสบการณ์ภาษาและเครื่องมือ" ที่ได้จากรูปแบบการประเมิน COCOMO2:

ประสบการณ์ภาษาและเครื่องมือ (LTEX)

ตัวชี้วัดนี้ใช้ในการวัดประสบการณ์ของทีมโครงการที่พัฒนาระบบซอฟต์แวร์หรือระบบย่อยโดยใช้ภาษาการเขียนโปรแกรมและเครื่องมือซอฟต์แวร์ การพัฒนาซอฟต์แวร์รวมถึงการใช้เครื่องมือในการทำข้อกำหนดการออกแบบและวิเคราะห์การแสดงออกการจัดการการกำหนดค่าการสกัดเอกสารการจัดการห้องสมุดรูปแบบของโปรแกรมและการจัดรูปแบบการตรวจสอบความสอดคล้องการวางแผนและการควบคุม ฯลฯ นอกเหนือจากประสบการณ์การเขียนโปรแกรมภาษาโครงการประสบการณ์ของชุดเครื่องมือสนับสนุนโครงการอาจส่งผลกระทบต่อความพยายามในการพัฒนา ประสบการณ์ต่ำกว่า 2 เดือนจะได้รับคะแนนต่ำมากและประสบการณ์ต่ำกว่า 6 เดือนหรือปีจะได้รับคะแนนสูงมากดูตารางด้านล่าง:

ฉันไม่รู้ว่านี่คือการลดลงแบบไหนมีกี่โครงการที่ได้รับผลกระทบ แต่สมองของฉันแปลการรวมกันของ "การลดลงอย่างมีประสิทธิภาพที่สำคัญ" โดยอัตโนมัติ "เสียเวลาในการพัฒนาหลายชั่วโมง"

นอกจากนี้หากคุณอ่านความคิดเห็นเกี่ยวกับบันทึกการโพสต์คุณจะสังเกตเห็นว่าหลายคนกำลังมีปัญหาการย้ายถิ่น ในความคิดเห็นเกี่ยวกับเวอร์ชัน 1.1.2 บางคนยังชี้ให้เห็นว่าการเปิดตัว "แพตช์" นี้ได้แนะนำการแก้ไขการทำลายล้าง (ย้อนหลังไม่เข้ากัน)

ในทางตรงกันข้ามถ้าคุณอ่านโน้ตของ Oracle JDK8 คุณจะพบว่ามันค่อนข้างเสถียร การดัดแปลงส่วนใหญ่เป็นการปรับปรุงความปลอดภัย

ดังนั้น Kotlin จึงเป็นภาษาที่ไม่มั่นคงและยังไม่บรรลุนิติภาวะเมื่อเทียบกับ Java - การย้ายถิ่นฐานไปยัง Kotlin จะมีอะไรในโครงการ? เพื่อตอบคำถามนี้ฉันจะใช้ปัจจัยการทำงาน "แพลตฟอร์มความผันผวน" จากรูปแบบการประเมิน Cocomo 2:

 ความผันผวนของแพลตฟอร์ม (PVOL) ที่นี่คำว่า "แพลตฟอร์ม" หมายถึงฮาร์ดแวร์และซอฟต์แวร์ที่ซับซ้อน (OS, DBMS ฯลฯ ) ที่เรียกว่าเมื่อผลิตภัณฑ์ซอฟต์แวร์ทำงาน หากซอฟต์แวร์ที่พัฒนาขึ้นเป็นระบบปฏิบัติการแล้วแพลตฟอร์มคือฮาร์ดแวร์คอมพิวเตอร์ หากระบบการจัดการฐานข้อมูลได้รับการพัฒนาแล้วแพลตฟอร์มคือฮาร์ดแวร์และระบบปฏิบัติการ หากเบราว์เซอร์ข้อความเครือข่ายได้รับการพัฒนาแล้วแพลตฟอร์มคือเครือข่ายฮาร์ดแวร์คอมพิวเตอร์ระบบปฏิบัติการและไลบรารีข้อมูลแบบกระจาย แพลตฟอร์มนี้รวมถึงคอมไพเลอร์หรือแอสเซมเบิลที่จำเป็นเพื่อรองรับการพัฒนาระบบซอฟต์แวร์ ดังที่แสดงในตารางต่อไปนี้หากแพลตฟอร์มเปลี่ยนแปลงเพียงครั้งเดียวทุก ๆ 12 เดือนคะแนนจะต่ำมากและหากมีการเปลี่ยนแปลงครั้งใหญ่ทุก 2 สัปดาห์การให้คะแนนจะสูงมาก:

คู่มือคำจำกัดความโมเดล Cocomo2

คุณอาจสังเกตเห็นว่าภาษาการเขียนโปรแกรมไม่ปรากฏโดยตรงในคำอธิบายของปัจจัยการทำงานนี้ แต่คอมไพเลอร์และแอสเซมเบิลปรากฏขึ้น ในความคิดของฉันคำอธิบายนี้ไม่ได้รวมภาษาการเขียนโปรแกรมอย่างชัดเจนเนื่องจากโครงการทั้งหมดที่ได้รับโมเดล Cocomo2 ใช้ภาษาที่มั่นคง

เนื่องจากคอมไพเลอร์และแอสเซมเบิลเป็นปัจจัยการทำงานนี้เราจึงสามารถอนุมานภาษาการเขียนโปรแกรมและเครื่องมือที่เกี่ยวข้อง

จากช่วงการให้คะแนนความผันผวนของแพลตฟอร์ม Java ควรเป็น 'มาก' ในขณะที่ Kotlin ควร 'ต่ำ' หรือสูงกว่า Kotlin อาจมีการจัดอันดับที่สูงขึ้นเนื่องจากต้องอาศัยเครื่องมืออื่น ๆ ภายในเพิ่มความเสี่ยงของปัญหาความเข้ากันได้

เนื่องจาก "มาก" ไม่ได้ให้ปัจจัยการทำงานเราจึงต้องมีการประมาณการ

เมื่อมองไปที่กฎการลดลงของปัจจัยจาก "สูง" ถึง "ต่ำ" ฉันคิดว่าเราสามารถสันนิษฐานได้ด้วยความมั่นใจว่าคะแนนของ "มาก" ไม่สูงกว่า 0.82

ตามสมมติฐานเหล่านี้ (เพื่อประโยชน์ของ Kotlin) หากโครงการต้องการภาระงานที่ได้รับการจัดอันดับ 5 คนต่อปีจากนั้นการใช้ Kotlin จะกลายเป็น 1,044 คนต่อวันในขณะที่ปริมาณงานทั้งหมดของการใช้ Java คือ 984 คนต่อวัน

การเลือกใช้โครงการดังกล่าวโดยใช้ Kotlin แทน Java จะเพิ่มปริมาณงานทั้งหมด 60 คน

งานพิเศษที่เกิดจากภาษาและความไม่เสถียรของเครื่องมือมากกว่าสองเท่าของงานที่ลดลงโดยการเปลี่ยนเป็น Kotlin

รวมปัจจัยทั้งหมด

โครงการที่ฉันพูดถึงเป็นตัวอย่างต้องใช้ภาระงานที่ได้รับการจัดอันดับ 5 คนต่อปี

จากการประเมินข้างต้นหากโครงการดำเนินการโดยใช้ Java โดยนักพัฒนาที่มีประสบการณ์การพัฒนา Java เฉลี่ย 1 ปีปริมาณงานทั้งหมดคือ:

5 คนปี*Ltex (Java)*PVOL (Java) = 984 (People-Day)

หากโครงการเดียวกันถูกนำไปใช้โดยใช้ Kotlin โดยนักพัฒนาที่มีประสบการณ์เพียงเล็กน้อยในการพัฒนา Kotlin ปริมาณงานทั้งหมดคือ:

5 คนปี*ltex (kotlin)*pvol (kotlin)*0.98+t_ramp_up = 1115+5*n_developers (Human-Heaven)

คาดว่าปริมาณงานเพิ่มเติมที่เกิดจากการเลือก Kotlin เพื่อแทนที่ Java คือ 131+5*N_Developers (Man-Day)

ข้อควรระวังการประเมิน

ในระหว่างการอภิปรายการประเมินผลเราได้รับค่าจุดเดียวที่สะดวกสำหรับภาระงานที่เกี่ยวข้องกับ Kotlin และ Java

แต่ในความเป็นจริงค่าจุดเดียวไม่ได้ประมาณการเลย - เป็นเพียงการคาดเดา การประมาณการที่แท้จริงจะต้องมีความไม่แน่นอนที่เกี่ยวข้อง กล่าวอีกนัยหนึ่งการประมาณการเป็นช่วงของความเป็นไปได้มากกว่าค่าจุดเดียว

เราลงเอยด้วยการใช้ค่าจุดเดียวแทนช่วงเพราะฉันเลือกค่าที่ดีที่สุดสำหรับ Kotlin จากช่วงการประมาณและแปลงการประมาณทั้งหมดเป็นค่าจุดเดียว

ตัวอย่างเช่นเมื่อพูดถึงผลกระทบของ Kotlin ต่อการเข้ารหัสและกิจกรรมการดีบักฉันเลือกมูลค่าเพิ่มประสิทธิภาพสูงสุด 10%จากช่วงความเป็นไปได้โดยประมาณ [-5%, 10%] ในกรณีอื่น ๆ เมื่อเราหารือเกี่ยวกับเวลาเฉลี่ยที่นักพัฒนาเปลี่ยนเป็น Kotlin ฉันเลือก 5 วันที่เล็กที่สุดจากช่วงความเป็นไปได้โดยประมาณ [5 วัน 21 วัน]

นอกจากนี้เรายังใช้ปัจจัยการทำงานที่อุทิศให้กับโมเดลการประมาณ COCOMO2 ปัจจัยเหล่านี้ไม่ใช่ความจริงสากลและในกรณีทั่วไปที่สุดควรมีความไม่แน่นอนที่เกี่ยวข้อง ฉันมอบหมายให้ Kotlin ให้คะแนนสูงกว่าที่ฉันคิดไว้จริง ๆ และฉันหวังว่าจะลบความไม่แน่นอนนั้นด้วยวิธีนี้

ไม่จำเป็นต้องพูดค่าจุดเดียวที่เราได้รับนั้นไม่ถูกต้อง 100% เพื่อให้ได้ประมาณการที่สมบูรณ์ยิ่งขึ้นเราสามารถใช้การประมาณการที่แท้จริงสำหรับการจำลอง Montecarlo ด้วยเทคนิคนี้เราสามารถสังเกตการกระจายของผลลัพธ์ที่เป็นไปได้และคิดว่าผลลัพธ์ที่จะเกิดขึ้นได้มากที่สุด

โปรดจำไว้ว่าเนื่องจากเราบีบอัดการประมาณการเป็นค่าจุดเดียวที่ดีที่สุดสำหรับ Kotlin ผลลัพธ์อื่น ๆ ที่เป็นไปได้จะแสดงค่าใช้จ่ายของ Kotlin ที่มากขึ้น ดังนั้นจากผลลัพธ์ที่เป็นไปได้ทั้งหมดค่าจุดเดียวที่เราอธิบายไว้ข้างต้นเป็นสิ่งที่ดีที่สุดสำหรับ Kotlin

สรุป

ในตอนต้นของบทความเราแสดงการตัดสินส่วนตัวบางอย่างที่อาจทำให้เข้าใจผิดกับการเปรียบเทียบภาษาการเขียนโปรแกรมของนักพัฒนา

ต่อไปเราจะหารือเกี่ยวกับความยากลำบากในการเปรียบเทียบภาษาการเขียนโปรแกรมอย่างเป็นกลางและดำเนินการประมาณการชุดเพื่อหาภาระงานทั้งหมดที่จำเป็นสำหรับ Kotlin Stack และ Java Stack เพื่อทำโครงการซอฟต์แวร์ให้เสร็จสมบูรณ์ เมื่อทำการประมาณค่าเรามักจะใช้ค่าที่ดีที่สุดของ Kotlin ในช่วงการประมาณ

จากการวิเคราะห์ของเราการเปลี่ยนจาก Java เป็น Kotlin ดูเหมือนว่าจะส่งผลให้ปริมาณงานทั้งหมดที่เพิ่มขึ้นเพื่อให้โครงการซอฟต์แวร์เสร็จสมบูรณ์

การทำงานมากขึ้นหมายความว่าธุรกิจจำเป็นต้องใช้เงินมากขึ้นเพื่อเปลี่ยนไปใช้ Kotlin เพื่อรับคุณสมบัติเดียวกันในขณะที่ผู้ใช้ต้องรอนานขึ้นเพื่อรับผลิตภัณฑ์

นักพัฒนาบางคนอาจประหลาดใจและพบว่าผลลัพธ์นี้ไม่ง่ายที่จะยอมรับ

หลังจากพิจารณาสถานการณ์ทั้งหมดในที่สุด Google ก็ตัดสินใจที่จะสนับสนุนการพัฒนา Kotlinanroid Google อาจต้องการการลงทุนอย่างมากในเรื่องนี้ - ไม่มีใครในทีมแพลตฟอร์ม Google Cloud ที่สามารถทำการวิเคราะห์ที่คล้ายกันเพื่อหาผลกระทบด้านลบของการเปลี่ยนเป็นภาษาใหม่หรือไม่?

ฉันคิดว่าพนักงานของ Google ทุกคนเป็นคนที่ฉลาดมากและฉันเชื่อว่าพวกเขาได้ทำการวิเคราะห์เชิงลึกมากก่อนที่พวกเขาจะตัดสินใจสนับสนุน Kotlin

ข้างต้นเป็นเนื้อหาทั้งหมดของบทความนี้เกี่ยวกับการเปรียบเทียบแบบอัตนัยและวัตถุประสงค์และการวิเคราะห์ของ Kotlin และ Java ฉันหวังว่ามันจะเป็นประโยชน์กับทุกคน เพื่อนที่สนใจสามารถอ้างถึงหัวข้ออื่น ๆ ที่เกี่ยวข้องในเว็บไซต์นี้ต่อไป หากมีข้อบกพร่องใด ๆ โปรดฝากข้อความไว้เพื่อชี้ให้เห็น!