Кто-то уже шутил, что если менеджеры научатся внятно формулировать задачи, то всех разрабов можно заменить на АИ. Именно поэтому разрабы в безопасности
Про это было в книге Мартина clean code. Ей уж много лет.
Чтобы ИИ справлялся с кодингом, надо не только хорошо формулировать задачи, но ещё и сделать исчерпывающую документацию. А это ещё сложнее.
в реальной бизнес разработке от силы процентов 10-20 описывается документацией, и такие замечательные вещи как код ревью и прочее тоже обычно пропускаются
Ты сейчас описываешь стартап на 5 человек. Это далеко не весь реальный бизнес.
Конечно, есть говно-проекты, написанные даже без тестов, и они реально работают. Но при отсутствии документации все упирается в персоналии. Вместо шаринга документов приходится рассказывать что и как работает новым членам команды. Отсутствие лида может серьезно затормозить проект, а человек может умереть/заболеть/выгореть. Ну по поводу ревью и так и вообще странно. Если 10 команд работает, код оунеры не нужны? Джунов на проектах не бывает?
Вообще я говорил про сервисы, вроде aws. Документации много, но не хватает, как по мне. Многое приходится просто пробовать.
У aws документации много. Иногда она дублируется, иногда нужная инфа закопана где-то в ебенях, иногда не в ебенях ложная информация, а в ебенях правильная
У нас огромный проект, документация вроде и есть, но когда что-то идёт не так - всё равно нет готового ответа и надо думать, проверять, чинить; код ревью есть, при чём с кучей автоматических проверок и обязательными голосами 2-х старших специалистов - всё равно некоторые из них даже не смотрят в задачу и просто оценивают код, так что ошибки выплывают постоянно, хотя код и выглядит нормально. Моё мнение, что важен не сам факт наличия определённых практик, а их смысловая нагрузка: пишешь документацию - пиши понятно и коротко, проверяешь код - хотя бы прочти в 2-х словах, что он должен делать.
Ну хз, вникать в чужую задачу на большом проекте такое себе: ты же в душе не ебёшь как вот этот вот кусок говна работает. Проверил что код логично без технических багов написан и норм, бизнес функционал и правильность проверят QA.
Мы делаем ревью. Мой сосед моя попа дырка боль. Я отправляю на ревью. Он отправляте на ревью. Я пишу комментарий. Он пишет комментарий. Через неделю мой PR смерджин. Его - нет. Радостно.
Как сказал чел выше это скорей мелкие проекты на несколько рыл или стартапы. На больших, дорогих проэктах все иначе. Там даже микро-фичи на полтора часа работы обкладываются 50 страницами документации, которые проходят все этапы проверок и подтверждений от бизнесса до QA. Код ревью проверяются вплоть до строчки, даже к комментариям проявляют внимание. И оно не мудрено, ведь есть проекты в которых, реально, одна херовая строчка кода от нерадивого джуна может привести к потере миллионов денег.
По моему опыту - вообще похую. В гугло-яндексах я конечно не работал. Но в относительно крупных коллективах побывать опыт имелся. Документация фрагментарна, устарела, раскидана по 5 местам, код ревью в 90% чистая формальность и даже отсутствие тестов - это вполне себе норма для относительно крупных софтверных компаний. Чаще всего последним носителем сакральных знаний является единственный человек, которого уже все заебало, и он уже пару лет подумывает уволиться вслед за всей предыдущей командой.
p.s. там еще его подпись LS
p.s.s. а оригинальный твит вообще из 2017 года, что добавляет контекста, ибо тогда нейронки были совсем слабые и эту табличку можно с 99% вероятностью трактовать как рофл, а не угрозу, особенно зная, как Лайнус все эти годы вел свой бизнес
Блин, те мне не послышалось что он энтони назвал женским именем Эмили, я то думал ну пранк, или оговорка, или я упустил когда начали говорить про другого сотрудника, а оно вон как
LaurieWired O
@Lauriewired
Follow
OS internals books are wild
Contents____________________________________
9.4 Process Primitives..............
9.4.1 Having Children...........
9.4.2 Watching Your Children Die.
9.4.3 Running New Programs______
9.4.4 A Bit of History: vforkt).
9.4.5 Ki
Отличный комментарий!