Thành thật mà nói, bạn thích mã hóa Cowboy? [đóng cửa]

Hầu hết các lập trình viên bảo vệ các phương pháp đúng về mặt chính trị như Agile, Waterfall, RUP, v.v ... Một số trong số họ tuân theo phương pháp này nhưng không phải tất cả. Thành thật mà nói, nếu bạn có thể chọn phương pháp luận, bạn chắc chắn sẽ đi đến các phương pháp "chính xác" hoặc bạn thích phương pháp "dễ dàng" hơn như lập trình cao bồi? Tại sao?

Tôi biết nó phụ thuộc. Xin vui lòng, giải thích khi bạn sẽ sử dụng cái này hay cái khác. Xin vui lòng, nói những lợi thế bạn nhìn thấy trên mã hóa Cowboy.

Xem về mã hóa Cowboy trên Wikipedia

Tôi nghĩ rằng hầu hết mọi lập trình viên có kinh nghiệm đều trải qua ba giai đoạn và một số trải qua bốn giai đoạn:

1. Các lập trình viên cao bồi hoặc cốm không biết gì nhiều về thiết kế và xem nó như một hình thức không cần thiết. Nếu làm việc trên các dự án nhỏ cho các bên liên quan phi kỹ thuật, thái độ này có thể phục vụ họ tốt trong một thời gian; Nó Gets Things Done, nó gây ấn tượng với sếp, khiến lập trình viên cảm thấy tốt về bản thân và xác nhận ý tưởng rằng anh ta biết mình đang làm gì (mặc dù anh ta không làm).

2. Các phi hành gia kiến ​​trúc đã chứng kiến ​​những thất bại của các dự án bóng sợi đầu tiên của họ để thích nghi với hoàn cảnh thay đổi. Tất cả mọi thứ phải được viết lại và để ngăn chặn sự cần thiết khác viết lại trong tương lai, họ tạo ra nền tảng bên trong , và kết thúc chi tiêu 4 giờ một ngày trên hỗ trợ vì không ai khác hiểu làm thế nào để sử dụng chúng đúng cách.

3. Các kỹ sư gần như thường tự nhầm lẫn với các kỹ sư thực tế , được đào tạo bởi vì họ thực sự có năng lực và hiểu một số nguyên tắc kỹ thuật. Họ nhận thức được các khái niệm kỹ thuật và kinh doanh cơ bản: Rủi ro, ROI, UX, hiệu suất, khả năng bảo trì, v.v. Những người này xem thiết kế và tài liệu là một sự liên tục và thường có thể điều chỉnh mức độ kiến ​​trúc / thiết kế theo yêu cầu của dự án.

   Tại thời điểm này, nhiều người yêu thích các phương pháp, cho dù họ là Agile, Waterfall, RUP, v.v. Họ bắt đầu tin vào tính không sai lầm tuyệt đối và thậm chí là cần thiết của các phương pháp này mà không nhận ra rằng trong lĩnh vực kỹ thuật phần mềm thực tế , chúng chỉ là công cụ , không phải tôn giáo. Và thật không may, nó ngăn cản họ đến giai đoạn cuối cùng, đó là:

4. Các lập trình viên băng keo AKA gurus hoặc các chuyên gia tư vấn được trả lương cao biết kiến ​​trúc và thiết kế nào họ sẽ sử dụng trong vòng năm phút sau khi nghe các yêu cầu của dự án. Tất cả các công việc kiến ​​trúc và thiết kế vẫn đang diễn ra, nhưng nó ở mức độ trực quan và diễn ra nhanh đến mức một người quan sát không được đào tạo sẽ nhầm nó với mã hóa cao bồi - và nhiều người đã làm như vậy .

   Nói chung những người này là tất cả về việc tạo ra một sản phẩm đó là "đủ tốt" và như vậy tác phẩm của họ có thể là một chút dưới chế nhưng họ dặm xa spaghetti mã được tạo ra bởi lập trình viên cao bồi. Nuggets thậm chí không thể xác định những người này khi họ nói về họ , bởi vì với họ, mọi thứ đang diễn ra trong nền không tồn tại.

Một số bạn có thể sẽ nghĩ cho bản thân mình vào thời điểm này rằng tôi chưa trả lời câu hỏi. Đó là bởi vì câu hỏi là thiếu sót. Mã hóa cao bồi không phải là một sự lựa chọn , đó là một cấp độ kỹ năng và bạn không thể chọn trở thành một lập trình viên cao bồi hơn bất kỳ ai bạn có thể chọn để không biết chữ.

Nếu bạn là một lập trình viên cao bồi, thì bạn không còn cách nào khác.

Nếu bạn đã trở thành một phi hành gia kiến ​​trúc, bạn không có khả năng sản xuất phần mềm mà không có thiết kế.

