Comments 60
Расскажите мне что делает это код?
Признаюсь, подумал что первый код понятнее чем второй, пока не прочитал правильный ответ. Такие дела.

Первый код действительно проще: два вложенных прогона массива и все. А второй — какие-то методы, которые где-то в другом месте применяются. Эти два куска кода просто некорректно сравнивать.


Но вот если мы возьмем первый код и попытамся понять, чем же там оперируют, тут вот, возникнут вопросы:
Что такое $u, почему не назвать $userData, может быть это что-то другое? и почему вдруг запрашиваем по 'u', неужели там так таблица названа?


Где-то в середине у нас есть $value и $value2 — это вообще как понимать? лезть в бд?
Потом череда магических чисел и какой-то ключ vis. Плохо спроектирована БД? исправь это функцией-геттером.


Ну и в целом, возвращаем мы true, false, а что становится ими — не известно.

Так неважно же "почему не назвать". Такая мысль мне даже в голову не пришла. Там в функции описана тривиальная логика, где нейминг не играет решающего значения — всё понятно и без него. Хотя да, с ним было бы лучше.


И в целом неважно что за vis — для начала надо понять общую логику и только потом разбираться откуда что берётся если понадобится.

Имелась ввиду смысловая бизнес нагрузка кода. Вы правда смогли понять что первый код итерирует массив private rules и если rule с id 11, то пользователю выставляется флаг visiter в true? :)

vis — по-голландски рыба. Определенно выставляют флаг, любит ли рыбу пользователь!

Первый код просто возвращает DB::get('u'), если я правильно понимаю, как работает PHP.

Второй foreach на каждой итерации перезаписывает переменную $value['vis'], можно с таким же успехом просто взять только последнее значение $value['p'], прогнать через if и записать $value['vis'] один раз.

$f и $key вообще не используются.
Так и есть, первый лучше. Хотя уверен, найдутся люди, которые поддержат второй вариант. Из чего следует, что нет одного «правильного» подхода к программированию, в этом и есть fail суждений автора статьи, который хочет всех под одну гребенку.

Автор вроде бы нигде и не говорит что есть какой-то один идеальный стиль. Как раз таки наоборот он говорит что стиль можно выбирать какой угодно. Главное чтобы все потом его придерживались.

Так в том-то и дело, что нет такого единого стиля, чтобы его все радостно придерживались. Поэтому всегда будут недовольные. Есть best practices, но они не навязывают единый какой-то стиль.

Что значит "его нет"? У вас вообще нет никаких правил? Даже неписанных? Даже чего-то вроде "локальные переменные пишем с маленькой буквы"? Или "не испоьзуем русский язык в названиях"? Наверняка же есть.


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

Автор статьи смешал в одну кучу оформление и организацию кода. Обычно, компании настаивают только на первом, например, вот Java Code Style от Google:
google.github.io/styleguide/javaguide.html. Он не такой жесткий, весьма краткий и вполне выполним для большинства разработчиков. Я придерживаюсь похожего подхода.

Автор же в примерах кода показывает, что он сторонник одного подхода и считает, что все должны ему следовать:
В этом примере мы просто берем весь репозиторий, потом используем builder, чтобы создать коллекцию, потом применяем фильтр.


Я считаю, что упорно настаивать на каком-то конкретном подходе принесет только вред и разочарование обоим сторонам. Зачем тогда было нанимать этого разработчика, ты же видел его код? Я сторонник подхода, что если код легко читается, не усложнен без надобности и легко сопровождаем(есть комментарии, логирование, возможен несложный рефакторинг), то он однозначно имеет право на жизнь и нет повода разводить тут алармы.
Я сторонник подхода, что если код легко читается, не усложнен без надобности и легко сопровождаем(есть комментарии, логирование, возможен несложный рефакторинг), то он однозначно имеет право на жизнь и нет повода разводить тут алармы.

А кто у вас решает удовлетворяет код этим параметрам или нет? Каждый для своего кода? Есть какие-то код-ревью и кто их тогда проводит? Есть кто-то вроде тимлида, который контролирует весь код?

Решает тот, кто апрувит изменения. Тимлид, естественно, должен быть ответственнен за весь код, выпускаемый его командой, но апрувить может любой опытный член команды.

Когда новый член команды начинает работать, его нужно ввести в курс дел и объяснить, что от него и в каком виде ожидают, этот процесс называется onboarding. Примерно за 1-3 месяца человек вьезжает в тему и начинает давать стране угля в нужном формате.
Тимлид, естественно, должен быть ответственнен за весь код, выпускаемый его командой, но апрувить может любой опытный член команды.

Тогда получается что если скажем для джунов/мидлов код сложно читается, то это никто и не заметит.
И самое главное вопрос в том насколько понятен будет этот код через два-три-четыре года когда будут новые "опытные" со своим новым стилем написания кода.


Когда новый член команды начинает работать, его нужно ввести в курс дел и объяснить, что от него и в каком виде ожидают, этот процесс называется onboarding. Примерно за 1-3 месяца человек вьезжает в тему и начинает давать стране угля в нужном формате

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


И можно кстати это делать поэтапно и не вводить все правил сразу за один приём. Тогда и сопротивляется народ меньше и привыкает проще.

Но имея адекватный code style это становится проще.

Ни один вменяемый разработчик не будет оспаривать нужность code style в каком-то виде. Более того, это сто раз описано во всех best practices.

И самое главное вопрос в том насколько понятен будет этот код через два-три-четыре года когда будут новые «опытные» со своим новым стилем написания кода.

А что с ним будет-то, с кодом? Он если написан несложно, то понятен будет и через 5 лет и через 50.

Тогда и сопротивляется народ меньше и привыкает проще.

Сопротивляются всегда излишним усложнениям, которые насаждаются излишне авторитарными тимлидами без оценки «а нахрена это нужно вообще».
А что с ним будет-то, с кодом? Он если написан несложно, то понятен будет и через 5 лет и через 50

Проблема в том что "несложно" это всё-таки очень субъективное понятие. Например если ты хорошо знаешь все бизнес процессы и свой код, то тебе не особо и надо писать комментарии или просто называть переменные/методы "говорящими" именами.


А вот через 5-10 лет разбирать такой легаси код новому человеку будет уже сложно.


Сопротивляются всегда излишним усложнениям, которые насаждаются излишне авторитарными тимлидами без оценки «а нахрена это нужно вообще».

"Излишне" это тоже достаточно субъективная вещь. И естественно палку перегибать не стоит. Но при этом я лично несколько раз был и по ту и по другую сторону баррикад когда поначалу сопротивлялись вполне себе полезным изменениям. И потом уже и сами признавали что они были полезными.

Проблема в том что «несложно» это всё-таки очень субъективное понятие.

Ну почему же, достаточно писать так, чтобы новый человек несложно разобрался в том, как работает Ваш код и смог его отладить/зарефакторить/развивать. А если при этом еще материться не будет — значит Вы сделали все как надо :).
Ну почему же, достаточно писать так, чтобы новый человек несложно разобрался в том, как работает Ваш код и смог его отладить/зарефакторить/развивать.

Вы извините, но то что вы перечислили это цель, а не "рецепт". С тем что надо писать именно такой код никто и не спорит. Вопрос в том как это делать.


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

Рецепт вытекает из этой цели — соблюдать KISS, управлять техдолгом, обучать членов команды, расставляться грамотно приоритеты между скоростью и качеством. Более конкретно — можно долго расписывать, но это возможно практически для любой фирмы и команды, если есть взаимопонимание с бизнес-людьми/инвесторами/владельцами.

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

Если честно до hard rules по code style я мог в свой код полуголовалой давности заглянуть и очень удивиться

Рандомными они могут лишь казаться, а по факту может оказаться, что когда-то была система, а при внесении изменений в код на неё забили, а может просто не знали или внедряли свою

что было в душе у того кто пишет код размазывая его по экрану как бог пошлет, рандомные отступы, рандомные переносы

Мысли о job security.

Ровно такая же ситуация, как Вы описали. Смотришь и диву даешься. Все пишут в шторме, у всех под рукой автоформатирование, которое можно легко настроить даже из predefined списка (psr1/psr2 как минимум). Так нет же, нужно писать так, как будто пробелы сами по себе в рандомное время появляются.

Деморализует ужасно — реально доходит до того, что я когда сажусь разбираться в таком куске кода — сразу накатывает уныние и желание пойти сменить место работы.
Статья — огонь. Прочитал на одном дыхании. Спасибо! (да, я работаю в ManyChat, но мне правда понравилось)

Вот как просто объяснить джуньорам что code style важен? По моему опыту процентов 90 его игнорируют, начинаешь вводить драконовские меры — начинают хныкать и обижаться. Что делать?

