-
How did you become a developer/project manager/team leader/whatever-you-are ? -
When and why did you decide to be an Inako? -
Something interesting about your life
-
Issues need to be set up as detailed as possible. Separate UI from functional tasks. Add detailed descriptions and try to separate them so as to have each task as close to being one-day (or less) in duration as possible. -
Design / UI tasks always need to have a screenshot attached in the task. -
Milestones need to be added, as well Release Dates. -
Never mix different issues in one. Close the original issue and open a new one, if needed. -
Always label issues (ios, android, server, admin, design, etc.). -
If there is an issue that says "XXX is not working correctly", it should also include an explanation on how it should work, for example: if the pivotal title is "The text in the title is right-aligned", the description or at least a comment in that issue should say something like "The text in the title should be centered".
-
Make sure you read the whole issue and review attachments before you start working on them. If the tasks are not 100% clear to you, reach out to the author. -
As soon as you start working on an issue, assign it to yourself. -
If you leave a comment or question in the issue, mention the person you need feedback from. -
If you find a bug, create a new issue for it.
-
As a developer, you must never submit code that's not tested (either with unit tests or otherwise). Therefore, the time you would spend testing your changes manually can also be spent writing an automated test for that same thing. That comes with an additional benefit: you can repeat that test as many times as you want and also get the other devs to automatically run it in every change, without actually having to remind and/or describe them how to test such a thing. -
Writing the tests before the actual code forces you to think about what your program should do before focusing on how to achieve it. This leads to more accurate and, generally, simpler code. -
Having a good test coverage in your code base increases your general trust on the written code and allows for easier and safer refactoring, if needed. -
If well written, tests usually work as documentation as well.
-
You're working on an API server project. -
You're working on an open-source library. -
Your project involves UI work and your language has the proper tools to write tests for it (e.g. rspec). -
You're writing an internal library with no UI pieces.
-
All of our projects are hosted on Github under Inaka's organization account. -
When starting a new project, create a new repository for you and add a brief description. -
For a more detailed guide on how to use Git/Github on your day to day tasks, refer to this Youtube Playlist by @elbrujohalcon .
-
To speed up the reviewing process. -
To help us write a good release note. -
To help the future maintainers of the code (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added.
-
Code must compile. All code merged must fully compile. This should be true for all commits in the history, because if there are commits that don’t fully compile, it will be more difficult to use git bisect. Partial commits with non-working code can be allowed if, prior to submitting the pull request, the branch is rebased interactively and the partial commits squashed into a single one. If desired, the work progress history can be retained in the extended commit message.
-
Grab a github issue and mark it as started (e.g. let's say you want to work on issue #123456 which is a story about editing this document). -
Open a branch with your name and the story id on it (e.g. elbrujohalcon.123456.edit.this.document ). -
Tag all your commits with the story id (e.g. git commit -m "[#123456] First edition" ). -
Remember you can have one or more commits per story, but no more than one issue # per commit. -
Once done, submit a Pull Request in github and assign one or more colleagues as reviewers. -
While you wait for the review, you can pick a different task and start this process over. If the PR is a blocker, warn whoever is responsible to communicate your block.
-
-
When opening a pull request to generate a page on which the changes can be discussed, make sure to use a draft pull request so that it is not merged. When the discussion concludes, mark it as "ready for review" and notify the reviewer so they can merge the pull request. -
The reviewer will then write comments on the PR and you'll have the chance to discuss them and/or fix them. -
When the review is done, your reviewer will merge your code into master. -
The name/story id branch should then be deleted.
-
It helps devs to spot small issues that would've gone undetected without a review. -
It keeps the general knowledge of the projects shared between, at least, two people. -
It's a great way to spot and learn useful practices and to start defining guidelines. -
It allows automatic code-style checking to be performed by special tools, like elvis and houndCI. -
It keeps a nice and shinny git history that let us move back and forward in history and understand what happened and why during the course of the project development.
-
Adopt a positive attitude! -
Try to evaluate the actual code (Is it easy to understand? is it maintanable? Are the right data structures being used? Are the variable and function/method names descriptive enough?, etc.) instead of the formatting. Ideally, the formatting should be validated by automatic tools, not by humans. -
As a reviewer, try to break your reviews into short sessions instead of one long time consuming ones. Also, try to have your own personal checklist of things to go over. -
As a submitter, keep your code short. The idea of a code review is to catch possible bugs, not show how much you can type in an hour. -
If your methodology is to collapse multiple stories into one PR, try to create at least one PR a day. Don't let your PRs grow over time, if you can avoid it. -
Don't forget to link PRs with issues by adding [#ISSUE-ID] to the PR description. -
You can easily reduce the burden of the whole workflow to just 3 commands using AW . -
The blog post "Effective Code Review" has a nice discussion of this topic.
-
Concentrate on the task at hand. Focus on your tasks above all. Deliver on time, but never compromise quality. Follow the processes, but within reason (don’t create a detailed design and write a manual for a code review project, for example). Document as much as required, and keep your colleagues informed about the project experience (issues, problems and solutions, technical forums, progress reports, meeting minutes to log customer requests). -
Don’t complicate things, keep your design as simple as possible. Make it work. Make it beautiful. Make it fast. In that order :) -
Respect your colleagues and customers. Write code so that other people can read it with pleasure. Respect the coding conventions pertaining your language. Don't hide the problems, be honest. Be nice to people. -
Never break the master branch. -
Version control your code – Git is your friend. -
Do code review – use pull requests. -
Build your code – don't create a pull request without testing it first. -
Use the right tool for the job When in doubt, prefer standard and proven tools over the last shouts of hipster fashion. -
Report the project’s progress. -
Share your knowledge and experience, and learn from others. Take notes on the wiki as you work. Share knowledge with your co-workers. Do post-project summaries. Write down stuff you have learned and make it publicly available.