Làm thế nào một Brainer phải có thể đối phó với mã Brainer Left-Brainer lớn? [đóng cửa]


11

Tôi là một nghệ sĩ, chủ yếu, mặc dù tôi mô tả bản thân là một nghệ sĩ / nhà vật lý. Trong khi tôi có thể làm toán, xử lý từ ngữ và những thứ "logic" được coi là não trái, đó là một nỗ lực và tôi mắc lỗi, trong khi tôi làm tốt và hầu hết thời gian nghĩ về những điều liên quan đến não phải suy nghĩ - quan hệ không gian, bối cảnh toàn cảnh lớn, v.v ... Tất nhiên tất cả chỉ là mờ nhạt, vì lý thuyết não phải trái là quá đơn giản và không có hoạt động tinh thần nào đơn giản như vậy. Tuy nhiên, tôi cảm thấy rằng tôi phù hợp với các nghệ sĩ, đạo diễn video, đầu bếp và tư duy phi ngôn ngữ, các kiểu sáng tạo khác, trong khi hầu hết mọi người trong "IT" hoặc các kỹ sư phần mềm khó tính đều có suy nghĩ khác biệt, chú ý đến chi tiết, nắm giữ nhiều chi tiết trong tâm trí cùng một lúc, và khả năng hợp lý và bằng lời nói mạnh mẽ.

Vì vậy, ở đây tôi đang làm một công việc được trả tiền để sửa các lỗi khó hiểu và tối nghĩa trong một khối lượng lớn phần mềm C ++, rất nặng về OO và bất kỳ một dòng mã nào cũng không có ý nghĩa gì trừ khi tôi nhớ về hai mươi tên lớp và phương thức khác, mối quan hệ giữa chúng, dòng chảy thực thi (rất giống spaghetti) và các chi tiết khác.

Bên cạnh đó, tôi cũng khá mạnh mẽ chống lại nhiều phong cách C ++ và OO đương đại. Những người đã viết mã này thực sự đã uống sâu OO và Modern C ++ kool-ade. Tôi thấy nó thực sự làm cho mã khó theo dõi hơn, khó hơn nhiều để quyết định nơi sửa chữa hoặc thay đổi một cái gì đó. Tôi không biết liệu đây có phải là một phần của sự khác biệt trái / phải (hoặc bất cứ điều gì bạn muốn gọi nó) hay không.

Nhưng tôi phải làm việc trên C ++ - mọi người phụ thuộc vào tôi vì thu nhập của tôi. Các mẹo và kỹ thuật để đối phó với tình huống này là gì, để có hiệu quả nhất có thể cho chủ nhân của tôi?


9
Đó không phải là sự khác biệt giữa não trái / não phải - không ai có thể hiểu hoặc sửa đổi loại mã C ++ đó mà không cần nỗ lực lớn, ngoại trừ người đã viết nó (thường, thậm chí không phải họ). Chỉ cần đảm bảo rằng khi bạn được yêu cầu ước tính thời gian sẽ có thứ gì đó, bạn sẽ đưa ra một vài trăm phần trăm tốt để đối phó với thiết kế "đương đại".
Carson63000

8
Đừng nản lòng. C ++ là ngôn ngữ rất lạ, trong đó mục tiêu thiết kế không phải là khả năng sử dụng (đối với con người) cũng như khả năng biên dịch, rõ ràng, chính xác (đối với trình biên dịch). Mục tiêu thiết kế duy nhất của C ++ là làm cho mọi hoán vị từ vựng có thể có nghĩa là một cái gì đó, ngay cả khi nó hoàn toàn không thực tế.

1
@Rocket: Bạn đã thổi nó lên :-) nhưng tôi đồng ý thành từng mảnh.
Geek

@mojuba - vâng, chúng tôi sử dụng một hình thức C ++ tiên tiến: D
DarenW

2
Đây được gọi là "Mã kế thừa" và vấn đề không chỉ dành riêng cho bạn. Xem en.wikipedia.org/wiki/Legacy_code để biết liên kết đến cuốn sách Michael Feathers về cách thuần hóa một con thú như vậy.

