Оцените уровень профпригодности программиста
неактуально
неактуально
жсФиддле почему-то это вариант не воспринял, положил результат сюда: demenkov.dp.ua/dou
Затянул с вариантом, но был несколько занят в основном проекте. Хотя, тут и без меня стало нескучно :)
4) «слабый уровень» — тупа відмазка, ти або рилом не вийшов, або не потрапив у з/пл вилку, або найшли дешевшого тушканчкика, або замолодий/застарий, або + овер 100500 причин для відмови.
Так що рев"ю діло чисто суб"єктивне (одному більше функці, іншому тре більше класів, третьому подавай правильне форматування, четвертому яксь конструкціяочі муляє, 5й скаже що в тебе стиль ацтой, 6й на JS так не пишуть".Критеріїв чітких нема і тут із Біблією, ніби Святе Писання одне, а сект і коніфесій море і кожен трактує по своєму.
Якщо хочеш нормальне рев"ю, то піди до людини, якій ти довіряєш і вона є авторитетом і зуби з«їла в цікавому тобі напрямі, тобто ти будеш впевнений, що вона не буде хизуватися своїм ЧСВ, а вкаже на реальні проблеми.
в целях личного самосовершенствования прошу желающих покритиковать код и ткнуть носом, как нужно было в такой задаче показать «сильный уровень».
Це не по адресу. Тут такого наплетуть, що вуха зів"януть, так як ДОУ тепер більше схожий на філіал вконтаках, тільки діти постарше із нахилом до кодування.
по мере практики читания и написания вырабатывается некоторый ессенс виденья того что хорошо, а что плохо.
в целом согласен. для себя нашел полезной эту многократно упоминавшуюся книжку www.google.com.ua/... clean code pdf — простые и полезные советы
щоб добре код писати тре багато доброго коду читати
Треба ще й розуміти прочитане. Знати відповідь — чому написано саме так, а не інакше. Хоча для початку да, згодиця і «роби як ось той»
у друкованих виданнях є редактори — в ІТ щось не зустрічав
І редактори теж мають різну кваліфікацію. Чим відоміше видавництво, тим більша ймовірність що видавництво найме більш кваліфікованого редактора, чим невідоме, маленьке.
в інженеріє стандарти, в ІТ кожен «сам собі режисер»
в IT також є стандарти. Треба розуміти що програмування відносиця до проектної діяльності. І тоді стане зрозумілим що немає суттєвої різниці з проектною діяльністю і у інженерії
Буває і тупою відмазкою.«слабый уровень» — тупа відмазка
Але такі віпадкі не відміняють різниці між людьми у талантах, і просто — професійному досвіді та навичках. Ви ж не будете стверджувати что Кличкам просто везе, а їх супротивники — просто рилом не вийшли?
Так що рев"ю діло чисто суб"єктивне
Так. Але книжки одних авторів продаюця, а інших — ні.
Критеріїв чітких нема
У багатьох явищах немає чітких критеріїв. Це не означає що їх взагалі нема ніяких.
Судя по коментариям, код по ссылке уже значительно подправлен — никаких 100 строк неотформатированного яваскрипта, который надо было разбивать на кучу ф-ций я не вижу. Было бы неплохо выложить «как было», что бы можно было сравнить с тем «что стало»... если, конечно, это еще кому-то интересно...
Судя по коментариям, код по ссылке уже значительно подправлен
Нет, такой же, про 100 строк — это гипербола.
который надо было разбивать на кучу ф-ций я не вижу.
А я, сходу, вижу 4 функции, обслуживающие создание: a, menu, deleteButton, updateButton; это грубо так, в общем там до 10 функций спокойно можно вынести.
А я, сходу, вижу 4 функции, обслуживающие создание: a, menu, deleteButton, updateButton; это грубо так, в общем там до 10 функций спокойно можно вынести.А нужно ли?
С точки зрения такой элементарной задачи, которая была поставлена
Потому что потом поставят задачу добавить кнопку № 3.
С точки зрения компактности и читабельности — существующий кусок кода 1у ф-цию лучше, чем разнесенный в 10 ф-ций, которые вызываются по одному разу.
Рылли?
Если интервьюеры хотели именно это (способность писать ф-ции) то они могли бы нанять любого бомжа с улицы — он бы им писал код за еду.
Интервьюеру надо хороший разработчик, который будет писать качественный (легкоподдерживаемый) код. А не добавить еще 5 строк к методу на 20 строк, когда попросят добавить кнопку № 3.
Ну, можно было бы вынести часто выполняющиеся операции в отдельные, более компактные методы, вроде document.createElement(...) в function get(id) и document.createElement(...) в function create(type)
Мдяяя... Вместо такого:
var a=document.createElement(’div’); a.className=’myblock’; a.style.top=y-2+’px’; a.style.left=x-2-(body.clientWidth-300)/2+parent.scrollLeft+’px’; a.setAttribute(’title’,’no name’); a.setAttribute(’description’,’no description’);
Надо было писать
createMarker(); // а не просто create(type)
Вот это по вашему хуже читаетсо:
if(isImg(elem)) { parent.appendChild(createMarker()); } else { if(isMyBlok(elem)) { // возможно isMarker() var menu=createBaseMenu(); // начало создания меню var deleteButton=createDeleteButton(); var updateButton=createUpdateButton(); menu.appendChild(updateButton); menu.appendChild(deleteButton); //все создание меню надо вынести еще в одну функцию body.appendChild(menu); } }
Оговорка № 2: Надо что-то сделать в appendChild, мо как-то чейнинг прикрутить, но мне лень думать как.
Рылли?
Оффкоз!
Интервьюеру надо хороший разработчик, который будет писать качественный (легкоподдерживаемый) код.
...а так же читать мысли менеджмента? (хотя, как дословно звучала задача не знаю, так что могу быть неправым по этой линии дискуссии)
Мдяяя... Вместо такого:
var a=document.createElement(’div’);
a.className=’myblock’;
a.style.top=y-2+’px’;
a.style.left=x-2-(body.clientWidth-300)/2+parent.scrollLeft+’px’;
a.setAttribute(’title’,’no name’);a.setAttribute(’description’,’no description’);
Надо было писать
createMarker(); // а не просто create(type)
А где тело метода createMarker()? Похоронено? Или оно само писаться будет?
Вот это по вашему хуже читаетсо:
if(isImg(elem)) {По моему, это просто хуже. И вот почему:
parent.appendChild(createMarker());
} else {
if(isMyBlok(elem)) { // возможно isMarker()
var menu=createBaseMenu(); // начало создания меню
var deleteButton=createDeleteButton();
var updateButton=createUpdateButton();
menu.appendChild(updateButton);
menu.appendChild(deleteButton); //все создание меню надо вынести еще в одну функцию
body.appendChild(menu);
}
}
С этой точки зрения, кстати, приведенные методы get(id) и create(type) улучшили бы читаемость кода. Банально, за счет уменьшения кол-ва букв основного алгоритма.
Надо что-то сделать в appendChild, мо как-то чейнинг прикрутить, но мне лень думать как.
Зачем?? Только ради понтов перед интервьюерами? «лень думать как» — яркое свидетельство того, что результат не оправдывает стоимость реализации.
Кароче, не надо раздувать простые задачи, до уровня фреймворков там, где это никому нафиг не надо. См. dou.ua/...mns/kiss-yagni
А где тело метода createMarker()?
ВСЕ РАВНО надо будет залезть в каждый метод
т.е. можно прочитать весь код за раз
В том то и дело что это не нужно. Если надо вносить изменения в процедуру создания кнопки «Удалить» (добавить конферм), то не нужно читать код кнопок «Обновить», не надо знать как создается вся форма целиком.
О каком повторном использовании может идти речь,
Я говорил что-то про повторное использование? Где? Разделение на функции решает задачи: читабельность, абстракции, удобства расширения функционала, удобство тестирования (уда в тестировании 44 строк :) )
Или вы заранее можете предугадать, какие свойства надо будет установить кнопке № 3?
А вот тут уже я вам советую не просто
А посмотреть что эти букавки значат.
:))))С этой точки зрения, кстати, приведенные методы get(id) и create(type) улучшили бы читаемость кода. Банально, за счет уменьшения кол-ва букв основного алгоритма.
Что делает следующий код:
create(’div’, params)
А этот:
createEditingForm(params)
Во втором случае больше букав, но посмотрев на вызов можно сказать для чего он надо: создать форму редактирования. В первом же случае? Вы создаете контейнер с параметрами? Или как это можно прочитать?
Только ради понтов перед интервьюерами?
Ради того чтобы убрать переменные, то есть уменьшить количество состояний (увеличив надежность) и уменьшить дублирование информации:
var deleteButton=createDeleteButton();
2 раза написано deleteButton.
«лень думать как» — яркое свидетельство того, что результат не оправдывает стоимость реализации.
Нет, это свидетельство того что я уже давно не использовал ДОМ-АПИ на прямую, и у меня нет желания его вспоминать для поговорить на форуме. Надо будет работать без шаблонизатора и/или джКвери, открою МДН.
Угу, не надо. И не надо недооценивать задачи.Кароче, не надо раздувать простые задачи, до уровня фреймворков там, где это никому нафиг не надо.
На интервью, такой код допустим, в «домашнем задании» — нет. «ДЗ» демонстрирует ваш стиль кодирования, и 100500 строк на метод — это провал, поскольку это значит что и в реальном проекте вы будете так же писать, а в реальном проекте от такого кода может требоваться утилизация.
ОМГ
А посмотреть что эти букавки значат.
Я-то прекрасно знаю, что означают аббревиатуры KISS и YAGNI. А судя по тому, что вы тут предлагали, как раз вам и следует еще несколько раз вдумчиво перечитать эту статью и определения этих понятий...
:))))
«-» понятнее чем «private»? «+» понятнее чем «public»?
Что делает следующий код:
create(’div’, params)
А этот:
createEditingForm(params)
Откуда вы взяли params — я не знаю. Вот что я имел ввиду:
document.getElementById("content«).onmousedown = function(event) { event = event || window.event; //... var parent=get(’content’); if (event.pageX == null && event.clientX != null ) { //... } if(elem.id==’img’) { var a=create(’div’); //... parent.appendChild(a); } else { if(elem.className==’myblock’) { var menu=create(’div’); //menu.className=’mymenu’; //.... var deleteButton=create(’button’); //deleteButton.innerHTML=’Delete’; //.... var updateButton=create(’button’); //updateButton.innerHTML=’Save’; //... //... elem.setAttribute(’title’, get(’name’).value); //... menu.appendChild(updateButton); menu.appendChild(deleteButton); body.appendChild(menu); } } } function create(type){ return document.createElement(type); } function get(id){ return document.getElementById(’content’); }
Но опять же, так МОЖНО сделать(чисто ради удобства), но НЕ обязательно! Ничего страшного не будет, в принципе, если сто раз использовать document.getElemntsById(...)
Ради того чтобы убрать переменные, то есть уменьшить количество состояний (увеличив надежность) и уменьшить дублирование информации:
Щито? Какие переменные? Какая ТУТ надежность? И тем более, какое там дублирование информации? ...В обычном разбиении на методы? Вы мой аргумент «Выносить в отдельные ф-ции надо код, который будет использоваться неоднократно» вообще игнорируете, как я вижу... вся ваша декомпозиция — это просто вынос кода в одноразовые методы, которые потом никому отдельно не нужны. Я бы это назвал «предварительной оптимизацией структуры кода». Повысит ли это читаемость кода или нет — в ДАННОМ конкретном примере — вряд ли. Я понимаю, если бы было действительно >100 строк кода. Но код автора топика достаточно мал, что бы вместиться в одну ф-цию, без ущерба читаемости(ИМХО, так и быть)). Если речь идет о дальнейшем расширении кода, то никто не мешает выносить его отдельные куски в методы, по мере роста кол-ва строк! Это элементарнейший рефакторинг, который целесообразнее всего проводить В ПРОЦЕССЕ развития этого конкретного метода! И никакие аргументы меня не убедят в обратном — можете даже не спорить на этот счет)
Да, но только не надо к каждой конкретной задаче искать обобщенное решение.И не надо недооценивать задачи.
Требуемый уровень гибкости должен быть понятен из условия задачи. А то в случае «преувеличения степени абстрактности», можно очень легко напороться на закон дырявых абстракций...
100500 строк на метод — это провал
Так если бы 100500 — то конечно провал, кто ж спорит!) Но в том то и дело, что тут даже 50 не набирается.
Откуда вы взяли params — я не знаю.
Повторяю вопрос: Какую логическую функцию выполняет следующий код:
create(’div’, params)
Ваши предположения?
Какая ТУТ надежность?
Не возможность удалить поле у объекта deleteButton, по причине отсутствия на него ссылки. Соответственно если «кнопка не работает», то ошибка с вероятностью 99% в функции createDeleteButton, а она всего 5 строк, а не 50 (как в исходном коде), или 5+11 (как в том что я написал вверху).
И тем более, какое там дублирование информации?
var deleteButton=createDeleteButton();2 раза написано deleteButton.
Вы мой аргумент «Выносить в отдельные ф-ции надо код, который будет использоваться неоднократно» вообще игнорируете
Игнорирую, ибо это не аргумент, а утверждение. При том не всегда верное.
Это элементарнейший рефакторинг, который целесообразнее всего проводить В ПРОЦЕССЕ развития этого конкретного метода! И никакие аргументы меня не убедят в обратном — можете даже не спорить на этот счет)
Когда надо будет исправить метод на 500+ строк, где одна переменная переустанавливается несколько раз, вы сами поймете, но будет позно :)
Так если бы 100500 — то конечно провал, кто ж спорит!) Но в том то и дело, что тут даже 50 не набирается.
И какой же для вас допустимый размер метода? Обычно считают около 5 строк — до 10; 15+ — это уже большой метод.
Ваши предположения?
Могу только предположить, что этот ваш create(’div’, params) должен создавать объект и присваивать значения его полям, выбирая их из словаря params... и что?
Когда надо будет исправить метод на 500+ строк, где одна переменная переустанавливается несколько раз, вы сами поймете, но будет позно :)
Если вдуматься во фразу:
Это элементарнейший рефакторинг, который целесообразнее всего проводить В ПРОЦЕССЕ развития этого конкретного метода!
...то можно обнаружить, что методов в 500+ строк, при таком подходе, просто не будет существовать! ...внезапно, правда?))
Обычно считают около 5 строк — до 10; 15+ — это уже большой метод
Ага, а потом черт ногу сломит пробираться через дебри заср*ного по уши такими методами классов, когда autocomplete предлагает выбрать из 100500 позиций приватных методов, а девелоперы будут плеваться, читая хитроумные названия из 10+ слов. Я, конечно, сгущаю краски, но тем не менее... ))
а девелоперы будут плеваться, читая хитроумные названия из 10+ слов.
возражу. по личному опыту короткие и очень короткие имена, не несущие смысловую нагрузку раздражают гораздо больше, чем осмысленные, пусть даже они и состоят из 10+ слов. если для понимания логики нужно рыскать по коду аки раненная лань, это не есть гут.
кхм. в языках с динамической типизацией, вроде JS, о типе возвращаемого значения действительно остается лишь предполагать. вас не смущает, что разработчики языка обозвали метод createElement(), а вы всего лишь create()?Могу только предположить, что этот ваш create(’div’, params) должен создавать объект...
я исходники не смотрел, смотрю лишь фрагменты. а смысл должен быть понятен даже по фрагментам. имхо.
возражу. по личному опыту короткие и очень короткие имена, не несущие смысловую нагрузку раздражают гораздо больше, чем осмысленные, пусть даже они и состоят из 10+ слов.
Я как бы не имел ввиду вопрос выбора длины имени метода...
Нет не смущает, по крайней мере в ЭТОМ конкретном случае.всего лишь create()?
Потому что он заводится исключительно ради удобства и его целью является, всего лишь, немного сократить часто повторяющуюся конструкцию document.createElement(’div’), и все!
а смысл должен быть понятен даже по фрагментам. имхо.
Метод в одну строчку сразу должен бросаться в глаза как фрагмент кода, имхо)
и что?
А то что вы не угадали :) И поэтому вам надо будет прочитать тело метода (а оно как правило более 10+ слов :) ), а при правильном именовании, только название.
что методов в 500+ строк, при таком подходе, просто не будет существовать!
Чисто не там где убирают, а там где не мусорят ©
Я, конечно, сгущаю краски, но тем не менее... ))
Похоже у вас проблемы с пониманием, повторяю второй раз и медленнно:
И какой же для вас допустимый размер метода?
А то что вы не угадали :)
А то что вы его вообще от балды взяли (а значит и то, что я не угадал — тоже от балды) имеет значение? :)
Если ограничения на размеры методов не прописаны в code convention, то в общем случае, с моей точки зрения, их нет. Размер метода — это скорее следствие и показатель дизайна/имплементации, чем требование, и может быть обусловлено другими ограничениями и ориентирами, вроде «код метода должен помещаться на экране», «надо писать максимально компактный удобочитаемый код», «надо форматировать код согласно принятому code convention» и др. Все зависит от специфики проекта.И какой же для вас допустимый размер метода?
Если какой-то конкретный метод занимает 50 строк, то это может быть сигналом о необходимости проведения рефакторинга. С другой стороны, в WinForms, например, метод InitializeComponents(), который генерится дизайнером форм, может занимать и 500 строк — но ведь никто в здравом уме не будет его пытаться впихнуть в правило
А то что вы его вообще от балды взяли (а значит и то, что я не угадал — тоже от балды) имеет значение? :)
Hskkb^
Что делает следующий код:
create(’div’, params)
А этот:
createEditingForm(params)?
Если ограничения на размеры методов не прописаны в code convention, то в общем случае, с моей точки зрения, их нет.
Вот так и появляютсо методы на 500 строк :)
Если какой-то конкретный метод занимает 50 строк, то это может быть сигналом о необходимости проведения рефакторинга.
То есть таки есть — 50 строк. Но его трудно рефакторить, у меня на мониторе 31 строка помешаетсо (с включенными отладчиком и тд). Мо таки скинем немного ;)
метод InitializeComponents(), который генерится дизайнером форм
И не предназначен для того чтобы его читали, правили!
Эта ветка — лучшее, что есть на этом форуме. Люди не отрезающие важность правильных наименований, однотипные копипаста кейсы, это ж просто кладезь сеньоров.
Да еще усиленно спорят, например, с вами, Богдан. Надеюсь, вы троллинга ради, а не потому что в интернете кто-то не прав. Ибо аж хочется начать носить очки, чтобы их снять и протереть глаза при просмотре постов в этом топике.
Коментар порушує правила спільноти і видалений модераторами.
Или в сложной системе вы бы так же одобрили подобный подход?
люди, не пишите свои варианты кода!!! — я сейчас перерабатываю этот пример, скоро покажу результат с учетом конструктивных замечаний, давайте соблюдем чистоту эксперимента.
Код write-only. Я даже читать не стал — просто стена текста. ИМХО уровень джуниора. Как минимум надо отформатировать код ньюлайнами и разнести по функциям, а там уже и почитать можно будет и проанализировать реализацию.
Но особо меня поразил код Мухи ниже. И это один из главных противников
И это один из главных противников
«23-летних синьоров», а сам пишет такое...
Ему можно, ЦПП головного мозга очень плохо лечетсо
Стыдно, господа инженеры!
Кодерок Формошлепов (aamartynenko), с возвращением на ДОУ! Как дела в МСе? Как Париж?
Я вернулся, уже год как. МС очень разочаровал =) Собственно Франция тоже разочаровала
разочаровал
Бложик ваш вроде сдох, вы где-то писали подробнее об этом? Мо на ДОУ напишете?
Хотел когда-то написать да передумал. В кратце — майкрософт стал очень унылым. По крайней мере тот где я был. Менеджмент бездарный, код гoвнo, лизня жопы приветствуется больше чем все остальное. Ну и плюс мне менеджер попался — земляк из Донецка. Редкое чмо. Во Франции высокие цены, низкие зарплаты после налогов и еще 100500 причин вернуться сюда. Прошел год как я вернулся и я очень рад что я это сделал. Освоил кучу всего нового и участвую в невероятно интересном проекте. А в МСе так бы и гнил на должности SDET тестируя гoвнoкод на T-SQL...
Ну и SDET это конечно уныло.
«Знал бы прикуп — жил бы в Сочи». Но после всего этого я в МС даже в Редмонд в крутой проект не хочу. Слишком уж гнилой он внутри.
так надо было спросить :) хотя меня многое устраивало, я даже думал вернуться ...
Так вроде ж предупреждали что на стартовую позицию и SDET и не в главный офис это не айс совсем
Интересно, а как вы затраты на переезд возвращали, ведь для Европы кажеться если уходишь раньше чем через год то нужно компенсировать затраты и там вроде по МСовким бюджетам порядка 30к может насобираться, неужели Украинский работодатель заплатил?
Стыдно, господа инженеры!
Стидно не коли видно, а коли нема що показати.
— Я же, дуся, человек измученный. Такие условия душа не принимает.
P.S. и не поленился искать, млин
я от не зрозумів підтекст, можна якось чітко сформулювати думку, чи легше скопіпейстити чуже чим виразити зрозуміло власну мислю з моску?
— ну и последнее — мы не знаем требования этих людей. лично я бы дал скорее негативную оценку вашей работе. и основной критерий был бы — халатность и отсутствие внимания к деталям.
так что просто это место не для вас. ищите другое, где ценятся ваши сильные качества.
Мог сделать класс который бы давал с легкостью переиспользовать твой код.
в завдані було написано так:
написать код, который будет добавлять в контейнер с прокруткой метки с названием и описанием, предусмотреть возможность их редактирования и удаления.
а не
разбить на несколько которые были бы ответственные за части алгоритма.
і не
сделать класс который бы давал с легкостью
переиспользовать твой код.
Для чого робити більше, якщо про це не просять?
Это показывает уровень программиста. Тебе не будут говорить как писать код, а будут ставить задачи; например «сделать такой то эффект».
С опытом ты поймешь сам что не так в твоем коде.
це ти з досвідом зрозумієш, що нема чого кидати бісер свиням під ноги
Вот мои мысли после того как я увидел код — человек никогда не писал ничего серьезного на javascript. Вот скажи какой у тебя опыт в javascript и приведи примеры твоих работ и заданий?
Тим більше ТС пише: «проект закінчується, маю роботу, непоспішаючи шукаю роботу», як ти думаєш, скільки часу він подтратить на виконання тесту для «noname company» і яке буде відношення до коду. Моя думка — аби працювало згідно завдання і був так -сяк оформлений.
Это тестовое задание на
4) зрозумій, що для «noname company» не будуть робити завдання як для гугла.
а ти значить вже рішав завдання для Google, Sony Mobile, KPMG, Coca Cola, etc.
Якщо ти звертаєшся до мене особисто, то відповідай за себе, а не перекидай стрілки на інших. Я бачу тобі нема що показати, так що все ти пишеш «бла-бла-бла».
также часто вмето switch используется if и наоборот
с этого куска поржал
switch (command) { case 0: cmd = “0 ” ;break; case 1: cmd = “1 ” ;break; case 2: cmd = “2 ” ;break; case 3: cmd = “3 ” ;break; case 4: cmd = “4 ” ;break; case 5: cmd = “5 ” ;break; case 6: cmd = “6 ” ;break; case 7: cmd = “7 ” ;break; case 8: cmd = “8 ” ;break; case 9: cmd = “9 ” ;break; default: cmd= “0 ” ;break; };
время рассмотрения — минуты полторы
а що не так?
Невже тре замінити на іф?
Там перетворення коду команди у ASCI строку, яка потім парсається: номер_команди + тип_команди.
ІМНО мікс іфів та сфічів дає більш читабельний код, чим кілька підряд вкладених іфів або свічів.
І потім кожного разу виконувати перетворення, коли простіше до кожної кнопки вже прив"язаний номер команди (в кожного девайса може бути свій набір команд, максимум 10) і до номера кнопки прив"язується номер команди (тобто пульт не знає що за функція кожної кнопки, лише номер)
А ще тре перевірка, а чи введено в допустимих межах [0..9], а потім ще тре визначии яке значення брати за дефолтну команду..
Вижу, вы пытаетесь спорить со всеми комментаторами и вам очень хочется быть правым. Разрешу все ваши проблемы — ваш код идеален.
Нє, лише намагаюсь дати тлумачення, так як Сільвервольф просив пояснень щодо сакрального змісту gовнокода.
Простите, не посчитайте меня троллем, но сколько сакральный смысл gовнокода не поясняй — в конфетку он не превратится. :)
ну мне, например, нравится принцип yagni. Не делать то чего не нужно, до тех пор пока оно не станет нужно. Впрочем данный объем кода небольшой, чтобы парится про копипейст... вот еслиб там было строчек 30, тогда да ;-)
На телефоні або де інде, як ти думаєш, можуть перейменувати з часом цифрові кнопки (якщо, звичайно ти не фанат FireFly або Futurama)?
Насколько мне известно, для ц такие штуки — коммон паттерн. Особенно денить в эмбедеде, где каждый такт на счету.
Если бы был какждый такт на счёту, то просто использовали бы мэппинг из массива стрингов, вместо пачки непредсказуемых переходов.
Ну теперь понятно почему отказали. Код на 14 строк делает то, что можно спокойно уместить в одну строку. Я не знаток JavaScript но на Java это выглядело бы так:
String cmd = (command < 10) ? String.valueOf(command) : "0" ;
"String cmd = (command < 10) ? String.valueOf(command) : «0» ;
дуже наглядно?
String cmd = (command < 10) ? String.valueOf(command) : «0» ;
String cmd = gePresentationCommand(command);
Но все одно ніяк не той дубовий switch.
Не лєньки ж було копіпастити а потом виправляти цифри.
відрізняти JS Java
Це ніяк не виправдовує
В приведеному коді не перевірки, а трансформація одного значення в інше.і зрозуміти, в що крім первірки на 0...10 є ще інші перевірки
Да, її можна робити за допомогою перевірок.
Але мета приведеного кода — не перевірки.Треба вчитись відрязняти мету від способу її досягнення.
А писати код — «а щоб відчепились», то може тра замислитись про зміну професії?
не comme il faut.«дубовий switch»
То хай розробники Java його викреслять із свого синтаксису.
Аналогії ніяк не захищають цей конкретний гівнокод.
Не треба валити невміле використання можливостей мови програмування на авторів цієї мови.То хай розробники Java його викреслять із свого синтаксису.
Коли довірять вам створити мову, тоді будете додавати чи викреслювати. А поки автору такого коду не довіряють навіть простеньку роботу — то нема чого скавчати що світ недобрий. Іншого все одно не буде в цьому житті. Або ти граєш за правилами, або шукаєш собі іншу гру.
чото я не понімаю Вас батєнька
А поки автору такого коду не довіряють навіть простеньку роботу — то нема чого скавчати що світ недобрий. Іншого все одно не буде в цьому житті. Або ти граєш за правилами, або шукаєш собі іншу гру.
хочеш потролити?
Якщо ти жовтороте курча — то краще б замислився — чому.
Вот он ЦПП (хотя тут наверное Ц) головного мозга :)чекаю на вагон критики
Дальше ближе к сути:
if (keyCode == KeyEvent.KEYCODE_0) IMM_string += «0»; if (keyCode == KeyEvent.KEYCODE_1) IMM_string += «1»; ...
Это какбэ взаимоисключающее, зачем +=?
String query = new String("");
Зачем new String?
private Pattern pattern; private Matcher matcher;
Почему они не локальные переменные, а поля?
public void UDP_send
так які варіанти замість того що є?
критика це — не «всьо пропало», а от це і це я би зробив так і так, тому і тому.
критика це — не “всьо пропало”, а от це і це я би зробив так і так, тому і тому.
А еще перед тем как давать совет, я задал 3 вопроса, ибо то, что выглядит как говнокод, может иметь сакральный смысл.
По пункту № 4 ну тут так просто не объяснишь, тут надо гуглить по словам рефакторинг и “чистый код”.
+=if (keyCode == KeyEvent.KEYCODE_0) IMM_string += «0»; if (keyCode == KeyEvent.KEYCODE_1) IMM_string += «1»;
я так подумав, що тре об"явити пусту строку, а потім її заповнити текстом (якщо такий намітиться).String query = new String("");
Не знаю,private Pattern pattern; private Matcher matcher;
4)
public void UDP_sendне зрозумів, що не так
і
}
не зрозумів, що не так
а що в даному випадку це важливо, маєм діло із приватним полем чи автоматичною змінною?
На ровном месте появляется шареное состояние, сюда же можно было хранить уже скомпиленый паттер, а не компилить его каждый раз.
я так подумав, що тре об“явити пусту строку
Ну для этого не обязательно делать “new String”.
а потім її заповнити текстом (якщо такий намітиться).Более правильно docs.oracle.com/...ingBuilder.htmlЯкий може бути інший механізм?
Хотя в вашем примере просто вынести в функции получение команды и добавление Гет/Сет (которые можно было бы сделать константами)
так це ж рекурсивни ввід IP адреси, до введеноъ строки ти добавляєш цифру 1..9 або крапку — dot.
И снова вынести в метод. Получим нечто вроде:
IMM_string = updateIMM_string(IMM_string, keyCode);
я над тим задумувався, але там майже вся бізнес логіка, тому вирішив не напрягати моск над декомпозицією на менші шматки.
100-150 строк на матод — это плохо, нормальный метод до 10 строк (максимум 15)
Решта — так таки так, тре вчити бібліотечні фукції.
IMM_string = updateIMM_string(IMM_string, keyCode);
хрін рєдьки не солодше.
Решта — так таки так, тре вчити бібліотечні фукції.
Еще бы и стиль попробуйте привести к общему. Кроме апача, сильно бросается в глаза НЕ кемелКейс; тот же “while” не особо часто используют.
тому вирішив не напрягати моск над декомпозицією на менші шматки.
Вот разбивка не методы решит проблему:
бо час від часу приходиться мати справу із дубомими компіляторами, які не допускають об"яв після виконнання коду
Сново же, если уж пишете на Джава, то экономить на вызовах методов — странно :)
Ну пишу я не для джави, ні для компілятора, ні для дяді, ні для тьоті.Сново же, если уж пишете на Джава, то экономить на вызовах методов — странно :)
Пам"ять слабенька, всього не запам«ятаю, а так з льоту розребти старий код — вважаю, що досить добре.
стиль попробуйте привести к общему.
копіпасту не завжди вдається причесати.
хто такий кемлКейс? я не в курсі.сильно бросается в глаза НЕ кемелКейс; тот же «while» не особо часто используют.
А що пропонує джава замість while?
-
Во-во, нечего работать в компаниях, требующих качественный код.
Вообще, прогоните код через www.jslint.com и разберитесь, чего оно ругается на, казалось бы, совершенно нормальные вещи.
Фуууу, реальные пацаны пользуютсо www.jshint.com :)
Для начала лучше все же JSLint.
JSHint — это вроде как для тех, кто уже не может терпеть JSLint.
А по сути одно и тоже, можно и JSHint.
Судя по коду, автор не очень хорошо понимает variable scope в JavaScript.
function f() {
var a = 0;
for (var i = 0; i < 10; i++) {
var a = i;
}
return a;
}
Сможете сходу без интерпретатора уверенно сказать, что вернет функция f?
Судя по коду, автор не очень хорошо понимает variable scope в JavaScript.
А что именно в коде вас навело на эту мысль?
Строчки типа var deleteButton=document.createElement('button');
var updateButton=document.createElement('button');
внутри if-блоков.
— кто-то допускает такие конструкции, если переменная заведомо будет использоваться только в «блоке».
Лично мне (сейчас) больше нравится именно второй вариант, так как его проще рефакторить. ... А после «правильного» рефакторинга переменные сами выползают в начало скопа.
Если бы человек понимал потенциальные проблемы такого подхода, то сделал бы по-другому — усилий дополнительных почти никаких.
А вот это вопрос приоритетов. Если собеседование в «компанию моей мечты», то можно и все правильно и чисто делать (еще и АМД/БДД и все такое продемонстрировать),Ну это ж код маленького тестового задания, где все лучше делать правильно и красиво.
но если это собеседование в очередной лидер рынка ... хм ... я сколько помню старалсо вежливо отказатсо ибо ценю свое время.
Если бы человек понимал потенциальные проблемы такого подхода, то сделал бы по-другому
Вот например я: понимаю чем это чревато, но часто делаю по другому, выше написал почему.
— кто-то допускает такие конструкции, если переменная заведомо будет использоваться только в «блоке».
да, именно поэтому я так и сделал.
иначе потом нельзя будет добавить дополнительные обработчики на этот элемент
2. HTML неплохо было бы вынести в отдельный шаблон, хоть здесь он и маленький, но вдруг разрастется то
3 коллбеки в коллбеках пораждают кашу:)
4. я наверное всё завернул бы в класс и разбил бы на несколько методов. один большой коллбек может потом стать неприятностью, которую сложно поддерживать и умопомрачительно сложно покрыть тестами
4. я наверное всё завернул бы в класс и разбил бы на несколько методов.
От до этого места все хорошо, но «класс» ... Накуя?!
Благодарю за ответ!
По второму: от вас в данном случае не требуется супернавороченный темплейт движок. Достаточно просто вынести форму в отдельный спрятанный див и показывать по необходимости. Спрятать можно CSS-ом или в script-тэге.
спасибо за совет!
Нет в JS классов, как это ни печально. Приходится работать с объектами и прототипами.
как это ни печально.И снова здравствуйте :)
Переиспользование кода, так же облегчается разбор кучи г**** когда скриптов много становиться.
И при чем тут классы? Модули прекрасно справляютсо на обемах более 2К строк. Миксины куда более гибкий вариант. Функции создающие объекты (или клонироание).
— это шо — гугль, или йахуу ? ну можид рамблер на крайний случай ?«чистым» жаваскрипт, без фреймворков.
так что предлагаю забить :)
з.ы. топик стартер приказал мне молчать а меня всё заносит, сорри, больше не буду
да вы продолжайте, может какой-то толковый конструктив проскочит в потоке ваших возвышенных гордых эмоций.. :)
нет никакой пользы давать задание, которое даже сам задающий не будет (и скорее всего не сможет сделать, разве что за много времени и очень длинно) — это просто некрасиво
нет никакой пользы давать задание, которое даже сам задающий не будет
Ну как сказать. Фишка таких «низкоуровневых» задачек в том что они показывают глубину понимания. То есть отказать тому кто не сделал нельзя, а вот тот кто осилил точно(!) подходит.
в данном конкретном случае занадто уж низкоуровневое задание, могли бы сразу на асме попросить :)
задание очень хорошее. когда ты используешь какие-то фрейворки ты все ровно должен понимать на уровень иначе ты даже эти фрейморки будет использовать не правильно!
4. Код слабенький (может дали мало времени)
з.ы. Согласен с Богданом что по такому куску ничего не понятно и это однозначно отговорка
1. Заданный функционал толком не работает.
уточните, пожалуйста — «толком»
2. Коментарии?
изначально, конечно же, были, но для данной темы они не нужны, меня интересует качество функциональной части
4. Код слабенький (может дали мало времени)
уточните, в чем конкретно слабость?..
Когда-нибудь вы поймете, что если нет чего конкретно сказать по сути вопроса, — то правильнее будет промолчать.
Ну это скорее всего отговорка, ибо по такому куску кода мало понятно.Код рассмотрели и от дальнейшего общения со мной отказались, с рецензией «слабый уровень».
— не обрабатывается клик дважды (2 раза открывается окно).
Форма редактирования не привязана к меткам, при прокрутке видно
— все в одной функции, слабая утилизация кода.
хмм.. как бы меня в свое время учили что так правильно.
— магические числа 300 и 2.
таковы условия вводной задачи
— не обрабатывается клик дважды (2 раза открывается окно).
да, действительно, недосмотрел.
— магические числа 300 и 2.Я совсем про другое. Про константы слышали когда-то? 2 — это какой-то markerSize, а не 2.
таковы условия вводной задачи
хмм.. как бы меня в свое время учили что так правильно.Вот теперь ясно, шо таки «слабый уровень». Ибо кто бы вам это не сказал — вас обманул, и при этом самое гланое, вы почему-то ему поверили, а не критически оценили его слова.
Когда титул зачитывают и их очень-очень много говорят «царь вся Руси и прочая, и прочая, и прочая.»"
Бррр... У нас тут +30 так шо я сильно туплю: все равно не понял, да наверное и не важно :)
Мне не понравилось, что форма редактирования отрывается от метки при прокрутке контейнера.
(хотя не исключаю вариант, что зарубили меня формально, — не подошел цвет глаз, возраст и т.д.)
тем более, отзываться о компании в целом из-за странных критериев оценки одного какого-то сотрудника, — не конструктивно.
Если компания держит таких некомпететных сотрудников значит вся компания такая.
Посуди сам:
* Один кретин некоректно оценил твой уровень.
* Тестовое задание на которое ты потратил своё время
* Слабый или сильный уровень по сути ничего не значит. Даже самые сложные знания навёрстать можно за пол года.
* Чисто джаваскрипт никому не нужен, глубоко собеседовать по нему этот как минимум унизить веб разработчика, ведь главные работы всегда проходят на сервере.
* Отзывы о твоём уровне это информация для служебного пользования. Тебе не должны были её говорить чтобы случайно не обидеть (как и случилось) или не переоценить.
* Тебя ейчар не спросила фидбек как тебе собеседование.
Вообщем, если в компании есть адекватное руководство, то ты можешь смело оставлять ЛЮБЫЕ свои отзывы дописав в к конце «у меня сложилось такое впечатление».
Фидбек, даже неверный и отрицательный это дар. Так что ты ещё поможешь стать компании лучше.
Теперь понятно, почему на ДОУ отзывы о компаниях закрыли. :-)
157 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів