Làm thế nào bạn có thể đạt được và duy trì dòng chảy trong khi lập trình cặp?

Flow là một khái niệm được giới thiệu bởi Mihaly Csikszentmihalyi; Nói tóm lại, nó có nghĩa là để vào "khu vực". Bạn cảm thấy đắm chìm trong nhiệm vụ của mình, tập trung; nhiệm vụ có thể khó khăn nhưng đầy thách thức cùng một lúc. Khi mọi người đạt được dòng chảy, năng suất của họ tăng lên. Lập trình đòi hỏi rất nhiều sự tập trung tinh thần bởi vì chúng ta thường cần phải sắp xếp một vài thứ trong tâm trí của chúng ta cùng một lúc. Nhiều người thích làm việc trong một môi trường yên tĩnh, nơi họ có thể hướng sự chú ý hoàn toàn vào nhiệm vụ. Nếu chúng bị gián đoạn, có thể mất vài phút hoặc thậm chí vài giờ để quay trở lại dòng chảy.

Tôi hiểu rằng có một thực tiễn trong phát triển nhanh và lập trình cực đoan được gọi là lập trình cặp. Điều đó có nghĩa là bạn đặt toàn bộ nhóm phát triển phần mềm trong một phòng để giao tiếp được liền mạch. Bạn viết mã với cặp của mình bởi vì cách này bạn nhận được các đánh giá mã tức thì và ít lỗi hơn.

Tôi luôn gặp vấn đề khi đạt được lưu lượng trong khi thực hiện lập trình cặp vì bị gián đoạn liên tục. Tôi đang suy nghĩ sâu sắc về một vấn đề thì đột nhiên ai đó hỏi tôi một câu hỏi từ một cặp khác. Chuyến tàu tư tưởng của tôi bị mất.

Làm thế nào bạn có thể đạt được và duy trì dòng chảy trong khi lập trình cặp?

Chỉnh sửa: Tuyên bố miễn trừ trách nhiệm - Đây là cách tôi xác định "vùng": A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

Tôi cố gắng tránh trạng thái này bởi vì, trong khi tôi có thể tạo mã chính xác trong vùng, tôi và các nhà phát triển khác sẽ khó hiểu về nó sau này. Nói ngắn gọn: đọc mã được viết trong vùng thường có thể yêu cầu người đọc ở trong vùng. Hạn chế đó là vấn đề của tôi.

Có một chương đáng yêu về Bộ giải mã sạch , nơi chú Bob giải thích một cách thuyết phục tại sao "vào khu vực" là một ý tưởng tồi tệ.

Đây là một giải pháp thay thế tốt hơn là "vào trong khu vực": suy nghĩ thẳng và cân nhắc một cách bình tĩnh và chuyên nghiệp những gì bạn đang làm. Giao tiếp. Chia sẻ suy nghĩ với (các) đối tác của bạn. Xác định các vấn đề thực sự. Thảo luận về các giải pháp có thể. Bạn có thể không cảm thấy tập trung siêu nhiên, nhưng bạn có khả năng đưa ra quyết định tốt và thiết kế dễ tiếp cận.

Nếu bạn và đối tác cặp của bạn có thể thảo luận vấn đề mà không cần cả hai bạn cực kỳ tập trung, thì rất có thể bạn đã giải quyết vấn đề với bản chất đơn giản hơn. Điều đó cho thấy bạn sẽ có thể hiểu lại bất cứ khi nào bạn cần.

Mặt trái ... Nếu bạn chỉ cần một chút thời gian một mình để thẳng đầu (tất cả chúng ta đôi khi làm), chỉ cần lấy nó. Nhận suy nghĩ của bạn với nhau. Làm việc vấn đề trong đầu của bạn đầu tiên.

Nhưng điều quan trọng là nếu bạn làm thế - đừng sử dụng thời gian đó để viết mã sản xuất. Thay vào đó, chơi xung quanh với mã mẫu và nguyên mẫu. Cố gắng hiểu vấn đề, mà không nghĩ về giải pháp nào. Một khi bạn có được mọi thứ thẳng thắn và viết ra, hãy thảo luận với nhóm của bạn và cặp đối tác, hoặc thậm chí con vịt cao su trên bàn của bạn. Nếu bạn vẫn không thể nói rõ điều đó hoặc họ không thể hiểu nó, thì hãy tinh chỉnh ý tưởng của bạn. Khi bạn đã đóng đinh tất cả những điều đó xuống - tích hợp tất cả những suy nghĩ và mã mẫu đó vào một giải pháp thực tế, hiệu quả.

Lập trình cặp đôi khi yêu cầu thời gian cách ly với đối tác của bạn.

Thí dụ

