Сообщение Re[9]: Есть кто здесь, кто требует у кандидатов github от 09.06.2019 9:06
Изменено 09.06.2019 9:23 okon
Re[9]: Есть кто здесь, кто требует у кандидатов github
Здравствуйте, jamesq, Вы писали:
J>Здравствуйте, okon, Вы писали:
O>>Тут путаница.
O>>Надо определить что есть ковнокод, я называю это не бажный код, а код который плохо читать и сопровождать.
O>>Например можно запилить весь код в одну процедуру main, а можно разделить на функции с хорошим названием, логически оба кода верные, с однаковым количеством дефектов,
O>>но первый вариант будет более проблемным с т.з. поддержки и сопровождения.
O>>А то что код содержит ошибки — это не говнокод, это не рабочий код называется, он может быть абсолютно красивым и понятным.
J>Я своими собственными глазами наблюдал ситуацию, когда сотрудник, когда ему поставили задачу по-быстрому кое-что сделать, и сообщить результаты вычисления программой.
J>Он накалякал бажный говнокод, и на голубом глазу преподнёс эти результаты как верные. А другой сотрудник начал строить далеко идущие выводы, на их основе. Там вообще шизофрения была.
Вполне возможно и бажный говнокод, тут важно понимать чтобы написать верную логику — обработать все ветки по которым может развиваться ситуация, придумать как решать их для конкретного решения
— это есть есть определенное необходимое время чтобы код был не бажным.
Поэтому нет смысла давать задание делать быстро , если требуемые кейсы не позволяют это сделать быстро.
Когда времени достаточно чтобы это все сделать — уже можно требовать не бажности кода.
J>Люди, затюканные KPI начали творить настоящий цирк, в погоне за мнимой производительностью.
KPI нельзя оценить по сделанной работе в настоящем, KPI можно оценить только в будущем, т.к. архитектурные проблемы или проблемы плохого кода они могут показать свою актуальность в будущем, если функционал написан, но плохо читается, при этом этот функционал больше никогда трогать не будут ( например программист написал отдельную функцию известного алгоритма, например Blur или QSort), то может он и прав что написал ее быстрее ( естественно в случае если алгоритм верен ) т.к. тут выгоднее написать быстрее и продать, чем красивее но не продать.
Всякие оценки красоты кода и правильности — опять же очень силен человеческий фактор, нет критериев для объективной оценки, особенно если коллектив подвержен разделению на группы конфликтующие.
J>Здравствуйте, okon, Вы писали:
O>>Тут путаница.
O>>Надо определить что есть ковнокод, я называю это не бажный код, а код который плохо читать и сопровождать.
O>>Например можно запилить весь код в одну процедуру main, а можно разделить на функции с хорошим названием, логически оба кода верные, с однаковым количеством дефектов,
O>>но первый вариант будет более проблемным с т.з. поддержки и сопровождения.
O>>А то что код содержит ошибки — это не говнокод, это не рабочий код называется, он может быть абсолютно красивым и понятным.
J>Я своими собственными глазами наблюдал ситуацию, когда сотрудник, когда ему поставили задачу по-быстрому кое-что сделать, и сообщить результаты вычисления программой.
J>Он накалякал бажный говнокод, и на голубом глазу преподнёс эти результаты как верные. А другой сотрудник начал строить далеко идущие выводы, на их основе. Там вообще шизофрения была.
Вполне возможно и бажный говнокод, тут важно понимать чтобы написать верную логику — обработать все ветки по которым может развиваться ситуация, придумать как решать их для конкретного решения
— это есть есть определенное необходимое время чтобы код был не бажным.
Поэтому нет смысла давать задание делать быстро , если требуемые кейсы не позволяют это сделать быстро.
Когда времени достаточно чтобы это все сделать — уже можно требовать не бажности кода.
J>Люди, затюканные KPI начали творить настоящий цирк, в погоне за мнимой производительностью.
KPI нельзя оценить по сделанной работе в настоящем, KPI можно оценить только в будущем, т.к. архитектурные проблемы или проблемы плохого кода они могут показать свою актуальность в будущем, если функционал написан, но плохо читается, при этом этот функционал больше никогда трогать не будут ( например программист написал отдельную функцию известного алгоритма, например Blur или QSort), то может он и прав что написал ее быстрее ( естественно в случае если алгоритм верен ) т.к. тут выгоднее написать быстрее и продать, чем красивее но не продать.
Всякие оценки красоты кода и правильности — опять же очень силен человеческий фактор, нет критериев для объективной оценки, особенно если коллектив подвержен разделению на группы конфликтующие.
Re[9]: Есть кто здесь, кто требует у кандидатов github
Здравствуйте, jamesq, Вы писали:
J>Здравствуйте, okon, Вы писали:
O>>Тут путаница.
O>>Надо определить что есть ковнокод, я называю это не бажный код, а код который плохо читать и сопровождать.
O>>Например можно запилить весь код в одну процедуру main, а можно разделить на функции с хорошим названием, логически оба кода верные, с однаковым количеством дефектов,
O>>но первый вариант будет более проблемным с т.з. поддержки и сопровождения.
O>>А то что код содержит ошибки — это не говнокод, это не рабочий код называется, он может быть абсолютно красивым и понятным.
J>Я своими собственными глазами наблюдал ситуацию, когда сотрудник, когда ему поставили задачу по-быстрому кое-что сделать, и сообщить результаты вычисления программой.
J>Он накалякал бажный говнокод, и на голубом глазу преподнёс эти результаты как верные. А другой сотрудник начал строить далеко идущие выводы, на их основе. Там вообще шизофрения была.
Вполне возможно и бажный говнокод, тут важно понимать чтобы написать верную логику — обработать все ветки по которым может развиваться ситуация, придумать как решать их для конкретного решения
— это есть определенное необходимое время чтобы код был не бажным.
Поэтому нет смысла давать задание делать быстро , если требуемые кейсы не позволяют это сделать быстро.
Когда времени достаточно чтобы это все сделать — уже можно требовать не бажности кода.
J>Люди, затюканные KPI начали творить настоящий цирк, в погоне за мнимой производительностью.
KPI нельзя оценить по сделанной работе в настоящем, KPI можно оценить только в будущем, т.к. архитектурные проблемы или проблемы плохого кода они могут показать свою актуальность в будущем, если функционал написан, но плохо читается, при этом этот функционал больше никогда трогать не будут ( например программист написал отдельную функцию известного алгоритма, например Blur или QSort), то может он и прав что написал ее быстрее ( естественно в случае если алгоритм верен ) т.к. тут выгоднее написать быстрее и продать, чем красивее но не продать.
Всякие оценки красоты кода и правильности — опять же очень силен человеческий фактор, нет критериев для объективной оценки, особенно если коллектив подвержен разделению на группы конфликтующие.
J>Здравствуйте, okon, Вы писали:
O>>Тут путаница.
O>>Надо определить что есть ковнокод, я называю это не бажный код, а код который плохо читать и сопровождать.
O>>Например можно запилить весь код в одну процедуру main, а можно разделить на функции с хорошим названием, логически оба кода верные, с однаковым количеством дефектов,
O>>но первый вариант будет более проблемным с т.з. поддержки и сопровождения.
O>>А то что код содержит ошибки — это не говнокод, это не рабочий код называется, он может быть абсолютно красивым и понятным.
J>Я своими собственными глазами наблюдал ситуацию, когда сотрудник, когда ему поставили задачу по-быстрому кое-что сделать, и сообщить результаты вычисления программой.
J>Он накалякал бажный говнокод, и на голубом глазу преподнёс эти результаты как верные. А другой сотрудник начал строить далеко идущие выводы, на их основе. Там вообще шизофрения была.
Вполне возможно и бажный говнокод, тут важно понимать чтобы написать верную логику — обработать все ветки по которым может развиваться ситуация, придумать как решать их для конкретного решения
— это есть определенное необходимое время чтобы код был не бажным.
Поэтому нет смысла давать задание делать быстро , если требуемые кейсы не позволяют это сделать быстро.
Когда времени достаточно чтобы это все сделать — уже можно требовать не бажности кода.
J>Люди, затюканные KPI начали творить настоящий цирк, в погоне за мнимой производительностью.
KPI нельзя оценить по сделанной работе в настоящем, KPI можно оценить только в будущем, т.к. архитектурные проблемы или проблемы плохого кода они могут показать свою актуальность в будущем, если функционал написан, но плохо читается, при этом этот функционал больше никогда трогать не будут ( например программист написал отдельную функцию известного алгоритма, например Blur или QSort), то может он и прав что написал ее быстрее ( естественно в случае если алгоритм верен ) т.к. тут выгоднее написать быстрее и продать, чем красивее но не продать.
Всякие оценки красоты кода и правильности — опять же очень силен человеческий фактор, нет критериев для объективной оценки, особенно если коллектив подвержен разделению на группы конфликтующие.