Nếu một lập trình viên thông thạo coi thường các thực hành tốt, thì sự lưu loát của anh ta có chống lại anh ta không? [đóng cửa]


16

Tôi đang làm việc trên một ứng dụng khá lớn và có lỗi - và do cách viết của nó (tôi sẽ tiết lộ chi tiết cho bạn, nhưng nó vi phạm các quy tắc trong hầu hết các lĩnh vực bạn có thể nghĩ đến), bên cạnh việc không thể phát triển nó mà không cần tái cấu trúc.

Phần quan trọng của ứng dụng được tác giả bởi các thực tập sinh, n00bs, v.v.; nhưng cũng đã có một lập trình viên trong cấp bậc của Nhà phát triển chính, và với tất cả sự khiêm nhường, mã mà anh ta để lại cũng đáng ngờ, theo một cách khác có lẽ nhưng vẫn còn.

Được cấp, mã của anh ta có xu hướng hoàn thành công việc - hầu hết thời gian - nhưng thường là khó hiểu, phát minh lại bánh xe (ví dụ: một phương pháp tùy chỉnh lớn thực hiện sao lưu SQL db khá bình thường), v.v. Về cơ bản, không cần nhầm lẫn cộng với quá nhiều lỗi quá mức

Và điều đó khiến tôi nghĩ rằng việc trở thành một lập trình viên có tay nghề cao (tôi cố tình không sử dụng từ "nhà phát triển", giả sử rằng nó chỉ ra một nhóm kỹ năng rộng hơn), nếu không đi kèm với các phẩm chất khác, thực sự có thể là một loại độc.

Giả sử đó là sự thật, một số lý do tôi có thể nghĩ đến là:

  • nếu bạn đang mã hóa một cách dễ dàng, thì cảm giác (hoặc thực tế là trong ngắn hạn) chỉ nhanh hơn để đưa ra các giải pháp của riêng bạn ngay lập tức, mà không cần chuyển sang các thư viện, chức năng có sẵn, v.v.
  • Nếu một người đủ kinh nghiệm để dễ dàng duy trì hình ảnh tinh thần của một chương trình phức tạp, thì người ta ít có khuynh hướng chia nó thành các mô-đun, lớp, v.v.

Vì vậy, quan điểm của tôi là nếu một lập trình viên thông thạo tình cờ là một nhà phát triển tồi, thì sự lưu loát của họ không chỉ không bù đắp cho cái sau mà còn thực sự gây hại nhiều hơn.

Bạn nghĩ gì về điều đó? Có đúng không (đến mức nào nếu vậy)?


24
"Hãy cho tôi sáu giờ để chặt cây và tôi sẽ dành bốn cái đầu tiên để mài rìu." --Abraham Lincoln "Làm sắc nét chiếc rìu của bạn vào thời gian của chính bạn." - Hầu hết các ông chủ
JeffO

15
Một số nhầm lẫn ở đây đối với tôi gây ra bởi tiêu đề, như khi tôi đọc 'lưu loát'I.ThinkOf(this).KindOfThing()
Stewol

Bạn có hỏi nhà phát triển cấp cao này lý do anh ta làm những việc này không? Như bạn đã chỉ ra ứng dụng là lỗi. Vì vậy, có lẽ nhà phát triển cấp cao bị hạn chế trong những gì anh ta có thể làm với ứng dụng lỗi nói trên. Nếu mã của anh ta chỉ hoạt động "hầu hết thời gian" thì nó có lỗi và nên được thay thế và / hoặc sửa.
Ramhound

@Ramhound - không, vì anh ấy đã rời công ty trước khi tôi gia nhập. Anh ấy là người cuối cùng làm việc với nó trước khi tôi đưa nó lên. Tôi biết từ đồng nghiệp rằng anh ấy đã từng rất vội vàng, vì sửa ứng dụng là ưu tiên hàng đầu do nhiều khiếu nại của khách hàng. Nhưng anh ấy đã không làm rất tốt về mặt quản lý thời gian, vì rõ ràng anh ấy đang lách qua một cánh cửa mở mọi lúc mọi nơi. BTW, ông đã tạo thư viện của riêng mình để bản địa hóa các ứng dụng WPF và Winforms.
Konrad Morawski

1
cao liên quan: nàynày . Một số (rất nhiều) người bị mắc kẹt trong giai đoạn này ...
BlueRaja - Danny Pflughoeft

Câu trả lời:


22

nếu bạn đang mã hóa một cách dễ dàng, thì cảm giác (hoặc thực tế là trong ngắn hạn) chỉ nhanh hơn để đưa ra các giải pháp của riêng bạn ngay lập tức, mà không cần chuyển sang các thư viện, chức năng có sẵn, v.v.

Đúng. Tôi đã từng là người đó. Và tôi đã học được rằng đó là một điều khủng khiếp.

Tất cả đều tốt cho bạn, bạn không cần phải học cái gì mới.

Nhưng những gì về phần còn lại của nhóm của bạn? Họ trở nên rất phụ thuộc vào bạn. Họ không thể google "ORive Quicky ORM" để nhận trợ giúp về trình ánh xạ quan hệ đối tượng mà bạn đã viết.

Và sau đó đến ngày họ cần thuê một người mới và họ không thể tìm kiếm những người có kinh nghiệm trong ORM Quicky ORM.

Và cuối cùng cũng đến ngày bạn rời đi và ai đó nhận thấy một lỗi trong ORM của bạn. Và nó sẽ ở đó, bởi vì bạn không có cả một cộng đồng người đang thử nghiệm và sửa chữa sản phẩm của bạn.

Đúng vậy, học Hibernate có thể mất nhiều thời gian hơn là viết một cái gì đó nhẹ nhàng. Nhưng lợi ích của việc làm này là quá lớn để bỏ qua, IMHO.


1
Tôi cũng là người đó - và tôi không đồng ý với câu thứ hai. Có thể giải quyết hầu hết các vấn đề không có nghĩa là các giải pháp của bạn mạnh mẽ, có thể bảo trì, linh hoạt, có thể mở rộng ... hoặc thậm chí là việc triển khai ban đầu được phát triển nhanh chóng. Rất nhiều ý tưởng hay nhất bạn học được ngoài sách hướng dẫn tham khảo ngôn ngữ / thư viện là những điều "tại sao tôi không nghĩ về điều đó?" đơn giản, và cũng linh hoạt, khả năng mở rộng, vv Một trong những điều tồi tệ nhất - nhận ra rằng tôi đã được tiếp xúc với một ý tưởng trước đó, tuy nhiên bác bỏ nó như là một phi lý học vô nghĩa với không sử dụng thực tế, vì vậy khi tôi cần nó ...
Steve314

6
Trong một số tổ chức, việc phê duyệt sử dụng thư viện của bên thứ 3 có thể mất sáu tháng trở lên. Trong một số trường hợp, dù sao đi nữa, bạn có thể đợi sáu tháng và bị từ chối. Tôi đã xây dựng ORM một lần trước đây chỉ vì tôi không muốn lãng phí thời gian để đối phó với bộ máy quan liêu khi tôi đã ở trên dòng thời gian ngắn.
Toby

2
@Toby: Điểm công bằng. Nhưng những công ty nói chung là vượt quá tiết kiệm.
pdr

Chưa kể Không quân Hoa Kỳ cũng giống như những công ty mà @Toby đã đề cập. Chúng tôi đã cố gắng đẩy Ruby trên Rails, nhưng họ không thích nó.
Travis Pessetto

@Toby có một vài trường hợp trong đó phát minh lại bánh xe là điều chính xác cần làm, điều quan trọng là đảm bảo bạn hiểu lý do tại sao bạn
jk.

14

• nếu bạn đang mã hóa một cách dễ dàng, cảm giác (hoặc thực tế là trong ngắn hạn) chỉ cần nhanh hơn để đưa ra các giải pháp của riêng bạn ngay lập tức, mà không cần chuyển sang các thư viện, chức năng có sẵn, v.v.

Có kỹ năng ngôn ngữ nhưng không phải là công cụ. Điều đó thậm chí không thực sự là một lập trình viên mạnh mẽ. Nó chỉ đánh bóng một kỹ năng (kiến thức ngôn ngữ) và cho phép người khác bị rỉ sét (kiến thức thư viện). Cách khác là xấu, nhưng dễ phát hiện hơn.

• nếu một người có đủ kinh nghiệm để dễ dàng duy trì hình ảnh tinh thần của một chương trình phức tạp, thì người ta ít có khuynh hướng chia nó thành các mô-đun, lớp, v.v.

