Giúp một người không và sẽ không bao giờ trở thành một lập trình viên chuyên nghiệp viết mã dễ đọc hơn và có thể sử dụng và giải thích [đóng]

Tôi là Elvis, rất cố gắng để trở thành Einstein. Tôi làm việc cho Mort.

Tên ngốc điên khùng này đang nói về cái quái gì vậy!? (Bạn chỉ cần đọc một vài đoạn đầu tiên)

Nếu bạn không cảm thấy thích đọc liên kết đó, về cơ bản, tôi là một lập trình viên chuyên nghiệp và ông chủ của tôi là (điều này hoàn toàn chính xác):

lập trình viên ngành kinh doanh chuyên nghiệp thiếu bằng cấp về khoa học máy tính nhưng lại rất quen thuộc với Office và VBA, và thường viết các ứng dụng năng suất được chia sẻ giữa các đồng nghiệp của mình

Tất cả những gì đã nói, một phần lớn công việc của tôi là lấy mã của anh ấy được ghép lại với nhau và làm cho nó được sản xuất. Tuy nhiên, phong cách rất kém và văn hóa hàng hóa làm cho điều này trở nên khó khăn. Điều này được kết hợp bởi thực tế là anh ấy không muốn đọc sách lập trình hoặc cho phép tôi giúp anh ấy cấu trúc lại mã của mình.

Có một số chiến lược khác để giúp một người không phải là lập trình viên chuyên nghiệp, sẽ không bao giờ trở thành một lập trình viên chuyên nghiệp viết mã về phía trước dễ đọc hơn và có thể sử dụng để tôi sử dụng và diễn giải?

Khi xem các câu trả lời của bạn trong một số ý kiến ​​tôi không biết nếu bạn nhận ra rằng những gì bạn đang trải qua là khá phổ biến, đặc biệt là khi làm việc trong các lĩnh vực đặc biệt, nơi cần các chuyên gia tên miền (hãy gọi họ là nhà khoa học) để tìm ra cách kết hợp và điều chỉnh các thuật toán cho các vấn đề trong tầm tay.

Thay vì phàn nàn về nhà khoa học và mong họ thay đổi, chỉ cần nhận ra rằng bạn không nên mong đợi nhà khoa học quan tâm nhiều đến "chất lượng mã". Rất khó để khiến các nhà phát triển phần mềm khác quan tâm đến "chất lượng mã" chứ đừng nói đến ai đó có lợi ích chính nằm trong miền chứ không phải lập trình.

Bạn đi đâu từ đây phụ thuộc phần lớn vào mức độ tự tin của "nhà khoa học" trong khả năng hiểu công việc của họ. Nếu họ tin tưởng rằng bạn có thể hiểu mã của họ và sẽ không làm hỏng nó khi bạn sửa đổi mọi thứ thì thường không có vấn đề gì. Họ sẽ dựa vào chuyên môn của bạn.

Tuy nhiên, nếu nhà khoa học không muốn bạn thay đổi mã của họ thì rất có thể bạn chưa "kiếm được" sự tự tin của họ. Nếu đó là trường hợp sau đó thay vì tập trung vào sửa chữa nhà khoa học, bạn nên tập trung vào "sửa chữa" chính mình. Ý tôi là điều đó là thực hiện các bước để đạt được sự tự tin của họ. Có lẽ cách dễ nhất để làm điều này là như sau:

Là một phần của quy trình thử nghiệm của bạn:

1. Bắt đầu biến các thuật toán thành một cái gì đó dễ hiểu hơn (ví dụ: sơ đồ, PDL, ký hiệu toán học)
2. Tìm hiểu để hiểu các thuật toán.
3. Hãy chắc chắn để xác định các trường hợp cạnh.
4. Hỏi nhà khoa học nếu đại diện "thay thế" đơn giản hóa của bạn là chính xác
5. VÀ QUAN TRỌNG NHẤT xác định các vấn đề mà bạn tìm thấy; VÀ không có âm thanh "buộc tội" nói điều gì đó như "Tôi đã xem xét thuật toán và nhận thấy XYZ là nó phải làm điều này hay nó được cho là làm điều đó?". Không có gì có được sự tự tin của họ tốt hơn viên đạn này.

Khi bạn bắt đầu tìm thấy lỗi VÀ đã thể hiện sự quan tâm trong lĩnh vực họ quan tâm thì tỷ lệ cược trở nên cao hơn rất nhiều, ít nhất họ sẽ cho phép bạn bắt đầu sửa đổi mã để làm cho nó trở nên "chuyên nghiệp" hơn. Thông thường, họ thậm chí sẽ không cảm thấy cần phải viết mã nguyên mẫu nữa. Họ sẽ chỉ viết một cái gì đó lên một trong những ký hiệu "thay thế" mà bạn đã dạy họ (mà không hề nhận ra) và họ sẽ tự tin rằng bạn sẽ hiểu ý của họ.

Bằng mọi cách, nỗ lực đầu tiên của tôi là đưa ra một số gợi ý về cách nhà khoa học có thể giúp "giao tiếp" tốt hơn để giúp bạn; nhưng có vẻ như bạn đã thử điều đó. Vì vậy, bước duy nhất mà bạn có quyền kiểm soát là những gì bạn làm. Kiếm được sự tự tin của họ và hầu như luôn luôn là chuyên gia tên miền sẽ cảm thấy nhẹ nhõm khi chuyển mã hóa cho người khác và không phải lo lắng về tất cả các chi tiết nhỏ đi vào viết mã. Họ muốn tập trung vào việc cải thiện các thuật toán.

Đôi khi, tất cả những gì bạn có thể làm là đưa ra một gợi ý và để lại sau đó. Bạn sẽ không gây ấn tượng với sếp hoặc cấp cao nếu bạn tiếp tục làm điều gì đó mà họ đã từ chối hoặc quyết định họ không muốn làm, ngay cả khi bạn đúng 100%. Trong thực tế, điều này sẽ làm hỏng một mối quan hệ, cho dù bạn là người gợi ý hay người được gợi ý. Chỉ cần tập trung vào những gì BẠN có thể làm để làm cho công việc của bạn dễ dàng hơn.

Khi anh ấy thực sự là "một người không phải là lập trình viên chuyên nghiệp, sẽ không bao giờ là một lập trình viên chuyên nghiệp" như bạn nói và khi một phần lớn công việc của bạn thực sự "lấy mã của anh ấy và cùng nhau sản xuất", nó có vẻ như là của bạn nhóm hai người sẽ làm việc hiệu quả hơn khi anh ta để lại chương trình cho bạn và tập trung vào phần quản lý của dự án.

Tuy nhiên, điều này giả định rằng bạn đúng. Chúng tôi lập trình viên luôn có xu hướng coi thường mã được viết bởi những người khác tồi tệ hơn nhiều so với của chúng tôi. Định kiến ​​này thực sự khó đánh bại và dẫn đến việc chúng ta đánh giá thấp đồng nghiệp của mình. Những gì bạn cho là "lập trình sùng bái hàng hóa" có thể là "thực tiễn tốt nhất đã được chứng minh" từ quan điểm của anh ấy, và những gì bạn cho là "ứng dụng tao nhã của các mẫu hướng đối tượng" có thể là "áp đảo không cần thiết" đối với anh ấy. Khó để nói cho tôi, bởi vì tôi chỉ biết khía cạnh của câu chuyện của bạn.

Sự coi thường đối với mã người khác trở nên mạnh mẽ hơn, phong cách lập trình của chúng ta càng khác biệt. Trong trường hợp đó là một bản năng tích cực, bởi vì pha trộn các phong cách lập trình khác nhau trong một dự án làm cho nó rất khó để duy trì.

Khi cả hai bạn không thể bắt chước phong cách của người kia, thì bạn có thể xác định trách nhiệm rõ ràng. Làm cho một người chịu trách nhiệm cho một phần của ứng dụng và người kia cho phần kia. Xác định các giao diện rõ ràng giữa cả hai mô-đun với nhau, nhưng để lại việc thực hiện nội bộ cho người chịu trách nhiệm. Để làm cho anh ấy nhận thức rõ hơn về các lỗi trong mã của anh ấy, bạn có thể viết các bài kiểm tra đơn vị cho anh ấy và chỉ ra khi mã của anh ấy rõ ràng không hoạt động theo hợp đồng giao diện mà bạn đã chỉ định cùng nhau.

Thông qua việc thiết lập quyền sở hữu mã rõ ràng, bạn có thể đạt được sự cùng tồn tại tốt hơn của các phong cách khác nhau của bạn. Ngoài ra, khi cả hai bạn chịu trách nhiệm sửa các lỗi trong mã của riêng họ, bạn sẽ không phải điều hướng mã của nhau thường xuyên.

Bạn phải tự hỏi: mục tiêu cuối cùng của bạn ở đây là gì? 1. để giúp sếp của bạn? 2. để giúp công ty? 3. để giúp mình? Và trước khi bạn trả lời "tất cả những điều trên", hãy chậm lại. Nhiệm vụ đầu tiên của bạn là xác định rõ mục tiêu chính của mình, vì câu trả lời phụ thuộc vào nó.

Nếu mục tiêu của bạn là:

1. Giúp sếp? Cho nó lên. Anh ta dường như không yêu cầu điều đó. Bạn nói, "Anh ta biết mã của anh ta là xấu, nhưng nó làm những gì anh ta cần." Vậy thì, kết thúc cuộc thảo luận. Trừ khi và cho đến khi sếp của bạn không hài lòng với tình hình hiện tại, anh ta sẽ không thay đổi, và anh ta sẽ phẫn nộ với những nỗ lực của bạn để giúp anh ta. Nếu tại một thời điểm nào đó trong tương lai anh ấy "cảm thấy đau" về hiện trạng, hy vọng bạn sẽ tự đặt mình là một người cố vấn đáng tin cậy và anh ấy sẽ biết nơi nào để được giúp đỡ.

