การใช้โครงการลอมบอกปลอดภัยหรือไม่? [ปิด]

ในกรณีที่คุณไม่ทราบว่าโครงการลอมบอกจะช่วยให้มีบางส่วนของ annoyances ชวากับสิ่งที่ชอบสร้าง getters และ setters ด้วยคำอธิบายประกอบและแม้กระทั่งJavaBean ง่ายๆเช่นรุ่นที่มี @Data มันสามารถช่วยฉันได้จริงๆโดยเฉพาะในวัตถุเหตุการณ์ 50 ชนิดที่คุณมีเขตข้อมูลต่าง ๆ ถึง 7 แห่งที่ต้องสร้างและซ่อนตัวด้วย getters ฉันสามารถลบรหัสเกือบพันบรรทัดด้วยสิ่งนี้

อย่างไรก็ตามฉันกังวลว่าในระยะยาวมันจะเป็นการตัดสินใจที่น่าเศร้า Flamewars จะปะทุใน##Java Freenodeช่องเมื่อฉันพูดถึงการให้ข้อมูลโค้ดจะสร้างความสับสนให้กับผู้ช่วยเหลือที่เป็นไปได้ผู้คนจะบ่นเกี่ยวกับ JavaDoc ที่หายไปและผู้มอบหมายในอนาคตอาจจะลบทิ้งทั้งหมด ฉันจะสนุกกับการบวก แต่ฉันกังวลเกี่ยวกับการลบ

ดังนั้น: ปลอดภัยหรือไม่ที่จะใช้ลอมบอกในโครงการใด ๆ ไม่ว่าเล็กหรือใหญ่ ผลกระทบเชิงบวกที่คุ้มค่ากับเชิงลบหรือไม่?

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

ก่อนที่คุณจะใช้ Project ลอมบอก (หรือเทคโนโลยีการเปลี่ยนเกมอื่น ๆ ) ในบางโครงการ (โอเพ่นซอร์สหรืออื่น ๆ ที่ชาญฉลาด) คุณต้องตรวจสอบให้แน่ใจว่าผู้มีส่วนได้ส่วนเสียของโครงการเห็นด้วยกับเรื่องนี้ ซึ่งรวมถึงนักพัฒนาและผู้ใช้ที่สำคัญ (เช่นผู้สนับสนุนอย่างเป็นทางการหรือไม่เป็นทางการ)

คุณพูดถึงปัญหาที่อาจเกิดขึ้นเหล่านี้:

Flamewars จะปะทุใน ## Java Freenode channel เมื่อฉันพูดถึงมัน

ง่าย. เพิกเฉย / ไม่เข้าร่วมใน flamewars หรือละเว้นจากการกล่าวถึงลอมบอก

การให้ข้อมูลโค้ดจะทำให้ผู้ช่วยสับสน

หากกลยุทธ์ของโครงการคือการใช้ลอมบอกผู้ช่วยเหลือที่เป็นไปได้จะต้องคุ้นเคยกับมัน

ผู้คนจะบ่นเกี่ยวกับ JavaDoc ที่หายไป

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

( FOLLOWUP - นักพัฒนาลอมบอกยอมรับว่าการไม่สร้างความคิดเห็น javadoc สำหรับวิธีการ getter และ setter ที่สังเคราะห์เป็นปัญหาหากนี่เป็นปัญหาสำคัญสำหรับโครงการของคุณแล้วทางเลือกหนึ่งคือการสร้างและส่งแพตช์ลอมบอกเพื่อแก้ไขปัญหานี้ )

และผู้มอบหมายในอนาคตอาจจะลบทิ้งทั้งหมด

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

แน่นอนว่าคุณได้ซื้อจากผู้มีส่วนได้เสีย ... รวมถึงนักพัฒนา และถือว่าคุณพร้อมที่จะโต้แย้งสาเหตุของคุณและจัดการกับเสียงคัดค้านอย่างหลีกเลี่ยงไม่ได้อย่างเหมาะสม

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

หากคุณมีคลาสที่มีคำอธิบายประกอบด้วยคลาส@Dataจะสร้าง getters และ setters สำหรับคุณตามชื่อฟิลด์ หากคุณใช้หนึ่งใน getters เหล่านั้นในคลาสอื่นจากนั้นตัดสินใจว่าฟิลด์นั้นมีชื่อไม่ดีมันจะไม่พบการใช้งานของ getters และ setters เหล่านั้นและแทนที่ชื่อเก่าด้วยชื่อใหม่

ฉันคิดว่าจะต้องทำผ่านปลั๊กอิน IDE และไม่ต้องผ่านลอมบ็อก

อัปเดต (22 ม.ค. 56)
หลังจากใช้ลอมบอกเป็นเวลา 3 เดือนฉันยังคงแนะนำสำหรับโครงการส่วนใหญ่ อย่างไรก็ตามฉันค้นหาข้อเสียอื่นที่คล้ายกับที่กล่าวข้างต้น

หากคุณมีชั้นเรียนให้บอกMyCompoundObject.javaว่ามีสมาชิก 2 คนทั้งที่มีคำอธิบายประกอบ@DelegateพูดmyWidgetsและmyGadgetsเมื่อคุณโทรmyCompoundObject.getThingies()จากชั้นเรียนอื่นเป็นไปไม่ได้ที่จะรู้ว่ามันเป็นตัวแทนWidgetหรือGadgetเพราะคุณไม่สามารถข้ามไปยังแหล่งภายใน IDE ได้อีกต่อไป

การใช้ Eclipse "Generate Delegate Methods ... " ช่วยให้คุณสามารถใช้งานฟังก์ชั่นเดียวกันได้อย่างรวดเร็วและรวดเร็ว ข้อเสียคือมันตัดแหล่งที่มาของคุณด้วยรหัสสำเร็จรูปที่เน้นสิ่งที่สำคัญ

อัปเดต 2 (26 ก.พ. 56)
หลังจาก 5 เดือนเรายังคงใช้ลอมบอกอยู่ แต่ฉันมีเรื่องน่ารำคาญอื่น ๆ การไม่มีตัวรับสัญญาณที่ประกาศ & ตัวตั้งค่าอาจทำให้เกิดความรำคาญในบางครั้งเมื่อคุณพยายามทำความคุ้นเคยกับรหัสใหม่

ตัวอย่างเช่นถ้าฉันเห็นวิธีที่เรียกว่าgetDynamicCols()แต่ฉันไม่รู้ว่ามันเกี่ยวกับอะไรฉันมีอุปสรรค์พิเศษที่จะข้ามไปเพื่อกำหนดวัตถุประสงค์ของวิธีนี้ อุปสรรคบางอย่างคือลอมบอกบางอันขาดปลั๊กอินอัจฉริยะของลอมบอก อุปสรรครวมถึง:

• ขาด JavaDocs ถ้าฉัน javadoc ฟิลด์ฉันหวังว่าผู้ทะเยอทะยานและผู้ตั้งค่าจะสืบทอด javadoc นั้นผ่านขั้นตอนการรวบรวมลอมบอก
• ข้ามไปที่นิยามวิธีการกระโดดฉันไปที่ชั้นเรียน แต่ไม่ได้ทรัพย์สินที่สร้างทะเยอทะยาน นี่เป็นปัญหาปลั๊กอิน
• เห็นได้ชัดว่าคุณไม่สามารถตั้งค่าเบรกพอยต์ใน getter / setter เว้นแต่ว่าคุณสร้างหรือโค้ดวิธี
• หมายเหตุ: การค้นหาอ้างอิงนี้ไม่ใช่ปัญหาอย่างที่ฉันคิดไว้ก่อน คุณจำเป็นต้องใช้มุมมองที่เปิดใช้งานมุมมองโครงร่าง ไม่ใช่ปัญหาสำหรับนักพัฒนาส่วนใหญ่ ปัญหาของฉันคือฉันใช้ Mylyn ซึ่งกรองOutlineมุมมองของฉันดังนั้นฉันจึงไม่เห็นวิธีการ การขาดการอ้างอิง ถ้าฉันต้องการดูว่าใครโทรgetDynamicCols(args...)มาฉันต้องสร้างหรือรหัสผู้ตั้งค่าเพื่อให้สามารถค้นหาการอ้างอิง

อัปเดต 3 (7 มี.ค. 56)
เรียนรู้ที่จะใช้วิธีการต่าง ๆ ในการทำสิ่งต่าง ๆ ใน Eclipse ฉันเดา คุณสามารถตั้งค่าเบรกพอยต์แบบมีเงื่อนไข (BP) ตามวิธีที่สร้างขึ้นโดยลอมบอก โดยใช้มุมมองของคุณสามารถคลิกขวาที่วิธีการที่จะOutline Toggle Method Breakpointจากนั้นเมื่อคุณกดปุ่ม BP คุณสามารถใช้Variablesมุมมองการดีบักเพื่อดูว่าวิธีการที่สร้างขึ้นชื่อพารามิเตอร์ใด (ปกติจะเหมือนกับชื่อฟิลด์) และสุดท้ายใช้Breakpointsมุมมองเพื่อคลิกขวาที่ BP และเลือกBreakpoint Properties...เพื่อเพิ่มเงื่อนไข ดี