Câu trả lời:


2

Hãy thử tham gia nhiều hơn vào khía cạnh thiết kế của những thứ thoải mái với sự mờ nhạt là một thế mạnh sẽ là gợi ý của tôi về sự phát triển nghề nghiệp. Là một người thích sáng tạo, làm việc trong bảo trì có thể không phù hợp lắm trong khi làm việc trên các công cụ mới có thể tốt hơn nếu điều đó là có thể.

Mặc dù không có gì sai khi muốn một chút tự hào về công việc của một người, muốn không bị sa lầy vào các chi tiết có thể là điều mà bạn có thể phải tìm một cách tiếp cận mới để cải thiện. Thay vì nhìn nó như đang suy sụp và bẩn thỉu, có thể có một viễn cảnh khác có thể khiến nó vui vẻ bằng cách nào đó.


Hỗ trợ và bảo trì có thể có người hâm mộ của họ vì một số người thích điều chỉnh các hệ thống hiện có hơn là đưa vào một hệ thống mới. Tôi biết tôi có xu hướng làm việc tốt hơn với một hệ thống hiện có mà tôi đang thay đổi thay vì cố gắng rút thứ gì đó ra khỏi ether.

Những gì bạn có thể cố gắng làm là lưu ý khi mọi người đang muốn ý tưởng xử lý các điểm rắc rối và giải pháp động não khác nhau vì đây là một phần của những gì bạn thích. Nó không phải là về việc biết những dòng mã nào sẽ thay đổi mà là nếu bạn có thể nói với ai đó, "Bạn đã nhìn vào đối tượng đó và xem liệu nó có đang làm nhiều hơn những gì nó tuyên bố không?" loại điều.

Một điểm khác là biết những gì bạn muốn tạo: Đồ họa, ứng dụng, trang web, quy trình hoặc hệ thống? Đây là tất cả những thứ hơi khác nhau mà muốn tạo ra, bạn có thể được yêu cầu "Tạo cái gì?"


Ý tưởng này gần như đã được đưa ra khỏi cuộc họp với sếp của tôi chỉ mới hôm qua. Tôi tự hỏi - không phải mọi người luôn tạo ra mọi thứ mong muốn hơn, và bảo trì luôn giống như làm sạch nhà vệ sinh? Nếu ai đó đi xung quanh nói "Tôi thà TẠO những thứ!" họ sẽ được thực hiện nghiêm túc?
DarenW

4
Tôi thích bảo trì mã. Nó giống như phẫu thuật hơn là làm sạch nhà vệ sinh: bạn phải sửa một phần của hệ thống làm việc mà không làm hỏng nó.
Frank Shearar

"rút thứ gì đó ra khỏi ether" - nhắc nhở tôi về một giấc mơ khi tôi kéo chiếc bánh rán chanh ra khỏi không khí để gây ấn tượng với một cô gái: D Nhưng nghiêm túc đó là một điểm mấu chốt đối với tôi - tôi luôn muốn, nghĩ về, tạo ra những điều mới.
DarenW

