การเขียนโปรแกรมฟังก์ชั่นการทำงานจำนวนเล็กน้อยสามารถเข้าใจได้โดยคนที่ไม่ใช่ FP หรือไม่ [ปิด]


43

กรณี : ฉันทำงานที่ บริษัท เขียนแอปพลิเคชันใน Python ที่จัดการข้อมูลจำนวนมากในอาร์เรย์ ฉันเป็นผู้พัฒนาโปรแกรมนี้เพียงคนเดียวในขณะนี้ แต่อาจมีการใช้ / แก้ไข / เพิ่มเติมในอนาคต (1-3 ปี) โดยโปรแกรมเมอร์คนอื่น ๆ ในขณะนี้ที่ฉันไม่รู้จัก ฉันอาจจะไม่ได้อยู่ที่นั่นเพื่อช่วยเหลือโดยตรง แต่อาจให้การสนับสนุนผ่านอีเมลหากฉันมีเวลา

ดังนั้นในฐานะนักพัฒนาซอฟต์แวร์ที่ได้เรียนรู้การทำงานของโปรแกรม (Haskell) ฉันมักจะแก้ปัญหาเช่นกรองเช่นนี้:

filtered = filter(lambda item: included(item.time, dur), measures)

ส่วนที่เหลือของรหัสคือ OO เป็นเพียงกรณีเล็ก ๆ ที่ฉันต้องการแก้ปัญหาแบบนี้เพราะมันง่ายกว่าและสวยงามกว่าตามที่ฉันบอก

คำถาม : วันนี้การเขียนโค้ดเป็นแบบนี้หรือไม่

  • นักพัฒนาซอฟต์แวร์ที่ไม่ได้เขียน / เรียนรู้ FP ตอบสนองต่อรหัสเช่นนี้อย่างไร
  • มันอ่านได้หรือไม่
  • สามารถปรับเปลี่ยนได้?
  • ฉันควรเขียนเอกสารเช่นอธิบายให้เด็กฟังว่าเส้นทำอะไร?

     # Filter out the items from measures for which included(item.time, dur) != True

ฉันถามหัวหน้าของฉันแล้วเขาก็บอกว่า "FP เป็นมนต์ดำ แต่ถ้ามันใช้งานได้และเป็นวิธีแก้ปัญหาที่มีประสิทธิภาพมากที่สุด

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


14
ในความคิดของภาษาสมัยใหม่จำนวนมากช่วยให้บางระดับของการเขียนโปรแกรมการทำงานและการใช้ที่จะมากขึ้นและร่วมกันมากขึ้น โดยส่วนตัวแล้วฉันจะบอกว่าไปได้ (อย่างน้อยสำหรับภารกิจการกรอง / การแมปที่ค่อนข้างง่าย)
Joachim Sauer

ฉันไม่สามารถให้คำตอบที่ไม่ได้รับผลกระทบกับคุณเพราะฉันชอบ FP เป็นความคิดที่ดีที่จะเพิ่มความคิดเห็นถ้ามันง่ายกว่านี้
Bruno Schäpper

3
ความคิดเห็นของคุณอาจชัดเจนขึ้น ตัวกรองมีองค์ประกอบที่การทดสอบเป็นจริงดังนั้นความคิดเห็นของคุณจึงสามารถอ่านได้: การ# Select the item's from measures for which included(item.time, dur) == Trueหลีกเลี่ยงค่าลบสองเท่าจะช่วยเพิ่มความเข้าใจ
Martijn Pieters

6
คุณเคยพิจารณาใช้ความเข้าใจในรายการแทนหรือไม่? พวกเขามักถูกมองว่าเป็น "pythonic" มากกว่าแผนที่ / ตัวกรอง
phant0m

2
@MatjazMuhic อืม, นั่นมันสวย ... ;)
kd35a

คำตอบ:


50

มันอ่านได้หรือไม่

สำหรับผม: ใช่ แต่ผมต้องมาทำความเข้าใจว่าชุมชนงูใหญ่มักจะดูเหมือนว่าจะต้องพิจารณา comprehensions รายการเป็นทางออกที่สะอาดกว่าการใช้/map()filter()

ในความเป็นจริง GvR ยังพิจารณาที่จะลดฟังก์ชั่นเหล่านั้นโดยสิ้นเชิง

พิจารณาสิ่งนี้:

filtered = [item for item in measures if included(item.time, dur)]

นอกจากนี้มีประโยชน์ที่ความเข้าใจในรายการจะกลับรายการ map()และfilter()ในทางกลับกันจะส่งคืนตัววนซ้ำใน Python 3

หมายเหตุ: หากคุณต้องการมีตัววนซ้ำแทนมันง่ายเหมือนกับการแทนที่[]ด้วย():

filtered = (item for item in measures if included(item.time, dur))

พูดตามตรงฉันเห็นว่าไม่มีเหตุผลในการใช้งานmap()หรือfilter()ใน Python

มันสามารถแก้ไขได้?

ใช่แน่นอนมีสิ่งหนึ่งที่ทำให้ง่ายขึ้น: ทำให้ฟังก์ชั่นไม่ใช่แลมบ์ดา

