Телеграмм чат группы ctodailychat страница 9778

ну я про то, что если чувак плохой API задизайнил - то это бОльшая проблема, и её Сонар никак не решает

19:24пожаловаться #1

я в таких случаях стараюсь сверху вниз идти. Во-первых мы внедряли у себя API-first подход - когда сначала писалась схеме OpenAPI и из неё генерились классы для фронта и бека, и документация.
Тогда можно было хотя бы за изменениями API следить, а не пост-фактум находить каку-то уже случившуюся и проросшую дичь

19:25пожаловаться #2

Victor Stepankov in ctodailychat

плохой апи - безусловно, нужен человек

let myVar = 0
…
myVar = 123
switch(myVar) {…}

такое влёт, как и наверно любой линтер.
Из куба вспомнилось, что он ещё проверял как данные в переменные попадают, нет ли напрямую каких-то присвоений из гет-параметра, например

19:25пожаловаться #3

во-вторых, для больших новых штук писать простенький дизайн-док - не что-то большое, буквально 1-pager. И дальше его обсуждать - уже решает массу проблем

19:26пожаловаться #4

а дальше код - зависит от уровня разработчиков. Чем круче разработчик, тем меньше нужно ревьюить его код и в том числе поэтому тем быстрее он работает 🙂

19:26пожаловаться #5

СА

Почему по собственным-то, когда по чужим?

20:14пожаловаться #6

СА

Я был примерно в такой ситуации, три бэка, фронт и я. Ревьюил фронт сам, бэк попросил кидать на меня поменьше. К счастью фронт был на TS, сначала было сложно, но потом ничего, втянулся. StackOverflow, вот это вот всё. Пару раз даже удалось настоять на своём с приведением ссылок на документацию (в большинстве случаев выслушивал аргументы фронтовика и соглашался, что ему виднее).

20:18пожаловаться #7

Artificial Iv in ctodailychat

Понял, спасибо! Буду втягиваться, значит

20:19пожаловаться #8

СА

Есть мнение, что альтернатива - это переписывать неподдерживаемый код с нуля каждые два года. Дальше каждый сам считает свою экономику. Если у вас сто микросервисов на 2-5 KLOC каждый и 200 человек инженеров - то наверное можно и без ревью, пусть у эксплуатации голова болит.

20:21пожаловаться #9

СА

Я просто поделился своим опытом, не факт что он оптимальный. Может быть экономически имеет смысл привлекать раз в неделю-две внешнего эксперта на 4-6 часов ревью, может быть проводить дизайн-ревью, когда фронтовик верхнеуровнево 15-20 минут рассказывает словами, как он будет делать каждую задачу.

20:23пожаловаться #10

Timur Valiev in ctodailychat

А ещё часто чем выше по лестнице разработчик тем меньше кода и больше 1-pagers🥲

21:29пожаловаться #11

Max Syabro in ctodailychat

А напомните чекер английских текстов, пожалуйста