Nếu bạn là một kỹ sư gần như (hoặc một kỹ sư chuyên nghiệp), thì việc hoàn thành một dự án với ít hoặc không có nỗ lực thiết kế trước là một lựa chọn có ý thức (thường là do thời hạn vô lý) phải được cân nhắc trước những rủi ro rõ ràng và được thực hiện chỉ sau khi các bên liên quan đã đồng ý với họ (thường bằng văn bản).

Và nếu bạn là một lập trình viên băng keo, thì không bao giờ có bất kỳ lý do nào để "mã cao bồi" bởi vì bạn có thể xây dựng một sản phẩm chất lượng nhanh như vậy.

Không ai "thích" mã hóa cao bồi hơn các phương pháp khác bởi vì đó không phải là một phương pháp. Đó là sự phát triển phần mềm tương đương với các nút nghiền trong trò chơi video. Nó ổn cho các cấp độ mới bắt đầu nhưng bất kỳ ai đã vượt qua giai đoạn đó chỉ đơn giản là sẽ không làm điều đó. Họ có thể làm một cái gì đó trông tương tự nhưng nó sẽ không giống nhau.

Đúng.

Tôi cũng thích để tất trên sàn nhà, nơi tôi đã tháo chúng ra, bàn làm việc của tôi phủ đầy các bản in và giấy gói đồ ăn nhẹ cũ, bồn rửa đầy bát đĩa bẩn và giường của tôi không được làm sạch.

Tôi không coi một kỳ nghỉ được lên kế hoạch trước là một kỳ nghỉ thích hợp, một bữa ăn với tâm trí hướng tới thực phẩm phù hợp về dinh dưỡng hoặc ở trên những con đường mòn được biết là đi bộ đường dài.

Tôi thích vui chơi, ngạc nhiên, học hỏi những điều mới, mắc lỗi và không bao giờ chắc chắn nếu tôi sẽ làm điều đó trở lại. Và đôi khi, thái độ đó chính xác là những gì cần thiết để đưa một dự án lên khỏi mặt đất ...

... nhưng hầu hết thời gian, nó thật vô trách nhiệm. Khi điệu nhảy kết thúc, piper sẽ được trả tiền ... Hãy quên điều này trong tình trạng nguy hiểm của bạn.

Bạn hoàn toàn chính xác. Cách tiếp cận "lập trình cao bồi" này có thể giúp sửa đổi mã đầu tiên nhanh hơn, nhưng tiết kiệm thời gian đó sẽ mất nhiều hơn nhờ:

• Lỗi bổ sung
• Cần thêm thời gian để tìm ra các lỗi mà bạn sẽ có
• Phải đảo ngược mã của bạn để ghi nhớ những gì bạn đã làm khi bạn cần thay đổi trong sáu tháng
• Dành thêm thời gian để đào tạo các nhà phát triển bổ sung cần làm việc với mã của bạn
• Không có nhật ký sửa đổi để nhìn lại khi bạn thực hiện một thay đổi phá vỡ một cái gì đó
• Không có mô-đun, bạn có thể dễ dàng sử dụng lại trong các dự án sau này
• Và trên và trên và trên

Giống như Neil Butterworth đã đề cập trong câu trả lời của anh ấy, đôi khi bạn phải làm những gì bạn phải làm. Tuy nhiên, như một thông lệ chung, không, đập ra mã càng nhanh càng tốt mà không mất thời gian cho việc kiểm soát mã nguồn, các mẫu, tài liệu, v.v. là một thói quen rất xấu để có được.

Tốt cho bạn để phân tích đồng nghiệp của bạn và xem xét liệu thói quen của họ có lợi hay có hại thay vì mù quáng làm như họ làm.

Điều này thực sự đi đến câu hỏi liệu bạn có thể thực hiện mọi thứ một cách chính xác mà không cần một cấu trúc chặt chẽ và mất nhiều thời gian trong kế hoạch hay không.

Tôi sẽ ném một cái gì đó ra đây trên cái này có thể thực sự không phổ biến: khách hàng thường muốn mọi thứ được xử lý theo kiểu cao bồi .

Đó là, họ muốn yêu cầu một cái gì đó được thực hiện, và có ai đó nhảy vào nó, thực hiện nó và đưa nó ra khỏi đó. Không có quản lý dự án, các cuộc họp, cuộc gọi hội nghị, hoặc các hình thức. Cứ làm đi. Tôi chưa bao giờ có một khách hàng nói "này, điều này được thực hiện quá nhanh so với thị hiếu của chúng tôi, chúng tôi sẽ đánh giá cao nếu bạn sẽ đặt một thác nước nhỏ hoặc một cái gì đó vào đó vào lần tới".

Các phương pháp và cấu trúc nhóm được thiết kế để san bằng sân chơi của dự án và nhận các cấp độ khác nhau của các nhà phát triển trên cùng một trang, làm việc cho cùng một mục tiêu, theo cùng một cách.

Những "cao bồi" thành công mà tôi đã làm việc cùng có thể:

