Funny (sausage) refactorings



    Hi% habrausername%. I want to play a game with you.

    You got a new job. And on the first day, immediately after signing the NDA, they show you what is left of the previous developer. You want to scream, you want to escape from this damned place, but an employment contract fetters you hand and foot. Therefore, you only barely audibly swear.

    From the previous developer there was a bunch of code and slippers. You carefully put slippers in the trash and start refactoring.

    This code is terrible. Firstly, there is no one who could say why this code was written. Secondly, there is no documentation. There are not even comments, not to mention unit tests. Thirdly, the code is not structured, and the names of classes and methods do not say anything. And, finally, it should not start working today, and not even yesterday, but suddenly .
    Well, how,% habrausername%, ran a chill on the back?

    In such a situation, every programmer believes that now he will do better than it was. But is it? Does code objectively get better after refactoring? If so, what is the criterion for improving the code? Or maybe refactoring serves to satisfy the ambitions of the developer?

    I bring to your attention TB MMOG called "Fun Refactoring".

    The bottom line is as follows. There is a certain code, the leader and N participants. The presenter sends the source code to the first participant by mail. The participant refactores and sends the result back to the lead. The facilitator then sends the result to the second participant, and so on, until the participants end. The code is transmitted anonymously, that is, none of the participants knows whose code it is refactoring.

    The goal is to get an idea of ​​the "perfect code" and the methods that different developers use to achieve it. And of course, it will be fun. Following the results of Fun Refactoring, an article will be written with an analysis of the changes made, and all source codes will be shared.

    If you want to take part in Fun Refactoring, send a request to recrowding@gmail.com. Indicate your email in the application (it will be used exclusively to send you the source code) and a few words about yourself (they will be published in the final report, this may include contacts, a link to the site, etc.).

    To prevent chaos, several rules are introduced:
    1. Do not hold the code for too long. If there is no answer from you for more than two days, you will be excluded from the game.
    2. You should not write any personal data in the code, so as not to tempt the next participant to contact you for help. Emails, names, appearances, etc. from the source code will be shamelessly cut out.
    3. You cannot change the programming language. In the rest, the participant is given complete freedom of action within the framework of the concept of “refactoring”. Yes, outright trash will be excluded.
    4. The general review will be published on Habré, and the works of all participants in the competition will be posted in a public repository along with a couple of words to themselves indicated in the application.


    For these Refactors, the Java language is chosen (because it is possible to refactor a program in Java endlessly). Applications are accepted until March 18.

    UPD Now that I’ve talked, I’ll say that the original bunch of code is collected in one file and has a length of no more than 200 lines.

    UPD2 To say that I received a lot of applications is to say nothing. I don’t have enough time physically to answer everyone, and I don’t need it, I guess. The main thing is that all incoming applications are recorded, and the source codes are already set sail. Be patient, everyone who sent me an email will get an archive with the code over time.

    Also popular now: