Chọn nỗ lực thiết kế mã hoặc sự lười biếng trong thế giới Ngân hàng

Tôi đã làm việc được hai năm trong một Ngân hàng Đầu tư tuyệt vời.

Tôi đã thực hiện một số dự án kỹ thuật với mong muốn tạo mã được tối ưu hóa nhất, tôn trọng các mẫu thiết kế tốt được điều chỉnh, nguyên tắc RẮN, luật của demeter và tránh tất cả các loại mã trùng lặp ...

Khi giao hàng trong sản xuất => không có lỗi, tất cả đã xảy ra như mong đợi.

Nhưng, phần lớn các nhà phát triển đã đến với tôi để chính xác rằng tất cả mã của tôi quá phức tạp để đọc hiểu. Tôi đã lắng nghe ví dụ: "tạo một số if và instanceof, quên tính đa hình để nó sẽ rất dễ dàng để sửa các lỗi sản xuất khẩn cấp". Tôi không thích trả lời ......

Biết các nhà phát triển này không tò mò chút nào, từ chối nỗ lực tìm hiểu một thiết kế tốt (ví dụ, 90% các nhà phát triển không biết Mô hình chiến lược là gì và tạo mã thủ tục và không bao giờ thiết kế vì họ muốn, đơn giản ), các nhà quản lý dự án của tôi nói với tôi rằng tôi thực sự sai lầm và quá lý tưởng cho thế giới Ngân hàng.

Bạn sẽ khuyên tôi điều gì? Tôi có nên giữ mong muốn về mã thực sự tốt hay thích ứng với phần lớn các nhà phát triển, tôi nhắc lại, thực sự không thú vị bởi mã thiết kế theo tôi, tất cả vẻ đẹp của công việc nhà phát triển của chúng tôi.

Hoặc ngược lại, họ có nên học các nguyên tắc OO cơ bản và thực tiễn tốt nhất để tự thích nghi với mã của tôi không?

những người quản lý dự án của tôi nói với tôi rằng tôi thực sự sai lầm và quá lý tưởng cho thế giới Ngân hàng.

GTFO!

Thời gian để rời đi và thương hại họ. Tại sao bạn nên cho một quái? Bạn biết điều đó sẽ khiến họ mất tiền trong thời gian dài với đội ngũ nhân viên bất tài của họ. Đây không phải là một trò chơi thảo luận kỹ thuật. Đây là về chính trị. Nhờ họ đào tạo các nhà phát triển khác hoặc GTFO! Nếu bạn không có đủ sức nặng chính trị, thì GTFO! Tìm kiếm một công ty với thực tiễn tốt hơn.

Lý do duy nhất để ở đó là một khoản bồi thường thỏa đáng cho những cơn đau đầu của bạn. Vì vậy, họ trả tiền tốt hơn mức trung bình hoặc GTFO! Tôi nghi ngờ bạn có thể phát triển ở đó như là một nhà phát triển phần mềm. Tăng trưởng trong nghề nghiệp của chúng tôi chủ yếu đạt được bằng cách làm việc với những người giỏi hơn bạn và những người khuyến khích thực hành tốt nhất. Và bạn càng giỏi, giá trị thị trường của bạn càng cao đối với các công ty quan tâm.

Vâng, tôi biết đây không phải là một trong những câu trả lời thông thường của tôi nhưng thực sự, nếu bạn không thể chơi trò chơi chính trị trong công ty này, GTFO.

Bạn sẽ khuyên tôi điều gì? Tôi có nên giữ mong muốn về mã thực sự tốt hay thích ứng với phần lớn các nhà phát triển, tôi nhắc lại, thực sự không thú vị bởi mã thiết kế theo tôi, tất cả vẻ đẹp của công việc nhà phát triển của chúng tôi.

Tôi sẽ không làm việc cho một công ty muốn tôi cung cấp các giải pháp tối ưu. Tôi muốn khắc tên tôi vào phần mềm. Tôi muốn tự hào về nó. Tôi không viết các ứng dụng thủ tục bằng các ngôn ngữ dựa trên mô hình OO. Tôi tin vào phần mềm chất lượng cao và nếu công ty không có, tôi sẽ GTFO! Hy vọng bạn có đủ "đụ bạn tiền".

Điểm khó khăn. Tôi nghĩ rằng bạn có thể đi song song hai cách, đứng lên quan điểm của mình và thể hiện ý chí để thỏa hiệp:

• Đây là về tiền. Như bất kỳ công việc dev nào trong thực tế, nhưng vì bạn nhấn mạnh vào môi trường ngân hàng, điều này sẽ hoạt động tốt hơn nữa;). Cho họ thấy rằng phong cách của bạn tiết kiệm tiền. Tìm một ví dụ về cách thay đổi yêu cầu có thể được thực hiện dễ dàng vì thiết kế của bạn. Cố gắng tìm một đoạn mã khác (bạn phải chắc chắn rằng bạn không quá hung dữ ở đây, nhưng này, đó là về việc so sánh các kiểu mã) có xu hướng bị phá vỡ sớm và cho họ thấy bạn không cần phải làm thế nào quan tâm đến các vấn đề như vậy bởi vì mã của bạn có chất lượng tốt hơn để bắt đầu.

• Đây là về tiền. Điều gì nếu phong cách mã hóa của bạn trong thực tế tốn tiền? Nó cũng có thể làm được, nếu người khác dành nhiều thời gian cố gắng hiểu mã của bạn hơn những gì được lưu bởi thiết kế phù hợp. Bạn có thể đang làm điều đúng đắn về mặt kỹ thuật và vẫn không đóng góp tích cực cho nỗ lực của nhóm. Ngoài ra, có thể lạm dụng thiết kế OOP. Tôi với bạn ở khía cạnh "thiết kế tốt là đẹp", nhưng tôi đang cố gắng làm cho bạn biết ở đây về quan điểm của họ và cách họ thực sự có thể đúng theo quan điểm của họ. Song song với điểm trước đó, hãy cố gắng tìm một vị trí mà bạn dùng quá liều. Điều đó cung cấp cho bạn một số chỗ để điều động: Bạn có thể nói, ok, tôi có thể thực dụng hơn một chút ở đây và ở đó, nhưng hãy nhìn xem, cũng có những nơi mà mã này thực sự tốt hơn.

Nhưng, phần lớn các nhà phát triển đã đến với tôi để chính xác rằng tất cả mã của tôi quá phức tạp để đọc hiểu

Có phải nó đã xảy ra với bạn rằng họ có thể đúng?

Tôi đã làm việc với một người nỗ lực rất nhiều để viết mã mà anh ta mô tả là thanh lịch. Ông đã dành rất nhiều thời gian để chê bai công việc của người khác là không thanh lịch. Khi cần thiết phải duy trì mã, mã của anh ấy không phải là mã tôi sẽ chọn để sửa đổi. Nó rất chính xác và chính xác đến nỗi việc thay đổi nó vô cùng nguy hiểm.

Từ thú vị mà bạn đề cập ở đây là "phức tạp". Mã có thể được mô tả là phức tạp hiếm khi cũng có thể được mô tả là đặc biệt tốt.

Các nhà sản xuất đồ nội thất thời Victoria (ít nhất, những người mà chúng ta vẫn thấy ngày nay) là những thợ thủ công thực sự, những gì họ làm là có chức năng, đẹp, được chế tạo tốt và được thiết kế và xây dựng để tồn tại lâu dài. Tuy nhiên trong 150 năm qua, thế giới đã thay đổi. Không nhiều người sẵn sàng trả tiền cho sự khéo léo như vậy, khi các lựa chọn thay thế rẻ hơn mang tính thực dụng hơn khi mua bàn ăn.

Nhiều lập trình viên muốn trở thành thợ thủ công cũ, không may, thương mại ra lệnh rằng điều này không thể xảy ra mọi lúc. Bạn có một sự lựa chọn, thích nghi hoặc rời đi. Có những công ty muốn thợ thủ công, nhưng họ đông đảo hơn những người muốn sản phẩm chủ yếu hoạt động, giá rẻ và bây giờ.

Gợi ý cho tôi rằng bạn không phù hợp với hầu hết các phát triển phần mềm thương mại là "Khi giao hàng trong sản xuất => không có lỗi". Thậm chí Nasa không đạt được điều đó với các tàu con thoi không gian.

Những nơi duy nhất mà bạn chú ý đến chi tiết, và do đó chi phí ban đầu, có thể được chấp nhận là các hệ thống quan trọng trong cuộc sống cấp 1 - ví dụ Avionics / Hàng không vũ trụ, Ô tô, Quân sự và Y tế.

Vấn đề là bạn đang làm việc không đúng chỗ. Có vẻ như bạn là một lập trình viên rất có khuynh hướng học thuật. Bạn sẽ không làm tốt trong môi trường mà bạn đang ở và rất có thể một số lý do sẽ được phát minh để loại bỏ bạn và mã "quá phức tạp" của bạn. Bạn có thể được giao nhiệm vụ rác và / hoặc được đánh giá hiệu suất kém và như vậy cho đến khi bạn tự mình rời đi hoặc họ có một dấu vết giấy che phía sau đủ để sa thải bạn.

Tôi khuyên bạn nên tìm một nơi làm việc sẽ coi trọng khả năng học tập của bạn. Họ đang ở ngoài kia. Bạn cũng sẽ tìm thấy một số thứ nằm trong hàng rào giữa thực dụng và học thuật. Một công việc như thế có thể là lựa chọn tốt nhất của bạn vì điều đó sẽ cho phép bạn mời một số hỗn loạn vào cách tiếp cận của bạn khi bạn giúp người khác khôi phục lại công việc của họ.

