주니어 프로그래머가 시험을 작성하게하는 방법? [닫은]
우리는 단순히 충분한 테스트를 작성하지 않는 주니어 프로그래머가 있습니다.
나는 두 시간마다 그를 잔소리해야한다. "테스트를 작성 했습니까?"
우리는 시도했다 :
- 디자인이 더 단순 해짐
- 그것을 보여주는 것은 결함을 방지
- 나쁜 프로그래머만이 아니라고 말하는 자아 만들기
- 이번 주말에 2 명의 팀원은 코드에 NULL 참조가 있었고 테스트하지 않았기 때문에 출근해야했습니다.
내 작업에는 최고 품질의 안정적인 코드가 필요하며 일반적으로 모든 사람이 그것을 '얻고'테스트를 진행할 필요가 없습니다. 우리는 그가 시험을 작성할 수 있다는 것을 알고 있지만, 유용한 시험은 시험에 응시할 때 작성되는 시험이라는 것을 모두 알고 있습니다.
더 많은 동기를 알고 있습니까?
이것은 가장 어려운 일 중 하나입니다 . 사람들 이 그것을 얻을 수 있습니다 .
때로 주니어 레벨 프로그래머가 '알고'노인들로부터 올바른 기술을 배우도록 돕는 가장 좋은 방법 중 하나는 약간의 페어 프로그래밍을하는 것입니다.
다가오는 프로젝트에서 주니어 녀석을 자신이나 다른 선임 프로그래머와 페어링하십시오. 그들은 "운전"(키보드로 타이핑하는 것)과 "코칭"(운전자의 어깨 너머로보고 제안, 실수 등을 지적함)을 번갈아 가며 함께 일해야합니다. 리소스 낭비처럼 보일 수 있지만 다음을 찾을 수 있습니다.
- 이 사람들이 함께 코드를 훨씬 빠르고 고품질로 만들 수 있습니다.
- 하급 직원이 선배에게 올바른 길을 따라 지시를 내리는 데 충분한 지식을 갖춘 경우 (예 : "지금 계속하기 전에이 기능에 대한 테스트를 작성해 보겠습니다.") 리소스 가치가 있습니다. 그것에 헌신하십시오.
그룹 내 누군가 누군가 Kate Rhodes 의 Unit Testing 101 프레젠테이션을하도록했을 수도 있습니다. 잘 전달된다면 사람들이 테스트에 대해 흥분하게 만드는 좋은 방법이라고 생각합니다.
당신이 할 수있는 또 다른 일은 Jr. Devs가 볼링 게임 Kata 를 연습하게하여 테스트 주도 개발을 배우도록 도와주는 것입니다. Java로되어 있지만 모든 언어에 쉽게 적용 할 수 있습니다.
모든 커밋 전에 코드 검토를 수행하고 (1 분 "이 변수 이름을 변경 했더라도"), 코드 검토의 일부로 단위 테스트를 검토하십시오.
테스트가 완료 될 때까지 커밋에 서명하지 마십시오.
(또한-그의 작업이 테스트되지 않은 경우-왜 처음부터 프로덕션 빌드에 있었습니까? 테스트되지 않은 경우 들어 가지 마십시오. 주말에 일할 필요가 없습니다)
나 자신을 위해, 내가 찾거나 고치는 모든 버그가 테스트로 표현되도록 주장하기 시작했다.
- "흠, 맞지 않아 ..."
- 가능한 문제 찾기
- 테스트를 작성하고 코드가 실패했음을 표시
- 문제를 해결
- 새 코드가 통과했음을 표시
- 원래 문제가 지속되면 루프
나는 물건을 두드리는 동안 에도이 작업을 시도하고 이미 부분 테스트 스위트를 사용하여 거의 같은 시간에 완료됩니다.
(나는 상용 프로그래밍 환경에 살고 있지 않으며 종종 특정 프로젝트를 수행하는 유일한 코더입니다.)
내가 마르코라는 모의 프로그래머라고 상상해보십시오. 내가 그렇게 오래 전에 학교를 졸업했고 실제로 시험을 쓰지 않아도된다고 상상해보십시오. 내가 실제로 이것을 요구하거나 요구하지 않는 회사에서 일한다고 상상해보십시오. 확인? 좋은! 이제 회사가 테스트 사용으로 전환하고 있다고 생각합니다. 나는 이것에 대한 연구를하지 않은 것처럼 지금까지 언급 한 항목에 약간의 반응을 줄 것입니다.
제작자부터 시작해 보겠습니다.
디자인이 더 단순 해짐을 보여줍니다.
더 많이 쓰는 방법이 더 간단 해집니다. 나는 더 많은 사건을 얻는 등의 일을 계속해야한다. 그러면 당신이 나에게 물어 보면 더 복잡해진다. 자세한 내용을 알려주세요.
표시하면 결함을 방지합니다.
나도 알아 이것이 바로 테스트라고하는 이유입니다. 내 코드는 훌륭하고 문제가 있는지 확인 했으므로 테스트가 도움이 될 위치를 찾지 못했습니다.
나쁜 프로그래머 만 그렇지 않다고 말하는 자아를 만드는 것.
오, 그래서 당신은 내가 많이 사용하는 테스트를하지 않기 때문에 내가 나쁜 프로그래머라고 생각합니다. 나는 당신을 모욕하고 긍정적으로 화가 나 있습니다. 나는 말보다 도움과 지원을 원합니다.
@ Justin Standard : 새로운 프로텍트 페어를 시작할 때 주니어 녀석은 자신이나 다른 상급 프로그래머와 짝을 짓습니다.
오, 이것은 매우 중요합니다. 일이 어떻게 진행되는지를 확인하고 일이 어떻게 수행되는지에 대한 도움을 받기 위해 자원이 사용될 것입니다. 이것은 도움이되며, 더 많이 시작할 수 있습니다.
@ Justin Standard : Kate Rhodes의 Unit Testing 101 발표 자료 읽기 .
아, 그거 흥미로운 발표 였고 테스트에 대해 생각하게 만들었습니다. 그것은 고려해야 할 몇 가지 요점을 망치고 내 견해가 약간 흔들릴 수 있습니다.
나는 이것이 더 효과적인 기사라고 생각하고 이것이 나를위한 올바른 방법이라고 생각하는 데 도움이되는 다른 도구를보고 싶다.
@ Dominic Cooney : 시간을 보내고 테스트 기술을 공유하십시오.
아, 이것은 기술에 관한 한 나에게 기대되는 것을 이해하는 데 도움이되며, 다시 사용할 수 있도록 더 많은 항목을 지식 가방에 넣습니다.
@ Dominic Cooney : 질문, 예제 및 책에 답변하십시오.
포인트 사람 (사람)이 질문에 대답하는 것이 도움이되며, 시도 할 가능성이 높아집니다. 좋은 예는 훌륭하며, 나에게 목표로 삼고 참조 할 것을 제공합니다. 이와 직접 관련된 책은 훌륭한 참고 자료입니다.
@ Adam Hayle : 서프라이즈 리뷰.
내가 완전히 준비하지 않은 무언가를 냈어. 불편한 점이 있지만 최선을 다하겠습니다. 나는 이제 이것이 다시 오는 것을 두려워하고 약간 걱정할 것입니다. 감사합니다. 그러나 겁 전술은 효과가 있었지만 비용이 많이 든다. 그러나 아무것도 작동하지 않으면 필요한 푸시 일 수 있습니다.
@ Rytmis : 항목은 테스트 케이스가있는 경우에만 수행 된 것으로 간주됩니다.
오, 흥미 롭군 나는 지금 이것을 정말로해야한다고 생각한다. 그렇지 않으면 나는 아무것도 완성하지 못한다. 이것은 말이됩니다.
눈부심, 눈부심, 눈부심 -내가 배울 수있는 기회가 있으며, 지원과 도움을 받아 팀에서 매우 중요하고 기능적인 부분이 될 수 있습니다. 이것은 지금 내 핸디캡 중 하나이지만 오래 걸리지 않습니다. 그러나 내가 그것을 얻지 못하면 나는 갈 것이라는 것을 이해합니다. 나는 그것을 얻을 것이라고 생각합니다.
결국, 우리 팀의 지원은이 모든 것에서 큰 역할을합니다. 사람이 도와주기 위해 시간을내어 좋은 습관을 갖도록하는 것은 언제나 환영합니다. 그런 다음 좋은 지원 네트워크를 갖는 것이 좋습니다. 누군가가 나중에 몇 번이나 와서 코드를 검토하여 리뷰 자체가 아니라 친절한 방문으로 모든 것이 어떻게 흐르는 지 확인하는 것이 좋습니다.
추론, 준비, 교육, 후속 조치, 지원.
많은 프로그래머들이 합리적인 수준에서 테스트의 가치를 본다는 것을 알았습니다. "예, 테스트해야한다는 것을 알고 있지만이 작업을 신속하게 완료해야합니다."와 같은 내용을 들었다면 내 말의 의미를 알 수 있습니다. 그러나 감정적 인 수준에서 그들은 실제 코드를 작성할 때만 무언가를 얻는다고 느낍니다.
그러므로 테스트는 실제로 무언가가 "완료"된 시점을 측정 할 수 있는 유일한 방법 이라는 것을 이해하게하여 테스트 를 작성하려는 본질적 동기를 부여하는 것이 목표입니다.
그래도 그것이 생각보다 훨씬 어려워서 두렵습니다. "실제로 서두르고 나중에 다시 작성 / 리 팩터 한 다음 테스트를 추가하겠습니다"라는 문구에 따라 많은 변명을들을 수 있습니다. 물론 후속 조치는 놀랍게도 '다시 다음 주 바쁜처럼 .
내가 할 일은 다음과 같습니다.
처음으로 ... "우리는이 프로젝트를 공동으로 할 것입니다. 테스트를 작성하고 코드를 작성합니다. 테스트 작성 방법에주의를 기울이십시오. coz는 우리가하는 일입니다. 이 주변에있는 것이 바로 내가 기대하는 것입니다. "
그 다음에 ... "완료 되었습니까? 훌륭합니다! 먼저 개발을 추진하고있는 테스트를 살펴 보겠습니다. 테스트를하지 않습니까? 언제 완료되었는지 알려 주시면 코드를 다시 예약하겠습니다. "공식 테스트에 도움이 필요하면 알려 주시면 도와 드리겠습니다."
주니어 프로그래머 인 저는 여전히 작문 시험 습관을들이려고 노력하고 있습니다. 분명히 새로운 습관을들이는 것은 쉽지 않지만, 나에게 무엇이 도움이 될지 생각할 때 코드 리뷰 및 코칭 / 페어 프로그래밍에 대한 의견을 +1해야합니다.
또한 테스트의 장기적인 목적을 강조 할 가치가 있습니다. 어제 효과가 있었던 것이 오늘날, 다음 주 및 다음 달에도 계속 작동하는지 확인하십시오. 나는 대답을 감추기 때문에 언급 한 내용을 보지 못했기 때문에 말할뿐입니다.
코드 검토를 수행 할 때 (당신이 그렇게하기로 결정한 경우), 젊은 개발자가 코드 를 내리는 것이 아니라 코드를 더 잘 만드는 것임을 알도록하십시오 . 그렇게하면 그의 자신감이 손상 될 가능성이 줄어 듭니다. 그리고 그것은 중요합니다. 반면에, 당신이 아는 것이 거의 없다는 것을 알고 있습니다.
물론, 나는 정말로 아무것도 모른다. 그러나 나는 그 단어가 도움이 되었기를 바랍니다.
편집 : [ 저스틴 표준 ]
자신을 내려 놓지 마십시오. 당신이 말해야 할 것은 거의 옳습니다.
On your point about code reviews: what you will find is that not only will the junior dev learn in the process, but so will the reviewers. Everyone in a code review learns if you make it a collaborative process.
Frankly, if you are having to put that much effort into getting him to do something then you may have to come to terms with the thought that he may just not be a good fit for the team, and may need to go. Now, this doesn't necessarily mean firing him... it may mean finding someplace else in the company his skills are more suited. But if there is no place else...you know what to do.
I'm assuming he is also a fairly new hire (< 1 year) and probably recently out of school...in which case he may not be accustomed to how things work in a corporate setting. Things like that most of us could get away with in college.
If this is the case, one thing I've found works is to have a sort of "surprise new hire review." It doesn't matter if you've never done it before...he won't know that. Just sit him down and tell him your are going to go over his performance and show him some real numbers...take your normal review sheet (you do have a formal review process right?) and change the heading if you want so it looks official and show him where he stands. If you show him in a very formal setting that not doing tests is adversely affecting his performance rating as opposed to just "nagging" him about it, he will hopefully get the point. You've got to show him that his actions will actually affect him be it pay wise or otherwise.
I know, you may want to stay away from doing this because it's not official... but I think you are within reason to do it and it's probably going to be a whole lot cheaper than having to fire him and recruit someone new.
He's already doing this. Really. He just doesn't write it down. Not convinced? Watch him go through the standard development cycle:
- Write a piece of code
- Compile it
- Run to see what it does
- Write the next piece of code
Step #3 is the test. He already does testing, he just does it manually. Ask him this question: "How do you know tomorrow that the code from today still works?" He will answer: "It's such a little amount of code!"
Ask: "How about next week?"
When he hasn't got an answer, ask: "How would you like your program to tell you when a change breaks something that worked yesterday?"
That's what automatic unit testing is all about.
As a junior programmer myself, I thought that Id reveal what it was like when I found myself in a similar situation to your junior developer.
When I first came out of uni, I found that it had severly un equipped me to deal with the real world. Yes I knew some JAVA basics and some philosophy (don't ask) but that was about it. When I first got my job it was a little daunting to say the least. Let me tell you I was probably one of the biggest cowboys around, I would hack together a little bug fix / algorithm with no comments / testing / documentation and ship it out the door.
I was lucky enough to be under the supervision of a kind and very patient senior programmer. Luckily for me, he decided to sit down with me and spend 1-2 weeks going through my very hacked togethor code. He would explain where I'd gone wrong, the finer points of c and pointers (boy did that confuse me!). We managed to write a pretty decent class/module in about a week. All I can say is that if the senior dev hadn't invested the time to help me along the right path, I probably wouldn't have lasted very long.
Happily, 2 years down the line, I would hope that some of my collegues might even consider me an average programmer.
Take home points
- Most Universities are very bad at preparing students for the real world
- Paired programming really helped me. Thats not to say that it will help everyone but it worked for me.
Assign them to projects that don't require "top quality stable code" if that's your concern and let the jr. developer fail. Have them be the one to 'come in on the weekend' to fix their bugs. Have lunch a lot and talk about software development practices (not lectures, but discussions). In time they will acquire and develop the best practices to do the tasks they are assigned.
Who knows, they might even come up with something better than the techniques your team currently uses.
If the junior programmer, or anyone, doesn't see the value in testing, then it will be hard to get them to do it...period.
I would have made the junior programmer sacrifice their weekend to fix the bug. His actions (or lack there of) are not affecting him directly. Also, make it apparent, that he will not see advancement and/or pay increases if he doesn't improve his skills in testing.
In the end, even with all your help, encouragement, mentoring, he might not be a fit for your team, so let him go and look for someone who does get it.
I second RodeoClown's comment about code reviewing every commit. Once he's done it a fair few times he'll get in the habit of testing stuff.
I don't know if you need to block commits like that though. At my workplace everyone has free commit to everything, and all SVN commit messages (with diffs) are emailed to the team.
Note: you really want the thunderbird colored-diffs addon if you plan on doing this.
My boss or myself (the 2 'senior' coders) will end up reading over the commits, and if there's any stuff like "you forgot to add unit tests" we just flick an email or go and chat to the person, explaining why they needed unit tests or whatever. Everyone else is encouraged to read the commits too, as it's a great way of seeing what's going on, but the junior devs don't comment so much.
You can help encourage people to get into the habit of this by periodically saying things like "Hey, bob, did you see that commit I did this morning, I found this neat trick where you can do blah blah whatever, read the commit and see how it works!"
NB: We have 2 'senior' devs and 3 junior ones. This may not scale, or you might need to adjust the process a bit with more developers.
- Make code coverage part of the reviews.
- Make "write a test that exposes the bug" a prerequisite to fixing a bug.
- Require a certain level of coverage before code can be checked in.
- Find a good book on test-driven development and use it to show how test-first can speed development.
Lots of psychology and helpful "mentoring" techniques but, in all honestly, this just boils down to "write tests if you want to still have a job, tomorrow."
You can couch it in whatever terms you think are appropriate, harsh or soft, it doesn't matter. But the fact is, programmers are not paid to just throw together code & check it in -- they're paid to carefully put together code, then put together tests, then test their code, THEN check the whole thing in. (At least that's what it sounds like, from your description.)
Hence, if someone is going to refuse to do their job, explain to them that they can stay home, tomorrow, and you'll hire someone who WILL do the job.
Again, you can do all this gently, if you think that's necessary, but a lot of people just need a big hard slap of Life In The Real World, and you'd be doing them a favor by giving it to them.
Good luck.
Change his job description for a while to solely be writing tests and maintaining tests. I've heard that many companies do this for fresh new inexperienced people for a while when they start.
Additionally, issue a challenge while he's in that role: Write tests that will a) fail on current code a) fulfill the requirements of the software. Hopefully it'll cause him to create some solid and thorough tests (improving the project) and make him better at writing tests for when he re-integrates into core development.
edit> fulfull the requirements of the software meaning that he's not just writing tests to purposely break the code when the code never intended or needed to take that test case into account.
If your colleague lacks experience writing tests maybe he or she is having difficulty testing beyond simple situations, and that is manifesting itself as inadequate testing. Here's what I would try:
- Spend some time and share testing techniques, like dependency injection, looking for edge cases, and so on with your colleague.
- Offer to answer questions about testing.
- Do code reviews of tests for a while. Ask your colleague to review changes of yours that are exemplary of good testing. Look at their comments to see if they're really reading and understanding your test code.
- If there are books that fit particularly well with your team's testing philosophy give him or her a copy. It might help if your code review feedback or discussions reference the book so he or she has a thread to pick up and follow.
I wouldn't especially emphasize the shame/guilt factor. It is worth pointing out that testing is a widely adopted, good practice and that writing and maintaining good tests is a professional courtesy so your team mates don't need to spend their weekends at work, but I wouldn't belabor those points.
If you really need to "get tough" then institute an impartial system; nobody likes to feel like they're being singled out. For example your team might require code to maintain a certain level of test coverage (able to be gamed, but at least able to be automated); require new code to have tests; require reviewers to consider the quality of tests when doing code reviews; and so on. Instituting that system should come from team consensus. If you moderate the discussion carefully you might uncover other underlying reasons your colleague's testing isn't what you expect.
It's his Mentor's responsibility to Teach him/her. How well are you teaching him/her HOW to test. Are you pair programming with him? The Junior more than likely doesn't know HOW to set up a good test for xyz.
As a Junior freshout of school he knows many Concepts. Some technique. Some experience. But in the end, all a Junior is POTENTIAL. Almost every feature they work on, there will be something new that they have never done before. Sure the Junior may have done a simple State pattern for a project in class, opening and shutting "doors", but never a real world application of the patterns.
He/she will only be as good as how well you teach. If they were able to "Just get it" do you think they would have taken a Junior position in the first place?
In my experience Juniors are hired and given almost same responsibility as Seniors, but are just paid less and then ignored when they start to falter. Forgive me if i seem bitter, it's 'cause i am.
@ jsmorris
I once had the senior developer and "architect" berate me and a tester(it was my first job out of college) in email for not staying late and finishing such an "easy" task the night before. We had been at it all day and called it quits at 7pm, I had been thrashing since 11am before lunch that day and had pestered every member our team for help at least twice.
I responded and cc'd the team with: "I've been disappointed in you for a month now. I never get help from the team. I'll be at the coffee shop across the street if you need me. I'm sorry i couldn't debug the 12 parameter, 800 line method that just about everything is dependent on."
After cooling off at the coffee shop for an hour, i went back in the office, grabbed my crap and left. After a few days they called me asking if I was coming in, I said I would but I had an interview, maybe tomorrow.
"So your quitting then?"
On your source repository : use hooks before each commits (pre-commit hook for SVN for example)
In that hook, check for the existence of at least one use case for each method. Use a convention for unit test organisation that you could easily enforce via a pre-commit hook.
On an integration server compile everything and check regularely the test coverage using a test coverage tool. If test coverage is not 100% for a code, block any commit of the developer. He should send you the test case that covers 100% of the code.
Only automatic checks can scale well on a project. You cannot check everything by hand.
The developer should have a mean to check if his test cases covers 100% of the code. That way, if he doesn't commit a 100% tested code, it is his own fault, not a "oops, sorry I forgot" fault.
Remember : People never do what you expect, they always do what you inspect.
First off, like most respondents here point out, if the guy doesn't see the value in testing, there's not much you can do about it, and you've already pointed out that you can't fire the guy. However, failure is not an option here, so what about the few things you can do?
If your organization is large enough to have over 6 developers, I strongly recommend having a Quality Assurance department (even if its just one person to start). Ideally, you should have a ratio of 1 tester to 3-5 developers. The thing about programmers is ... they are programmers, not testers. I have yet to interview a programmer that has been formally taught proper QA techniques.
Most organizations make the fatal flaw of assigning the testing roles to the new-hire, the person with the LEAST amount of exposure to your code -- ideally, the senior developers should be moved to the QA role as they have the experience in the code, and (hopefully) have developed a sixth sense for code smells and failure points that can crop up.
Furthermore, the programmer that made the mistake is probably not going to find the defect because its usually not a syntax error (those get picked up in the compile), but a logic error -- and the same logic is at work when they write the test as when they write the code. Don't have the person who developed the code test that code -- they'll find less bugs than anyone else would.
In your case, if you can afford the redirected work effort, make this new guy the first member of your QA team. Get him to read "Software Testing In The Real World: Improving The Process", because he obviously will need some training in his new role. If he doesn't like it, he'll quit and your problem is still solved.
A slightly less vengeful approach would be let this person do what they are good at (I'm assuming this person got hired because they are actually competent at the programming part of the job) , and hire a tester or two to do the testing (University students often have practicum or "co-op" terms, would love the exposure, and are cheap)
Side Note: Eventually, you'll want the QA team reporting to a QA director, or at least not to a software developer manager, because having the QA team report to the manager who's primary goal is to get the product done is a conflict of interest.
If your organization is smaller than 6, or you can't get away with creating a new team, I recommend paired programming (PP). I'm not a total convert of all the extreme programming techniques, but I'm definitely a believer in paired programming. However, both members of the paired programming team have to be dedicated, or it simply doesn't work. They have to follow two rules: the inspector has to fully understand what is being coded on the screen or he has to ask the coder to explain it; the coder can only code what he can explain -- no "you'll see" or "trust me" or hand-waving will be tolerated.
I only recommend PP if your team is capable of it, because, like testing, no amount of cheering or threatening will persuade a couple of ego-filled introverts to work together if they don't feel comfortable doing so. However, I find that between the choice of writing detailed functional specs and doing code reviews vs. paired programming, the PP usually wins out.
If PP is not for you, then TDD is your best bet, but only if its taken literally. Test Driven Development mean you write the tests FIRST, run the tests to prove they actually do fail, then write the simplest code to make it work. The trade off is now you (should) have a collection of thousands of tests, which is also code, and is just as likely as production code to contain bugs. I'll be honest, I'm not a big fan of TDD, mainly because of this reason, but it works for many developers who would rather write test scripts than test case documents -- some testing is better than none. Couple TDD with PP for a better likelihood of test coverage and less bugs in the script.
If all else fails, have the programmers equivalence of a swear jar -- each time the programmer breaks the build, they have to put $20, $50, $100 (whatever is moderately painful for your staff) into a jar that goes to your favorite (registered!) charity. Until they pay up, shun them :)
All joking aside, the best way to get your programmer to write tests is don't let him program. If you want a programmer, hire a programmer -- If you want tests, hire a tester. I started as a junior programmer 12 years ago doing testing, and it turned into my career path, and I wouldn't trade it for anything. A solid QA department that is properly nurtured and given the power and mandate to improve the software is just as valuable as the developers writing the software in the first place.
This may be a bit heartless, but the way you describe the situation it sounds like you need to fire this guy. Or at least make it clear: refusing to follow house development practices (including writing tests) and checking in buggy code that other people have to clean up will eventually get you fired.
The main reason junior engineers/programmers don't take lots of time to design and perform test scripts, is because most CS certifications do not heavily require this, so other areas of engineering are covered further in college programs, such as design patters.
In my experience, the best way to get the junior professionals into the habit, is to make it part of the process explicitly. That is, when estimating the time an iteration should take, the time of design, write and/or execute the cases should be incorporated into this time estimate.
Finally, reviewing the test script design should be part of a design review, and the actual code should be reviewed in the code review. This makes the programmer liable for doing proper testing of each line of code he/she writes, and the senior engineer and peers liable to provide feedback and guidance on the code and test written.
Based on your comment, "Showing that the design becomes simpler" I'm assuming you guys practice TDD. Doing a code review after the fact is not going to work. The whole thing about TDD is that it's a design and not a testing philosophy. If he didn't write the tests as part of the design, you aren't going to get a lot of benefit from writing tests after the fact - especially from a junior developer. He'll end up missing a whole lot of corner cases and his code will still be crappy.
Your best bet is to have a very patient senior developer to sit with him and do some pair programming. And just keep at it until he learns. Or doesn't learn, in which case you need to reassign him to a task he is better suited to because you will just end up frustrating your real developers.
Not everyone has the same level of talent and/or motivation. Development teams, even agile ones, are made up of people on the "A-Team" and people on "B-Team". A-Team members are the one who architect the solution, write all the non-trivial production code, and communicate with the business owners - all the work that requires thinking outside the box. The B-Team handle things like configuration management, writing scripts, fixing lame bugs, and doing maintenance work - all the work that has strict procedures that have small consequences for failure.
참고URL : https://stackoverflow.com/questions/7252/how-to-make-junior-programmers-write-tests
'programing tip' 카테고리의 다른 글
| jQuery를 사용하여 동적으로 onClick 이벤트 추가 (0) | 2020.08.05 |
|---|---|
| ReactJS 코드에서 휴식 후 전화를 거는 방법? (0) | 2020.08.05 |
| Ruby on Rails에서 DateTime을 간단한 날짜로 변환 (0) | 2020.08.05 |
| 자바 스크립트에서 대소 문자를 구분하지 않는 정규 표현식 (0) | 2020.08.05 |
| Google Apps Script를 디버깅하는 방법 (일명 Logger.log는 어디에 기록됩니까?) (0) | 2020.08.04 |