• Xác định cách đơn giản nhất để thực hiện một cái gì đó nhanh chóng
• Biết tại thời điểm nào nó sẽ phá vỡ
• Viết mã sạch, dễ đọc và đơn giản
• Dự đoán cách người dùng sẽ sử dụng nó, lạm dụng và phá vỡ nó
• Chia tỷ lệ / tóm tắt nó ở đúng nơi, và không đi phi hành gia kiến ​​trúc trên đó
• Biết nơi và cách xử lý các trường hợp và trường hợp ngoại lệ

Những người như thế này tạo ra kết quả thực sự tuyệt vời với rất ít chi phí quản lý và cấu trúc, nhưng chúng rất hiếm.

EDIT: Để tham khảo trong tương lai, câu trả lời của tôi là cho một câu hỏi khác , đã được hợp nhất vào câu hỏi này. Nó khá lạc lõng ở đây, nhưng đó không phải là cuộc gọi của tôi.

Cô ấy chỉ lười biếng, kiêu ngạo, không biết gì và cực kỳ ích kỷ. Hành vi này là liều lĩnh.

Ý tôi là, không phải cô ấy sử dụng một phương pháp độc đáo hoặc có thể lỗi thời. Cô chỉ có ý thức sử dụng không có . Không có tiêu chuẩn. Không đảm bảo chất lượng. Không có gì. Cô ấy mong đợi chất lượng phần mềm đến từ đâu? Cây?
Thật buồn cười khi cô ấy thực sự phủ nhận trải nghiệm của những người bạn trích dẫn, khi cô ấy rõ ràng là thiếu nó. Cung cấp các đối số có thể kiểm chứng và có liên quan để đặt câu hỏi về yêu cầu của họ là hợp lệ. Nhưng chỉ cố gắng làm mất uy tín của họ bằng cách từ chối kinh nghiệm của họ là không.

Nhưng, điểm chính là: Kiểm soát phiên bản mất bao nhiêu thời gian?
Nếu cô ấy không thể bị thuyết phục đầu tư 5 giây mỗi giờ và sau đó, bạn nên đưa nó lên cho sếp của cô ấy. Kiểm soát phiên bản không phải là tùy chọn. Dấu chấm.

Và một khi bạn có cô ấy sử dụng kiểm soát phiên bản, bạn có thể dễ dàng theo dõi những lỗi mà cô ấy đã giới thiệu. Và để cô ấy sửa chúng. Đó là mớ hỗn độn của cô ấy, tại sao bạn phải dọn dẹp nó? Nếu cô ấy nghĩ rằng cách tiếp cận của mình tốt hơn, thì hãy để cô ấy làm điều đó - tất cả các cách .
Giả sử cô ấy thực sự có thể làm điều đó (trong thời gian hợp lý), bạn vẫn có một vấn đề: làm việc nhóm với cô ấy là gần như không thể. Và đây là điều bạn sẽ phải giải quyết bằng cách thuyết phục cô ấy (điều này nghe có vẻ không ổn), khiến cô ấy rời đi (vì lợi ích của công ty bạn) hoặc rời đi (vì sự tỉnh táo của bạn).
Nhưng thất bại của cô ấy ở nơi đầu tiên có nhiều khả năng và chắc chắn nên chứng minh quan điểm của bạn. Và sau đó cô ấy sẽ bắt đầu tuân thủ các thực hành tốt nhất như nhiều người có nhiều kinh nghiệm làm.

Nó hoàn toàn phụ thuộc vào việc tôi đang làm việc một mình hay trong một nhóm.

Nếu tôi làm việc trong một nhóm, một số quy ước và thỏa thuận là bắt buộc - mọi người trong nhóm phải tuân theo một số tiêu chuẩn thường được thống nhất để làm việc hướng tới mục tiêu chung để những nỗ lực của họ tương thích.

Nhưng nếu tôi làm việc một mình, thì dĩ nhiên tôi muốn trở thành cao bồi. Tất cả các sáng tạo vĩ đại trên thế giới đã được phát minh bởi một tâm trí duy nhất, hoặc nhiều nhất là hai, làm việc theo phong cách cao bồi. Chỉ cần nêu một vài tên:

• Cơ học cổ điển? Cowboy Isaac Newton, sau này bổ sung từ Leibniz, Lagrange, Hamilton.
• Máy bay? Cao bồi Wright.
• Lý thuyết tương đối? Cao bồi Albert Einstein.
• Khoa học cơ bản về máy tính? Cao bồi Alan Turing.
• Transitor? Cao bồi Walter Brattain và John Bardeen.

Các nhóm rất giỏi trong việc cải tiến gia tăng và kết hợp các hệ thống mới dựa trên các công thức đã được chứng minh khá nhanh chóng (với điều kiện là họ được lãnh đạo tốt), nhưng thật hiếm khi nghe về một phát minh thực tế do một nhóm thực hiện. Làm việc theo nhóm và các phương pháp cần có đức tính của họ, nhưng mã hóa cao bồi cũng vậy.