Đó chỉ là sự lười biếng được ngụy trang như một kỹ năng. Sẽ không mất nhiều nỗ lực để giữ những gì bạn đang tích cực làm việc trong đầu. Nó có kỹ năng để tìm các đường nối thích hợp và phân chia mã dọc theo chúng. Các lập trình viên nói rằng nhanh hơn hoặc tốt hơn là để mọi thứ ở một chỗ thường không thể thấy mục nào cần tách ra.


1
Vâng thực sự. Và tôi cho rằng tôi sẽ trái ngược với dân gian kiểu này hơn nếu tôi không kiếm được một cuộc sống tốt trong những năm tới để dọn dẹp sau khi họ ... ;-)
Mike Woodhouse

4

Chỉ cần đảm bảo rằng điều này không phải vì anh ấy đang làm việc trong môi trường "Nếu bàn phím của bạn không nhấp, bạn không làm việc". Tất cả chúng ta đều nhìn lại mã và tự hỏi chúng ta đã nghĩ gì. Ngoài ra, cửa hàng này trong thực tế tái cấu trúc mã của họ? Đó có thể là một sự xa xỉ mà anh không được ban cho.

Tuy nhiên, chúng tôi cần phải tách ra khỏi ý tưởng đầu tiên của chúng tôi (ý tưởng mà bạn có thể ngồi xuống và thực hiện) và lên kế hoạch, nghiên cứu, suy nghĩ nhiều hơn một chút. Sự cám dỗ để đưa từng vấn đề nhỏ ra khỏi đường đi là cám dỗ và toàn bộ dự án tràn ngập thực tiễn này. Không ai muốn trả tiền cho mọi người để sửa chữa những thứ "không bị hỏng", vậy tại sao lại cấu trúc lại.

Chỉnh sửa: Hãy chắc chắn rằng chúng tôi không trừng phạt những người tình cờ biết câu trả lời. Có những người thông thạo và viết mã tốt với tốc độ. Điều quan trọng là không tiếp cận mọi vấn đề theo cách này.


Chính xác là suy nghĩ của tôi. Nếu trọng tâm chính của công ty là giao hàng nhanh nhất có thể, thì mọi người thường làm việc muộn và làm những việc họ sẽ không làm nếu họ được phép làm việc mà không bị áp lực. Bạn cảm thấy "hiệu quả" và hữu ích hơn nếu bạn nhập nhiều mã mà bạn nghĩ về trong khi gõ. Lùi lại để suy nghĩ, hoặc thậm chí để trò chuyện với đồng nghiệp về một vấn đề ... vấn đề đó dễ khiến bạn cảm thấy như bạn đang trì hoãn dự án. Bạn có thể được mã hóa trong thời gian đó, phải không? ;-).
dẫn

Tôi đã may mắn. Tôi được phép làm việc tại nhà sau khi chuyển địa điểm. Mọi người đều muốn biết nếu nó được thực hiện và tôi không làm việc. Tôi sẽ không bị trừng phạt vì biết câu trả lời.
JeffO

3

100%.

Cách nhìn hoài nghi về điều này sẽ là các loại lập trình viên này thực sự đang giữ phần lớn các nhà phát triển làm việc, sửa các lỗi cơ bản đến mức bạn có thể chìm hàng ngàn giờ của nhà phát triển vào đó mà không cần một nửa để ổn định, linh hoạt, an toàn , mô-đun hoặc hệ thống [tài sản phần mềm yêu thích của bạn]. Các hệ thống này có rất nhiều đặc điểm riêng đến nỗi suy nghĩ chuyển sang một thứ khác, thậm chí với 95% các tính năng đã có và một cộng đồng sôi động đằng sau nó, được coi là một nơi nào đó giữa vô lý và căn cứ để bị sa thải.

Nói tóm lại, các lập trình viên thông thạo có thể gây ra nhiều thiệt hại hơn một nhóm đối thủ cạnh tranh, nhưng giá thường được trả trong nhiều năm. Và họ thường chỉ đơn giản là làm công việc của họ (theo định nghĩa của người khác).

Làm thế nào để biết bạn là nhà phát triển hay lập trình viên? Tôi đoán điều đó là không thể, nhưng mỗi khi bạn tìm cách làm cho mã của mình đơn giản hơn mà không làm giảm chất lượng, bạn đã thực hiện một bước nữa để giác ngộ.


1

Vấn đề bạn mô tả về cơ bản là NIH ("không được phát minh ở đây") - có các triệu chứng khác không?

