경력에서 배운 최고의 교훈은 무엇입니까? [닫은]

필자는 5 분 정도의 직업이 없다고 생각한다. 프로그래머들은 개발에 대해 지나치게 낙관적 인 경향이 있으며, 문제에 대한 빠른 해결책을 약속하고 코드에 뛰어 들기 전에 그 의미를 생각해야한다.

항상 코드를 작성하는 더 좋은 방법이 있습니다.

작성한 코드를 아무리 훌륭하게 찾더라도 몇 년 안에 코드를 검토하면 코드가 얼마나 나빠지는지 놀랄 것입니다. 몇 년 전만해도 오늘날 알고있는 패턴이나 그 동안 배운 언어 기능 등을 알지 못했습니다.

1. 코딩을 시작하기 전에 생각하십시오.

2. 임시 솔루션보다 영구적 인 것은 없습니다 :)

3. 문제를 해결하기가 끔찍한 경우 문제 자체는 처음부터 잘못 제기되었을 가능성이 큽니다.

소프트웨어는 작성 당시 생각했던 것보다 훨씬 오래 작동합니다.

나는 80 년대에 경력을 시작했습니다. 나는 70 년대에 시작된 소프트웨어에서 시작하여 여전히 90 년대에 사용되고있었습니다 (어쩌면 더 오래, 그 운명에 대해서는 잘 모릅니다). 내 자신의 오픈 소스 코드 중 일부는 20 년이 지났습니다.

다른 사람들과 잘 지내는 것이 매우 중요합니다.

"당신의 '남자에게 가십시오'를 보여주세요 그리고 나는 당신에게 당신의 문제를 보여줄 것입니다"

Slapdash Hero Coders-컨벤션, 가독성 또는 다른 작업을 고려하지 않고 코드를 작성하는 사람들은 좋은 것보다 더 많은 해를 입힐 수 있습니다.

좋은 품질의 톤 코드를 작성할 수있는 사람들은 나쁜 것입니다. 아주 드물다.

그것은 겸손의 교훈이 될 것입니다.

새로운 언어를 배우는 것은 일의 일부입니다

나는 80 년대에 학교에서 4 개의 프로그래밍 언어에 대해 배웠지 만 그 중 하나를 직장에서 사용했습니다. 나는 내가 사용하기 위해 고용 된 언어조차 몰랐던 네 가지 직업을 가졌습니다.

전반적으로, 나는 FORTRAN, c, c ++, c #, java, perl, Tcl, ruby, groovy, awk, python, sh, batch, DCL, javascript 및 a를 포함하여 12 가지 언어를 전문적으로 배우고 사용했습니다. 작은 DSL. 약간의 수학을 할 때, 나는 몇 년마다 새로운 언어를 평균화하는 것처럼 보이지만 중복되는 부분은 많습니다.

내 경력에 일정한 것이 있다면 변화입니다.

소프트웨어는 완전하지 않습니다.

처리해야 할 요구 사항, 개선 사항, 버그 수정에는 항상 몇 가지 변경 사항이 있습니다. 따라서 융통성을 유지 "software is never complete"하고 항상 개선의 여지가 있다는 사실을 받아들이십시오 .

매일 공부하십시오. 오늘의 지식은 내일 쓸모가 없습니다.

아이러니하게도이 대답은 내일도 쓸모 없어야합니다. 그러나 실제로 하나 또는 두 가지를 열심히 공부하고 가능한 경우 인증을 받고 해당 언어의 신이 되십시오 (프로그래밍 언어 또는 시스템 / 네트워크 / 데이터베이스 관리 일 수 있음). 당신.

예를 들어, 훌륭한 Java 및 Oracle DB 관리 전문가가 되겠지만 인증 수준은 아니지만 Python, PHP, C ++, HTML5, Javascript에 대해 조금 공부합니다. 존재하는 각 웹 또는 언어 프레임 워크를 연구하십시오. SQL Server, MySQL, Cassandra, HBase, PostgreSQL 및 MongoDB 및 CouchDB와 같은 No-SQL 세계와 같이 존재하는 각 데이터베이스에 대해 약간의 기본 경험을 연구하거나 시도하십시오. 리눅스 관리 및 가상화 경험을 쌓으십시오.