Phụ thuộc vào vấn đề. Một nhà phát triển cao cấp giỏi sẽ viết mã rất nhỏ gọn, đơn giản và mạnh mẽ, rất ổn định và sử dụng tất cả các thực tiễn tốt nhất mà không cần lướt qua các trang tài liệu và hàng tấn mô hình và mô hình khác nhau. Nhưng anh ấy cũng sẽ biết khi nào anh ấy có thể đủ khả năng để làm những việc như vậy.

Tôi sẽ bị sốc nếu anh ấy gặp vấn đề mới và bắt đầu thiết kế một ứng dụng đòi hỏi nhiều tháng từ đầu. Nhưng nếu đó là một plugin, công cụ đơn giản bạn có thể viết trong 2 giờ, một chức năng thực hiện một số chuyển đổi và không nhằm mục đích tái sử dụng, thiết kế và các mẫu thực sự chỉ tốt cho việc lãng phí thời gian.

Ngoài ra, tôi đoán phần lớn thiết kế đã được xử lý trong một luồng nền ở đâu đó bên trong phần đầu của các nhà phát triển cao cấp.

Bạn phải bắt đầu lo lắng khi nhà phát triển cao cấp bắt đầu khuấy động các lớp của một hệ thống phức tạp hoặc các ứng dụng mới từ đầu và không có kế hoạch bước.

Nó phụ thuộc vào hoàn cảnh. Ví dụ, sau một số vụ bê bối giao dịch thảm khốc, một số sàn giao dịch chứng khoán điện tử nhấn mạnh rằng cờ giao dịch tự động đã được thêm vào tất cả các giao dịch. Và điều này phải dành cho tất cả các phần mềm giao dịch trong vòng một tuần. Ý tôi là nó phải được thực hiện - nếu cờ không ở đó bạn không thể giao dịch. Trong trường hợp như vậy, tất cả các hoạt động tốt đều diễn ra - bạn chỉ cần đi (như chúng ta thường nói) "hacky, hacky, hacky". Và trong những trường hợp đó, viết mã nhanh và chính xác là chìa khóa. Đặc biệt là không có hệ thống kiểm tra có sẵn.

Từ kinh nghiệm của tôi, mã hóa cậu bé bò với kiểm soát nguồn là cách tốt nhất và không có lỗi nhất để phát triển các hệ thống phần mềm lớn.

Tôi nghĩ rằng một trong những nhà bình luận đã đúng - tất cả là về kết quả.

Nếu người đó có thể sản xuất một sản phẩm tốt - thứ gì đó làm những gì nó phải làm, và có thể duy trì và đáng tin cậy - thì có vấn đề gì nếu phương pháp hay quy trình chính thức được tuân theo? Các quy trình là tuyệt vời để đảm bảo chất lượng sàn, nhưng nếu ai đó đã làm việc trên tầng đó, thì các quy trình không thêm gì vào phương trình. Quá nhiều nhà phát triển ngày nay, imo, dường như nghĩ rằng quan điểm của lập trình là tuân thủ các quy trình, trái ngược với việc sản xuất một sản phẩm tốt.

Loại người này được gọi là tin tặc và thường không phải là một thuật ngữ miễn phí từ những người chuyên nghiệp hơn trong số chúng ta.

Như bạn đã nhận thấy, thời gian lưu trong thiết kế, tổ chức và kiểm soát bị mất khi gỡ lỗi. Và thường trong việc tìm ra bản phát hành mã nào là bản phát hành thực sự. Nếu bạn có thể tìm thấy nó ở tất cả!

Tôi thấy loại người này quá khép mình, nghĩ rằng họ quá tốt để làm việc với 'những hạn chế' mà người khác phải chịu đựng và vì vậy đừng bận tâm đến họ, và điều đó thậm chí còn mất nhiều thời gian hơn khi những người còn lại đội phải dọn dẹp sau khi họ. Họ cũng không quá tham gia vào quá trình sửa lỗi (đó là nhiệm vụ của nhà phát triển bảo trì, bên dưới các kỹ năng và tài năng của người lập trình l33t).

Vì vậy, nó có thể là một cách tiếp cận phổ biến ở nơi khác, nhưng tại địa điểm của tôi (và tôi là một lập trình viên cao cấp có xu hướng tiếp cận phương pháp này, ahem) chúng tôi không phải chịu đựng điều đó. Không phải là chúng tôi yêu cầu rất nhiều quy trình và thủ tục, nhưng chúng tôi nhấn mạnh vào một số lượng tối thiểu của tổ chức, kiểm soát mã nguồn (mà thành thật mà nói là đông máu và rất hữu ích!)