Trước khi thực hiện các biện pháp quyết liệt như thay đổi chủ nhân của bạn, tôi sẽ cố gắng cải thiện khả năng của chính bạn để giải thích những người không lập trình như bạn điều hành tại sao cách mã hóa của bạn tốt hơn cho công ty và tiết kiệm thời gian và tiền bạc cho họ. Ngoài ra, hãy chắc chắn rằng bạn không áp dụng các mẫu thiết kế chỉ vì lợi ích của các mẫu thiết kế - bạn có chắc là bạn cũng đã tuân theo các quy tắc của KISS và YAGNI? (Ok, mô hình chiến lược và đa hình không phải là khoa học tên lửa, hãy cho đồng nghiệp của bạn một chút thời gian để thích nghi và giải thích cho họ lý do tại sao bạn chọn cách tiếp cận đó.)

Tại công ty của tôi, chúng tôi đã tiến hành một loạt các hội thảo dựa trên Clean Code Developer . Mục đích là để tạo ra một diễn đàn bên ngoài hoạt động kinh doanh hàng ngày với sự bận rộn và thời hạn và thỏa hiệp xấu, nơi các nhà phát triển có thể tìm hiểu về các nguyên tắc thiết kế phần mềm (như bạn đã đề cập), kỹ thuật lập trình, v.v. và phản ánh về các dự án của họ và công việc riêng của họ.

Các ví dụ thực tế từ các dự án thực tế cũng được thảo luận. Phản hồi từ những người tham gia là AFAIK rất tích cực. Thật khó để đo lường một lợi ích thực tế, mặc dù.

Tham dự các hội thảo đó là một phần thời gian do công ty tài trợ, một phần thời gian rảnh rỗi của người tham gia. Bạn sẽ không tiếp cận được với những đồng nghiệp không quan tâm đến việc học và chỉ muốn làm công việc của họ và về nhà, nhưng đối với bất kỳ ai khác có hứng thú với công việc của mình thì điều này có thể thú vị.

Trước hết tôi sẽ kiểm tra xem cách của bạn có thực sự tốt hơn không. Mã hướng đối tượng có thể rất hay, nhưng nó cũng có thể là cơn ác mộng của các tác dụng phụ ẩn và mỗi hành động có thể yêu cầu một vài lớp khác nhau.

Tốt hơn hết hãy đến InfoQ và xem buổi nói chuyện của Rich Hickey về "Simple Made Easy"

Bạn sẽ phải nhượng bộ một chút nếu bạn muốn tiếp tục làm việc ở đó mà không phải vật lộn liên tục. Một nhóm nhà phát triển là tất cả các thủ tục sẽ không chấp nhận đa hình ngay lập tức. Mặc dù họ có thể không thể thiết kế theo cách OO, họ có thể học từ mã của bạn. Họ có thể đánh giá cao rằng một số mã của bạn dễ bảo trì hơn.

Là một lưu ý phụ, bạn cần đặt câu hỏi trong quá trình phỏng vấn để xem quy trình phát triển và phương pháp mã hóa nào được sử dụng nếu bạn nghĩ rằng điều quan trọng là phải phù hợp với sở thích của bạn.

Trường hợp khẩn cấp xảy ra. Bạn không hoàn hảo và đôi tay của họ sẽ làm hỏng mã của bạn tại một số điểm. Điều đó trừ khi bạn không bao giờ nghỉ, điều này, như bác sĩ đa khoa của bạn sẽ xác nhận, không tốt cho sức khỏe của bạn. Và dẫn đến cơ hội cao hơn để phát ra mã kém.

Mã của bạn có thể có chất lượng cao hơn, (thực tế chưa được chứng minh) nhưng họ có chính sách . (chắc chắn là sự thật

Bạn đã được cảnh báo tuân theo các chính sách và sẽ chịu trách nhiệm về việc không tuân theo chúng. Trong tình huống khẩn cấp. Trong một ứng dụng ngân hàng. Ý tôi là, nếu mục tiêu của bạn kết thúc kém và trong tù tôi có thể tìm ra nhiều cách hài hước và ý nghĩa hơn để có được kết quả tương tự.

Tuy nhiên, bạn cùng phòng của bạn sẽ rất vui mừng khi nghe bạn lan man về sự thiếu tò mò của các đồng nghiệp cũ của bạn.

. sẽ có 40% cơ hội ghi được một đòn chí mạng)

Hãy cố gắng nhớ rằng lập trình được một số người coi là phương tiện để kết thúc chứ không phải vì lợi ích của chính nó. Hãy nghĩ về tất cả các sản phẩm và dịch vụ bạn sử dụng: bạn có dành nhiều thời gian để xem xét nếu mã bên dưới được thực hiện một cách thanh lịch? Hay bạn chỉ đơn giản là đánh giá cao họ khi họ chỉ làm việc? Tìm một ngành công nghiệp hoặc khiến bạn đam mê, sau đó tìm một tổ chức với điều đó, sau đó cung cấp cho họ các giải pháp bao gồm lập trình nhưng không chỉ vậy. Các vấn đề có thể được giải quyết một cách xuất sắc theo những cách khác nhau.