UFO landed and left these words here
Люди — не собаки, если так к ним относится — то ничем хорошим это не закончится.
UFO landed and left these words here
Есть и четвертый путь — адаптировать code style под команду, обсуждая каждый пункт. Все 3 указанные Вами пути по сути являются авторитарным видом управления. Он работает, когда у Вас есть заслуженный авторитет в команде и большинство решений являются верными. Часто приводит к большой текучке в команде и снижению общей продуктивности.
UFO landed and left these words here
Так это надо было сразу в Disclaimer писать, тут другие правила нужны, так как обычный индус спорить с начальством не привык, даже если он не собирается выполнять его приказы.
UFO landed and left these words here
Ну не знаю, в России даже в 90-х разработчики получали вполне прилично и существенно выше среднего. Где пожирнее — туда и идут, так всегда было. С горящими глазами молодняк и сейчас бегает, тем более на стартапах можно заработать больше, чем сидя спокойно в офисе.

Простые решения — это всегда хорошо, при условии, что они работают и оправдывают себя.
UFO landed and left these words here
все молодые кого знаю, пытаются вскочить в IT поезд, правдами и неправдами.

Потому что молодые знают, что дальше будет интереснее — роботы, AI, всеобщее подключение к сети. IT открывает огромные возможности, в Америке даже джуны на расхват, я уж не говорю о сеньорах, за которых бьются лучшие компании. Да даже в Москве выпускник вуза, умеющий программировать, может смело претендовать на соточку в месяц. В 90-е такого спроса не было…
Если я правильно понимаю что значит «на расхват», то в США джуны не на расхват.
Во всяком случае не в вебе.
Даже мидл с резюме средней паршивости может искать работу по пол года.
Да, если хорошо поработать над резюме и «интервью проходительными скилами», или если готов переехать в «заповедники программистов» то без работы не останешься, но, например, в Пенсильвании человек с 3мя годами опыта в JS+React+немного PHP+SQL (1 лет 10 в IT вообще) искал работу, емнип, год.
А вот на стройку его в тот же день взяли, при чём после звонка по первому обьявлению из бесплатной газеты. Вот это я понимаю «на расхват» :)
При чём когда он таки нашёл работу вэб разработчиком и уходил со стройки, ему предлагали те же деньги что-бы остался. Но там просто человек с руками и головой дружит.
Agree, but this IT train is getting longer, also due to the fact that its a very lucrative field, worlds best software development companies including GoodCore Software and others are paying the top dime for such skills.

Году в 2000-м квартиру в Питере можно было купить тысяч за 5 долларов. Где-то в других регионах, и того дешевле. При рейте долларов 20 в час вполне на квартиру хватило бы, не самую плохую на, например, Камчатке — сам продавал в то время.

Я сам из Питера. Где можно было купить в городе квартиру за такие деньги? В 1998 во время кризиса родственники удачно купили двухкомнатную квартиру в строящемся доме благодаря внезапному возврату долга. Квартира обошлась в 10 тысяч, но там «окно» для подобной операции было в районе месяца. Когда рубль обвалился, а цены на квартиры ещё не выросли. Ни до, ни после такого не было.

Например, на Обводном, 7 минут от Фрунзенской, смотрел квартиру даже за 4200 не позже конца 2001. Полуподвал, ужасное состояние, но купить можно было.

А, ну это не квартира в полном смысле :) но я понял, что вы имеете в виду.
4. Автоматизировать приведение кода к единому code style из пункта 3 и тратить время на совсем другие вещи.
Джуну надо объяснять, для чего это нужно и важно, а если 90% его игнорируют, то может руководство — не Ваша сильная сторона и нужно немного поучиться или заняться другим? Впрочем, бывают очень жесткие code style из сотни пунктов, понятно, что адекватные люди его будут саботировать.
Тут примерно как с вождением машины, если человек совсем не понимает, то пока в столб не впечатается не поймет почему нужно за руль держаться и по полосе ездить. Я один раз особо упорного джуна перекинул на 2 недели в проект с лютым легаси. Одного дня хватило, остальные 9 чисто в воспитательных целях.
Драконовские меры — да. Чекинг стилистики и принципов один из пунктов ревью. Не должно быть конфликтов, должны быть написаны тесты, не должен упасть регресс, линтер должен быть зеленым. Культура прививается только контролем. Дети иногда бегают через дорогу, джуны иногда пишут код не по правилам. Задача наставника — научить и воспитать :)