Kent Beck và cộng sự, tất cả các chuyên gia đều thấy những cách xử lý cũ là xấu, vì vậy họ đã tạo ra các phương pháp mới để tổ chức mã hóa trong khi vẫn giữ nó theo định hướng thủ công hơn, và sau đó nói với mọi người về điều đó - bằng cách xuất bản sách ( Làm thế nào khác bạn đã làm điều đó trước khi Internet?)

Bạn có vẻ như bạn có quyền - không chấp nhận thực hành kém chỉ vì người khác không thể hack nó. Trưởng nhóm hoặc người quản lý của bạn sẽ gặp khó khăn với 'ngôi sao nhạc rock' này, nhưng nếu họ không .. tốt, điều đó vẫn không ngăn cản bạn làm điều đúng đắn. Chỉ cần không chấp nhận thực hành kém chất lượng từ cô ấy, nếu cô ấy làm hỏng (và cô ấy sẽ!) Sau đó để cô ấy làm sạch nó. Bạn tuân thủ các thực tiễn tốt (và bạn biết chúng là gì) mà không để chúng ảnh hưởng đến năng suất mã hóa của bạn và bạn sẽ tốt cho tương lai.

Đây là một bài luận từ một nhà văn thực sự sâu sắc. Nó không khắc phục vấn đề của bạn, nhưng nó cung cấp cho bạn một vài hiểu biết về lý do tại sao nó lại như vậy và có thể là một vài mẹo để giải quyết vấn đề một cách chuyên nghiệp.

Thực tế quan trọng duy nhất là kết quả sản phẩm dài hạn của nhóm.

Có một tuyên bố rằng một nhóm bao gồm một lập trình viên vĩ đại (hoặc nhiều hơn) sẽ tạo ra kết quả tốt hơn so với một nhóm có số lượng lập trình viên trung bình thậm chí còn lớn hơn ở mức trung bình.

Nếu cao bồi sản xuất những thứ mà các lập trình viên thông thường không (trong một thời hạn hoặc thông số cụ thể) và nhóm với cao bồi thậm chí phải mất vài tuần / tháng để dọn dẹp mớ hỗn độn của cao bồi, họ vẫn có thể kết thúc với kết quả tốt hơn sớm hơn.

Nếu đội với cao bồi không thể dọn dẹp (tài liệu, gỡ lỗi, tích hợp, duy trì) mớ hỗn độn ngay cả sau nhiều tháng / năm, thì bất cứ tiến bộ nào mà cao bồi tạo ra cũng không mang lại lợi thế lâu dài cho đội.

Quyết định và tối ưu hóa đội hình của đội.

Không phải mọi lập trình viên đều làm việc (hoặc nên làm việc) theo cùng một cách, miễn là kết quả cuối cùng là tốt.

Bạn có thể tìm thấy một số hiểu biết sâu sắc trong câu trả lời của tôi cho Frankly, bạn có thích mã hóa cao bồi không? Vấn đề là, "mã hóa cao bồi" có nghĩa là những thứ khác nhau đối với những người khác nhau và nó không rõ ràng ngay lập tức, đối với con mắt chưa được huấn luyện, phiên bản mà bạn đang nhìn thấy.

Khi ai đó có thể xem xét một vấn đề và ngay lập tức bắt đầu thực hiện mã, một cách nhanh chóng và chính xác, đó có thể là dấu hiệu của một kỹ sư bậc thầy đã nhìn thấy nó hàng ngàn lần trước đó và đã biết cách tốt nhất để giải quyết vấn đề.

Hoặc, nó có thể là dấu hiệu của một cấp bậc nghiệp dư.

Tôi sẽ nói với bạn một điều: Từ chối sử dụng kiểm soát phiên bản hoặc viết bài kiểm tra vì chúng quá "hàn lâm" chắc chắn không phải là phương pháp "cao cấp" hay thậm chí là từ xa chuyên nghiệp. Bạn sẽ không bao giờ thấy loại việc này được thực hiện tại một cửa hàng phần mềm lớn như Microsoft hay Google và có thể sẽ không thấy nó trong hầu hết các công ty mới khởi nghiệp hoặc các nhóm doanh nghiệp trưởng thành một cách hợp lý.

Những rủi ro là quá lớn. Nếu PC của bạn chết qua đêm thì sao? Tạm biệt 3 năm năng suất. Được rồi, vì vậy bạn thực hiện sao lưu; Sau đó, điều gì xảy ra khi bạn thực hiện một thay đổi lớn, nhận ra rằng nó đã hoàn toàn sai và phải hoàn nguyên nó? Điều này xảy ra ngay cả với những nhà phát triển giàu kinh nghiệm và tài năng nhất vì các yêu cầu đều sai. Nếu bạn không chạy bất kỳ loại điều khiển phiên bản nào, bạn sẽ quay bánh xe trong bùn. Tôi đã từng ở đó, một lần và sẽ không bao giờ quay lại.

