Khắc phục giải quyết vấn đề chậm do tăng kiến ​​thức về những gì có thể sai [đóng]


450

Điều này đã gây rắc rối cho tôi trong một thời gian và tôi thực sự đánh giá cao đầu vào của các chuyên gia khác.

Bối cảnh ngắn: Tôi bắt đầu lập trình khi bố mẹ mua cho tôi chiếc máy tính đầu tiên vào năm 1988 (lúc 14 tuổi, tôi 39 tuổi). Tôi đã đi theo một vài con đường sự nghiệp khác trước khi cuối cùng trở thành một lập trình viên chuyên nghiệp vào năm 1997. Có lẽ cuối cùng, nhưng đó là như vậy. Tôi vẫn hài lòng với lựa chọn của mình, tôi thích lập trình và tôi thấy mình giỏi trong những gì tôi làm.

Gần đây, tôi nhận thấy rằng tôi càng có nhiều kinh nghiệm, tôi càng mất nhiều thời gian để hoàn thành các dự án hoặc một số nhiệm vụ nhất định trong một dự án. Tôi sẽ không già đi. Chỉ là tôi đã thấy rất nhiều cách khác nhau để mọi thứ có thể đi sai. Và những cạm bẫy và vấn đề tiềm năng mà tôi biết và nhớ ngày càng nhiều hơn.

Ví dụ tầm thường: trước đây chỉ là "được thôi, viết một tập tin ở đây". Bây giờ tôi đang lo lắng về quyền, khóa, đồng thời, hoạt động nguyên tử, gián tiếp / khung, hệ thống tệp khác nhau, số tệp trong thư mục, tên tệp tạm thời có thể dự đoán được, chất lượng ngẫu nhiên trong PRNG của tôi, thiếu điện ở giữa hoạt động, một API dễ hiểu cho những gì tôi đang làm, tài liệu phù hợp, v.v.

Nói tóm lại, các vấn đề từ lâu đã chuyển từ "làm thế nào để tôi làm điều này" sang "cách tốt nhất / an toàn nhất để làm điều đó".

Kết quả cuối cùng là tôi mất nhiều thời gian để hoàn thành một dự án hơn là một người mới. Phiên bản của tôi có thể là đá rắn, và không thể xuyên thủng như tôi biết cách tạo ra nó, nhưng phải mất nhiều thời gian hơn.

Ví dụ "tạo tập tin" ở trên chỉ là một ví dụ. Nhiệm vụ thực tế rõ ràng phức tạp hơn, nhưng ít phù hợp hơn cho một câu hỏi chung chung như thế này. Tôi hy vọng bạn hiểu tôi đang đi đâu với điều này. Tôi không có vấn đề gì với các thuật toán hiệu quả, tôi yêu môn toán, tôi thích các môn phức tạp, tôi không gặp khó khăn gì với sự tập trung. Tôi nghĩ rằng tôi có một vấn đề với kinh nghiệm, và do đó sợ một lỗi (nội tại hoặc bên ngoài).

Tôi dành gần hai giờ mỗi ngày để đọc các phát triển mới, kỹ thuật mới, ngôn ngữ, nền tảng, lỗ hổng bảo mật, v.v. Câu hỏi hóc búa là tôi càng có nhiều kiến ​​thức, tôi càng chậm hoàn thành các dự án.

Làm thế nào để bạn đối phó với điều này?


126
Bài học quan trọng là: bám sát yêu cầu, không hơn . Bằng cách đó, bạn sẽ không cố gắng thực hiện các tính năng không cần thiết.
mouviciel

19
Bạn xem xét Phương pháp phát triển Agile thay vì mô hình thác nước. Cung cấp những thứ lớn đầu tiên và lặp đi lặp lại cung cấp phần còn lại. Đây là khái niệm mới nhưng giúp giảm rủi ro và chi phí.
Satish

23
Tóm tắt các quan điểm và thêm điểm của tôi (trong trường hợp bạn bỏ lỡ): Bạn nên xem xét các dự án mang tính nhiệm vụ quan trọng hơn (kinh doanh khôn ngoan, không an toàn) hoặc có yêu cầu cao hơn về chất lượng (khiếm khuyết thấp) về tính phong phú của các tính năng. Nói cách khác, tìm kiếm các dự án mà kỹ năng tốt nhất của bạn được đánh giá cao nhất.
rwong

13
Khi bạn đọc bất kỳ cuốn sách nào về chất lượng mã, một chủ đề vang dội là trong khi có thể tốn nhiều tiền hơn để tạo mã tốt ở nơi đầu tiên, nó sẽ tốn ít chi phí hơn trong thời gian dài khi bạn có yếu tố bảo trì.
James Snell

6
"Làm điều đơn giản nhất có thể có thể làm việc." Một khi bạn đã làm điều đó, sau đó bạn quyết định nếu bạn cần phải lo lắng về bất cứ điều gì khác.
Wayne Werner

Câu trả lời:


268

Bạn không chậm hơn trong việc hoàn thành các dự án. Trước đây, bạn nghĩ rằng các dự án mới làm quen của bạn đã được thực hiện khi chúng thực sự không. Bạn nên bán chất lượng này cho khách hàng.

"Công ty này có thể hoàn thành công việc nhanh hơn và rẻ hơn, nhưng nó đã thực sự hoàn thành chưa? Hay bạn sẽ săn lùng bọ trong nhiều năm?"

Ngoài ra, bạn cần biết và chấp nhận thành ngữ cũ: "Hoàn hảo là kẻ thù của điều tốt".


112
nhắc nhở tôi về 'tốt, nhanh, rẻ, chọn hai' - khi bạn biết ít hơn bạn đang hy sinh vì 'tốt', và bây giờ bạn biết nhiều hơn, bạn đang hy sinh 'nhanh'.
Sevenseacat

10
@ Không có gì có thể là lỗi miễn phí. Sẽ luôn có một vấn đề, chúng chỉ trở nên nhỏ hơn hoặc phức tạp hơn. Lý tưởng nhất là OP nên tìm một dấu ấn nơi anh ta đang hoàn thành đủ nhanh và để lại một vài lỗi đủ để hài lòng với chất lượng của mình và giữ cho khách hàng hài lòng với chi phí và thời gian
RhysW

10
@Neil "Đúng giờ. Về ngân sách. Trên sao Hỏa. Chọn hai."
Dan Neely

5
@Leonardo: không, hình thức của Telastyn là chính xác (và đó là một câu nói khá cũ . Xem thêm YAGNI và "nếu nó hoạt động, đừng sửa nó".
mikołak

3
Câu trả lời này thật nhảm nhí. Tiếp tục, hãy thử và nói với một khách hàng tiềm năng rằng bạn sẽ làm điều đó với giá 40K thay vì 20K nhưng với chất lượng và độ tin cậy cao hơn gấp 10 lần. Họ sẽ nói với bạn điều này: "Ngân sách của tôi là 20 nghìn và tôi không cần chất lượng đó". Tại một số điểm, bạn phải chấp nhận rằng 99% khách hàng không thực sự quan tâm đến chất lượng và bất kỳ chất lượng nào cũng sẽ có khoản đầu tư cá nhân của bạn.
Mẹ ơi.

179

Có vẻ như đã đến lúc bạn tham gia vào mặt tối: quản lý.

Tôi không đề nghị bạn từ bỏ lập trình và trở thành người quản lý. Nhưng có vẻ như tất cả những trải nghiệm bạn đã trích dẫn cho đến bây giờ đều mang tính kỹ thuật. Trong thao tác đơn giản bằng cách viết ra một tệp, bạn có thể nghĩ đến 10 khía cạnh khác nhau mà một nhà phát triển kém trưởng thành sẽ không bao giờ xem xét. Không hẳn là một điều xấu, nhưng ...

Mặt tối là tất cả về giá trị hiện tại. Đó là về việc đầu tư tối thiểu để đạt được lợi nhuận tối đa (phân tích lợi ích chi phí). Trong kinh doanh, mọi thứ đều có thể khiến tôi phải trả giá bao nhiêu, xác suất thành công, xác suất thất bại, xác suất thất bại ngoạn mục và lợi ích tiềm năng. Làm toán; hành động phù hợp.

Điều này cũng hoạt động tốt khi bạn là nhà phát triển: tạo một tệp tạm thời, bỏ qua các quyền và xung đột tên - 5 phút. Thu nhập ròng, phần còn lại của nhóm có thể bắt đầu làm việc với bất kỳ mã nào phụ thuộc vào sự hiện diện của tệp đó. Nó có phải là một giải pháp hoàn hảo? Tuyệt đối không. Nó sẽ giúp bạn 99%, 95%, có thể 90%? Vâng, nó có thể sẽ.

Một câu hỏi khác để hỏi: Bạn cảm thấy thế nào về nợ kỹ thuật? Một số người nghĩ rằng nó phải được loại bỏ. Tôi nghĩ những người đó là sai. Cũng giống như trong kinh doanh, nợ kỹ thuật cho phép bạn vay "tiền mặt" hoặc "thời gian" để cung cấp một cái gì đó sớm hơn. Điều gì tốt hơn: Một giải pháp hoàn hảo trong 2 năm hoặc một bản hack hoàn chỉnh mà khách hàng có thể sử dụng và mua trong 4 tháng? Mọi tình huống đều khác nhau, nhưng trong một số tình huống nếu bạn đợi 2 năm, khách hàng của bạn sẽ đăng ký với đối thủ của bạn.

Chìa khóa là quản lý nợ kỹ thuật giống như cách một doanh nghiệp hoạt động tốt quản lý nợ tài chính. Nếu bạn không nhận đủ, bạn sẽ không nhận được lợi tức đầu tư tối ưu. Nếu bạn nhận quá nhiều, sự quan tâm sẽ giết chết bạn.

Vì vậy, lời khuyên của tôi: Bắt đầu đánh giá công việc của bạn dựa trên việc bạn có tối đa hóa giá trị của mình thay vì tối đa hóa tính kỹ lưỡng của bạn hay không. Và nếu bạn thực hành điều này, bạn sẽ phát triển cùng một trực giác mà bạn đã phát triển trong lĩnh vực kỹ thuật của mình.

Một ghi chú bên lề, gần đây tôi đã bắt đầu thực hiện kỹ thuật pomodoro và nó đã giúp ích rất nhiều. Thay vì tiếp tục tiếp tuyến, hãy tập trung vào những khoảng thời gian nhỏ và sau đó phân bổ pomodoros cho công việc / nghiên cứu trong tương lai. Thật đáng ngạc nhiên bao nhiêu lần tôi đã ghi chú để nghiên cứu một chủ đề nhưng một giờ sau khi thời gian đến, tôi tự nghĩ, "có ít nhất 3 điều khác tôi có thể làm với thời gian của mình ngày hôm nay có giá trị hơn."


9
Vì vậy, theo bạn, cố tình tạo ra lỗi là chấp nhận được miễn là chúng xảy ra đủ hiếm?
SCAI

87
@scai - bạn chọn trận đánh của bạn. Tôi đã ở trong ngành được 15 năm và tôi chưa thấy một bản phát hành nào trong 3 công ty mà tôi làm việc cho đến nay, với 0 lỗi. Nó không xảy ra trong thế giới thực. Tôi không nói rằng bạn cố tình giới thiệu mã bị hỏng nhưng có một mức độ hoàn hảo và chống đạn mà đơn giản là nó không được đền đáp
DXM

25
Tạo một lỗi "cố ý" có nghĩa là bản thân lỗi đó là cố ý - điều này không giống với nhận thức về khả năng hoặc thậm chí là sự tồn tại cụ thể của lỗi hoặc không tương thích. Tôi có một ứng dụng HTML5 không hoạt động ngay trong IE6, tôi biết về nó, tôi thậm chí đã nghi ngờ rằng đó sẽ là trường hợp khi tôi tạo ra nó - đó chỉ là "những vấn đề không quan tâm và những người quan tâm đừng quan trọng ". Bạn có thể cố tình xây dựng một cây cầu không chịu được một cuộc tấn công hạt nhân, và điều đó không sao cả.
BrianH

27
+100 cho khoản nợ kỹ thuật của bạn. Giống như OP, tôi đã cố gắng loại bỏ tất cả các khoản nợ kỹ thuật. Tôi chưa bao giờ nghĩ rằng nợ kỹ thuật là ổn, cho đến khi tiền lãi bắt đầu giết chết bạn. Bây giờ tôi thấy rằng quản lý nợ quan trọng hơn nhiều so với việc loại bỏ nó. Tôi chưa bao giờ nghĩ về nó trong những điều khoản trước đây. (btw Tôi cũng sử dụng kỹ thuật pomodoro.)
adj7388

6
Câu trả lời này phản ánh chặt chẽ kinh nghiệm của bản thân tôi và nhận Nợ kỹ thuật. Hơn cả việc cố tình tạo ra nó, chỉ đơn giản bằng cách giao phó công việc cho nhân viên cấp dưới, bạn kết thúc với nợ kỹ thuật một cách tự nhiên, phải được khắc phục sau đó, giáo dục họ trong quá trình này. Về cơ bản một khi bạn đạt đến giai đoạn này, bạn PHẢI đầu tư vào việc tìm hiểu về sự đánh đổi và suy nghĩ về các khoản nợ vay mà sau này phải trả. Điều này bởi vì bạn PHẢI giao phó công việc cho nhân viên cấp dưới chỉ vì chỉ có một bạn và ngay cả khi những gì bạn nhận được có chất lượng thấp hơn, bạn có thể cung cấp những gì không thể cho riêng bạn.
SplinterReality

94

Tôi đã có (có khả năng) vấn đề tương tự nhiều năm trước, nó đã kéo dài một vài năm và tôi đã vượt qua nó. Vì vậy, có thể bạn sẽ cảm thấy thú vị khi biết tôi đã đạt được điều đó như thế nào, ngay cả khi tôi không chắc chắn cách của tôi cũng sẽ áp dụng cho bạn.

Bạn cũng nên có một cái nhìn ở đây: Bảy giai đoạn chuyên môn về Kỹ thuật phần mềm Điều đó cho thấy năng suất phần lớn là một tác dụng phụ của mức độ kỹ năng. Có thể bạn vẫn đang ở một thời điểm nào đó giữa giai đoạn 3 và giai đoạn 4 về công nghệ bạn đang sử dụng (trình độ kỹ năng phụ thuộc vào công nghệ, bạn có thể thành thạo một số công nghệ trong khi vẫn học những công nghệ khác).

Bây giờ tôi bắt đầu với lời khai tiểu sử.

Một chút bối cảnh. Tôi 47. Tôi bắt đầu lập trình lúc 12 tuổi vào những năm 80. Khi còn học trung học, tôi cũng làm việc như một lập trình viên trò chơi chuyên nghiệp bán thời gian. Về cơ bản, nó không mang lại cho tôi nhiều tiền như vậy, chỉ đủ để mua phần cứng, nhưng tôi thích nó và học được nhiều thứ. Năm 18 tuổi, tôi bắt đầu học chính thức về Khoa học Máy tính.

Kết quả là khi tôi 20 tuổi, bất cứ khi nào bắt đầu bất kỳ nhiệm vụ lập trình nào, tôi đều biết nhiều cách để giải quyết các vấn đề đã cho và rất ý thức về nhiều tham số và cạm bẫy trong tay, và những hạn chế và giới hạn của bất kỳ phương pháp nào.

Tại một số điểm (khoảng 26 tuổi), việc viết bất kỳ chương trình nào trở nên thực sự khó khăn đối với tôi. Có rất nhiều khả năng đã mở ra mà tôi không thể lựa chọn giữa chúng nữa. Trong một vài năm (làm cho nó 6) tôi thậm chí đã ngừng lập trình và trở thành một người viết tin tức kỹ thuật.

Tôi chưa bao giờ hoàn toàn ngừng cố gắng để lập trình tuy nhiên. Và đến một lúc nào đó nó trở lại. Chìa khóa đối với tôi là lập trình cực đoan, cụ thể hơn là nguyên tắc Đơn giản: "Viết điều đơn giản nhất có thể làm việc".

Về cơ bản, tôi buộc bản thân không quan tâm đến hiệu quả mã (đó là rào cản chính của tôi, tránh các thiết kế không hiệu quả), nhưng chỉ đi theo cách dễ nhất. Tôi cũng buộc tôi phải quan tâm ít hơn về các lỗi và trì hoãn việc xử lý lỗi để sau đó, sau khi viết các bài kiểm tra làm tăng lỗi (thực sự đó là TDD).

Đó là điều tôi học được khi viết. Khi tôi không biết viết gì, hoặc tôi biết những gì tôi đang viết là xấu . Cứ đi tiếp. Thực tế viết những thứ xấu. Cuối cùng tôi sẽ sửa nó sau. Hoặc nếu nó thực sự tệ đến mức xóa nó và viết lại, nhưng nó nhanh hơn để viết những thứ hai lần viết bất cứ điều gì hoàn hảo ngay lần đầu tiên.

Thực sự rất có khả năng một mã mà bạn tin là tốt ngay từ lần viết đầu tiên sẽ cần cải thiện nhiều như một mã thực sự xấu.

Nếu bạn đi theo con đường Đơn giản, bạn cũng nhận được một phần thưởng bổ sung. Bạn dễ dàng chấp nhận để loại bỏ / thay đổi thiết kế / mã hóa ban đầu. Bạn có được một tâm trí linh hoạt hơn.

Tôi cũng có thói quen đưa một nhận xét tạm thời vào mã, giải thích những gì tôi không làm bây giờ và dự định sẽ làm sau khi mã sẽ hoạt động trong trường hợp sử dụng bình thường.

Tôi cũng đã tham dự một Dojo XP, một katas mã thực hành với các lập trình viên khác để tiếp thu các thực hành XP. Nó đã giúp đỡ. Nó làm cho các phương pháp chính thức ở trên theo bản năng. Lập trình cặp cũng giúp. Làm việc với các lập trình viên trẻ mang lại một số động lực, nhưng với kinh nghiệm bạn cũng thấy những gì họ không làm. Ví dụ trong trường hợp của tôi, tôi thường thấy họ tham gia vào các thiết kế quá phức tạp và tôi biết cơn ác mộng thiết kế có thể dẫn đến. Đi theo cách đó. Đã làm điều đó. Có vấn đề.

Điểm tối quan trọng đối với tôi là giữ dòng chảy. Nhanh chóng là thực sự thành công trong việc giữ dòng chảy.

Bây giờ tôi trở lại là một lập trình viên chuyên nghiệp và tôi tin rằng tôi đều tốt hơn và nhanh hơn với sự hiểu biết sâu sắc hơn về những gì tôi đang làm. Thực hành TDD Tôi vẫn có thể chậm hơn một chút so với khi tôi còn là một con bò đực nhỏ (và chưa thử nghiệm gì), nhưng tôi cũng không sợ tái cấu trúc và chắc chắn dành ít thời gian để gỡ lỗi hơn (gần như không có thời gian, làm cho nó ít hơn 10% thời gian ).

Cuối cùng: Tôi đã vượt qua codeblock của mình bằng các phương thức nhanh (XP), đơn giản hóa sau đó tái cấu trúc và thực hành để biến điều đó thành bản năng. Nó làm việc cho tôi. Không chắc chắn nó có thể được khái quát cho bất cứ ai khác.

Về mức độ tiếp thu kỹ năng, tôi chủ yếu học cách chấp nhận rằng mỗi khi tôi thay đổi công nghệ (học ngôn ngữ mới, khuôn khổ mới, v.v.) tôi sẽ trải qua một giai đoạn khi tôi chậm lại. Điều này là bình thường và cuối cùng sẽ khắc phục điều đó. Tôi cũng có thể bù đắp cho điều đó bằng phương pháp tốt và kỹ năng lập trình mục đích chung và nó sẽ không còn là vấn đề nữa.


22
+1 cho "lần đầu tiên viết nhanh hơn hai lần viết bất cứ điều gì hoàn hảo"
Brendan Long

2
+1 để chia sẻ một câu chuyện cá nhân mà tôi mong đợi sẽ dễ nhận biết và hữu ích cho người hỏi.
R. Schreurs

Tôi đồng ý, bạn có thể gặp phải khối lập trình viên (như khối nhà văn). Bạn không thể quản lý sự phức tạp, vì vậy bạn nên dùng. Việc chữa bệnh cũng giống như đối với khối nhà văn; viết một cái gì đó . Ngay khi bạn có một cái gì đó trên màn hình, nó sẽ cho bạn ý tưởng làm thế nào để tiến hành. Có lẽ bạn đã được đưa ra lời khuyên này ở dạng ít sáng suốt hơn, vì, "Đừng lo lắng về hiệu quả / lỗi / bất cứ điều gì, chỉ cần hoàn thành công việc nhanh chóng." Vâng, đó là một nửa câu trả lời. Một nửa còn lại là một khi bạn vượt qua màn hình trống, thực hiện xử lý lỗi thực tế , thuật toán hiệu quả hoặc bất cứ điều gì đơn giản.
SeattleCplusplus

@SeatussyCPlusPlus: Tôi đồng ý rằng nó đơn giản cho các vấn đề đơn giản, có thể là đối với hầu hết các mã thuật toán. Không đơn giản như vậy khi bạn muốn có được một số cấu trúc lớp tốt. Quy tắc tái cấu trúc không hoàn toàn vô dụng.
kriss

41

Một phần quan trọng của lập trình là quản lý và kiểm soát sự phức tạp và đối với cá nhân tôi, đó là một trong những vấn đề hàng đầu. Nếu bị bỏ qua thì tần suất thiếu hụt sẽ tăng hoặc như trong trường hợp của bạn, ETA của phần mềm đã hoàn thành tăng đáng kể.

Tăng sự thiếu hụt hoặc giảm ETA

Độ phức tạp của phần mềm có thể được kiểm soát và quản lý từ nhiều cấp độ và cách khác nhau nhưng một nguyên tắc tốt để có được một số quan điểm là: "Ưu tiên hàng đầu của bất kỳ dự án phần mềm nào là sự hài lòng của khách hàng là chức năng của sự mong đợi của họ."

Nói cách khác, độ phức tạp của phần mềm phụ thuộc rất nhiều vào mức độ bạn có kỹ năng kiểm soát sự mong đợi của khách hàng.

Khi một người chấp nhận quan điểm đó, thì hai điểm quan trọng trở nên rõ ràng:

  1. kỳ vọng của khách hàng phải được thực hiện rõ ràng (dưới bất kỳ hình thức nào);
  2. kỳ vọng của khách hàng luôn có thể được sửa đổi và điều đó được thực hiện thông qua nghệ thuật đàm phán.

Ví dụ của bạn là một ví dụ rất hay, "chỉ cần viết nó" so với "vô số những cân nhắc khác". Hãy suy nghĩ về nó - nếu ai đó viết ra các yêu cầu toàn diện cho cả hai biến thể, liệu có thể có sự tương đương trong các tính năng được mô tả hay không?

Xây dựng một chiếc F16 khác với việc chế tạo một chiếc Cessna mặc dù cả hai đều có thể bay.


24

Câu trả lời đơn giản là: chấp nhận nó.

Trong tất cả các hệ thống, có sự đánh đổi giữa độ tin cậy, độ bền, bảo mật, tốc độ, chi phí phần cứng, chi phí phát triển, thời gian đưa ra thị trường, bạn đặt tên cho nó. Bạn sẽ không luôn đồng ý với cách khách hàng đưa ra những đánh đổi đó, nhưng bạn không phải là người đưa ra những quyết định đó. Tất cả những gì bạn có thể làm là cung cấp một ý kiến ​​xem xét. Phát triển phần mềm bao gồm toàn bộ gam, từ "trang web cá nhân của tôi" đến "chạy lò phản ứng hạt nhân" và mã phải được viết tương ứng. Nếu sự cố có nghĩa là "tải lại trang web cá nhân của tôi" thì ai thực sự quan tâm nếu điều đó xảy ra? Nhưng nếu một sự cố có nghĩa là "Chernobyl" thì sở thích của bạn đối với mã rắn là nếu bất cứ điều gì hơi bình thường theo ý thích của tôi.

Có một số khách hàng sẽ vui vẻ chấp nhận mã cấp độ "Proof of Concept" và chạy nó trong các hệ thống trực tiếp của họ và thường họ có các quản trị viên hệ thống đã quen với điều đó. IME hệ thống của họ thường không có sẵn trong một giờ hoặc lâu hơn vào giữa đêm trong khi một loạt các khởi động lại theo lịch trình xảy ra. Nhưng họ đã đưa ra quyết định kinh doanh đó là cách họ muốn lăn. Lý tưởng là vì lĩnh vực của họ chuyển động nhanh đến mức mã chất lượng cao sẽ không bao giờ sẵn sàng, nhưng thường vì họ không thể thấy giá trị (nếu một hệ thống "chỉ hoạt động" thì họ không bao giờ nhận thấy nó, do đó hệ thống đó không đại diện cho giá trị tiền bạc). Nếu điều đó làm phiền bạn quá nhiều, hãy cố gắng tránh những khách hàng đó.

Luôn cập nhật là thời gian tất cả chúng ta phải chi tiêu, hoặc ít nhất nên dành. Đôi khi điều đó sẽ giúp bạn làm việc, những lần khác nó chỉ giữ cho tâm trí của bạn ở trạng thái tốt. Dù bằng cách nào, hãy cố gắng tận hưởng nó.


4
Đó là một chút "bình thường theo ý thích của tôi" trong so sánh Chernobyl của bạn đã làm cho ngày của tôi. Tôi thực sự đã cười rất lớn :)
Zilk