그것은 16 년의 경험에서 배운 가장 큰 교훈입니다. 필자는 10 년 전부터 파스칼을 사용하고, 밀레니엄 초반에 Visual Basic 6을 사용했으며, 9 년 전부터 PHP 개발자로 10 년 동안 단일 언어 프로그래머였습니다. 그러나 그때부터 나는 개발자가 적어도 모든 것을 알아야한다는 것을 배웁니다.

"수학이 틀렸다면 토스트입니다."

몇 년 전에 처음 배웠습니다. 불과 2 주 전에 다시 배웠습니다.

내가 배운 최고의 교훈은

"당신은 항상 최선의 접근 방법을 찾아야 합니다 ."

나는 것을 배운 최고의 디자인 원리 KISS는 (바보, 간단하게!) .

코드를 단순하고 깨끗하게 유지하는 것이 주요 관심사이며 각 팀원은 코드가 무엇인지 이해해야한다는 것을 알게되었습니다. The KISS principle대부분의 시스템은 복잡하게 만들지 않고 단순하게 유지하면 가장 잘 작동하므로 단순성은 디자인의 핵심 목표가되어야하며 불필요한 복잡성을 피해야합니다.

고장 나지 않았다면 고치지 마십시오!

이미 작동하는 것을 확장하고 개선하려고하면 큰 두통이 생길 수 있습니다

시도가 없습니다

4 일이 소요될 것으로 예상되는 작업이나 작업이 있다고 가정 해 봅시다. 그런 다음 상사 나 프로젝트 관리자가 중요한 이유로 이틀 안에 작업을 수행 할 수 있는지 묻습니다. 훌륭하고 융통성있는 직원이되기를 원한다면, 시도 할 수 있습니다. 이로 인한 대부분의 결과는 마감일을 놓치거나 반쯤 해킹하여 해킹을 수행한다는 것입니다. 그리고 당신이 그것을 요구하는 것은 당신의 상사의 잘못이 아닙니다. 그것이 그의 일입니다. 아니오라고 대답하지 않은 것은 당신의 잘못입니다.

당신은 시간과 협상 할 수 없습니다. 범위와 흥정 할 수 있습니다. 전문적이고 자신을 짧게 팔지 마십시오.

"그런 일이 일어나지 않을 것"은 실제로 "제작 첫날까지 일어날 수 없을 것"을 의미합니다

최고 수준의 첨단 첨단 코드를 작성하는 것이 좋습니다.

코드 기반을 망칠 수있는 빠른 수정 해결 방법을 요청받은 경우에도 오히려 좋은 방법입니다.

• 코드 작성이 쉽습니다. 코드를 읽기가 어렵습니다. 코드가 당신의 것이더라도. 따라서 가능할 때마다 읽기 쉬운 접근 방식을 찾으십시오.

• 당신은 다른 사람들보다 똑똑하지 않습니다. 당신이 접근하는 것이 최선이라고 생각하지 마십시오.

• BY WHOM이 아니라 WHATM에 대해주의하십시오. 가장 예기치 않은 출처에 대한 훌륭한 아이디어가 나올 수 있습니다.

• 게으르지 마십시오. 좋은 코드를 작성하기 위해 시간을 내십시오. 어쨌든 더 높은 비용으로 문제를 해결해야합니다.

단지 멋진 OOP 기능을 사용하지 마십시오 ! - 야니 (필요하지 않을 것입니다)

Use fancy OOP features그들이 해결하려는 문제에 대해 구체적이고 명백한 이점 이 있기 때문 입니다. 당신은 웃지 만, 나는 이것을 항상 봅니다. 대부분의 프로그래머는 마음에 들지 않는 물건을 만난 적이 없습니다. 나는 그것이 다른 방법으로 주위에 있어야한다고 생각합니다 : 이러한 기술은 KISS 의 법원에서 무죄로 입증 될 때까지 유죄 입니다.