Không có lý do - phải mất 10 phút để thiết lập kho lưu trữ và 10 giây để thực hiện cam kết. Nó chiếm khoảng 1% tổng thời gian phát triển của bạn. Các xét nghiệm, nếu bạn đang vội, có thể dễ dàng giảm xuống còn 20-30 phút mỗi ngày mà vẫn hữu ích.

Tôi không phải là người hâm mộ các phương pháp của Agile (lưu ý vốn A) nhưng đôi khi bạn thực sự cần phải xắn tay áo lên và bắt đầu viết mã chết tiệt. Tôi đã thấy những người và các đội bị "tê liệt phân tích" và năng suất thực sự có một cú hích rõ ràng. Nhưng việc loại bỏ các công cụ cơ bản trong giao dịch của chúng tôi như kiểm soát sửa đổi và kiểm tra thực sự là mấu chốt đối với tôi; người này không thuộc về một vị trí cao cấp.

Có, nhưng bạn phải nhận ra khi nào KHÔNG làm điều đó.

Trên bất cứ điều gì nhỏ bạn có thể ổn, nhưng nếu bạn có một cái gì đó phức tạp, nguy hiểm, bị gò bó, v.v., bạn cần có khả năng nhận ra khi một thiết kế phù hợp có giá trị thêm thời gian.

Tôi cũng nghĩ bạn chắc chắn nên suy nghĩ thông qua câu trả lời của Aaronaught. Cowboy có nghĩa là những thứ khác nhau cho những người khác nhau.

Khi tôi nghĩ các phương pháp "truyền thống", tôi nghĩ rằng "quản lý không biết cách hiểu các nhà phát triển, vì vậy thay vì đến với thế giới của các nhà phát triển và hiểu đủ để biết những gì đang diễn ra, họ làm cho các nhà phát triển bước vào thế giới của họ".

Về cơ bản, khi tôi nghĩ về "Agile", tôi nghĩ rằng "bạn làm những gì bạn cần làm để giảm thiểu sự thiếu hiệu quả được giới thiệu bởi nhiều người làm việc cùng nhau". Vì vậy, tôi chắc chắn trong trại rằng "không có những điều như THE Phương pháp Agile , chỉ là một tập hợp các giá trị và nguyên tắc".

Nói cách khác, có những điều bạn cần làm trong một dự án rất lớn, và có những điều bạn cần làm trong các dự án nhỏ, và có những điều bạn làm trên cả hai.

Ví dụ, tôi sẽ không có nhiều hơn các hồ sơ tồn đọng đơn giản nhất cho một dự án mà tôi đang tự làm việc ... Nó sẽ chỉ là một danh sách việc cần làm. Nếu có hai chúng tôi, có lẽ tôi đã chia sẻ danh sách đó, nhưng ở định dạng rất đơn giản (có lẽ chỉ là một ghi chú được lưu trữ trong kho mã của chúng tôi). Khi tôi có 3 hoặc 4, tôi đang tìm kiếm một số loại hệ thống mục công việc.

Chỉ khi tạo mẫu của các tính năng rất đơn giản.

Sau khi hoàn thành và xem xét đúng cách, tôi bỏ mã và nghiêm túc.

Tôi đã thực hiện nó một lần trong một dự án thực tế (vào thời điểm chúng tôi gọi nó là Lập trình Samurai, sau loạt bản phác thảo Samurai Tailor trên Saturday Night Live), và thật ngạc nhiên, nó đã hoạt động tốt. Tất nhiên, những gì tôi bắt đầu là rác, vì vậy có rất ít rủi ro làm cho nó tồi tệ hơn.

Tuy nhiên, tôi là một người "gọn gàng" và không thích phong cách phát triển kiểu bắn súng.

Mặt khác, modus operandi nặng quá trình cũng không phải là sở thích của tôi. Tôi chỉ thích lập kế hoạch trước khi hành động.

Nói chung, tôi cảm thấy rằng số lượng quy trình chính thức phù hợp phụ thuộc rất nhiều vào độ lớn (kích thước của mã, thời gian thực hiện dự án, số lượng nhà phát triển, loại yêu cầu, v.v.) của dự án. Tôi muốn áp dụng các tiêu chí khắt khe và nghiêm ngặt đối với những người phát triển phần mềm cho thiết bị điện tử hàng không hoặc thiết bị y sinh, ví dụ: Đối với các trò chơi, ví dụ, có ít bất lợi hơn cho bất kỳ thất bại nào, vì vậy chi phí và gánh nặng của các hoạt động phát triển nghiêm ngặt và có phương pháp không thực sự biện minh.

Nó phụ thuộc (rất nhiều) vào quy mô của dự án. Một mặt, để có được một kết quả tốt, bạn cần phải có một thiết kế. Mặt khác, nếu dự án đủ nhỏ để bạn có thể khái niệm hóa toàn bộ thiết kế (dù sao cũng là hầu hết) mà không cần viết ra, vẽ sơ đồ, v.v., thì có lẽ bạn cũng sẽ thoải mái mà không cần làm thêm ghi lại tất cả những gì bạn làm