Bạn đang làm việc cùng nhau trên một lớp cụ thể và bạn nhận ra rằng bạn cần phải viết một phương thức đòi hỏi suy nghĩ sâu sắc về một số logic phức tạp, nhưng nếu không thì trả về một kết quả trần tục. Bạn cùng nhau tạo ra các bài kiểm tra đơn vị cho phương pháp đó và trì hoãn việc viết phương thức đó trong một khoảng thời gian khi bạn làm việc một mình. Khi phương thức hoàn thành, bạn quay lại với nhau như một cặp và đánh giá kết quả.

Tôi đã tìm thấy có một lớp nhỏ các vấn đề mà lập trình cặp hoạt động. Ví dụ: nếu bạn đang làm việc trên một sản phẩm đa nền tảng và anh chàng Winders đã triển khai một tính năng yêu cầu mã cụ thể của hệ điều hành, anh ta có thể giúp anh chàng Mac thực hiện tính năng tương tự trên mã Mac trong khi anh chàng Mac lái xe.

Tuy nhiên, theo kinh nghiệm của tôi, lập trình cặp kết quả bất thường dẫn đến mất năng suất ròng. Nó thường có cảm giác như chúng ta đang trả tiền cho hai nhà phát triển để thực hiện công việc của một người.

Vâng, nó làm giảm khả năng khủng khiếp rằng một nhà phát triển có thể nghỉ giải lao stackexchange trong ngày làm việc.

IMHO sẽ rẻ hơn đối với những công ty muốn cảnh sát các nhà phát triển của họ chỉ ghép mỗi nhà phát triển với một nhân viên bảo vệ tư nhân để đứng sau nhà phát triển và tấn công nhà phát triển nếu anh ta chậm lại hoặc cố gắng đạt đến đỉnh điểm không cần thiết trang web.

Là một nhà phát triển đang cố gắng vào khu vực, bạn sẽ cố gắng tự cô lập bản thân tốt nhất có thể để có được sự thoải mái và giải tỏa tâm trí của bạn. Tại sao nên lập trình cặp khác nhau?

Bạn và đối tác của bạn nên tìm một môi trường cảm ứng khu vực phù hợp với cả hai bạn. Điều này có thể sẽ đòi hỏi sự thỏa hiệp về một số thứ, nhưng điểm chính của tôi là môi trường cặp nên tương tự như solo. Tắt thế giới bên ngoài. Cặp đôi đang lập trình cùng nhau; các cặp khác (các đồng nghiệp khác nói chung) không nên làm gián đoạn (ngoại trừ các vấn đề nghiêm trọng, làm giảm những gì bạn đang làm).

Flow là một trạng thái tuyệt vời khi bạn biết các bước chính xác để giải quyết vấn đề. tức là vài ẩn số chưa biết. Bạn ngồi trong một góc yên tĩnh và búa đi giải pháp. Tuy nhiên, hầu hết các vấn đề / câu chuyện / tính năng không rõ ràng khi bạn bắt đầu lập trình chúng. Sẽ luôn có một "khoảng cách" giữa trạng thái kết thúc dự kiến ​​và cách bộ não của bạn đã "lên kế hoạch" cho nó. Bạn học được rất nhiều điều khi bạn thực sự "làm điều đó". Bộ não của bạn tung hứng

• Thiết kế mã

• Đánh máy

• Học những điều mới về tên miền và mã

Khi tôi lập trình một mình, tôi đấu tranh để cân bằng những điều này. Tôi có xu hướng chui vào "hố thỏ" nơi mà sự ngụy biện về chi phí chìm của tôi ngăn tôi lùi lại một bước và nhìn vào bức tranh lớn và thay đổi thiết kế của tôi. Tôi cũng khó nói chuyện với một con vịt cao su tưởng tượng hoặc một con vịt thật cho vấn đề đó. Tôi sau tất cả trong "dòng chảy".

Khi tôi kết hợp lập trình một cách hiệu quả, tôi nhận được các giai đoạn gõ xen kẽ theo sau là các giai đoạn suy nghĩ và suy ngẫm. Đây là nơi có rất nhiều điều ẩn giấu tiết lộ và một thiết kế khác có thể xuất hiện. Nếu tôi chui vào hố thỏ, đối tác ghép đôi của tôi có thể kéo tôi ra khỏi đó. Nói / giải thích điều gì đó với một con người thực sự có tác dụng tuyệt vời này làm cho suy nghĩ của bạn rõ ràng hơn bằng cách nào đó. Đôi khi, tôi rất nhớ việc ở trong "dòng chảy", nhưng tôi nghĩ rằng tôi đóng góp nhiều hơn cho đội của mình khi tôi ghép chương trình hơn là khi tôi lập trình solo. Sau khi lập trình xong! = Gõ. Lập trình xảy ra trong não và lập trình tốt hơn xảy ra khi hai bộ não hợp tác và chỉ trích lẫn nhau.