16

Có vẻ như các kỹ năng của bạn sẽ rất hữu ích cho việc phát triển hệ thống quan trọng cho nhiệm vụ chất lượng rất cao, như các ứng dụng liên quan đến tài chính / giao dịch, phát thanh truyền hình, hàng không vũ trụ, quốc phòng ...

Lỗi trong các loại ứng dụng này rất tốn kém và họ thuê những người có suy nghĩ giống bạn vì bạn có thể giải quyết tất cả các trường hợp.


15

Sự thật là các hệ thống hiện đại ngày càng trở nên phức tạp. Máy tính bây giờ giống với trò chơi "Jenga" nơi bạn có tất cả các phần này dựa vào nhiều phần khác. Kéo ra một mảnh sai và bạn có một lỗi, rút ​​ra một mảnh chính xác / cần thiết và bạn vẫn có thể tạo ra một lỗi. Hệ thống càng phức tạp, bạn càng có nhiều thời gian để nghĩ ra các cách để làm cho mã của bạn mạnh mẽ hơn và hy vọng cũng an toàn hơn. Tốc độ sẽ rất tốt, nhưng tôi nghĩ rằng tốc độ chiếm chỗ dựa rất nhiều trong những ngày này khi bạn nghe tin công ty "XYZ" bị hack và 6 triệu số thẻ tín dụng của khách hàng đã bị đánh cắp.