def is_included(item):
    return included(item.time, dur)
filtered = filter(is_included, measures)
filtered = [item for item in measures if is_included(item)]

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

ผู้พัฒนาที่ไม่ได้เขียน / เรียนรู้ FP มีปฏิกิริยาอย่างไรกับรหัสเช่นนี้

เขาไปที่เอกสาร Python และรู้วิธีทำงานในเวลาห้านาที มิฉะนั้นเขาไม่ควรเขียนโปรแกรมใน Python

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

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


5
มันอาจจะมีมูลค่าการกล่าวขวัญยังแสดงออกกำเนิดซึ่งทำงานเช่นเดียวกับ comprehensions รายการ แต่กำเนิดผลตอบแทนแทนของรายการเป็นmapและfilterทำในหลาม 3.
เจมส์

@ James: ความคิดที่ดีฉันได้เพิ่มพวกเขาในโพสต์ของฉัน ขอบคุณ!
phant0m

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

4
+1 สำหรับการสังเกตสำนวนที่ต้องการของภาษาที่เป็นปัญหา ความสม่ำเสมอของ IMHO นั้นมีคุณค่าอย่างมากและการใช้ภาษาในลักษณะที่ "ผู้พูด" ส่วนสำคัญสามารถให้การบำรุงรักษาได้มากกว่าการแสดงความคิดเห็นในบางครั้ง
Joshua Drake

4
+1 สำหรับ "เขา googles สำหรับเอกสาร Python และรู้ว่ามันทำงานอย่างไรในอีกห้านาทีต่อมามิฉะนั้นเขาไม่ควรเขียนโปรแกรมใน Python"
Bjarke Freund-Hansen

25

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

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

รหัสก่อนการเปลี่ยนโครงสร้าง:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

รหัสเดียวกันหลังจากการเปลี่ยนโครงสร้างใหม่โดยใช้ FP:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

ทำให้ฉันคิดว่า:

  • คุณไม่ควรกังวลหากคุณรู้ว่านักพัฒนาคนต่อไปที่จะรักษารหัสของคุณจะมีประสบการณ์โดยรวมที่เพียงพอและมีความรู้เกี่ยวกับการเขียนโปรแกรมการทำงาน แต่:

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


8
+1 ถ้า FP ไม่ทำให้ใครๆ อ่านรหัสได้ง่ายขึ้นแสดงว่าคุณทำผิด
György Andrasek

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

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

2
@MainMa ประเด็นของคุณถูกต้องสมบูรณ์ฉันควรจะเจาะจงมากขึ้น สิ่งที่ฉันหมายถึงคือนักพัฒนาในภาษาใดก็ตามที่คาดว่าควรจะใช้คุณสมบัติของภาษาเหล่านั้นได้อย่างมีประสิทธิภาพ ตัวอย่างเช่นการใช้ 'ลักษณะการทำงาน' ใน C # (โดยใช้ตัวกรอง / แผนที่ / ลดการเขียนโปรแกรมสไตล์หรือฟังก์ชั่นการส่ง / ย้อนกลับ) ไม่มีอะไรใหม่และดังนั้นฉันคิดว่านักพัฒนา C # ที่ไม่สามารถอ่านข้อความเหล่านี้ ทักษะ ... อาจเร็วมาก ฉันคิดว่านักพัฒนาซอฟต์แวร์ทุกคนควรเรียนรู้ Haskell เพียงเล็กน้อย แต่เพื่อเหตุผลทางวิชาการเท่านั้น นี่คือสิ่งที่แตกต่าง
Sprague

2
@Sprague: ฉันได้รับคะแนนของคุณและเห็นด้วยกับมัน เป็นเพียงที่เราคาดหวังได้ยากตัวอย่างเช่นโปรแกรมเมอร์ C # ที่เริ่มใช้กระบวนทัศน์จาก FP เมื่อโปรแกรมเมอร์จำนวนมากเกินไปไม่ได้ใช้ยาสามัญ จนกว่าจะมีโปรแกรมเมอร์ที่ไม่มีทักษะจำนวนมากแถบในอาชีพของเราจะต่ำโดยเฉพาะอย่างยิ่งเนื่องจากคนส่วนใหญ่ที่ไม่มีพื้นฐานด้านเทคนิคไม่เข้าใจเลยว่าการพัฒนานั้นเกี่ยวกับอะไร
Arseni Mourzenko

20

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

ไม่มีความคิดเห็นและฉันคิดว่าไม่มีความจำเป็นใด ๆ ฉันไม่ได้ขอให้เพื่อนร่วมงานของฉันช่วยฉันเข้าใจรหัสของเขา

เมื่อคำนึงถึงว่าฉันทำงานมาประมาณ 1.5 ปีฉันคิดว่าโปรแกรมเมอร์ส่วนใหญ่จะสามารถเข้าใจและแก้ไขโค้ดดังกล่าวได้

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


1
ขอบคุณสำหรับความคิดเห็นของคุณ! มันให้ข้อมูลเพิ่มเติมกับฉันในมุมมองอื่น ๆ มันง่ายที่จะกลายเป็นบ้านคนตาบอดและจากนั้นคุณไม่ทราบว่ามันดูเหมือนเมื่อคุณไม่ได้รู้ว่า FP :)
kd35a

1
@ kd35a ยินดีต้อนรับ โชคดีที่ฉันสามารถ
ตั้งเป้าหมาย

1
+1 สำหรับการชี้ให้เห็นว่าตอนนี้หลายภาษามีองค์ประกอบของ FP แล้ว
Joshua Drake

LINQ เป็นตัวอย่างหลักของ FP ใน C #
Konrad Morawski

3

ฉันจะบอกว่าใช่แน่นอน!

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

ตัวอย่างเช่นฉันคิดว่าการเขียนฟังก์ชั่นล้วนมีความสำคัญอย่างยิ่งต่อซอฟต์แวร์ที่เขียนในภาษาใด ๆ (โดย "บริสุทธิ์" ฉันหมายถึงไม่มีผลข้างเคียง) เนื่องจาก:

  • ง่ายต่อการทดสอบหน่วย
  • พวกมันประกอบได้มากกว่าฟังก์ชั่นปรับผลข้างเคียง
  • ง่ายต่อการดีบัก

ฉันมักจะหลีกเลี่ยงการเปลี่ยนแปลงค่าและตัวแปร - แนวคิดอื่นที่ยืมมาจาก FP

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


2

เรามีการสนทนาแบบเดียวกันนี้กับ บริษัท ที่ฉันทำงานเมื่อปีที่แล้ว

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

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

TL; DR: หลีกเลี่ยงในส่วนส่วนกลางระดับสูงของแอปพลิเคชัน (ซึ่งจำเป็นต้องอ่านเพื่อดูภาพรวมการทำงานของแอปพลิเคชัน) มิฉะนั้นใช้มัน


จุดที่ดีในการหลีกเลี่ยงการใช้มันในรหัสระดับที่สูงขึ้น!
kd35a

ฉันคิดอยู่เสมอว่าการขาดระเบียบแบบแผนและโอกาสเป็นอย่างมากในการกำหนดเทคนิคการเขียนโปรแกรมในบล็อกประเภทต่าง ๆ (เช่นวิธีการคงที่, วิธีการสาธารณะ, ผู้สร้าง ฯลฯ ) คำตอบที่ดี ... มันทำให้ฉันทบทวนบางอย่าง ของความคิดเหล่านั้น
Sprague

2

ชุมชน C ++ เพิ่งได้รับแลมบ์ดาเช่นกันและฉันเชื่อว่าพวกเขามีคำถามเดียวกันโดยประมาณ คำตอบอาจไม่เหมือนกัน C ++ ที่เทียบเท่ากันจะเป็น:

std::copy_if(measures.begin(), measures.end(), inserter(filter),
  [dur](Item i) { return included(i, dur) } );

ตอนนี้std::copyไม่ใช่เรื่องใหม่และ_ifตัวแปรก็ไม่ใช่เรื่องใหม่ แต่แลมบ์ดานั้น แต่มันถูกนิยามไว้ค่อนข้างชัดเจนในบริบท: durถูกจับและดังนั้นจึงมีค่าคงที่Item iแตกต่างกันในลูปและreturnคำสั่งเดียวจะทำงานทั้งหมด

สิ่งนี้ดูเหมือนยอมรับนักพัฒนา C ++ หลายคน ฉันยังไม่ได้สุ่มตัวอย่างความคิดเห็นเกี่ยวกับแลมบ์ดาที่มีลำดับสูงกว่าและฉันคาดหวังว่าจะได้รับการยอมรับน้อยลง


ประเด็นที่น่าสนใจคืออาจมีคำตอบที่แตกต่างกันไปขึ้นอยู่กับภาษาที่ใช้นั้นอาจเกี่ยวข้องกับ@Christopher Käckโพสต์เกี่ยวกับวิธีที่ PHP-coders มีปัญหากับเรื่องแบบนี้มากกว่า Python-coders
kd35a

0

โพสต์โค้ดขนาดสั้นลงใน dev ของเพื่อนที่ไม่ใช่ภาษาไพ ธ อนและถามเขาว่าเขาสามารถใช้เวลา 5 นาทีเพื่อตรวจสอบโค้ดเพื่อดูว่าเขา / เธอเข้าใจหรือไม่

ถ้าใช่คุณน่าจะดี ถ้าไม่คุณควรมองให้ชัดเจนยิ่งขึ้น

เพื่อนร่วมงานของคุณอาจงงและไม่เข้าใจสิ่งที่ควรจะชัดเจน? ใช่ แต่คุณควรตั้งโปรแกรมให้สอดคล้องกับ KISS เสมอ

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

หากทั้งหมดนี้คุณยังคงคิดว่าคุณต้องการและต้องการทำมันด้วยวิธี FP แล้วก็ทำได้ เชื่อในสัญชาตญาณของคุณพวกมันเหมาะกับความต้องการของคุณมากกว่าคนส่วนใหญ่ในฟอรัมใด ๆ :)


อย่าลังเลที่จะอธิบายเหตุผลของการลงคะแนนเสียง
Arnab Datta
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.