부적절한 관리를 다루는 방법

Question

내가 진행하고있는 프로젝트가 완료되었으므로, 내 고용주의 새로운 태스킹으로 넘어갔습니다. 이전 작업은 매우 민첩하고 소규모 팀이었고 절차 진행 과정 등이었습니다.

어쨌든 새 프로젝트가 있습니다. 관리 방법을 혼란스럽게 생각합니다. 그들은 객체 지향 프로그래밍, 현재 기술 또는 방법론에 대한 진정한 이해가 없습니다. 그들은 변화를 두려워하는 것처럼 보입니다. 최근에 우리는 최신 JRE로 옮겼습니다.

우리는이 코드 리뷰를 작성하고 ADA에 얼마나 좋은지 또는 C에서 어떻게 사용했는지 말하는 "회색 수염"에 귀를 기울여야합니다. 그러나 검토를 코드화하려고 할 때 - OOP 디자인과 개발자에 대한 기본적인 이해조차도 부족합니다. 그들은 코드의 스타일에 더 중점을 둡니다. 간격; 메서드 이름;

고위급 사람들 중 한 사람은 이전에 작성한 학술적 PDF의 log4j에 대한 부정적인 검토 때문에 log4j 대신 자체 로거를 작성해야한다고 말합니다.

어떻게 처리합니까? 어떻게하면 그들의 디자인이 잘못되었거나 정말로 시대에 뒤떨어 졌는지 설명 할 수 있습니다. 나는 약 1 년 동안이 단체와 만 있었기 때문에 나는 얼마나 많은 신뢰를 가질 수 있는지 모른다.

Answer 1

코드 검토에 관해서는, 나는 그 (것)들을 행복한 만드는지 말할 것입니다. 원하는대로 이름을 지정하고 공백을 넣으십시오. 물론 더 나은 디자인에 집중하고 ADA 추억을 즐기십시오. 그래도 현재의 위치와 어떻게 도착했는지에 대한 배경을 제공 할 수 있습니다.

즉, 그 부분을 너무 심각하게 생각하지 마십시오. 일을 끝내는 데 중요한 일이 무엇인지 걱정됩니다. 이 경우 작업은 프로젝트에 긍정적 인 기여를했다고 느끼는 사람들을 만드는 것입니다.

