mastodon.world is one of the many independent Mastodon servers you can use to participate in the fediverse.
Generic Mastodon server for anyone to use.

Server stats:

8.1K
active users

#codereview

1 post1 participant0 posts today

“I reviewed Pirate Software’s Code. Oh boy…” (Coding Jesus vs Pirate Software e la situazione si fa eterna)

A quanto pare, il tizio del software pirata, Pirate Software, dopo la sua grande caduta dall’altare da cui predicava non è semplicemente finito sul colpo… bensì, la gente sta scavando. E oooh, se dalla terra stanno uscendo cose… e, in questo caso, incuriosiscono anche me, perché intrecciano due grandi mie passioni: il gaslighting, e lo sviluppo software; nella prima il signorino ha evidentemente appena fallito, mentre sembra che direttamente non sia proprio del mestiere, riguardo la seconda, che nel suo caso è nel campo dei videogiochi… 😰

In particolare, il signore è entrato in questioni con un certo Gesù del Coding (e i nomi in questa storia stanno diventando così surreali che davvero inizio a pensare al fatto che, nonostante tutto, viviamo proprio nel migliore dei mondi possibili…), che ha osato fare code review del suo giochino RPG, Heartbound (nome, ancora, scelto veramente a cazzo, visto che sul momento ho pensato fosse il gioco di Nintendo dello stesso genere e probabilmente in parte d’ispirazione, Earthbound; e pronunciati a voce anziché scritti, ovviamente, la differenza non la noterebbe nemmeno chi a differenza mia ha un cervello funzionante)… e ne è uscito fuori veramente da piangere come mai prima d’ora. 😿

Sostanzialmente, questo RPG (che dicono essere estremamente mid dal punto di vista del gioco in sé, ma non avendo voglia nemmeno di provare la demo non mi esprimo su ciò) sarebbe in sviluppo da una roba come 7 anni, avendo ricevuto finora tipo 20mila dollari di raccolta fondi, e non va avanti. Questo, a detta sua, è perché sta avendo problemi con la scrittura… ma invece no: è perché il suo codice è uno spaghetto di livello extraterrestre, molto semplicemente. Ah, e anche perché, invece di lavorare per davvero allo sviluppo, è ogni giorno in live a yappare o a fare gaming… e la cosa mi ricorda stranamente un altro sviluppatore indie a suo tempo ancora più perculato, ma non voglio divagare già ora… ☠️

Tornando al punto: Coding Jesus, in un suo video, ha preso tutti i frame dove si vedeva codice del gioco nelle sue live (che, per essere nel corso di mesi e mesi, sono sorprendentemente pochi), e lo ha semplicemente distrutto. Questa non è una code review che si può spiegare in due parole… ma, in breve, Thor (si, anche lui stesso ha un nome assurdo, per chi non lo avesse ancora afferrato…) dimostra praticamente di non afferrare i principi base di programmazione; il codice è completamente inmantenibile, ma a livello praticamente da meme. 🤥

https://www.youtube.com/watch?v=HHwhiz0s2x8

Il problema di tutta la storia, ovviamente, non è di per sé il fatto che questo qui sia un incapace patentato… ma che ha un ego smisurato, che ha praticamente mentito sulla sua intera carriera professionale (pur se non inventando cose di sana pianta, solo omettendo o manipolando alla grande i piccoli dettagli), che a riguardo di questo suo progetto racconta tutt’ora di continuo sempre e solo palle pur di non ammettere la tragica situazione reale che lo riguarda, e che in generale sembra essere ben più interessato a pavoneggiarsi che a fare quello che dice di voler fare! Oh, io sono la prima che dice che è assolutamente sacrosanto il diritto a creare anche la merda; fateli i giochi, assolutamente, pure se non sapete programmare… ma non fate la voce profonda per apparire più saggi di quello che siete davvero, vi prego! 😭

E boh, mi permetto persino una riflessione spaventosamente reale qui, perché nessuno sembra averla fatta: è specialmente curioso che, quando escono queste controversie riguardo sviluppatori indie, sono sempre sviluppatori di videogiochi. Non che ne escano tantissime eh — e, infatti, l’unico pensiero parallelo a questa storia che gira nella mia mente riflettendoci è che questo Thor è letteralmente il nuovo YandereDev per quanto mi riguarda, e non riesco minimamente a confutare questa mia ipotesi stellare — però boh, in altri casi esce poco… Sarà forse che, negli altri casi, da un lato è puramente il codice a parlare, mentre dall’altro i polli che donano migliaia di soldi sulla pura fiducia non ci sono? 🥴

The impact of file position on code review

arxiv.org/abs/2208.04259

arXiv logo
arXiv.orgFirst Come First Served: The Impact of File Position on Code ReviewThe most popular code review tools (e.g., Gerrit and GitHub) present the files to review sorted in alphabetical order. Could this choice or, more generally, the relative position in which a file is presented bias the outcome of code reviews? We investigate this hypothesis by triangulating complementary evidence in a two-step study. First, we observe developers' code review activity. We analyze the review comments pertaining to 219,476 Pull Requests (PRs) from 138 popular Java projects on GitHub. We found files shown earlier in a PR to receive more comments than files shown later, also when controlling for possible confounding factors: e.g., the presence of discussion threads or the lines added in a file. Second, we measure the impact of file position on defect finding in code review. Recruiting 106 participants, we conduct an online controlled experiment in which we measure participants' performance in detecting two unrelated defects seeded into two different files. Participants are assigned to one of two treatments in which the position of the defective files is switched. For one type of defect, participants are not affected by its file's position; for the other, they have 64% lower odds to identify it when its file is last as opposed to first. Overall, our findings provide evidence that the relative position in which files are presented has an impact on code reviews' outcome; we discuss these results and implications for tool design and code review. Data and materials: https://doi.org/10.5281/zenodo.6901285

Morning time is code review time. And like in >90% of the code I'm reviewing before merging branches it is like "Yeah, that is okay. Some small things we should change. But nothing what I would not merge and we can do it afterwards."

The one not falling into that category are mostly conceptual errors or misunderstood requirements. And they are often those we did plan rather quickly or we do not talk when something does not add up.

It's #CodeReview time at work, and I can't just hit "approve" on everything, that might look like I'm not paying attention. Thankfully I found a legitimate reason to request changes on one of the pull requests so I don't have to find something absurd to nit-pick about.

Fellow people in #softwareDevelopment: How do you do "#CodeReview post-processing", meaning what do you do with the review comments that either weren't (considered) directly actionable during the MR/PR (e.g. follow-up tickets) or contained general feedback/shortcomings that have to be addressed outside the scope of the MR/PR (e.g. improve our handbook, "replace this in the whole codebase", "we need to discuss this as a team" etc.)?

Код-ревью: борьба или мотивация?

Привет! Меня зовут Илья, последние 7 лет я занимаюсь фронтендом и наконец решил отметиться на Хабре. Стартую с темы, которая, как кажется, уже успела приесться, но всё ещё вызывает жаркие споры — код ревью (CR). Не смотря на сотни статей и мануалов, каждая команда подходит к этому процессу по‑своему. Хочется зафиксировать и осмыслить собственный опыт, показать, как мы подходили к настройке процесса в реальном проекте, и почему, на мой взгляд, код‑ревью не может быть универсальным , а должен опираться на контекст команды. В этой статье не будет технических деталей вроде рекомендаций по максимальному количеству строчек в diff‑е или формату названий коммитов. Я хочу подняться на уровень выше и поговорить о целях, ключевых факторах и реальных компромиссах которые встречаются в CR.

habr.com/ru/articles/914664/

ХабрКод-ревью: борьба или мотивация?Привет! Меня зовут Илья, последние 7 лет я занимаюсь фронтендом и наконец решил отметиться на Хабре. Стартую с темы, которая, как кажется, уже успела приесться, но всё ещё вызывает жаркие споры — код...

Каждому сотруднику по личному помощнику: как мы подружились с AI-ревью

Вы любите делать код-ревью? «Не могу дождаться следующего PR!», — ответит абсолютно никто. Понимаю! Ревью — штука необходимая, но давайте честно: утомляет, забирает время и ресурс, который можно потратить на другие задачи. Делегировать, казалось бы, хорошая идея… но кому? Личного ревьюера на полную ставку ни у кого нет. Меня зовут Александр Федотов, я руководитель группы разработки в «Лаборатории Касперского». В своей команде я уже не раз пытался упростить ревью: менял подходы, вводил правила, подключал автоматизацию. Но все равно ощущение такое, что можно сделать еще лучше. Тем временем, коллеги реализовали интеграцию Azure DevOps с внутренней AI-моделью ЛК. И вот одним морозным зимним днем, во время настройки каких-то доступов, я попал в раздел Manage Features, где наткнулся на неприметный пунктик Pull Request AI, который позволял воспользоваться преимуществами этой интеграции. Не теряя времени, я активировал фичу и стал счастливым обладателем раздела AI в каждом PR. С тех пор ревью стало другим. И теперь я не просто верю в автоматизацию — я ею пользуюсь и хочу поделиться с вами своими мыслями об этом.

habr.com/ru/companies/kaspersk

#ai #codereview #pull_request #c++ #c# #azure_devops

ХабрКаждому сотруднику по личному помощнику: как мы подружились с AI-ревьюВы любите делать код-ревью?  «Не могу дождаться следующего PR!», — ответит абсолютно никто. Понимаю! Ревью — штука необходимая, но давайте честно: утомляет, забирает время и ресурс, который можно...