ปัญหา (เช่นการบำรุงรักษา) ในการพัฒนาด้วยภาษาที่ไม่เป็นที่นิยม

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

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

ดังนั้นการเขียนโปรแกรมในภาษาที่ไม่นิยมใช่ไหม (เพื่อความสนุกของฉันเอง) ฉันควรใช้ภาษายอดนิยมมากกว่านี้ไหม? (อย่างน้อยเช่น python)

ฉันแน่ใจว่าถ้าฉันออกจากทีม - ไม่ได้บอกว่าฉันไปแล้ว :) - ไม่มีใครจะรักษามัน โปรแกรมนี้จะถูกทำลายและบางส่วนจะพัฒนาด้วยภาษาอื่น

ฉันสนุกกับการพัฒนาด้วย clojure มาก แต่ฉันก็เจอกับสิ่งนี้อาจไม่เหมาะกับทีมของฉัน

คุณคิดอย่างไรเกี่ยวกับเรื่องนี้? ฉันคิดว่าโปรแกรมเมอร์จำนวนมากที่รักภาษาที่ไม่เป็นที่นิยมมีปัญหาเกี่ยวกับเรื่องเดียวกัน

ฉันรู้สึกถึงความเจ็บปวดของคุณฉันชอบที่จะเขียนโปรแกรมการทำงานมากขึ้น (Haskell ดูสนุกมาก!) ฉันรู้สึกว่าฉันมีรอยขีดข่วนเพียงเพราะฉันยังไม่ได้ใช้มันในบริบททางธุรกิจ

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

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

ฉันแน่ใจว่าถ้าฉันออกจากทีม - ไม่ได้บอกว่าฉันไปแล้ว :) - ไม่มีใครจะรักษามัน

อาจเป็นเท็จ

หากโปรแกรมนั้นมีคุณค่าและฝ่ายบริหารเห็นคุณค่าพวกเขาจะมอบหมายคนที่เรียนรู้ Clojure และดูแลรักษา

เกิดขึ้นตลอดเวลา

โปรแกรมนี้จะถูกทำลายและบางส่วนจะพัฒนาด้วยภาษาอื่น

จริงเสมอ แล้วทำไมต้องเป็นห่วง?

โปรแกรมทั้งหมดจะต้องถูกแทนที่ในที่สุด

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

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

การใช้ภาษาใหม่หรือภาษา " โดดเดี่ยว " โดยงานบางอย่างมีความเสี่ยงสูงในโครงการ

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

ในบางกรณีปัญหานี้สามารถใช้ในการปรับปรุงและกระจายทักษะของทีมโดยงานในอนาคต

Clojure อาจมีฐานการติดตั้งขนาดเล็กในปัจจุบัน (ปรากฏในปี 2007) แต่ก็ไม่ค่อยเป็นที่นิยม - ในความเป็นจริงมันอาจเป็นภาษาใหม่ที่ "ร้อนแรงที่สุด" รอบ ๆ ฉันจะแปลกใจถ้าคุณไม่สามารถหาคนอื่นที่สนใจในการเรียนรู้มัน

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

ข้อดีของการนำ Clojure:

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

ข้อเสียของการนำ Clojure

• ภาษาเสริมหนึ่งภาษาที่จะสนับสนุน
• นักพัฒนาอาจต้องการการฝึกอบรมและเวลามากขึ้นเพื่อเพิ่มความเร็ว

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

ไม่ต้องกังวลมีความสุข

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

ฉันจะบอกว่าคุณมีพลังมากขึ้น! เสียงกระเพื่อมเป็นภาษาคอมพิวเตอร์และยังมีความเกี่ยวข้องในปัจจุบัน; ความจริงที่ว่ามันไม่เป็นที่นิยมฉันคิดว่าเป็นเพราะความจริงที่ว่ามันไม่มี IDEs ปุยอันอบอุ่นของ C # และ Java และการใช้งานคอมไพเลอร์หลักใน Windows จะทำงานภายใต้ Cygwin (yuk!) การพัฒนาดูเหมือนจะเกิดขึ้นใน Emacs และฉันคิดว่ามันเล่นได้ดีกับ Linux หรือ Mac

การแข่งขันการเข้ารหัสนี้ได้รับรางวัลจากโปรแกรม Lisp ในปี 2010: http://planetwars.aichallenge.org/

ย้อนกลับไปในวันที่พวกเขาสามารถแก้ไขข้อบกพร่องได้จากประมาณ 100 ล้านไมล์: http://www.flownet.com/gat/jpl-lisp.html

คุณกำลังสละธงแดงบำรุงรักษาอย่างแน่นอน แต่คิดว่าเป็นการให้โอกาสการเรียนรู้แก่ผู้อื่น หากคุณใช้ภาษาฝันร้าย (เช่น MUMPS) หรือภาษาที่น่าเบื่อ (เช่น TCL) ฉันคิดว่าควรถามคำถาม แต่ฉันคิดว่าคุณควรนึกถึงผู้ชายที่พยายามรักษาประเพณีที่ดีที่สุดไว้ :)

มีคำตอบที่ดีมากมาย แต่ฉันต้องการเพิ่มจุด

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

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

โชคดี!

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

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

ดังที่ฉันได้อธิบายไว้ทั้งสองแนวทางมีประโยชน์และข้อเสียบางประการ อย่างที่เป็นอยู่บ่อยครั้งไม่มีวิธีการที่ถูกหรือผิด คุณเพียงแค่แลกเปลี่ยนผลประโยชน์และชุดหนึ่งให้กับอีกชุดหนึ่ง บริษัท ไม่จำเป็นต้องไปในทิศทางใดทิศทางหนึ่งโดยสิ้นเชิง มันสมเหตุสมผลอย่างสมบูรณ์แบบที่จะทำงานส่วนใหญ่ใน C ++ หรือ Java แต่จุ่มนิ้วเท้าลงใน Lisp หรือ Python เป็นครั้งคราวเพื่อลองใช้งานและดูว่าอะไรทำงานได้ดี ดูเหมือนว่าอาจเป็นสิ่งที่ บริษัท ของคุณกำลังทำอยู่

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

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

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

แน่นอนว่าไม่ผิดที่จะเขียนโปรแกรมในภาษา "ไม่เป็นที่นิยม" ทำไมคุณถึงสนใจว่าพวกเขาเป็นที่นิยมหรือไม่ ฉันเห็นด้วยอย่างยิ่งกับ @quanticle เกี่ยวกับเรื่องนี้ หาก Clojure หรือภาษาอื่นที่ไม่สำคัญเป็นเครื่องมือที่ดีที่สุดสำหรับปัญหาที่คุณกำลังแก้ไขคุณควรเลือกมัน

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

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

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