3
@FrankShearar Đôi khi nó giống như phẫu thuật được thực hiện trong nhà vệ sinh; (
mlvljr

16

Nó không có âm thanh (ít nhất là với tôi) như mã của bạn đặc biệt hướng đối tượng hoặc đặc biệt tương tự như "Modern C ++". Thay vào đó, ngược lại, một trong những yếu tố chính của định hướng đối tượng tốt là đóng gói, mục đích chính của nó là giảm số lượng những thứ bạn cần theo dõi tại bất kỳ thời điểm nào. Tương tự như vậy, "dòng chảy thực thi giống như spaghetti" nghe có vẻ không hướng đối tượng cũng không hiện đại (bất cứ điều gì).

Bây giờ, tôi cho rằng nếu tôi nhìn vào mã bạn đang duy trì, tôi có thể thấy nó khác và / hoặc bạn có thể thấy mã của tôi giống với mã bạn đang duy trì ngay bây giờ - điều đó hơi khó đoán. Đúng là nếu bạn cố gắng theo dõi từng chi tiết về cách mã của tôi hoạt động, tôi cho rằng bạn có thể thấy nó là một luồng kiểm soát khá giống spaghetti.

Ví dụ, tôi rất thích (hoặc ít nhất là khoan dung) với khá nhiều chuyển đổi ngầm so với nhiều lập trình viên - Tôi sử dụng những thứ như các lớp proxy khá nhiều. Điều này có nghĩa là có thể dễ dàng có ba hoặc bốn đối tượng tạm thời thuộc các loại khác nhau được tạo trong quá trình gọi một hàm duy nhất (và lưu ý rằng tôi không nói về việc thực sự thực thi hàm, chỉ gọi nó). Tất nhiên, tất cả các đối tượng tạm thời đó sẽ bị hủy một lần nữa vào cuối biểu thức có chứa lệnh gọi hàm. Nếu bạn đếm nó, bạn có thể dễ dàng có một nửa tá hoặc nhiều chức năng riêng biệt được gọi trong khi gọi / trả về từ một chức năng "rõ ràng" được gọi trong mã.

Tuy nhiên, quan điểm của việc thực hiện theo cách đó là làm cho nó dễ dàng bỏ qua hầu hết các câu đố liên quan đến (ví dụ) xử lý các chi tiết như cách một đối tượng cụ thể được thể hiện và chỉ tập trung vào những gì nó thực sự thay thế. Bạn sẽ chỉ cần xử lý hầu hết các mã đó nếu bạn thấy một lỗi trong phần cụ thể đó. Tôi cố gắng tránh nhiều điều đó, tuy nhiên, bằng cách tạo ra các lớp quá nhỏ và đơn giản, làm rất ít, đến nỗi chỉ cần nhìn thoáng qua để nhận ra rằng điều đó rõ ràng là chính xác, vì vậy từ đó trở nên dễ dàng bỏ qua.


Ừ! Loại công cụ đó làm tôi co rúm lại! Có lẽ phong cách suy nghĩ của tôi là quá thấp, tức là "lập trình định hướng opcode", để thoải mái với điều này.
DarenW

2
Đối với "để làm cho nó dễ dàng bỏ qua hầu hết các câu đố" - phong cách mã hóa dường như là một vinh quang tầm thường. Cố gắng khắc phục một điều nhỏ trong tuần này, có những chi tiết không thể tin được mà thực sự không làm được gì.
DarenW

"... bằng cách tạo các lớp quá nhỏ và đơn giản, làm rất ít, chỉ mất nhiều hơn một cái nhìn thoáng qua ..." Có ví dụ mã nguồn mở nào tốt về điều này không?
DarenW

2
@darrenw chắc chắn, smalltalk 80
Tim Williscroft

10

Cảnh báo : câu trả lời này rất dài và có nhiều tâm lý (mà tôi cố gắng giải thích, nhưng vẫn còn). Tôi có thể nói gì? Tâm lý học là một trong những môn học yêu thích của tôi ngoài lập trình.

Tôi là một nghệ sĩ, chủ yếu, mặc dù tôi mô tả bản thân là một nghệ sĩ / nhà vật lý. Trong khi tôi có thể làm toán, xử lý từ ngữ và những thứ "logic" được coi là não trái, đó là một nỗ lực và tôi mắc lỗi, trong khi tôi làm tốt và hầu hết thời gian nghĩ về những điều liên quan đến não phải suy nghĩ - quan hệ không gian, bối cảnh toàn cảnh lớn, v.v ... Tất nhiên tất cả chỉ là mờ nhạt, vì lý thuyết não phải trái là quá đơn giản và không có hoạt động tinh thần nào đơn giản như vậy. Tuy nhiên, tôi cảm thấy rằng tôi phù hợp với các nghệ sĩ, đạo diễn video, đầu bếp và tư duy phi ngôn ngữ, các kiểu sáng tạo khác, trong khi hầu hết mọi người trong "IT" hoặc các kỹ sư phần mềm khó tính đều có suy nghĩ khác biệt, chú ý đến chi tiết, nắm giữ nhiều chi tiết trong tâm trí cùng một lúc, và khả năng hợp lý và bằng lời nói mạnh mẽ.

Điều này thực sự dựa trên một quan điểm có phần lỗi thời về khoa học thần kinh. Tại một thời điểm, các nhà khoa học tin rằng não trái chỉ chịu trách nhiệm về logic và dữ liệu cảm giác thô trong khi não phải chỉ chịu trách nhiệm về trực giác và cảm giác. Hóa ra, não trái thực sự có khả năng làm mọi thứ mà não phải và ngược lại. Là một người cực kỳ não phải nhưng logic, khủng khiếp với định hướng và định hướng không gian và hoàn toàn không có bất kỳ sáng tạo nghệ thuật nào có truyền thống liên quan đến não phải, tôi có thể chứng thực điều này.

Cách tốt nhất để nghĩ về sự khác biệt giữa não trái và não phải là nghĩ về chúng như hình ảnh phản chiếu của nhau. Để hiểu điều này, bạn cần một số dữ liệu nền. Một nhà tâm lý học tên là Carl Jung đã đưa ra một lý thuyết về tính cách trong những năm 20 phân chia tính cách theo một vài chiều. Bạn có thể đã nghe nói về một trong số họ: hướng nội và thái quá. Tôi đã viết một vài bài viết trên blog về chủ đề này, nhưng về cơ bản, nó tập trung vào vấn đề này: sự hướng nội khác biệt với những người khác trong khi sự vượt trội tập trung vào cách nó có thể kết nối với người khác. Điều này được gọi là một "thái độ".

Sau đó, bạn có bốn chức năng nhận thức khác nhau: suy nghĩ, cảm giác, cảm giác và trực giác. Để đơn giản, chúng ta chỉ cần nói rằng hai trong số các chức năng này được coi là chức năng "phán xét" (suy nghĩ và cảm giác) trong khi hai chức năng còn lại là chức năng "nhận thức". Các chức năng đánh giá đưa ra quyết định. Khi bạn đang trong một tư duy phán xét, bạn đang cố gắng tránh những điều bất ngờ. Bạn muốn đưa ra tất cả các quyết định đúng đắn trước đó để bạn không phải thích nghi khi có bất ngờ xảy ra. Bởi vì bạn đã thực hiện rất nhiều kế hoạch trước, bạn có thể có xu hướng trở nên cứng nhắc và không linh hoạt một khi quyết định được đưa ra. Mặt khác, một tư duy nhận thức có xu hướng thích bay bằng chỗ ngồi của quần và lăn với những cú đấm.

Nói chung, bạn kết hợp chức năng và thái độ để tạo ra một thái độ (được đặt tên sáng tạo) - thái độ (suy nghĩ hướng nội, cảm giác hướng ngoại, v.v.). Tính cách có ý thức của mọi người được xác định chủ yếu bởi thái độ chức năng chi phối và thái độ chức năng phụ trợ. Cuối cùng, các nhà tâm lý học đã đi đến thống nhất rằng có hai loại người: những người có hai chức năng chính bao gồm chức năng phán đoán hướng nội và chức năng nhận thức hướng ngoại, hoặc những người có hai chức năng chính bao gồm chức năng phán đoán hướng ngoại và chức năng nhận thức hướng nội . Nếu bạn đã từng làm bài kiểm tra tính cách MBTI hoặc tương tự, lá thư cuối cùng sẽ cho bạn biết bạn thuộc loại nào. Nếu bạn là P, điều đó có nghĩa bạn là một người đánh giá / người nhận thức hướng nội và J là cách khác.

Vẫn còn với tôi cho đến nay? Đây là nơi tôi hiểu ý của hai bên là hình ảnh phản chiếu của nhau. Không ai nhận ra điều đó vào thời điểm đó, nhưng về cơ bản họ đang xây dựng một bản phác thảo về chức năng nằm trong não. Thật vậy, mỗi thái độ chức năng của Jung đã được ánh xạ tới một vị trí gồ ghề trong não. Hóa ra, tất cả các chức năng P (phán đoán hướng nội và nhận thức hướng ngoại) nằm ở bên phải của não và các chức năng J nằm ở bên trái của não.

Bất cứ khi nào bạn nói rằng những người có não trái lại giỏi về chi tiết và những người có não phải thì rất giỏi về "bức tranh lớn" (mặc dù tôi sẽ nói "toàn bộ bức tranh" sẽ chính xác hơn), bạn đang tập trung vào mặt trái của mọi thứ . Nếu một người có não trái quản lý một người có não phải, người bất chính sẽ muốn biết tất cả các chi tiết về việc người bên phải sẽ làm công việc của họ trước và trước. Họ muốn các yêu cầu đặt ra trong đá và thời hạn cứng quyết định trước. The righty chỉ muốn một ý tưởng rất rộng về những gì họ cần làm để họ có thể điền vào các chi tiết sau.

Tuy nhiên, lưu ý rằng điều này dường như không phải là những gì bạn đang trải qua. Có vẻ như mã của những người cánh tả có lẽ không được suy nghĩ kỹ càng trước và có một số vấn đề có thể được ngăn chặn bởi một số người đã nghĩ trước. Điều này là do khi bạn xây dựng các mô hình trừu tượng của những thứ như mã trong đầu, bạn đang sử dụng chức năng hướng nội của mình , hoạt động theo cách khác. The righty muốn xây dựng mô hình đó trước và làm như vậy theo cách nó lấp đầy tất cả các chi tiết cần thiết hoặc dễ dàng có thể điền vào tất cả các chi tiết. Thêm vào đó, họ có thể trở nên cứng nhắc về cách tiếp cận tốt nhất để thực hiện (lưu ý rằng bạn đang thực hiện một cách cứng rắn về cách bạn cảm nhận về các tính năng nâng cao hơn của C ++). Mô hình của những người cánh tả sẽ đặc biệt hơn và được điền vào khi họ đi.

Kinh nghiệm của tôi là vì điều này, những người cánh tả sẽ buộc tội những người có quyền kỹ thuật quá mức trong khi những người bên phải sẽ buộc tội những người bên trái quá nhanh và bẩn. Cả hai bên đều có một hạt sự thật với họ, nhưng chỉ khi cách tiếp cận đó được đưa đến mức cực đoan. Mặc dù đây là điều buồn cười: họ đang thực hiện các cách tiếp cận ngược lại để đạt được cùng một mục tiêu (nghĩa là hoàn thành công việc). Các nhà cầm quyền muốn đưa mô hình của họ ra quyết định trước để họ có thể dành ít thời gian hơn để thực hiện điều đó và do đó hoàn thành toàn bộ dự án sớm hơn. Những người cánh tả muốn dành ít thời gian hơn cho kiến ​​trúc để họ có thể hoàn thành công việc sớm hơn.

Ngẫu nhiên, hai thái độ này bị đảo ngược khi nói đến công cụ loại quản lý dự án (xác định thời gian, đưa ra các yêu cầu, v.v.). Điều này có thể dẫn đến một tình huống thực sự khó hiểu khi một bên cáo buộc bên kia quá cứng nhắc trong khi bên còn lại cho rằng bên kia không lên kế hoạch trước đủ, và sau đó cuộc tranh luận tiếp theo có cả hai bên có lập trường hoàn toàn trái ngược.

Bạn có thể làm gì về tất cả những điều này? Không có gì khác ngoài việc nhận thức được những khác biệt này và cố gắng làm nổi bật quan điểm của người khác càng nhiều càng tốt. Vấn đề là điều này đi cả hai chiều. Bạn có thể hiểu và chứa đựng những người bên trái càng nhiều càng tốt, nhưng điều đó sẽ không tạo ra nhiều khác biệt trừ khi họ cố gắng trả lại sự ủng hộ. Đây luôn là thử thách. Không phải vì những người bên trái là những kẻ khốn nạn và muốn làm cho cuộc sống của những người bên phải trở nên khốn khổ, mà bởi vì những người bên trái đã từng chiếm ưu thế trong lĩnh vực lập trình. Nếu cách suy nghĩ của bạn bị lặp lại bởi khá nhiều người khác, bạn sẽ khá tin rằng bạn cũng đúng.


Sâu sắc, và đủ dài để đọc để ngừng làm việc thực sự trong một thời gian!
DarenW

6
Những thứ rất thú vị. Có nguồn nào không?
Mason Wheeler

4

Hãy tin vào trực giác của bạn. Nếu bạn là một chuyên gia giỏi, điều đó có nghĩa là bất kể "trí tuệ" của bạn - trái hay phải - những điều mà những người não trái làm một cách có ý thức bạn có thể làm theo trực giác. Cuối cùng, đó là điều tương tự. Thật không may, chúng ta không kiểm soát tiềm thức của mình, nhưng nó thực hiện công việc nhanh hơn ý thức của chúng ta, nếu nó hoàn toàn làm điều đó. Những hiểu biết trực quan đến từ hư không chính xác là kết quả của tính toán tiềm thức.

Ồ, và bạn có thể thất bại, nó quá không đáng tin cậy. Nhưng vì bạn đã hỏi ...;)


2

Tôi nghĩ trực quan cũng và các chi tiết của typography bedevil tôi.

Thuật ngữ Google: Trang web chứng khó đọc của Anh cũng Phong cách học: tư duy không gian trực quan, học tập toàn bộ.

Khái niệm đầu tiên, lời khuyên sau

  1. Những người có não phải tưởng tượng mọi thứ trong 'mắt của tâm trí' của họ.
  2. Khi hình dung của bạn tương ứng tốt với thực tế, công việc trở nên dễ dàng
  3. Những người có tư duy não phải không làm tốt Những người có tư duy não phải phải dựa vào trực quan
  4. Những người học có bản lĩnh phải học toàn bộ mọi thứ cùng một lúc 'aha!' sau đó phù hợp với các chi tiết vào cấu trúc tinh thần. Họ cần cái nhìn tổng quan ĐẦU TIÊN, sau đó là chi tiết.
  5. Không có cái nhìn tổng quan về bối cảnh, các chi tiết trôi nổi trong chân không, không được kết nối trong mắt của tâm trí - vì vậy phải ghi nhớ lực lượng vũ phu. Rất khó khăn cho người bên phải.

MIPSO đã giúp tôi:

  • 1 Sử dụng Màu để phân biệt các phần cú pháp
    1. viết mã giả của mã bạn đang gỡ lỗi: cái này thực hiện điều này, sau đó vào đây và gắn nhãn các phần mã để khớp
    2. nếu các đối tượng là, động vật thật, chúng sẽ có thói quen và hành vi mong đợi. Đây là cách suy nghĩ dễ hình dung hơn về mã hóa.
    3. Tôi tưởng tượng mã như một câu chuyện với mã giả như các ghi chú của tôi và sau đó làm theo quy trình xung quanh.

  • Phần nào để sửa tiếp theo?

  • Quy trình làm việc của tôi

  • Ai sống ở đó? (quá trình, kết nối, dữ liệu, v.v.)

  • họ cần làm gì (chức năng) OK

    đồng ý

  • mã nó ở đâu đó có thể được kiểm tra cú pháp / chính tả OK sao chép và dán

  • Kiểm tra

    Kết quả -> nó hoạt động? Vâng, tiếp tục đi

    Không? Các nhân vật phải diễn Hamlet nơi mọi người chết.

  • Quay trở lại môi trường-

  • để lại một cái gì đó?, lỗi sysntax
  • cần một kết nối
  • cần dữ liệu
  • Mã lỗi có ý nghĩa gì?
  • nó hoạt động trong một phần khác của mã?
  • Phiên bản rắc rối?
  • nó phải làm việc
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.