Hầu như tất cả mọi người đã nghe đủ những câu chuyện kinh dị để nhận ra rằng cố gắng nhảy vào mà không có ý tưởng rõ ràng về những gì bạn đang làm và nơi mọi thứ đang diễn ra là một công thức cho thảm họa. Điều hiếm khi được chỉ ra là ngược lại có thể là thảm họa như nhau. Chẳng hạn, hầu hết chúng ta thường xuyên viết các công cụ nhỏ trong quá trình lập trình. Viết một đặc điểm kỹ thuật hoàn chỉnh, các bài kiểm tra, tài liệu thường không đáng giá. Có một ngưỡng dưới mức sản xuất không đáng giá - mọi người thường không thích phát minh lại bánh xe, nhưng trong một số trường hợp, việc tái tạo lại nó dễ dàng hơn là tránh nó.

Trong những trường hợp như thế này, có chuyện gì thường là đáng giá được productizing một thư viện để thực hiện nhiệm vụ như thế này dễ dàng. Cùng với đó, mã mặt trước thường trở nên tầm thường đến nỗi việc viết (hoặc sửa đổi) mã để làm những gì bạn muốn trở nên dễ dàng hơn là sắp xếp làm thế nào để có được một chương trình hoàn chỉnh để làm những gì bạn muốn. Hãy xem xét, ví dụ, gnu thụt lề với hơn 50 cờ khác nhau, nhiều trong số chúng tương tác theo nhiều cách tinh tế khác nhau, vì vậy về các lựa chọn hợp lý duy nhất là 1) không sử dụng nó, hoặc 2) quyết định thích những gì nó mang lại cho bạn thay vì cố gắng để có được những gì bạn muốn ban đầu.

Dường như có hai phe - những người ủng hộ kết quả và những người ủng hộ các nguyên tắc. Tôi rơi vào cái sau.

Tôi là một lập trình viên tầm thường nhưng có lương tâm - mối quan tâm chính của tôi khi viết mã, ngoài việc hoàn thành công việc, là tôi đang giúp bất cứ ai sử dụng mã của mình để hoàn thành công việc CỦA HỌ. Tôi không thể nói rằng tôi luôn đạt được điều đó - nhưng đó là điều tôi hướng đến.

Chắc chắn, bạn có thể có một hotrod trong nhóm của mình - nhưng điều gì xảy ra khi họ nghỉ phép vài tuần và bạn được yêu cầu gỡ lỗi công việc của họ, hoặc thêm công cụ vào đó? Cuối cùng, các lập trình viên cao bồi không phải là người chơi nhóm. Họ có thể tạo ra mã tuyệt vời, nhưng nếu nhóm phụ thuộc vào họ - thì điều đó thật nguy hiểm.

Tôi có cảm giác rằng sự chán ghét của bạn đối với phong cách của cô ấy đang khiến bạn hơi hiểu sai về nó. Bạn nói rằng phương pháp cao bồi được trả tiền khi gỡ lỗi - đây có phải là điều đã xảy ra hay đó là giả định của bạn về cách nó sẽ diễn ra?

Tiết lộ công bằng - Bản thân tôi là một nhà phát triển cao cấp và tôi thường từ bỏ một quy trình chính thức để thiết kế và trải nghiệm. Không có một quy trình chính thức cho một người rất có kinh nghiệm trong lĩnh vực vấn đề là khá phổ biến. Nếu bạn đã giải quyết vấn đề hàng chục lần, bạn không cần một quy trình chính thức để thiết lập lại một giải pháp tương tự.

Một quy trình chính thức liên quan đến việc thiết kế mã - Tôi không hiểu tại sao nên đưa ra nhiều lỗi hơn vì một quy trình chính thức bị thiếu. Vấn đề lớn duy nhất tôi đọc được trong tài khoản của bạn là kiểm soát sửa đổi không được sử dụng - điều này không chỉ ích kỷ mà còn hết sức liều lĩnh thay mặt nhà phát triển. Có phải cô ấy thực tế không cam kết gì không, hay chỉ là không cam kết theo một khuôn mẫu theo ý thích của bạn?

Không có cách tiếp cận chính thức để thiết kế không phải là 'mã hóa cao bồi' trong cuốn sách của tôi (mặc dù không sử dụng kiểm soát sửa đổi). Kinh nghiệm nên được sử dụng cho chính xác điều đó - để giảm thời gian cần thiết để đưa ra giải pháp 'đủ tốt'. Hãy nhớ rằng, bạn phải giải quyết các vấn đề bạn hiện có và làm cho mã dễ thay đổi, không thiết kế cho các kịch bản trong tương lai có thể không bao giờ xảy ra. Với kinh nghiệm bạn có được cảm giác tốt về cách làm điều đó rất nhanh.

Không bao giờ.

Tôi luôn luôn làm phân tích yêu cầu, suy nghĩ về kiến ​​trúc, thiết kế các chi tiết, và sau đó mã. Ngay cả khi tôi làm việc solo ở nhà cho một dự án cá nhân.

Và tôi sẽ ngay lập tức sa thải một nhà phát triển trong đội của mình nếu anh ấy / cô ấy làm việc theo phong cách cao bồi. Chúng tôi là các kỹ sư và có trách nhiệm với khách hàng và người dùng.

Tôi không nghĩ mã hóa cao bồi là một cách tiếp cận cao cấp.

Như những người khác đã nói, có một mối nguy hiểm thực sự trong việc loại bỏ kiểm soát phiên bản. Bỏ qua tài liệu và phân tích cũng có thể có nguy cơ phân phối thứ gì đó mà người dùng không muốn. Chỉ là ý kiến ​​của tôi, nhưng tôi không nghĩ bạn đi từ "lập trình viên đến nhà phát triển" nếu tất cả những gì bạn làm là mã cao bồi.

Tuy nhiên, vâng, có những trường hợp ngoại lệ như một đề cập của Neil Butterworth. Và trong những tình huống này, tôi muốn có một nhà phát triển cấp cao có kinh nghiệm là người phải thực hiện mã hóa cao bồi.

Lập trình cao bồi là một cách khá chắc chắn để tạo ra một quả bóng lớn . Mà, khó chịu như nó có vẻ, có xu hướng cung cấp ...

Tôi nghĩ rằng các lập trình viên mới hơn có xu hướng thực hiện một số điều mã hóa cao bồi khi đảm nhận các khía cạnh của dự án / phạm vi mà họ có thể không có nhiều kinh nghiệm hoặc khi họ đang cố gắng "hoàn thành công việc" do áp lực từ ông chủ, v.v. Tôi biết rằng tôi chắc chắn đã đi xuống con đường này một vài lần vì tôi thiếu kiến ​​thức về mô hình phù hợp để sử dụng và chỉ "hack theo cách của tôi thông qua nó".

Sự khác biệt giữa tôi và người mà bạn đang phàn nàn là tôi thường ngay sau khi nhận ra rằng tôi có thể làm điều đó tốt hơn và khiến nó dễ bảo trì hơn và nó thường thúc đẩy tôi học hỏi nhiều hơn và cải thiện kỹ năng của mình (bằng cách đọc sách / bài viết trên môn học). Khi tôi quay lại để gỡ lỗi một số giải pháp bị hack này, tôi thường thấy đó là một nỗi đau và nó đóng góp nhiều hơn cho tôi muốn học cách làm "đúng cách". Tôi nghĩ rằng người mà bạn đang mô tả về cơ bản bị mắc kẹt ở mức độ phản xạ bản thân của trẻ sơ sinh và nó cho phép cái tôi của họ thực sự cải thiện kỹ năng của họ như một nhà phát triển phần mềm, dường như không phải là người mà tôi muốn làm việc cùng.

Tôi thấy bài viết của bạn thú vị. Tôi thường chia sẻ quan điểm với chủ đề của bạn và cảm giác của cô ấy là các phương pháp được chính thức hóa quá mức đang trở nên ngột ngạt. Như một người khác đã lưu ý, nếu cô ấy là một thiên tài và có thể theo dõi vô số ghi chú tinh thần cùng một lúc mà không quên hoặc bị nhầm lẫn, thì bạn hoàn toàn có thể duy trì một đoạn mã nguyên khối và khiến nó thực hiện những điều tuyệt vời với những thay đổi hoàn toàn tối nghĩa . Có một niềm hạnh phúc tinh thần nhất định đến với bộ não của những người có thể làm điều đó - nó giống như là một vị thần của một vũ trụ nhỏ trong tâm trí bạn.

Tuy nhiên, các nhà tuyển dụng thông minh đã học được một cách khó khăn mà không ai ngoài tác giả ban đầu có thể làm bất cứ điều gì đáng giá cho mã đó. Nếu lập trình viên tiếp tục, họ sẽ lãng phí rất nhiều tiền để nhận ra rằng lựa chọn duy nhất là viết lại (tôi đã từng nghĩ điều đó có nghĩa là mất hoàn toàn, nhưng tôi nhận ra rằng ngày nay bạn không phá hủy kết quả nội tại của phát triển lặp ở cấp độ chức năng bên ngoài).

Cá nhân, tôi sẽ không phiền khi có ai đó như vậy trong đội, bởi vì trong một cuộc khủng hoảng, họ có thể làm điều gì đó mà không ai nghĩ tới.

Mặt khác, hãy là người của chính bạn và tự quyết định câu trả lời cho câu hỏi của bạn là gì, bởi vì điều duy nhất chắc chắn là không ai tìm ra khi xây dựng phần mềm. Đó là một trong những điều làm cho nó trở thành một lĩnh vực thú vị ...