Khách hàng của bạn có thể không muốn nghe rằng chương trình của họ cần được bảo mật, mạnh mẽ, v.v. Nhưng bạn có thể nói với họ rằng xe của họ không cần dây an toàn và túi khí cũng như nhà của họ cần khóa và cửa ... vì ai muốn nghe tất cả cái đó?

Nếu bạn đang suy nghĩ quá mức, bạn đang đi về mọi thứ đúng cách, ngoại trừ việc bạn cần chọn một chiến lược có vẻ "cụ thể" và chỉ cần đi theo nó.


9

Có vẻ như bạn nhận thức được xu hướng suy nghĩ của bạn về mọi thứ có thể sai.

Các nhà phát triển thận trọng có kinh nghiệm thường học cách tuân theo câu thần chú YAGNI, bạn sẽ không cần nó, khi họ cố gắng trở lại quy trình làm việc gọn gàng, nhanh nhẹn và hiệu quả sau khi bị nghẹt thở trong đám cỏ của phân tích chế độ thất bại.

Tuy nhiên, nếu bạn thực sự đang viết một cái gì đó trong một lĩnh vực mà mức độ chăm sóc đó không kém gì những gì Chuyên nghiệp yêu cầu, thì bạn nên nhận ra rằng "vận tốc", "năng suất" của bạn, theo thuật ngữ ròng, có thể đo lường được bằng bao nhiêu tốt ( hoặc gây hại) bạn đang làm cho công ty của bạn, khách hàng của bạn và bộ phần mềm hoặc gia đình sản phẩm bạn đang xây dựng hoặc bảo trì.

Nhớ:

  • Bao gồm tổng chi phí bảo trì, tổng chi phí sở hữu và tổng chi phí triển khai và bảo trì các giải pháp khi bạn xem xét các thay đổi trong phương pháp của mình. Đi nhanh hơn và phạm nhiều sai lầm hơn có thể hoặc không thể làm mọi thứ tốt hơn.

  • Nếu bạn làm việc trong một công ty tốt, có lẽ bạn có thể thảo luận điều này trong nhóm của riêng bạn và với người giám sát của riêng bạn, mà không phải là một Động thái giới hạn nghề nghiệp. Nếu bạn không thể, bây giờ là thời điểm tốt để tìm hiểu điều đó và tìm một công việc mới.


YAGNI đã cứu tôi khi tôi đang trải qua giai đoạn này. Câu trả lời này cần nhiều upvote hơn. Vấn đề "Tôi quá chậm" không chỉ được chấp nhận; có những lúc bạn hy sinh một kiến ​​trúc hoàn hảo để nhanh chóng đưa nó ra khỏi cửa.
Roman Starkov

7

Điều duy nhất tôi có thể thấy là: "Bạn đang ngày càng trở nên có giá trị hơn".

Và khi bạn có được nhiều kinh nghiệm hơn, bạn sẽ học về những điều bạn nên tránh, và đây là điều giúp bạn trở nên tốt hơn những người khác.

