68 Matching Annotations
  1. Jan 2024
  2. May 2023
    1. ake sure you are mentoring someone, always. Make sure you’re always mentoring others. And I have found that mentoring others gives me new perspectives on things. Because I may be telling them things, but I’m learning a lot while I’m telling them.


  3. Apr 2023
  4. Jan 2023
    1. ExportProcessControl

      This can (should) be parameterized—not just here, but in the procurement constructor.

  5. Sep 2022
    1. I have refactored the schema to use allOf, oneOf, and unevaluatedProperties, which not only dramatically shrank the file (1500 lines down to 845) but allowed a different approach consisting of a number of "mix-in" schemas grouping commonly used fields, which are then referenced throughout a set of object schemas.
  6. May 2022
    1. By offering to have a real-time technical discussion, you are reframing the code review process away from an 'instructor correcting student' dynamic and into a 'colleagues working together' mindset.
    1. Level 5: Stop the line. The highest level of code review comments. Borrowing the term from Toyota's manufacturing process this is when the code reviewer noticed something in the PR that signals a major defect.

      Stop the line - 5th type of MR comments

    2. Level 4: Infringement. This is where things get more serious, note that infringement means rules were broken. In this context, rules can mean a number of things, from the more obvious feature spec and framework rules to things like style guides and coding principles.

      Infringement - 4th type of MR comments

    3. Level 3: Suggestions. These can also be thought of as recommendations and alternatives.

      Suggestions - 3rd type of MR comments

    4. Level 2: Nitpicks. Usually, comments about grammar errors and minor stylistic issues/typos go there. The solution to the nitpicks is usually very obvious and if the solution is opinionated, the opinion is not strongly held. Naming a method foobarGenerator vs foobarFactory goes in here, and nitpick comments often start with Nitpick:.

      Nitpicks - 2nd type of MR comments

    5. Level 1: Clarifications. I also think of these as sanity checks, I may even start the comment with something like I may be completely off the base here... or Just to sanity check...

      Clarifications - 1st type of MR comments

  7. Jan 2022
    1. and if I think this is too boilerplatey, I can export a handler from some .js file and pass the error to that: <script> import { onError } from 'svelte' import { genericHandler } from '../my-error-handler.js' onError(genericHandler(e => { // code which is called first to try to handle this locally return true // we've handled it here, don't do anything else. }) </script>
  8. Nov 2021
    1. Abstract the whole queryCommandState / execCommand system into a store (or some wrapper that also holds a store) that has state like isBold and canMakeBold and a makeBold() function.
    1. The consumer component will barely change from our last example. The only difference is the way we'll get a reference to our store (since now the store is exported from the JS module):
    2. In order to use this, we need to use a little more advanced readable store. Here's your example updated for this:
    3. // our temperature is now a store with initial value 0 const temperature = writable(0); // now we don't need to change this function, the change will be propaged // by the store itself const getTemperature = () => { return temperature; }
    4. Here's how we would rewrite our callback example with a store instead:
  9. Jul 2021
  10. test-prof.evilmartians.io test-prof.evilmartians.io
    1. That's it! Just replace let! with let_it_be. That's equal to the before_all approach but requires less refactoring.
    2. That technique works pretty good but requires us to use instance variables and define everything at once. Thus it's not easy to refactor existing tests which use let/let! instead.
  11. Jun 2021
    1. I've seen (and fixed) Ruby code that needed to be refactored for the client objects to use the accessor rather than the underlying mechanism, even though instance variables aren't directly visible. The underlying mechanism isn't always an instance variable - it can be delegations to or manipulations of a class you're hiding behind a facade, or a session store with a particular format, or all kinds. And it can change. 'Self-encapsulation' can help if you need to swap a technology, a library, an object specification, etc.
    2. Also, Sandi Metz mentions this in POODR. As I recall, she also advocates wrapping bare instance variables in methods, even when they're only used internally. It helps avoid mad refactoring later.
    3. But sure, go ahead and enforce self-encapsulation if you like; it makes it easier to do memoization or whatever later on.
  12. Apr 2021
  13. Mar 2021
    1. The number one problem that I see developers have when practicing test-first development that impedes them from refactoring their code is that they over-specify behavior in their tests. This leads developers to write more tests than are needed, which can become a burden when refactoring code.
    1. Refactoring is a means of addressing the problem of software rot. It is described as the process of rewriting existing code to improve its structure without affecting its external behaviour.
    1. Unfortunately, given how widely used concat_javascript_sources is, this required changing a lot of tests. It would be nice if we could remove some of the duplication in these tests (so that similar changes would not require updating this many tests), but that can come in another PR.
  14. Feb 2021
  15. Jan 2021
  16. Dec 2020
  17. Nov 2020
    1. Refactoring at scale is challenging and a significant investment, so communicating the progress is important both from a business perspective but also as a motivational effect to developers. In this case we used a combination of complexity trend visualizations and Code Health Metric as shown in the preceding example.

      [[refactoring at scale]]

    1. I refactored quite a bit of tarball-fetcher now to use actual Promises and asyncawait instead of passing resolve / reject callbacks around. This makes the code quite a bit easier to follow in my opinion, but let me know if anything should be changed there.
    2. I know this is existing code but we can probably use this as an opportunity to "fix" it: it is discouraged to use the async exists method to check for a file and try operating on it.
  18. Oct 2020
    1. Derived data can move between being synchronous and asynchronous without modifying the components that use it.
    2. State can be replaced with derived data without modifying the components that use it.
  19. Sep 2020
    1. This is pretty good, but I don’t love that $contactStore.length bit. If we wanted to change the shape of the store from an array to a key-value store or something, we’d have to remember to update this component too. Instead, we can define a new derived store: contactCountStore. It’ll always track the count, which lets this component have less knowledge about the structure of the store. That refactor looks like this:
    1. When a component reaches such a size that this becomes a problem, the obvious course of action is to refactor it into multiple components. But the refactoring is complex for the same reason: extracting the styles that relate to a particular piece of markup is an error-prone manual process, where the relevant styles may be interleaved with irrelevant ones.
    1. Primitives are often used to “simulate” types. So instead of a separate data type, you have a set of numbers or strings that form the list of allowable values for some entity. Easy-to-understand names are then given to these specific numbers and strings via constants, which is why they’re spread wide and far.
  20. Jul 2020
    1. It would be nice if the tests weren't so implementation specific, but rather tested the essence of the functionality. I tried to make them less brittle but failed. To that end, re-writing all the tests in rspec would be (IMHO) a brilliant improvement and pave the way for better tests in the future and more flexibility in implementation.
  21. Jun 2020
    1. Prefactoring is the application of experience to the creation of new software systems. Its relationship to its namesake refactoring is that lessons learned from refactoring are part of that experience.
    1. Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality.

      First sighting: "non-functional attributes".

  22. May 2020
  23. Apr 2020
    1. If you'd just like to see refactorings without Quick Fixes, you can use the Refactor command (Ctrl+Shift+R).

      To easily see all the refactoring options, use the "Refactor" command

  24. Apr 2019
    1. What is code refactoring?Code refactoring means restructuring your existing code, in a way that improves the internal structure but doesn’t change its external behavior. This complex procedure is aimed at modernizing software. It is typically used to increase the system’s maintainability, enhance performance, scalability, security and so on. If performed well, it can help developers discover some hidden bugs or vulnerabilities in the system.Typically, refactoring is done in small steps, called micro-refactorings. Each of these steps is usually a tiny change to a source code that leaves the functionality of the system unchanged, it just makes the code cleaner and simpler. And if you do want to change some functionality of your code, it’s much easier to do with a clean, refactored code.