Log4j와 관련해서는 다른 프레임 워크를 제안 할뿐입니다. 내장 된 JDK 로깅 (그것에 대해 불평 할 수 없다. API가 내장되어있다.) 또는 SLF와 같은 것이있다. 원하는대로 플러그인 할 수있다. (내 자신을 포함해서, 버리고 대체 할 수있다. 실수 였을 때 진짜 일을하고 클래스 패스 만 변경하면됩니다.

이제 중요한시기가 있습니다. 이 경우 가능한 한 많이 소리를내어 아이디어라고 생각하십시오. 예를 들어, 로깅의 경우 코드 줄을 나타내는 많은 로깅 프레임 워크가 있으며이 프로젝트에서이 작업을 활용할 다른 방법이 있는지 궁금해하고 있습니다. 해결책.

뭔가를 아이디어로 푸시해야하는 경우가 있습니다. 다른 방법은 없습니다. 이 경우 증거에 충실하고, 좋은 동맹에 영향력을 행사하는 사람들과 관계를 유지함으로써 가능한 한 많이 격렬한 동맹을 맺고, 싸우는 모든 전투가 승리 할지라도 (심지어 특히 당신이이기는 경우에도) .

Answer 2

'제안'으로 우려 사항을 제기하는 것이 좋습니다. 제안을하고 자신의 견해를 묻습니다. 마치 씨앗을 심고 대화를 지휘하고 있다고해도 그들이 통제 할 수있는 것처럼 느끼는 방식입니다.

조직에 얼마나 오래 있었는지에 관계없이 귀하는 거기에 있으며 이유가 있습니다 (귀하가 귀하의 의견을 묻기 위해 귀하를 고용 했음). 목소리를 찾고 팀 구성원에게 제안 및/또는 우려 사항에 가장 잘 접근하는 방법을 찾으십시오. 이는 팀원이되는 데있어 중요한 부분이며 귀하의 가치를 높입니다.

Answer 3

좋은 포맷터를 만들고 이것들에 대해 불평 할 수없는 메소드 이름을 생성하면 토론이 실제 문제로 넘어갈 수 있습니다.

일부 사람들은 리뷰 중에 이러한 작은 세부 사항을 극복 할 수 없으므로 문제가되지 않도록해야합니다.

Answer 4

log4j 외에 다른 로깅 프레임 워크의 권장 사항에 동의하지 않습니다. 개인적인 경험없이 이전 리뷰를 인용하면 하루를 이겨서는 안됩니다.

그러나 이점을 활용할 수있는 방법이있을 수 있습니다. JDK 또는 Apache Commons 로깅에 내장 된 로깅에 동의하고 권장하는 경우 두 가지 모두 매우 유사하며 실제로 log4j를 기본 구현으로 사용할 수 있습니다.

당신의 상대가 많은 관심을 기울이지 않는다면, 포기하고 자전거 헛소리를 피하고 원하는 것을 얻을 수 있습니다.

Answer 5

내 손님, 틀 렸습니다. 처음부터 틀렸어.

내 손님 : 다시 conter 반응을 받아들이는 것을 망설이지 말라!

당신이 그 계급을 통과 할 수도 있습니다 : 신인.

참고 : 경영진은 고용주입니다. 우리가 그들을 도울 수있는 한 그들은 우리에게 돈을 지불합니다. 그들이 당신을 원하지 않는다면, 당신은 틀렸어. 우리가 돈에 대해서 이야기 한 이후에 그들은 옳다. 귀하의 도서에서만 귀하의 권리가 있다면, 당신은 문제가 있습니다 ...

Answer 6

당신의 작품은 당신의 말을 듣기 전에 신뢰를 얻어야합니다. 그렇습니다. 다른 사람들이 추천 한 것처럼해야하며 중요하지 않은 서식 법을 준수해야합니다. 그러나 당신을 무시하거나 주 변화시킬 수없는 양질의 일을하십시오. 아이디어가 그들에게서 나왔다고 생각하게하는 방식으로 안내하도록하십시오.

Answer 7

나는 장로님을 존중합니다! :)

그래도 기저귀에있는 동안 회색 턱수염이 많이 나왔을 것입니다. 그렇다고해서 최신 기술에 대한 전문가가 될 수는 없지만 적어도 당신의 존경심은 커야합니다. 그리고 때로는 당신이 모든 헤밍과 헤킹을 과거의 모습으로 볼 수 있고 "내 하루 뒤에"물건을 발견 할 수 있다면, 당신은 그 늙은 개들에게서 지혜의 진주를 얻을 수 있습니다!

프로그래밍 관점에서 볼 때, Yishai가 옳은 것처럼 보입니다. 그들이 원하는 코딩 스타일을 따르는 것은 꽤 쉬워야하고 일단 당신이 행복하게 만들었 으면 원하는 방식으로 코드를 실행할 수 있습니다.

의견 견적을 제출해야하는 경우이를 백업하십시오. log4j와 같은 것을 사용하고 싶다면 과거에 사용했던 특정 프로젝트에 대해 이야기하고 잘 작동했는지, 누군가가 가지고있는 문제 등을 해결할 수 있도록 제안하십시오.

기억하기 , 당신은 오래된 회색 수염을보고 시원한 새로운 프로그래밍을하는 법을 알지 못하는 것처럼, 그들은 세상을 바꾸기 위해 많은 미친 아이디어를 가진 젊은 채찍 끈을 보게 될 것입니다. 인내의 온스는 존경의 파운드를 얻을 것이다.

Answer 8

나는 늙은 회색 턱수염이지만 35 년 전에 COBOL을 폐기하고 dotNET C#에서 코드를 작성하고 젊은 와이파이 애호가들과 잘 지내며 멘토를 도왔습니다. VB6와 같은 어두운 시대에 아직도 웹 팜, 웹 서비스를 허용 할 수없는 많은 관리자와 프로그래머를 보았습니다.이 회색 비어드와 젊은 와이퍼 스너 중 일부는 데이터베이스 테이블을 3NF로 표준화 할 수 없으므로 nTier, WCF 또는 단서가있다. 더욱 나쁜 점은 관리자 중 일부는 30 년 뒤이고 VB6와 Access97을 사용하는 플랫 파일에 의존한다는 것입니다.