Một điều bạn sẽ nhận thấy rằng mã của bạn sẽ an toàn hơn và dễ bảo trì hơn bây giờ.

  • Điều duy nhất bạn cần làm là giải thích cho khách hàng của mình tại sao phải mất thời gian và nó sẽ hữu ích như thế nào đối với họ.
  • Bạn cần cho họ thấy chiều sâu của kiến ​​thức của bạn.
  • Bạn cần nói với họ lý do tại sao bạn đã làm, những gì bạn đã làm và làm thế nào nó quan trọng với họ và doanh nghiệp của họ.

Đề nghị của tôi sẽ tập trung vào phần này.


7

khi nghi ngờ mặc định trích dẫn sai Knuth ...

"Tối ưu hóa sớm là gốc rễ của mọi tội lỗi."

Đây là những gì tôi muốn đề xuất, vì dường như thỉnh thoảng bạn có một vấn đề mà tôi gặp phải ...

Điều gì thực sự hiệu quả với tôi ...

  1. Viết các bài kiểm tra đơn vị, như thể tất cả các mã đã được thực hiện.
  2. tài liệu giao diện.
  3. thực hiện giao diện.

những gì bạn đã thực sự làm:

  1. làm việc thông qua các yêu cầu lớp mô hình
  2. thực sự thiết lập sự phân chia công việc, đối tượng nào chịu trách nhiệm cho những gì
  3. làm việc trong một môi trường khi bạn thực sự có thể bước qua mã làm việc, điều này làm cho mọi thứ nhanh hơn rất nhiều, chính xác hơn ...

cũng dựa vào các xác nhận trong phát triển ban đầu ... sau đó tìm ra biện pháp khắc phục nào cần được thực hiện và bạn sẽ không viết mã không thể truy cập được hoặc khó kiểm tra.


Nghe giống như chú Bob, anh chàng RẮN.
Warren P

6

Tôi nghĩ bạn nên tuân thủ các tiêu chuẩn mã hóa của mình, nhưng hãy chắc chắn rằng bạn thẳng thắn với khách hàng của mình. Nhiều khách hàng không biết những gì cần / chi phí để xây dựng phần mềm tốt. Đó là một phần công việc của nhà phát triển chuyên nghiệp để giáo dục họ.

Cho dù bạn nhanh nhẹn hay thác nước, bạn sẽ nhận được một số thỏa thuận từ khách hàng về những gì họ mong đợi ứng dụng sẽ làm. Quá nhiều nhà phát triển (OK có thể nhiều nhân viên bán hàng hơn) phạm tội bao cát . "Họ không nói rằng họ muốn có một trang web bảo mật cao." Trong hầu hết các trường hợp, đó là vì họ không được hỏi. "Bạn có phiền nếu trang web thương mại điện tử của bạn bị hack không?" Tất nhiên họ quan tâm và tại sao bạn sẽ xây dựng nó để cho phép bất cứ ai xâm nhập an ninh? Bạn phải giáo dục họ.

Chỉ cần đảm bảo rằng bạn chỉ làm những gì khách hàng trả tiền cho bạn để làm. Một phần của dịch vụ của bạn là kinh nghiệm của bạn. Khách hàng mong đợi bạn biết những cạm bẫy mà không cần phải hỏi. Tùy thuộc vào họ để bao gồm các yêu cầu. Bạn có thể muốn truyền cho khách hàng muốn một cái gì đó giá rẻ.


Trên thực tế, bạn chỉ lấy ví dụ về điều tồi tệ nhất: phần mềm web, nơi php noobs chính thức cạnh tranh. Giá là một yếu tố cực kỳ quan trọng và khi tôi cung cấp phần mềm chất lượng cao, khách hàng của tôi trả tiền cho phần mềm và tôi trả tiền cho chất lượng cao.
Mẹ ơi.

6

Hãy nghĩ về hậu quả thực tế của một lỗi so với tất cả các vấn đề khác cần giải quyết.

Hãy xem xét các hậu quả sau đây của việc tạo ra một đoạn mã được viết kém:

  1. Toàn bộ cơ sở dữ liệu bị đổ mỗi tháng. 48 giờ ngừng hoạt động trong khi các bản sao lưu được khôi phục.
  2. Hồ sơ khách hàng được liên kết chéo. Đơn hàng trị giá $ 200 được chuyển đến khách hàng sai mỗi tháng.
  3. Một đơn hàng bị kẹt trong tình trạng sai mỗi tuần một lần. Đặt hàng tàu nhưng kho phải gọi trợ giúp mỗi khi nó xảy ra.
  4. Một lần sau hai tuần, ứng dụng gặp sự cố và người dùng phải nhập lại dữ liệu trị giá 2 phút.
  5. Mỗi tháng một lần, ứng dụng bị treo khi khởi động. Người dùng phải giết quá trình và bắt đầu lại.

Điều đầu tiên rõ ràng là không thể chấp nhận được. # 2 - # 5 có thể có hoặc không, tùy thuộc vào bản chất của doanh nghiệp. # 2 - # 5 cần được đánh giá trong bối cảnh các vấn đề khác mà doanh nghiệp đang gặp phải.