UPDATE 4 (16 ส.ค. 56)
Netbeans ไม่ชอบเมื่อคุณอัพเดทการพึ่งพาลอมบอกใน Maven pom ของคุณ โปรเจ็กต์ยังคงคอมไพล์ แต่ไฟล์ถูกตั้งค่าสถานะว่ามีข้อผิดพลาดในการคอมไพล์เนื่องจากไม่เห็นวิธีที่ลอมบ็อคกำลังสร้าง การล้างแคช Netbeans ช่วยแก้ไขปัญหา ไม่แน่ใจว่ามีตัวเลือก "Clean Project" เหมือนใน Eclipse หรือไม่ ปัญหาเล็กน้อย แต่ต้องการทำให้เป็นที่รู้จัก

อัปเดต 5 (17 มกราคม '14)
ลอมบอกเล่นได้ไม่ดีกับ Groovy หรืออย่างน้อยก็ตลอดgroovy-eclipse-compilerไป คุณอาจต้องดาวน์เกรดคอมไพเลอร์ของคุณ Maven Groovy และ Java + Lombok

อัปเดต 6 (26 มิ.ย. '14)
คำเตือน ลอมบอกเป็นคนเสพติดเล็กน้อยและถ้าคุณทำงานในโครงการที่คุณไม่สามารถใช้มันด้วยเหตุผลบางอย่างมันจะรบกวนความโกรธของคุณ คุณอาจจะดีกว่าไม่เคยใช้เลย

อัปเดต 7 (23 ก.ค. '14)
นี่เป็นการอัปเดตที่น่าสนใจเนื่องจากเป็นเรื่องความปลอดภัยโดยตรงในการยอมรับลอมบอกที่ OP สอบถาม

ตั้งแต่วันที่ v1.14 @Delegateคำอธิบายประกอบได้รับการลดระดับเป็นสถานะการทดลอง รายละเอียดมีการบันทึกไว้ในเว็บไซต์ของพวกเขา ( ลอมบ็อกมอบหมายเอกสาร )

สิ่งนี้คือถ้าคุณใช้คุณสมบัตินี้ตัวเลือกแบ็คเอาท์ของคุณมี จำกัด ฉันเห็นตัวเลือกดังนี้:

• ลบ@Delegateคำอธิบายประกอบด้วยตนเองและสร้าง / handcode รหัสผู้แทน สิ่งนี้จะยากขึ้นเล็กน้อยหากคุณใช้แอททริบิวต์ในหมายเหตุประกอบ
• ลบไฟล์ที่มี@Delegateคำอธิบายประกอบและอาจเพิ่มกลับเข้าไปในคำอธิบายประกอบที่คุณต้องการ
• อย่าอัปเดตลอมบอกหรือรักษาทางแยก (หรือใช้ชีวิตด้วยการใช้ฟีเจอร์ประสบการณ์)
• Delombok โครงการทั้งหมดของคุณและหยุดใช้ลอมบอก

เท่าที่ผมสามารถบอกได้Delombok ไม่ได้มีตัวเลือกในการลบย่อยของบันทึกย่อ ; มันคือทั้งหมดหรือไม่มีอะไรอย่างน้อยสำหรับบริบทของไฟล์เดียว ฉันเปิดตั๋วเพื่อขอคุณสมบัตินี้ด้วยธง Delombok แต่ฉันจะไม่คาดหวังว่าในอนาคตอันใกล้

UPDATE 8 (20 ตุลาคม '14)
ถ้าเป็นตัวเลือกสำหรับคุณข้อเสนอ Groovy ที่สุดของผลประโยชน์เดียวกันของลอมบอกบวกภาระเรือของคุณสมบัติอื่น ๆ รวมทั้ง@Delegate หากคุณคิดว่าคุณมีปัญหาในการขายความคิดให้กับพลังที่เป็นอยู่ให้ดูที่@CompileStaticหรือเพิ่มความคิดเห็น@TypeCheckedเพื่อดูว่าสิ่งนั้นสามารถช่วยคุณได้หรือไม่ ในความเป็นจริงเป็นเป้าหมายหลักของการปล่อย Groovy 2.0 เป็นความปลอดภัยแบบคงที่

อัปเดต 9 (ก.ย. 1 '15)
ลอมบอกยังคงได้รับการบำรุงรักษาและปรับปรุงอย่างแข็งขันซึ่งเป็นลางที่ดีในระดับความปลอดภัยของการยอมรับ @Builderคำอธิบายประกอบเป็นหนึ่งในคุณสมบัติใหม่ที่ชื่นชอบ

อัปเดต 10 (17 พ.ย. 58)
อาจดูเหมือนไม่เกี่ยวข้องโดยตรงกับคำถามของ OP แต่เป็นการแบ่งปันที่คุ้มค่า หากคุณกำลังมองหาเครื่องมือที่จะช่วยให้คุณลดปริมาณของรหัสสำเร็จรูปที่คุณเขียนคุณยังสามารถตรวจสอบGoogle Auto - โดยเฉพาะในAutoValue หากคุณดูที่เด็คสลิปของพวกเขารายการลอมบอกเป็นวิธีแก้ปัญหาที่เป็นไปได้สำหรับปัญหาที่พวกเขากำลังพยายามแก้ไข ข้อเสียพวกเขาสำหรับลอมบอกคือ:

• รหัสที่แทรกไว้จะมองไม่เห็น (คุณไม่สามารถ "เห็น" วิธีการที่จะสร้าง) [หมายเหตุที่ทราบแล้ว - จริง ๆ แล้วคุณทำได้ แต่เพียงต้องการตัวถอดรหัส)
• แฮ็คคอมไพเลอร์ไม่ได้มาตรฐานและเปราะบาง
• "ในมุมมองของเรารหัสของคุณไม่ได้เป็นจาวาจริงๆอีกต่อไป"

ฉันไม่แน่ใจว่าฉันเห็นด้วยกับการประเมินของพวกเขามากแค่ไหน และด้วยข้อเสียของ AutoValue ที่บันทึกไว้ในสไลด์ฉันจะติดกับลอมบอก (ถ้า Groovy ไม่ใช่ตัวเลือก)

UPDATE 11 (8 กุมภาพันธ์ '16)
ผมพบว่าฤดูใบไม้ผลิตานาโรมีบางส่วนคำอธิบายประกอบที่คล้ายกัน ฉันรู้สึกประหลาดใจเล็กน้อยที่พบว่า Roo ยังคงเป็นสิ่งสำคัญและการค้นหาเอกสารประกอบสำหรับคำอธิบายประกอบนั้นค่อนข้างหยาบ การกำจัดยังไม่ได้ดูง่ายเหมือน de-lombok ลอมบอกดูเหมือนเป็นตัวเลือกที่ปลอดภัยกว่า

อัปเดต 12 (17 ก.พ. 59)
ในขณะที่พยายามหาเหตุผลว่าทำไมจึงปลอดภัยที่จะนำลอมบอกสำหรับโครงการที่ฉันกำลังทำงานอยู่ฉันพบทองคำชิ้นหนึ่งที่เพิ่มเข้ามาด้วยv1.14- The Configuration System ! นี่คือหมายความว่าคุณสามารถกำหนดค่าโครงการให้ยกเลิกคุณสมบัติบางอย่างที่ทีมของคุณเห็นว่าไม่ปลอดภัยหรือไม่พึงประสงค์ ยังดีกว่ามันยังสามารถสร้างการตั้งค่าเฉพาะไดเรกทอรีด้วยการตั้งค่าที่แตกต่างกัน นี่มันเจ๋งมาก.

UPDATE 13 (4 ตุลาคม '16)
ถ้าชนิดของสิ่งนี้มีความสำคัญกับคุณโอลิเวอร์ Gierkeรู้สึกว่ามันเป็นความปลอดภัยที่จะเพิ่มลอมบอกฤดูใบไม้ผลิข้อมูลส่วนที่เหลือ

อัปเดต 14 (26 ก.ย. '17)
ตามที่ระบุโดย@gavenkoaในความคิดเห็นเกี่ยวกับคำถามOPs การสนับสนุนคอมไพเลอร์ JDK9 ยังไม่พร้อมใช้งาน (ฉบับที่ 985) นอกจากนี้ดูเหมือนว่าจะไม่ใช่เรื่องง่ายสำหรับทีมลอมบอกในการเดินทาง

อัปเดต 15 (26 มีนาคม '18)
การเปลี่ยนแปลงลอมบอกระบุเมื่อวันที่ v1.16.20 "การรวบรวมลอมบอกบน JDK1.9 เป็นไปได้ตอนนี้เป็นไปได้ " แม้ว่า# 985ยังคงเปิดอยู่

อย่างไรก็ตามการเปลี่ยนแปลงเพื่อรองรับ JDK9 นั้นจำเป็นต้องมีการเปลี่ยนแปลงบางอย่าง แยกทั้งหมดเพื่อการเปลี่ยนแปลงในค่าเริ่มต้น มันเป็นเรื่องเล็กน้อยที่เกี่ยวข้องกับการที่พวกเขานำเสนอการเปลี่ยนแปลงที่ไม่หยุดยั้ง แต่เวอร์ชันดังกล่าวกระแทกเฉพาะหมายเลขรุ่น "เพิ่มเติม" (ไปจาก v1.16.18 ถึง v1.16.20) เนื่องจากโพสต์นี้เกี่ยวกับความปลอดภัยหากคุณมีyarn/npmระบบการสร้างที่อัพเกรดเป็นรุ่นที่เพิ่มขึ้นล่าสุดโดยอัตโนมัติคุณอาจเข้าสู่การปลุกที่หยาบคาย

อัปเดต 16 (9 มกราคม 19)

ดูเหมือนว่าปัญหาของ JDK9 นั้นได้รับการแก้ไขแล้วและลอมบอกนั้นทำงานร่วมกับ JDK10 และแม้แต่ JDK11 เท่าที่ฉันจะบอกได้

สิ่งหนึ่งที่ฉันสังเกตเห็นว่าเกี่ยวข้องกับด้านความปลอดภัยคือข้อเท็จจริงที่ว่าบันทึกการเปลี่ยนแปลงที่เกิดขึ้นจาก v1.18.2 เป็น v1.18.4 แสดงรายการสองรายการเป็นBREAKING CHANGE! ฉันไม่แน่ใจว่าการเปลี่ยนแปลงที่เกิดขึ้นในการอัพเดทแพทช์ อาจเป็นปัญหาหากคุณใช้เครื่องมือที่อัพเดตเวอร์ชันแพตช์อัตโนมัติ

ไปข้างหน้าและใช้ลอมบอกคุณสามารถถ้าจำเป็น "delombok" รหัสของคุณหลังจากนั้นhttp://projectlombok.org/features/delombok.html

โดยส่วนตัว (และเป็นการส่วนตัว) ฉันพบว่าการใช้ลอมบอกทำให้โค้ดของฉันแสดงออกอย่างชัดเจนมากขึ้นเกี่ยวกับสิ่งที่ฉันพยายามที่จะบรรลุเมื่อเปรียบเทียบกับ IDE / การใช้งานของวิธีการที่ซับซ้อนเช่น hashcode & เท่ากับ

เมื่อใช้งาน

@EqualsAndHashCode(callSuper = false, of = { "field1", "field2", "field3" })

มันง่ายกว่ามากในการรักษา Equals & HashCode ให้สอดคล้องกันและติดตามว่าฟิลด์ใดบ้างที่ถูกประเมินมากกว่าการใช้งาน IDE / ของตัวเอง นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งเมื่อคุณยังคงเพิ่ม / ลบฟิลด์อย่างสม่ำเสมอ

เดียวกันจะไปสำหรับ@ToStringคำอธิบายประกอบและพารามิเตอร์ที่ชัดเจนสื่อสารพฤติกรรมที่ต้องการเกี่ยวกับการรวม / สาขาที่ได้รับการยกเว้นการใช้งานของ getters super.toString()หรือการเข้าถึงข้อมูลและสภาพอากาศหรือไม่ที่จะเรียกร้อง

และอีกครั้งโดยใส่คำอธิบายประกอบทั้งคลาสด้วย@Getterหรือ@Setter(AccessLevel.NONE)(และเลือกแทนที่วิธีการที่แตกต่างกัน) มันชัดเจนทันทีว่าวิธีใดที่จะใช้ได้สำหรับฟิลด์

ประโยชน์ที่ได้รับไปเรื่อย ๆ

ในใจของฉันมันไม่ได้เกี่ยวกับการลดรหัส แต่เกี่ยวกับการสื่อสารอย่างชัดเจนในสิ่งที่คุณต้องการที่จะบรรลุมากกว่าที่จะคิดออกจาก Javadoc หรือการใช้งาน รหัสที่ลดลงทำให้ง่ายต่อการสังเกตเห็นการใช้งานแบบ divergent

ลอมบอกเยี่ยมมาก แต่ ...

ลอมบอกแบ่งกฎของการประมวลผลคำอธิบายประกอบโดยที่มันจะไม่สร้างไฟล์ต้นฉบับใหม่ ซึ่งหมายความว่าจะไม่สามารถใช้กับตัวประมวลผลคำอธิบายประกอบอื่นได้หากคาดหวังว่า getters / setters หรืออะไรก็ตามที่มีอยู่

การประมวลผลคำอธิบายประกอบจะทำงานในชุดของรอบ ในแต่ละรอบแต่ละรอบจะวิ่ง หากพบไฟล์ java ใหม่หลังจากเสร็จสิ้นการปัดเศษอีกรอบจะเริ่มต้นขึ้น ด้วยวิธีนี้ลำดับตัวประมวลผลคำอธิบายประกอบไม่สำคัญว่าจะสร้างเพียงไฟล์ใหม่ เนื่องจาก lombok ไม่ได้สร้างไฟล์ใหม่ใด ๆ จึงไม่มีการเริ่มรอบใหม่ดังนั้น AP บางตัวที่ใช้โค้ด lombok จะไม่ทำงานตามที่คาดไว้ นี่เป็นแหล่งที่มาของความเจ็บปวดอย่างมากสำหรับฉันในขณะที่ใช้ mapstruct และ delombok-ing ไม่ใช่ตัวเลือกที่มีประโยชน์เพราะมันทำลายหมายเลขบรรทัดของคุณในบันทึก

ในที่สุดฉันก็แฮกสคริปต์สร้างเพื่อทำงานกับทั้งลอมบอกและแมปโครงสร้าง แต่ฉันต้องการที่จะวางลอมบอกเนื่องจากวิธีแฮ็คมัน - ในโครงการนี้อย่างน้อย ฉันใช้ลอมบอกตลอดเวลาในสิ่งอื่น ๆ

ฉันอ่านความคิดเห็นเกี่ยวกับลอมบอกและจริง ๆ แล้วฉันใช้มันในบางโครงการ

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

เหตุผลที่ฉันจะคิดแบบนี้:

• IDE ปลั๊กอินพึ่งพา การสนับสนุน IDE สำหรับลอมบอกผ่านปลั๊กอิน แม้จะทำงานได้ดีในเกือบตลอดเวลาคุณก็ยังเป็นตัวประกันจากปลั๊กอินนี้เพื่อรักษาไว้ในรุ่นต่อ ๆ ไปของ IDEs และแม้กระทั่งเวอร์ชันภาษา (Java 10+ จะช่วยเร่งการพัฒนาภาษา) ตัวอย่างเช่นฉันพยายามอัปเดตจาก Intellij IDEA 2017.3 เป็น 2018.1 และฉันทำไม่ได้เพราะมีปัญหาบางอย่างในเวอร์ชัน lombok plugin จริงและฉันต้องรอการอัปเดตปลั๊กอิน ... นี่เป็นปัญหาถ้าคุณ ต้องการใช้ IDE ทางเลือกอื่นที่ไม่มีการสนับสนุนจากลอมบ็อก
• ปัญหา 'ค้นหาประเพณี' . การใช้ลอมบอกคุณจะไม่เห็นตัวสร้างตัวติดตั้งตัวสร้างวิธีการสร้างและอื่น ๆ ดังนั้นหากคุณวางแผนที่จะค้นหาว่าวิธีการเหล่านี้ถูกใช้ในโครงการของคุณโดย IDE ของคุณคุณไม่สามารถทำได้ สำหรับคลาสที่เป็นเจ้าของวิธีการที่ซ่อนอยู่นี้
• เพื่อให้ง่ายต่อว่านักพัฒนาไม่สนใจที่จะทำลายการห่อหุ้ม ฉันรู้ว่าไม่ใช่ปัญหาจากลอมบอกจริงๆ แต่ฉันเห็นแนวโน้มที่ใหญ่กว่าจากนักพัฒนาที่จะไม่ควบคุมอีกต่อไปว่าวิธีการที่จะต้องมองเห็นได้หรือไม่ ดังนั้นหลายครั้งที่พวกเขาเพียงแค่คัดลอกและวาง@Getter @Setter @Builder @AllArgsConstructor @NoArgsConstructorคำอธิบายประกอบบล็อกโดยไม่ต้องคิดว่าวิธีการเรียนต้องสัมผัส
• Builder Obssession © ฉันคิดค้นชื่อนี้ (ลงมา Martin Fowler) แยกออกจากกันตัวสร้างเป็นเรื่องง่ายที่จะสร้างแม้ว่าคลาสมีเพียงสองพารามิเตอร์ที่นักพัฒนาต้องการใช้@Builderแทนตัวสร้างหรือวิธีการสร้างแบบคงที่ บางครั้งพวกเขาก็พยายามที่จะสร้างตัวสร้างภายในลอมบอก Builder สร้างสถานการณ์แปลก ๆ MyClass.builder().name("Name").build().create()เช่น
• ปัญหาและอุปสรรคที่เมื่อ refactoring หากคุณกำลังใช้ตัวอย่างเช่น a @AllArgsConstructorและจำเป็นต้องเพิ่มพารามิเตอร์อีกหนึ่งพารามิเตอร์ในตัวสร้าง IDE ไม่สามารถช่วยคุณเพิ่มพารามิเตอร์พิเศษนี้ได้ในทุก ๆ ที่ (ส่วนใหญ่เป็นการทดสอบ) ที่ทำให้คลาสเป็นอินสแตนซ์
• ผสมลอมบอกด้วยวิธีการที่เป็นรูปธรรม คุณไม่สามารถใช้ลอมบอกในทุกสถานการณ์เพื่อสร้างผู้ได้รับ / setter / ฯลฯ ดังนั้นคุณจะเห็นทั้งสองวิธีผสมกันในรหัสของคุณ คุณจะคุ้นเคยกับสิ่งนี้หลังจากผ่านไประยะหนึ่ง แต่รู้สึกเหมือนแฮ็คกับภาษา

เช่นเดียวกับคำตอบอื่น ๆ ที่กล่าวว่าหากคุณโกรธเกี่ยวกับการใช้คำฟุ่มเฟือยของ Java และใช้ลอมบอกเพื่อรับมือกับมันลองใช้ Kotlin

มีความเสี่ยงในการบำรุงรักษาระยะยาวเช่นกัน ครั้งแรกผมอยากแนะนำให้อ่านเกี่ยวกับวิธีลอมบอกใช้งานได้จริงเช่นบางคำตอบจากนักพัฒนาที่นี่

เว็บไซต์อย่างเป็นทางการยังมีรายการข้อเสียรวมถึงคำพูดนี้จาก Reinier Zwitserloot:

แฮ็คทั้งหมด ใช้ API ที่ไม่ใช่แบบสาธารณะ การคัดเลือกล่วงหน้าที่น่าเกรงขาม (รู้ว่าตัวประมวลผลคำอธิบายประกอบที่ทำงานอยู่ใน javac จะได้รับอินสแตนซ์ของ JavacAnnotationProcessor ซึ่งเป็นการใช้งานภายในของ AnnotationProcessor (อินเทอร์เฟซ) ซึ่งเกิดขึ้นเพื่อให้มีสองวิธีพิเศษที่ใช้เพื่อรับ AST สด .

บน eclipse มันแย่กว่านั้น (และยังแข็งแกร่งกว่า) - เอเจนต์ java ถูกใช้เพื่อแทรกโค้ดลงในคลาสไวยากรณ์และ parser ของ eclipse ซึ่งแน่นอนว่าเป็น API ที่ไม่ใช่แบบสาธารณะทั้งหมดและไม่ จำกัด ทั้งหมด

หากคุณสามารถทำสิ่งที่ lombok ทำกับ API มาตรฐานฉันจะทำอย่างนั้น แต่คุณทำไม่ได้ แต่สำหรับสิ่งที่คุ้มค่าฉันได้พัฒนาปลั๊กอิน eclipse สำหรับ eclipse v3.5 ที่รันบน java 1.6 และโดยไม่ทำการเปลี่ยนแปลงใด ๆ กับ eclipse v3.4 ที่ทำงานบน java 1.5 เช่นกันดังนั้นจึงไม่บอบบางอย่างสมบูรณ์

โดยสรุปในขณะที่ลอมบ็อคอาจช่วยคุณประหยัดเวลาในการพัฒนาหากมีการอัพเดต javac ที่ใช้งานร่วมกันได้แบบย้อนหลัง (เช่นการลดช่องโหว่) ลอมบอกอาจทำให้คุณติดกับ Java เวอร์ชันเก่าในขณะที่นักพัฒนา API ภายใน ความเสี่ยงที่ร้ายแรงนี้ขึ้นอยู่กับโครงการหรือไม่

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

สำหรับคำถามของคุณ: ง่ายกว่าที่จะให้นักพัฒนาซอฟต์แวร์ของคุณลองใช้ลอมบอกมากกว่าสกาลา ลองดูและถ้าพวกเขาชอบลองสคาลา

เช่นเดียวกับข้อจำกัดความรับผิดชอบ: ฉันชอบ Java ด้วย!

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

เมื่อฉันแสดงโครงการให้ทีมของฉันมีความกระตือรือร้นสูงดังนั้นฉันคิดว่าคุณไม่ควรกลัวคำตอบของทีม

• สำหรับ ROI นั้นเป็นเรื่องง่ายที่จะผสานรวมและไม่จำเป็นต้องเปลี่ยนรหัสในรูปแบบพื้นฐาน (เพียงเพิ่มคำอธิบายประกอบเดียวในชั้นเรียนของคุณ)

• และสุดท้ายถ้าคุณเปลี่ยนใจคุณสามารถรัน unlombok หรือปล่อยให้ IDE ของคุณสร้าง setters, getters และ ctors (ซึ่งฉันคิดว่าจะไม่มีใครถามเมื่อพวกเขาเห็นว่าบทกวีของคุณกลายเป็นอย่างไร)

สิ่งที่ฉันใช้กับลอมบอกก็คือมันมีเพียงทางลัดสำหรับการเขียนโค้ด Java ของ bolilerplate
เมื่อพูดถึงการใช้ทางลัดในการเขียนโค้ด Java ของ Bolilerplate ฉันจะใช้คุณสมบัติดังกล่าวที่มีให้โดย IDE เช่นใน Eclipse เราสามารถไปที่เมนู Source> Generate Getters and Setters เพื่อสร้าง getters และ setters
ฉันจะไม่พึ่งพาห้องสมุดเช่นลอมบอกสำหรับเรื่องนี้:

1. มันเป็นมลพิษรหัสของคุณกับชั้นร้ายของไวยากรณ์ทางเลือก (อ่าน@Getter, @Setterฯลฯ คำอธิบายประกอบ) แทนที่จะเรียนรู้ไวยากรณ์ทางเลือกสำหรับ Java ฉันจะเปลี่ยนไปใช้ภาษาอื่นที่มีภาษาลอมบอกเป็นไวยากรณ์
2. ลอมบอกต้องใช้ IDE ที่สนับสนุนลอมบอกเพื่อทำงานกับรหัสของคุณ การพึ่งพาอาศัยกันนี้มีความเสี่ยงสูงสำหรับโครงการที่ไม่สำคัญ โปรเจ็กต์โอเพนซอร์สลอมบอกมีทรัพยากรเพียงพอที่จะให้การสนับสนุนเวอร์ชันต่างๆของ Java IDE ที่มีอยู่หลากหลายหรือไม่?
3. โครงการลอมบ็อกโอเพนซอร์สมีทรัพยากรเพียงพอที่จะให้การสนับสนุนจาวารุ่นใหม่ที่จะมาในอนาคตหรือไม่?
4. ฉันยังรู้สึกกังวลว่าลอมบอกอาจแนะนำปัญหาความเข้ากันได้กับเฟรมเวิร์ก / ไลบรารีที่ใช้กันอย่างแพร่หลาย (เช่น Spring, Hibernate, Jackson, JUnit, Mockito) ที่ทำงานกับโค้ดไบต์ของคุณที่รันไทม์

โดยรวมแล้วฉันไม่ต้องการ "เติมชีวิตชีวา" Java ของฉันด้วยลอมบอก

ต้องการใช้ lombok @ToStringแต่ในไม่ช้าก็ต้องเผชิญกับข้อผิดพลาดในการรวบรวมแบบสุ่มในการสร้างโครงการใหม่ใน Intellij IDEA มีการเข้าชมคอมไพล์หลายครั้งก่อนการคอมไพล์ที่เพิ่มขึ้นสามารถทำให้สำเร็จได้

ลองทั้ง lombok 1.12.2 และ 0.9.3 ด้วย Intellij IDEA 12.1.6 และ 13.0 โดยไม่มีปลั๊กอิน lombok ภายใต้ jdk 1.6.0_39 และ 1.6.0_45

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

ปรับปรุง

ปัญหาเกิดขึ้นเมื่อเปิดใช้งานการคอมไพล์แบบขนานเท่านั้น

ยื่นปัญหา: https://github.com/rzwitserloot/lombok/issues/648

ปรับปรุง

mplushnikov แสดงความคิดเห็นเมื่อ 30 มกราคม 2016:

เวอร์ชั่นใหม่ของ Intellij ไม่มีปัญหาเช่นนี้อีกแล้ว ฉันคิดว่ามันสามารถปิดได้ที่นี่

ปรับปรุง

ฉันขอแนะนำให้เปลี่ยนจาก Java + ลอมบอกเป็นKotlinถ้าเป็นไปได้ เนื่องจากได้รับการแก้ไขตั้งแต่ต้นจนจบปัญหา Java ทั้งหมดที่ลอมบอกพยายามหลีกเลี่ยง

ฉันพบปัญหากับลอมบอกและแจ็กสัน CSVเมื่อฉันทำการวิเคราะห์วัตถุ (java bean) ของฉันเป็นไฟล์ CSV คอลัมน์ที่ซ้ำกันดังนั้นฉันจึงลบคำอธิบายประกอบ @Data ของลอมบอก

ฉันไม่แนะนำ ฉันเคยใช้มัน แต่เมื่อฉันทำงานกับ NetBeans 7.4 มันทำให้รหัสของฉันยุ่ง ฉันจะลบลอมบอกในไฟล์ทั้งหมดในโครงการของฉัน มี delombok อยู่ แต่ฉันจะแน่ใจได้อย่างไรว่ามันจะไม่ทำให้รหัสของฉันผิด ฉันต้องใช้เวลาหลายวันเพื่อลบลอมบอกและกลับสู่สไตล์ Java ทั่วไป ฉันแค่เผ็ดเกินไป ...

ฉันยังไม่ได้ลองใช้ลอมบอก - เป็น / อยู่ในรายชื่อของฉัน แต่ดูเหมือนว่า Java 8 ได้ก่อให้เกิดปัญหาที่สำคัญและงานแก้ไขยังคงดำเนินต่อไปเมื่อสัปดาห์ที่แล้ว แหล่งที่มาของฉันสำหรับที่เป็นhttps://code.google.com/p/projectlombok/issues/detail?id=451