7 Secrets of Maintainable Codebases • Adam Tornhill • GOTO 2016

แชร์
ฝัง
  • เผยแพร่เมื่อ 4 ธ.ค. 2024

ความคิดเห็น •

  • @BeneWil_MgmtConsultantBeiBG
    @BeneWil_MgmtConsultantBeiBG ปีที่แล้ว +4

    7 (+1) Secrets:
    #0 - Maintainable Code goes beyond Technology.
    #1 - All code is equal (...but some code is more equal than others.)
    #2 - Complexity isn't the problem (...at least not on its own.)
    #3 - Your brain is not your friend.
    #4 - Know your change patterns.
    #5 - (Most) Organizational Problems are mistaken for technical issues.
    #6 - Find your blind spots.
    #7 - Make it fun.

  • @corsaro0071
    @corsaro0071 2 ปีที่แล้ว +6

    Did a really good job in keeping secret those 7 secrets

  • @sunwicked
    @sunwicked ปีที่แล้ว +1

    Very interesting take.

  • @JeremyAndersonBoise
    @JeremyAndersonBoise 8 ปีที่แล้ว +11

    Fantastic talk, incredibly practical.

  • @a13ph0
    @a13ph0 8 ปีที่แล้ว +7

    To clarify implied: to support your decisions with data - test against your assumed hypotheses

  • @michaelharings9913
    @michaelharings9913 6 ปีที่แล้ว +3

    "Fun is virtually a guarantee that things get done."--nice!

  • @jordanstewart225
    @jordanstewart225 7 ปีที่แล้ว +5

    What if code isn't changed because it has technical debt? If isn't changed because it has technical debt, if would invalidate the hypothesis Adam said, "you should focus on removing technical debt from code that is changed a lot".
    Almost by definition, if code is being changed a lot is it easy to work with, and has low cognitive load on the developer. That could be because developers are familiar with that code, rather than the code itself is simple.

    • @sasukesarutobi3862
      @sasukesarutobi3862 3 ปีที่แล้ว +2

      You make a good point, but I don't think it's necessarily always the case that frequently-changed code is easier to work with. It may be the case that it's frequently being changed because a lot of bugs are getting reported there, or that the important features are there so the product managers keep pushing for changes, or even because it's a ball of code that contains a lot of important responsibilities within the program. Especially in these cases, the code may be quite complicated, but developer familiarity means that they're not going to change the structure to improve things - they'll just tip-toe in, change what looks like it needs changing to add the new feature, and then tell the product manager that they were warned that it might break. Or you'll get a new developer come on board and then have to spend a week just getting to understand how this service works before they can actually contribute any changes.

  • @jscancella
    @jscancella 7 ปีที่แล้ว +3

    Are there any automated tools that can help me do this myself?

    • @adamtornhill2546
      @adamtornhill2546 7 ปีที่แล้ว +4

      Yes, have a look at CodeScene which is free for open source: codescene.io/

  • @halfz3bra
    @halfz3bra 8 ปีที่แล้ว

    Could you please explain what is teh reasoning behind the use of Fractal Figures diagram? Wouldn't a regular pie-chart do alright?

  • @ChrisAthanas
    @ChrisAthanas ปีที่แล้ว +1

    9:46 it only took 56 victims before the police got a clue lol

  • @denisvorotyntsev5729
    @denisvorotyntsev5729 2 ปีที่แล้ว +2

    I like how he compared software engineers and sex offenders

  • @jordanstewart225
    @jordanstewart225 7 ปีที่แล้ว +1

    Gorilla videos:
    th-cam.com/video/vJG698U2Mvo/w-d-xo.html
    th-cam.com/video/IGQmdoK_ZfY/w-d-xo.html

  • @kpectbi
    @kpectbi 8 ปีที่แล้ว

    nice talk

  • @SeanFrancisNBallais
    @SeanFrancisNBallais 8 ปีที่แล้ว +4

    Common LISP is a great language.

    • @xnoreq
      @xnoreq 7 ปีที่แล้ว +2

      (s
      (u
      (r
      (e
      !)))))

    • @llothar68
      @llothar68 7 ปีที่แล้ว +1

      I tried to write a "tries" datastructure one. No it is not, the lack of syntax makes it unreadable. But as a toplevel assembly of components - the task that are never algorithmic complex - it might be useable.

  • @logiciananimal
    @logiciananimal 4 ปีที่แล้ว

    Tragedy of the commons type situation on the code parts that have had many different people change it.

  • @aimafirm
    @aimafirm 8 ปีที่แล้ว +15

    Can someone explain what the point of this talk is?

    • @tyleryang5858
      @tyleryang5858 8 ปีที่แล้ว +2

      +1

    • @thereGoMapo
      @thereGoMapo 8 ปีที่แล้ว +3

      from what I gather: applications of data analysis, forensics, psychology to software engineering.

    • @tyleryang5858
      @tyleryang5858 8 ปีที่แล้ว +1

      No offense, it's extremely difficult to understand his point.

    • @mangak4
      @mangak4 8 ปีที่แล้ว +7

      how to find hotspots and make your code more maintainable

    • @NielsBuus
      @NielsBuus 8 ปีที่แล้ว +8

      I agree. I must admit that I haven't watched the whole talk, but when he starts measuring the value of code refactoring based on diff frequency on the source code, my interest wanes. I think it's a pointless metric and it's even more pointless to apply it to individual files. If anything, it should be applied on the project as a whole and used to compare multiple projects to establish which one may benefit the most, because it's most active.
      The majority of time in programming is spent reading, understanding and reflecting on existing code. Refactoring, both at class level and at an architectural level, is about reducing the time you must spend to reason about the system to decide on a proper implementation of something new and reducing the risk of you getting that implementation wrong.

  • @edgeeffect
    @edgeeffect 2 ปีที่แล้ว

    Wasn't this old "GOTO" introduction SO much less annoying than the "boom bang zoom" of the newer intro.

  • @JonathanSambrook
    @JonathanSambrook 8 ปีที่แล้ว

    not arshitecture, but arkitecture

  • @beavbeast69
    @beavbeast69 8 ปีที่แล้ว +3

    3:02 Conway's Law give him credit!