Lý tưởng nhất là # 2 - # 5 sẽ không bao giờ xảy ra. Trong cuộc sống thực, với những ưu tiên mâu thuẫn, những người ký vào bảng lương của bạn có thể muốn bạn làm việc với những thứ khác thay vì viết mã hoàn hảo mà không bao giờ có vấn đề. Họ sẽ không bị ấn tượng nếu số 5 được sửa chữa với chi phí không sửa một lỗi nghiêm trọng hơn trong một chương trình khác.


5

Giải pháp là tạo ra một tập hợp các thư viện với các chức năng thường được sử dụng mà bạn có thể sử dụng lại trên các dự án. Ví dụ: tôi có thư viện StringFiances.dll .NET, công cụ như mã hóa, mã hóa, giải mã, đánh giá biểu thức chính quy, v.v ... Bằng cách này, tôi không phải viết lại liên tục những thứ không thay đổi.

Có một trình bao bọc cho các tác vụ tạo tập tin cũng có rất nhiều ý nghĩa. Thư viện của bạn có thể hiển thị một phương thức gọi là GetFile () thực hiện tất cả các kiểm tra cho bạn và trả về null hoặc một tệp (hoặc bất cứ điều gì bạn thấy hữu ích).


4

Tôi nghĩ bạn cần học cách quyết định cần thực hiện bao nhiêu cho dự án nào. Một số dự án có thể là tầm thường và bạn thực sự không cần phải dành tất cả thời gian đó để hoàn thiện nó. Không phải tất cả mọi thứ sẽ cần mã hóa vững chắc cũng như mọi thứ sẽ mở rộng tới hàng triệu người dùng.

Viết một chương trình có thể mở rộng quy mô cho hơn một triệu người dùng sẽ mất thời gian và trải nghiệm mà bạn có bây giờ, nhưng nếu bạn biết rằng ứng dụng của bạn sẽ không được sử dụng tối đa hơn 1000 người dùng, sẽ không có điểm nào để chi tiêu hết thời gian đó hoàn thiện nó

Tôi nghĩ rằng đây là một giai đoạn quan trọng trong sự nghiệp lập trình của bạn và bây giờ bạn cần phải đi đến cấp độ tiếp theo, điều này phải làm với sự trưởng thành và không phải lập trình. Bạn cần có khả năng quyết định chính xác bao nhiêu thời gian và mã nên đủ cho bất kỳ dự án cụ thể nào.

Và giống như mọi thứ khác, bạn có thể đạt được điều này cũng như thực hành. Vì vậy, hãy cố gắng quyết định điều này trước khi bạn bắt đầu một dự án, đôi khi ngay cả khi bạn đang làm việc với nó, với kinh nghiệm bạn cũng sẽ vượt qua điều đó. Có thể có một vài lần truy cập và bỏ lỡ ngay từ đầu nhưng theo thời gian, bạn sẽ hoàn thiện nó (ra quyết định, không phải mã).


3

@Zilk, tôi không phải là lập trình viên tuyệt vời và tôi đã lập trình từ năm 1998. Ngay cả bây giờ tôi cũng đang đối mặt với vấn đề này. Nhưng những gì tôi nhận ra cuối cùng là vấn đề chất lượng. Nếu tôi chết hôm nay, ai đó sẽ có thể lấy những gì tôi đang làm bây giờ từ nơi tôi đã rời đi. Đó phải là tiêu chuẩn của lập trình (Universal).

Tôi đã chuyển mình từ nhà phát triển sang kiến ​​trúc sư bây giờ. Chuyển sang Quản lý đang thay đổi dòng. Nếu bạn muốn tiếp tục với đam mê của mình, bạn có thể chuyển sang làm Kiến trúc sư.

Ban đầu là Kiến trúc sư kỹ thuật -> Kiến trúc sư giải pháp -> Kiến trúc sư doanh nghiệp -> Kiến trúc sư trưởng, v.v.

Là một kiến ​​trúc sư, bạn sẽ hướng dẫn mọi người thành công. Những người như bạn đã lập trình trong nhiều thập kỷ kinh nghiệm mà bạn có thể sử dụng để hướng dẫn người khác.

Giống như một con chim cao hơn nó bay nhiều đất hơn nó có thể thấy đó là kinh nghiệm của bạn.

Tôi cũng cho bạn biết lập trình thực hiện đúng là quan trọng hơn lập trình thực hiện sai nhanh hơn. Gần đây, một trong những đàn em của tôi đã lập trình một cái gì đó sai và nó tiêu tốn của ngân hàng rất nhiều tiền. Tất nhiên chúng tôi đã giao hàng đúng hẹn trước đó nhưng điều đó không có ích! Tôi có được giao vai trò hướng dẫn mặc dù cùng một thiếu niên sẽ mã hóa rằng vấn đề sẽ không xảy ra. Tôi đang đưa ra ví dụ này để nhấn mạnh rằng việc đưa ra hướng dẫn tốt cũng rất quan trọng. Một số người gọi công việc này là Tư vấn.


3

Một lựa chọn khác là: ngừng viết mã, thay vào đó hãy bán chuyên môn của bạn để phát hiện ra các vấn đề trước.

Nói cách khác, trở thành một nhà tư vấn .

Nhiều tổ chức sẵn lòng trả đô la đắt tiền (nếu không phải là đô la hàng đầu) cho ai đó để phát hiện ra các vấn đề trước khi dành nhiều tháng để tạo mã tạo ra các vấn đề. Người ta biết rằng sửa một lỗi trong thiết kế, là các đơn đặt hàng có cường độ rẻ hơn / dễ dàng hơn so với sửa lỗi sau khi nó được mã hóa, kiểm tra và triển khai.

Bạn sẽ không được viết càng nhiều mã, và bạn có thể có thể bỏ lỡ đó, nhưng sau đó có vẻ như các dòng thực tế của mã không phải là sức mạnh cốt lõi của bạn, nhưng khi biết đó dòng mã nên được viết - và không nên.