2. Giúp công ty của bạn? Là tình hình hiện tại đe dọa dòng dưới cùng? Thời hạn có nguy cơ không? Là quản lý cấp trên tăng nhiệt của nó? Nếu không, sau đó cho nó lên. (Đây thực chất là điểm mà Jimmy Hoffa đã đưa ra trong nhận xét của mình cho bài viết gốc của bạn.) Tuy nhiên, nếu thực tế, tình huống hiện tại thực sự là một rủi ro không thể chấp nhận được cho bộ phận / công ty của bạn, thì việc thay đổi quy trình là theo thứ tự. Trong trường hợp đó tôi sẽ đề nghị bạn ngồi xuống và phác thảo một khácphân công lao động. Chìa khóa ở đây là giải thích rằng thời gian bạn dành để tái cấu trúc mã của sếp sẽ tốt hơn dành cho việc viết mã mới. Bạn nói rằng bạn không có thời gian để tự viết tất cả, nhưng đó không phải là điều tôi đang đề xuất. Bạn cần tìm ra cách để tối đa hóa điểm mạnh tương ứng của mình. Ngừng suy nghĩ về anh ta như một Mort, và nghĩ về anh ta như một nhà phát triển cơ sở với kiến ​​thức tên miền vượt trội. Đó là một sự sắp xếp làm việc rất phổ biến trong ngành, và nó sẽ khiến bạn học cách phát triển mạnh trong nó. Ví dụ, đảm bảo rằng anh ấy biết rằng bạn biết chuyên môn của anh ấy cần thiết như thế nào (lặp lại bước này thường xuyên), và sau đókhiêm tốn đề xuất chiến lược sau (hoặc một cái gì đó tương tự) như một con đường nhanh hơn để đưa kiến ​​thức của mình vào thị trường: (a) chia công việc thành các cuộc chạy nước rút "nhanh nhẹn", (b) hợp tác mạnh mẽ lên phía trước (trong mỗi lần chạy nước rút) xác định kết thúc -tất cả các yêu cầu và kiến ​​trúc. (c) Hãy để anh ta ra đi và xây dựng nguyên mẫu để đưa ra tất cả các quyết định thuật toán, trong khi bạn xây dựng cơ sở hạ tầng mà bạn đã đồng ý ở bước trước. (d) Triển khai các thuật toán của anh ấy vào cấu trúc của bạn trong khi anh ấy xây dựng các bài kiểm tra để xác minh nó. (e) Tiến hành V & V của bạn với nhau trong môi trường lập trình ngang hàng. (ví dụ: "Thử nghiệm này không thành công; tại sao? lỗi logic thuật toán hoặc lỗi mã hóa?"; lặp ở đây).

3. Tự lo lấy thân? Hãy trung thực ở đây. Nếu tất cả những gì bạn đang làm là phàn nàn rằng bạn không thích công việc của mình, tôi khuyên bạn nên dành nhiều thời gian hơn để suy nghĩ về # 2 ở trên. Nếu bạn không quan tâm đến công ty VÀ bạn không thích công việc của mình, hãy bắt đầu phân phối hồ sơ của bạn. Nếu bạn quan tâm đến công ty của mình nhưng không thích công việc của mình, thì việc tập trung vào # 2 sẽ giúp ích cho cả hai tài khoản. Nhưng trong trường hợp đó, đó chỉ là "đôi bên cùng có lợi" nếu mọi người rõ ràng rằng niềm đam mê của bạn thực sự bắt nguồn từ mong muốn giúp đỡ Nhóm, và không chỉ từ sự thất vọng tự cho mình là trung tâm trong nhiệm vụ của bạn.

Tôi không chắc chắn tôi sẽ thêm một cái gì đó vào cuộc thảo luận này, nhưng đã làm việc trong các tình huống tương tự khi vi phạm Access truy cập vào một dòng có ShowMessage('Hello');hoặc tương tự, chỉ để biết rằng cùng một dòng có nhiều mã hơn, ngoài màn hình vào đúng,

Tôi tin rằng bạn có hai lựa chọn cơ bản:

1. Hãy để mã chạy . Nếu mã đang hoạt động và làm những gì cần làm, trừ khi sếp của bạn đặc biệt yêu cầu bạn sửa mã của họ, hãy cứ để nguyên như vậy. Điều đó cũng có thể khiến anh ta hiểu rằng mã của bạn trông đẹp hơn và giao lại công việc cho bạn (cũng được Dunk chỉ ra trong câu trả lời của anh ta).
2. Nếu bạn rất quyết tâm làm cho mã chuyên nghiệp, hãy xây dựng một thư viện / khung mà anh ta có thể sử dụng. Nếu có một mô hình về các lỗi / chiến lược mà bạn thường sửa, bạn có thể gói chúng vào một vài tệp thư viện và đưa nó cho anh ấy làm "thư viện cơ sở cho công ty" , mà bạn cũng có thể sử dụng như một giao diện chung.