Đôi khi NIH, đặc biệt nếu nó bị cô lập với một hoặc hai người, có thể được xử lý trong một cuộc thảo luận nhóm ("Joe ở đây có một số kinh nghiệm trong việc thực hiện sao lưu SQL bằng các thư viện chuẩn - bạn nghĩ sao, Joe?"). Điều này có thể ít đối đầu hơn so với việc bạn trực tiếp đến gặp người đó và nói "Này! Sử dụng thư viện chuẩn, đồ ngốc!" :)


1

Đã từng ở trong hoàn cảnh của bạn và đã gây ra những tình huống tương tự tôi hiểu sự thất vọng của bạn, nhưng tôi nghĩ câu trả lời cho câu hỏi của bạn là "không". Fluency không đảm bảo rằng một lập trình viên sẽ tạo ra mã có thể bảo trì. Thông thường các tổ chức buộc các lập trình viên phải cung cấp phần mềm được thiết kế và triển khai kém do hạn chế về ngân sách và thời gian. Có thể các lập trình viên thông thạo đang cắt giảm chỉ các lập trình viên quan tâm đến việc cung cấp một cái gì đó mà khách hàng quan tâm. Rõ ràng điều này không tốt trong thực tế, nhưng thật đáng buồn là một thực tế mà hầu hết mọi lập trình viên đều phải đối phó vào một lúc nào đó trong sự nghiệp của họ. Cũng có khả năng là lập trình viên thông thạo chỉ là lười biếng hoặc tự mãn. Tôi có thể nói tiếng Anh hoàn hảo, nhưng sử dụng tiếng lóng dễ dàng và thú vị hơn.

Đối với việc sử dụng mã của người khác hoặc đưa ra lập luận của riêng bạn, tôi nghĩ rằng nó thực sự phụ thuộc vào những gì hoàn thành công việc tốt nhất. Đôi khi "tốt nhất" không giải thích cho những thứ như phong cách và khả năng bảo trì nếu "tốt nhất" có nghĩa là cung cấp một dự án sáu tuần trong hai tuần. Đây là lý do tại sao chúng tôi tái cấu trúc và tinh chỉnh. Ngoài ra, nhà phát triển phải nhận thức được những gì có sẵn về mặt mã của bên thứ ba và họ phải biết cách sử dụng nó và tin tưởng rằng nó sẽ hoạt động và được hỗ trợ / bảo trì đúng cách. Cho rằng có hàng ngàn khung, thư viện và API tùy chọn cho bất kỳ mô hình phát triển phổ biến nào sử dụng những thứ như vậy có thể sẽ tốn nhiều thời gian, năng lượng và căng thẳng hơn là chỉ tự mình lăn lộn. Ngoài ra, tôi tìm thấy các trường hợp mã bên thứ ba không thực hiện chính xác những gì tôi cần nó làm - đó là khi nó '


0

Tôi đang ở trong chiếc thuyền đó (bản viết lưu loát bằng văn bản) và bản thân tôi thuộc loại thông thạo một thời gian.

Rào cản lớn nhất đối với các giải pháp "nhanh và bẩn" luôn là khi bạn cần bổ sung thêm cho nó sau này. Khi bạn cần nhiều tính năng hơn. Chỉ có rất nhiều bạn có thể làm mà không cần cấu trúc. Sau đó, nó bị hỏng và tốn kém để sắp xếp lại nó (vẫn thỏa mãn, nhưng không thực sự được đánh giá cao).

Về cơ bản, bạn phải tự bảo vệ mình trước BẤT K H HACK nào có khả năng trở thành một "giải pháp khả thi", sẵn sàng để được bán bởi một nhân viên bán hàng háo hức. Đó là câu nói cũ "Nó chưa sẵn sàng! - Nhưng nó hoạt động, phải không?" câu hỏi hóc búa.


Làm thế nào để trả lời câu hỏi này?
gnat

@gnat Câu hỏi là "Bạn nghĩ gì về điều đó?", câu trả lời của tôi là những gì tôi nghĩ. Tôi vẫn có cùng quan điểm: sự lưu loát (do đó có thể thực hiện các giải pháp nhanh chóng, hack, v.v.) có thể dẫn đến mã có hại trong thời gian dài. Bạn không thể thông thạo một ngôn ngữ, bạn phải biết cách tổ chức mã.
MPelletier
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.