Tập trung vào điểm mạnh của bạn.
(tốt, nếu đó là những gì bạn thích ...)


2

Đề nghị tốt nhất của tôi cho bạn là: xây dựng khối.

Tạo một khối xây dựng tệp mà bạn luôn có thể tin tưởng, tạo một khối cho API của bạn, ngừng lãng phí thời gian của bạn để viết cùng một thứ nhiều lần. Hãy suy nghĩ về mọi vấn đề một lần và sửa chữa nó một lần và mãi mãi.

Sẽ không có ai bắt kịp điều đó, chắc chắn không phải là người mới dành 80% thời gian để gỡ lỗi mã cho các trường hợp góc mà họ không hiểu.

Trên hết, không khắc phục các sự cố không thể xảy ra, chẳng hạn như quyền sai.

Nếu các quyền là sai, một cái gì đó đã sai và bạn nên sửa nó thay vì làm bằng chứng chương trình của bạn.

Đến một lúc nào đó bạn phải tự bắn vào chân mình thay vì luôn kiểm tra xem mình có làm hay không.

Thay vì dành thời gian cho tài liệu, hãy dành thời gian làm cho mã của bạn tự viết tài liệu và càng ngắn càng tốt. Thay thế tất cả các chức năng trùng lặp. Thu nhỏ thư viện của bạn, đổi tên mọi thứ với độ chính xác.


1

Đừng quá khó khăn với chính mình. Bạn đang làm việc trong một nghề ngày càng phức tạp, đòi hỏi trí tuệ, kiến ​​thức và kinh nghiệm của con người nhiều hơn bao giờ hết.

Sức mạnh xử lý của máy tính đang chậm lại - có lẽ sẽ bị đình trệ - dẫn đến nhu cầu giới thiệu chip đa lõi, số điện áp gpu, song song, v.v ... Chỉ có rất nhiều bóng bán dẫn có thể được đặt trên chip.

Do đó, những tiến bộ lớn hiện nay và trong tương lai sẽ đến từ các lập trình viên - thuật toán tiên tiến và mã hiệu quả hơn.

Nếu bạn nhìn vào GTA 4 và GTA 5, sự khác biệt là đáng kinh ngạc. Nhưng cả hai đều chạy trên cùng một phần cứng. Đây là kết quả của một số thực hành lập trình rất thông minh và tiên tiến mà đơn giản là không bắt buộc, hoặc có sẵn, 10 năm trước.

Điều đó cũng có thể có nghĩa là các lập trình viên có kinh nghiệm có thể trở nên có giá trị hơn trong tương lai - giống như các ngành nghề khác như kỹ thuật nơi thu nhập cao nhất thường xảy ra muộn trong sự nghiệp.


1

Cũng giống như bạn, tôi bắt đầu lập trình từ năm 14 tuổi, cũng là lúc tôi có chiếc máy tính đầu tiên (mặc dù tôi đã học được vài tháng tại thời điểm đó). Tuy nhiên, tôi "chỉ" 33 bây giờ. :-)

Đề nghị của tôi là, khi phát triển một cái gì đó, bạn lấy từng một trong những lo lắng đó (quyền tệp, số lượng tệp trong một thư mục, v.v.) và sau đó sử dụng tất cả kinh nghiệm rộng lớn của bạn để trả lời một số câu hỏi về nó, theo tinh thần này:

  • Sẽ mất bao lâu để xử lý vấn đề đó đúng trong mã của bạn?
  • Nếu bạn không xử lý nó đúng cách, có khả năng thứ này sẽ cắn bạn sau này?
  • Nếu nó cắn bạn, hậu quả là gì?

Với những câu trả lời đó, một anh chàng có kinh nghiệm như vậy sẽ không gặp vấn đề gì để đưa ra quyết định sáng suốt. ;-)

Trách nhiệm của những "cựu chiến binh" như bạn đưa ra loại yêu cầu này và liên quan đến cả việc xác định những gì có thể sai và quyết định những vấn đề tiềm ẩn nào bạn nên chú ý.


1
Phản ứng của OP là tất cả các vấn đề tiềm năng quan sát được cần phải ngăn chặn. Điều này có thể đúng khi anh bắt đầu làm lập trình viên cơ sở (vì những vấn đề tiềm ẩn mà anh nhận ra sau đó thường có nghĩa là cải thiện chất lượng rất lớn), rất có thể nó không còn đúng nữa: Như @igorrs giải thích: không tự động kết luận rằng mọi vấn đề tiềm ẩn mà bạn thấy phải được ngăn chặn - quyết định một cách có ý thức nếu bạn cần. Đó là những lợi thế bạn có hơn lập trình viên cơ sở: họ chỉ có thể ngăn chặn những gì họ có thể thấy, trong khi bạn có thể ngăn chặn những gì thực sự cần ngăn chặn.
Astrotrain

0

Biết tất cả các tiêu chí có thể có trong khi phát triển ứng dụng là điều quan trọng nhất trong việc phát triển một sản phẩm chất lượng. Bạn đang làm tốt trong việc này. Một điều bạn có thể làm là, Bạn có thể phân loại yêu cầu thành mức chất lượng sau đó ánh xạ mức độ với thời hạn nhất định. Bằng cách này, bạn có thể đáp ứng thời hạn dự án Easliy.


0

Theo lời của Edsger Dijsktra: Mạnh Nếu gỡ lỗi là quá trình loại bỏ các lỗi phần mềm, thì lập trình phải là quá trình đưa chúng vào. Đó chỉ là một câu hỏi về việc học cách dành thời gian để mã hóa nó đúng. Tôi vẫn còn là một lập trình viên tương đối trẻ (đọc 20ish) và tôi khao khát có thể viết mã một cái gì đó hoàn toàn đúng một lần. Một giờ lập kế hoạch và 10 phút mã hóa là cách tốt hơn so với 10 phút lập kế hoạch, một giờ mã hóa và ba lần gỡ lỗi.

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.