Самый простой вариант это дать им переписывать на чистую или рефэкторить какой-нибудь легаси проект у которого вообще никогда не было никакого code style.


П.С. Это конечно если что-то подобное имеется в наличии.

Все же склонен считать, что программистов не стоит под одну гребенку чесать и настаивать на одном жестком подходе — это убивает интерес к работе у части талантливых ребят. Скорей всего они просто покинут такую команду. В большинстве случаев достаточно лишь нескольких правил к оформлению кода — длина строки, пробелы, оформление if/for/while и так далее.

У нас кодстайл внедряться начал мной после прихода на новое рабочее место. В плане кодстайла я немного параноик, поэтому был введен длинный список правил сначала на CodeSniffer, конфиге к шторму и MD файле со списком типовых архитектурных решений. По началу в шторме весь файл светился варнингами, а на ревью было по десятку замечаний. Некоторых это утомляло. Некоторые выступали против. Но, благо, начальство было на моей стороне, поэтому эта практика внедрялась все глубже и шире. В конечном итоге все привыкли писать сразу правильно. Потом подключили php-cs-fixer с пачкой правил, в том числе и самописных, и мы просто разом прогнали его по всему проекту, сделав код почти единообразным. В итоге скорость чтения и написания кода увеличилась у всей команды, а код-ревью стало гораздо более простым делом.
Талант можно проявлять в элегантных решениях, чем в общем-то и блещет наш тим-лид, создавая по-настоящему изящный код. А код-стал, как по мне, не то место, где можно выпендриваться.

У нас code style внедрялся с самого начала, еще с использованием венгерской нотации.
А потом было решено перейти на google code style.
Учитывая, что часть народа игнорирует рекомендации по стилю, а железной руки нет, получается ужасная каша из старого стиля, нового стиля и безстилья.
Тихий ужас и кошмар.

Не очень понятно зачем вам был нужен такой сложный и длинный путь, у нас в компании все намного проще. Не рискованные изменения по кодстайлу применяються автоматически при коммите, рискованные запусаются, но не применяються, а только выводятся на экран. На CI сервера происходит тоже самое, и пока код стайл не будет исправлен, данный мердж реквест не может быть смерджен.
По мимо этого еще есть phpstan который проверяет правильность самого кода, phpmd, phpcpd и многое другое.

Не то чтобы он был длинным и сложным. По большей части для решения проблемы нужно понимать причины, немного покопать интернет, немного свести, поэкспериментировать на уровне менеджмента команды. Вы описываете финальную реализацию. К этому всё и приходит, главное на берегу договориться что можно что нельзя, ruleset не обязательно должен быть объемным.
звучит не очень надежно когда система что-то делает у тебя за спиной
Вспомним 2 главные проблемы программирования? Инвалидация кеша и нейминг переменных.

А как же «off-by-1 errors»?
Статья отличная, спасибо. Собственно, главное преимущество использования единого стиля и жёсткого следования ему описано в той части, где вы говорите о времени, которое тратится на чтение кода. Пока разработчик разбирается в чужом (или даже своём старом) коде, пытаясь понять, что он делает, он не занимается непосредственно работой. Это время выброшено впустую. Чем больше такого кода, тем меньше эффективность его работы. Если выбранный стиль логичен и обоснован и поддерживается всей командой, повышается читаемость кода, а значит разработчику неважно, кто и когда его написал, и читал ли он его прежде. Поиск ошибок и написание новой функциональности значительно упрощается.
Пока разработчик разбирается в чужом (или даже своём старом) коде, пытаясь понять, что он делает, он не занимается непосредственно работой.

Не согласен. Это непосредственная работа, в большинстве случаев обязательная. Вопрос лишь в том, какой КПД у этой работы, сколько времени потребуется, чтобы разобраться в одной и той же по сути логики — в зависсимости от архитектуры, именования, кодстайла и т. п. время может различаться даже не в разы, а на порядки.


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

Безусловно. Я не имел в виду, что разработчик вообще не должен читать чужой код, я подразумевал, что он не должен продираться через код, тратя время впустую на попытки освоить чужой стиль (или отсутствие такового) и приспособиться к нему.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

26 June 2016

Location

Россия

Employees

101–200 employees

Registered

31 July 2019