👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Итак, родился вариант номер два.
Учел почти все конструктивные пожелания, в ИЕ7 проверил.
Комментарии и структуру для придирчивых сделал.
Я понимаю, что за всеми не уследишь, и всех пожеланий не учтешь, — но тем не менее, прошу ранее высказавшихся комментаторов посмотреть и этот вариант, — я правильно понял критику?

жсФиддле почему-то это вариант не воспринял, положил результат сюда: demenkov.dp.ua/dou

Затянул с вариантом, но был несколько занят в основном проекте. Хотя, тут и без меня стало нескучно :)

Після аналізу аналізу:
1) щоб добре код писати тре багато доброго коду читати — в ІТ одні пишуть г-код інші читають його і потім тішать себе тим, що добрі рев"ювери (г-кода);
2) у друкованих виданнях є редактори — в ІТ щось не зустрічав, знову ж звідки візьмуться рев"ювери (в ІТ графомани рев«ювають інших графоманів)
3) в інженеріє стандарти, в ІТ кожен «сам собі режисер» (хоча є автомтиві є MISRA для С) тому там хоч якісь правила (але український автомотив в глибокій ж.)

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 функций спокойно можно вынести.
А нужно ли?
С точки зрения такой элементарной задачи, которая была поставлена, выделять каждую строчку в метод, который больше никогда не будет вызван — это разве что для демонстрации способности создавать ф-ции в JS в принципе (что вообще ниже уровня джуниора) С точки зрения компактности и читабельности — существующий кусок кода 1у ф-цию лучше, чем разнесенный в 10 ф-ций, которые вызываются по одному разу.
Если интервьюеры хотели именно это (способность писать ф-ции) то они могли бы нанять любого бомжа с улицы — он бы им писал код за еду.
А может ожидали увидеть JSON, но если просто требовалось решить задачу — то код вполне нормальный.
Ну, можно было бы вынести часто выполняющиеся операции в отдельные, более компактные методы, вроде document.createElement(...) в function get(id) и document.createElement(...) в function create(type), но опять же — это не сильно критично.

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

Потому что потом поставят задачу добавить кнопку № 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);
}
}
По моему, это просто хуже. И вот почему:
1. Что бы прочесть весь код(т.е. знать, какие конкретно объекты создаются, а не просто поверхностную структуру алгоритма) ВСЕ РАВНО надо будет залезть в каждый метод, т.е. вместо ± линейного чтения 44х строк надо будет дергаться зигзагом по экрану.
2. Существующий вариант практически влазит во фрейм целиком (на Full HD мониторах, по крайней мере) — т.е. можно прочитать весь код за раз, а если выносить в отдельные ф-ции — это еще плюс 3-4 строки на каждую ф-цию что только раздувает код (т.е. может уже и не влезть в тот же фрейм).
3. Каждый метод вызывается ровно один раз. О каком повторном использовании может идти речь, в ДАННОМ конкретном случае? Или вы заранее можете предугадать, какие свойства надо будет установить кнопке № 3? Или эти ф-ции должны содержать по 10 аргументов на все случаи жизни? Что-то мне подсказывает, что вы бы создали ф-цию createButtonN3()...
Выносить в отдельные ф-ции надо код, который будет использоваться неоднократно... ключевое слово — «неоднократно».

С этой точки зрения, кстати, приведенные методы get(id) и create(type) улучшили бы читаемость кода. Банально, за счет уменьшения кол-ва букв основного алгоритма.

Надо что-то сделать в appendChild, мо как-то чейнинг прикрутить, но мне лень думать как.

Зачем?? Только ради понтов перед интервьюерами? «лень думать как» — яркое свидетельство того, что результат не оправдывает стоимость реализации.

Кароче, не надо раздувать простые задачи, до уровня фреймворков там, где это никому нафиг не надо. См. dou.ua/...mns/kiss-yagni

А где тело метода createMarker()?

ВСЕ РАВНО надо будет залезть в каждый метод

т.е. можно прочитать весь код за раз

В том то и дело что это не нужно. Если надо вносить изменения в процедуру создания кнопки «Удалить» (добавить конферм), то не нужно читать код кнопок «Обновить», не надо знать как создается вся форма целиком.

О каком повторном использовании может идти речь,

Я говорил что-то про повторное использование? Где? Разделение на функции решает задачи: читабельность, абстракции, удобства расширения функционала, удобство тестирования (уда в тестировании 44 строк :) )

Или вы заранее можете предугадать, какие свойства надо будет установить кнопке № 3?

А вот тут уже я вам советую не просто

См. dou.ua/....mns/kiss-yagni

А посмотреть что эти букавки значат.

С этой точки зрения, кстати, приведенные методы get(id) и create(type) улучшили бы читаемость кода. Банально, за счет уменьшения кол-ва букв основного алгоритма.

:))))
«-» понятнее чем «private»? «+» понятнее чем «public»?

Что делает следующий код:

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+ слов. если для понимания логики нужно рыскать по коду аки раненная лань, это не есть гут.

Могу только предположить, что этот ваш create(’div’, params) должен создавать объект...

кхм. в языках с динамической типизацией, вроде JS, о типе возвращаемого значения действительно остается лишь предполагать. вас не смущает, что разработчики языка обозвали метод createElement(), а вы всего лишь create()?

я исходники не смотрел, смотрю лишь фрагменты. а смысл должен быть понятен даже по фрагментам. имхо.

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

Я как бы не имел ввиду вопрос выбора длины имени метода...

всего лишь create()?

Нет не смущает, по крайней мере в ЭТОМ конкретном случае.

Потому что он заводится исключительно ради удобства и его целью является, всего лишь, немного сократить часто повторяющуюся конструкцию document.createElement(’div’), и все!

а смысл должен быть понятен даже по фрагментам. имхо.

Метод в одну строчку сразу должен бросаться в глаза как фрагмент кода, имхо)

и что?

А то что вы не угадали :) И поэтому вам надо будет прочитать тело метода (а оно как правило более 10+ слов :) ), а при правильном именовании, только название.

что методов в 500+ строк, при таком подходе, просто не будет существовать!

Чисто не там где убирают, а там где не мусорят ©

Я, конечно, сгущаю краски, но тем не менее... ))

Похоже у вас проблемы с пониманием, повторяю второй раз и медленнно:

И какой же для вас допустимый размер метода?

А то что вы не угадали :)

А то что вы его вообще от балды взяли (а значит и то, что я не угадал — тоже от балды) имеет значение? :)

И какой же для вас допустимый размер метода?

Если ограничения на размеры методов не прописаны в code convention, то в общем случае, с моей точки зрения, их нет. Размер метода — это скорее следствие и показатель дизайна/имплементации, чем требование, и может быть обусловлено другими ограничениями и ориентирами, вроде «код метода должен помещаться на экране», «надо писать максимально компактный удобочитаемый код», «надо форматировать код согласно принятому code convention» и др. Все зависит от специфики проекта.

Если какой-то конкретный метод занимает 50 строк, то это может быть сигналом о необходимости проведения рефакторинга. С другой стороны, в WinForms, например, метод InitializeComponents(), который генерится дизайнером форм, может занимать и 500 строк — но ведь никто в здравом уме не будет его пытаться впихнуть в правило «5-10 строк», правда?

А то что вы его вообще от балды взяли (а значит и то, что я не угадал — тоже от балды) имеет значение? :)

Hskkb^

Что делает следующий код:
create(’div’, params)
А этот:
createEditingForm(params)

?

Если ограничения на размеры методов не прописаны в code convention, то в общем случае, с моей точки зрения, их нет.

Вот так и появляютсо методы на 500 строк :)

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

То есть таки есть — 50 строк. Но его трудно рефакторить, у меня на мониторе 31 строка помешаетсо (с включенными отладчиком и тд). Мо таки скинем немного ;)

метод InitializeComponents(), который генерится дизайнером форм

И не предназначен для того чтобы его читали, правили!

Эта ветка — лучшее, что есть на этом форуме. Люди не отрезающие важность правильных наименований, однотипные копипаста кейсы, это ж просто кладезь сеньоров.

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

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

Или в сложной системе вы бы так же одобрили подобный подход?

про 100 строк — то комментаторы несколько преувеличили... :)

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

Код write-only. Я даже читать не стал — просто стена текста. ИМХО уровень джуниора. Как минимум надо отформатировать код ньюлайнами и разнести по функциям, а там уже и почитать можно будет и проанализировать реализацию.

Но особо меня поразил код Мухи ниже. И это один из главных противников «23-летних синьоров», а сам пишет такое... Стыдно, господа инженеры!

И это один из главных противников «23-летних синьоров», а сам пишет такое...

Ему можно, ЦПП головного мозга очень плохо лечетсо

Стыдно, господа инженеры!

Кодерок Формошлепов (aamartynenko), с возвращением на ДОУ! Как дела в МСе? Как Париж?

Я вернулся, уже год как. МС очень разочаровал =) Собственно Франция тоже разочаровала

разочаровал

Бложик ваш вроде сдох, вы где-то писали подробнее об этом? Мо на ДОУ напишете?

Хотел когда-то написать да передумал. В кратце — майкрософт стал очень унылым. По крайней мере тот где я был. Менеджмент бездарный, код гoвнo, лизня жопы приветствуется больше чем все остальное. Ну и плюс мне менеджер попался — земляк из Донецка. Редкое чмо. Во Франции высокие цены, низкие зарплаты после налогов и еще 100500 причин вернуться сюда. Прошел год как я вернулся и я очень рад что я это сделал. Освоил кучу всего нового и участвую в невероятно интересном проекте. А в МСе так бы и гнил на должности SDET тестируя гoвнoкод на T-SQL...

Надо было в Редмонд ехать. Чего там было во Франции ловить? Если сейчас идти в европейский MS, то наверно альтернатива только одна — Skype.

Ну и SDET это конечно уныло.

«Знал бы прикуп — жил бы в Сочи». Но после всего этого я в МС даже в Редмонд в крутой проект не хочу. Слишком уж гнилой он внутри.

так надо было спросить :) хотя меня многое устраивало, я даже думал вернуться ...

Так вроде ж предупреждали что на стартовую позицию и SDET и не в главный офис это не айс совсем

Интересно, а как вы затраты на переезд возвращали, ведь для Европы кажеться если уходишь раньше чем через год то нужно компенсировать затраты и там вроде по МСовким бюджетам порядка 30к может насобираться, неужели Украинский работодатель заплатил?

Стыдно, господа инженеры!

Стидно не коли видно, а коли нема що показати.

«... хорошо излагает, учитесь Шура ...»

Договаривающиеся стороны заглядывали друг
другу в глаза, обнимались, хлопали по спинам и вежливо смеялись.
— Ну, — сказал Остап, — за все дело десятку!
— Дуся! — удивился монтер. — Вы меня озлобляете. Я человек, измученный нарзаном.
— Сколько же вы хотите?
— Положите полста. Ведь имущество-то казенное. Я человек измученный.
— Хорошо. Берите двадцать! Согласны? Ну, по глазам вижу, что согласны.
— Согласие есть продукт при полном непротивлении сторон.
— Хорошо излагает, собака, — шепнул Остап на ухо Ипполиту Матвеевичу, — учитесь.
— Когда же вы стулья принесете?
— Стулья против денег.
— Это можно, — сказал Остап, не думая.
— Деньги вперед, — заявил монтер, — утром — деньги, вечером — стулья или вечером —
деньги, а на другой день утром — стулья.
— А может быть, сегодня — стулья, а завтра — деньги? — пытал Остап.

— Я же, дуся, человек измученный. Такие условия душа не принимает.

ну я смысл передал, давно уже читал просто ... или может в фильме слегка по другому :)

P.S. и не поленился искать, млин

я от не зрозумів підтекст, можна якось чітко сформулювати думку, чи легше скопіпейстити чуже чим виразити зрозуміло власну мислю з моску?

підтексту небуло, сподобалась фраза от і все, не заводься

скорее всего основным было следующее:
— код весь в куче
— всякие вещи вроде «-300», а почему не «-299»?
— работает коряво: menu создается каждый раз, save у меня не работает
— халатность: у вас код не очень хорошо поддерживает прокрутку. а в задании на этом сделано ударение
— возможно описание задания было более внятно, чем вы привели. иначе, например я, в жизни бы не догадался что именно надо делать. и спрашивал бы.

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

так что просто это место не для вас. ищите другое, где ценятся ваши сильные качества.

Все написано в одной функцией в 100 строк длиной — вот потому и написали слабый уровень.
Мог бы разбить на несколько которые были бы ответственные за части алгоритма.

Мог сделать класс который бы давал с легкостью переиспользовать твой код.

а для чого?

в завдані було написано так:

написать код, который будет добавлять в контейнер с прокруткой метки с названием и описанием, предусмотреть возможность их редактирования и удаления.

а не

разбить на несколько которые были бы ответственные за части алгоритма.

і не

сделать класс который бы давал с легкостью
переиспользовать твой код.

Для чого робити більше, якщо про це не просять?

Это показывает уровень программиста. Тебе не будут говорить как писать код, а будут ставить задачи; например «сделать такой то эффект».

а що за виконання тестів платять?

Вся суть в том что тебе поставили задачу и её можно было бы решить многими способами. В зависимости от способа определили твой уровень. Каждому уровню соответствует свои принципы и методы написания (это мое личное мнение).

С опытом ты поймешь сам что не так в твоем коде.

це ти з досвідом зрозумієш, що нема чого кидати бісер свиням під ноги

Зачем же так грубо)

Вот мои мысли после того как я увидел код — человек никогда не писал ничего серьезного на javascript. Вот скажи какой у тебя опыт в javascript и приведи примеры твоих работ и заданий?

А до чого тут я?
Ну якщо хоч потратити свій час не мій г0внокод, то можеш подивитися приклади
(абстрактний С++ для мастдая) -> github.com/...-Spell-Checker
(чистий С для мікроконтролера — github.com/...a/PSoC-Dialer)
— (Java/Android server/client ) github.com/...Home-Automation
п.с.
мій випад був до того, що за тестове завдання грошей не платять, тому пишеться в рамках поставленої задачі.
А то бодішоп уявляє, що кандидати будуть вилизувати код тестового завданя як для гугла, а потім напишуть через треті руки — «слабо». Тобто при такому нехлюйському відношенні кандидати повинні писати ідеальний код?

Тим більше ТС пише: «проект закінчується, маю роботу, непоспішаючи шукаю роботу», як ти думаєш, скільки часу він подтратить на виконання тесту для «noname company» і яке буде відношення до коду. Моя думка — аби працювало згідно завдання і був так -сяк оформлений.

Это тестовое задание на 10-15 мин в любом варианте исполнения. Я себе не возьму в команду человека который будет оформлять код «так-сяк», вот и они разделяют мое мнение) Ищи себе команду где будут писать так как ты и все будет супер)

1) ще раз для тих хто в танку, я не ТС
2) до тебе не просився в команду.
3) не кажи мені що робити я не казатиму куди тобі іти.

4) зрозумій, що для «noname company» не будуть робити завдання як для гугла.

задачка не для гугла ...

а ти значить вже рішав завдання для Google, Sony Mobile, KPMG, Coca Cola, etc.

А якє це має відношення до цього поганого коду?

ага. погугли многие выкладывают их)

Якщо ти звертаєшся до мене особисто, то відповідай за себе, а не перекидай стрілки на інших. Я бачу тобі нема що показати, так що все ти пишеш «бла-бла-бла».

И это говорит человек без навыков в джаваскрипте....

п.с. навыков javascript хватает)

И совсем плохо работает в ИЕ9.

а мона мені?
github.com/...-Automation.git

чекаю на вагон критики

кодинг-стиль неаккуратненький — я заметил три или четыре разных стиля использования {}

также часто вмето 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 строку, яка потім парсається: номер_команди + тип_команди.
ІМНО мікс іфів та сфічів дає більш читабельний код, чим кілька підряд вкладених іфів або свічів.

цеж не сішечка.

Просто конвертнути з інта в стрінг, не ? :-)

Можна, але так довгий код вийде, то раз, а по друге світч, використовується для наглядності.
От уяви пуль для девайса.
Ти вибираєш команду простим нажиманням кнопки, а не:
якщо я не нажав кнопку 1, то тре перевірити кнопку 2, а якщо не 2 то може кнопка 3 була нажата і т.д.

І потім кожного разу виконувати перетворення, коли простіше до кожної кнопки вже прив"язаний номер команди (в кожного девайса може бути свій набір команд, максимум 10) і до номера кнопки прив"язується номер команди (тобто пульт не знає що за функція кожної кнопки, лише номер)

що довгого у cmd = Integer.toString(command) + " "; ?

cmd = «0 » набагато коротше,
п.с.
краткость — сестра таланта ©
K.I.S.S у прогерів
п.п.с.
У тебе як мінімум п"ять операцій, які тре втримати в моєму прогарамерському кеші:
— згадати про клас інтегер,
— викликати з нього метод 2стрінг
— передати йому параметер
— до результату добавити пробіл
— зробити присвоєння.

А ще тре перевірка, а чи введено в допустимих межах [0..9], а потім ще тре визначии яке значення брати за дефолтну команду..

Вижу, вы пытаетесь спорить со всеми комментаторами и вам очень хочется быть правым. Разрешу все ваши проблемы — ваш код идеален.

Нє, лише намагаюсь дати тлумачення, так як Сільвервольф просив пояснень щодо сакрального змісту gовнокода.

Простите, не посчитайте меня троллем, но сколько сакральный смысл gовнокода не поясняй — в конфетку он не превратится. :)

Тю, блин, а если вместо «0», «1», «2» будет что-то другое со временем?

Как вы угадываете что будет, а что нет ?

Я не угадываю, а предполагаю.

ну мне, например, нравится принцип yagni. Не делать то чего не нужно, до тех пор пока оно не станет нужно. Впрочем данный объем кода небольшой, чтобы парится про копипейст... вот еслиб там было строчек 30, тогда да ;-)

На телефоні або де інде, як ти думаєш, можуть перейменувати з часом цифрові кнопки (якщо, звичайно ти не фанат FireFly або Futurama)?

Цифровые кнопки — это уже конкретика.

Нет, их не переименуют.

Вот про такие случае и говорит идея YAGNI

а что на C\C++ нельзя без switch обойтись? :)

Насколько мне известно, для ц такие штуки — коммон паттерн. Особенно денить в эмбедеде, где каждый такт на счету.

я всегда думал что коммон паттерн это что-то вроде:

commad + ’0′

очень сомневаюсь , по крайней мере для приведенного выше switch

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

Ну теперь понятно почему отказали. Код на 14 строк делает то, что можно спокойно уместить в одну строку. Я не знаток JavaScript но на Java это выглядело бы так:

String cmd = (command < 10) ? String.valueOf(command) : "0" ;

Якщо би читав уважно, то міг би
— бачити я не ТС;
— відрізняти JS Java
— а що
"

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 є ще інші перевірки

В приведеному коді не перевірки, а трансформація одного значення в інше.

Да, її можна робити за допомогою перевірок.

Але мета приведеного кода — не перевірки.

Треба вчитись відрязняти мету від способу її досягнення.

А писати код — «а щоб відчепились», то може тра замислитись про зміну професії?

Ну ви дивні люди,
а для чого на пульті до телевізора ставити 20 кнопок, коли можна зробити весь ГУЙ на одній?
А що,

«дубовий switch»

не comme il faut.

То хай розробники 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

353-203 == 150, даже если скинуть 50 строк на апач коде-стайл — это дох.

так які варіанти замість того що є?
критика це — не «всьо пропало», а от це і це я би зробив так і так, тому і тому.

критика це — не “всьо пропало”, а от це і це я би зробив так і так, тому і тому.

А еще перед тем как давать совет, я задал 3 вопроса, ибо то, что выглядит как говнокод, может иметь сакральный смысл.

По пункту № 4 ну тут так просто не объяснишь, тут надо гуглить по словам рефакторинг и “чистый код”.

1)

if (keyCode == KeyEvent.KEYCODE_0) IMM_string += «0»; if (keyCode == KeyEvent.KEYCODE_1) IMM_string += «1»;

+=
так це ж рекурсивни ввід IP адреси, до введеноъ строки ти добавляєш цифру 1..9 або крапку — dot. Після вводу має вийти щось схоже на 255.255.255.255 (хоча може бути і 999.999.999.999) але далі є парсер.
2)

String query = new String("");

я так подумав, що тре об"явити пусту строку, а потім її заповнити текстом (якщо такий намітиться).
Який може бути інший механізм?
3)

private Pattern pattern; private Matcher matcher;

Не знаю,
а що в даному випадку це важливо, маєм діло із приватним полем чи автоматичною змінною?
Просто в мене звичка об"являти все з чим працюю спочатку, а не по ходу діла (можливо це діло звички, бо час від часу приходиться мати справу із дубомими компіляторами, які не допускають об"яв після виконнання коду)

4)

public void UDP_send
не зрозумів, що не так

і

353-203 == 150, даже если скинуть 50 строк на апач коде-стайл — это дох.

тут мається на увазі брейкет кодінг стайл?
так це діло хозяйське, мої дужки, як хочу так і ставлю.
А чому відступи мають бути по 4 пробіла а не по 7,
або чому має бути {
Hello_world ();
}
а не
{
hi_All ();

}

не зрозумів, що не так

100-150 строк на матод — это плохо, нормальный метод до 10 строк (максимум 15)

а що в даному випадку це важливо, маєм діло із приватним полем чи автоматичною змінною?

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

я так подумав, що тре об“явити пусту строку

Ну для этого не обязательно делать “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?

«apache code style» — це мабуть тяжка спадщина Сайбервіжена

Вполне нормальный у вас код, радуйтесь что не работаете в той компании.

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

Вообще, прогоните код через www.jslint.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-блоков.

Это не о чем не говорит. Тут больше философский вопрос:
— кто-то считает что надо все объявлять вначале, шоб небыло непоняток;

— кто-то допускает такие конструкции, если переменная заведомо будет использоваться только в «блоке».

Лично мне (сейчас) больше нравится именно второй вариант, так как его проще рефакторить. ... А после «правильного» рефакторинга переменные сами выползают в начало скопа.

Ну это ж код маленького тестового задания, где все лучше делать правильно и красиво.

Если бы человек понимал потенциальные проблемы такого подхода, то сделал бы по-другому — усилий дополнительных почти никаких.

Ну это ж код маленького тестового задания, где все лучше делать правильно и красиво.

А вот это вопрос приоритетов. Если собеседование в «компанию моей мечты», то можно и все правильно и чисто делать (еще и АМД/БДД и все такое продемонстрировать),

но если это собеседование в очередной лидер рынка ... хм ... я сколько помню старалсо вежливо отказатсо ибо ценю свое время.

Если бы человек понимал потенциальные проблемы такого подхода, то сделал бы по-другому

Вот например я: понимаю чем это чревато, но часто делаю по другому, выше написал почему.

— кто-то допускает такие конструкции, если переменная заведомо будет использоваться только в «блоке».

да, именно поэтому я так и сделал.

Вы таки правильно догадались

1. document.getElementById("content").onmousedown
вот так делать плохо
нужно вместо этого использовать document.addEventListener, либо document.attachEvent

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

2. HTML неплохо было бы вынести в отдельный шаблон, хоть здесь он и маленький, но вдруг разрастется то

3 коллбеки в коллбеках пораждают кашу:)

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

4. я наверное всё завернул бы в класс и разбил бы на несколько методов.

От до этого места все хорошо, но «класс» ... Накуя?!

1. — принял, логику понял.
2. — но задача как бы не того уровня...
3. — да, в этом есть смысл.

Благодарю за ответ!

По второму: от вас в данном случае не требуется супернавороченный темплейт движок. Достаточно просто вынести форму в отдельный спрятанный див и показывать по необходимости. Спрятать можно CSS-ом или в script-тэге.

кстати да! незачем плодить окошки меню, пусть одно будет, суть-то та же..

спасибо за совет!

Нет в JS классов, как это ни печально. Приходится работать с объектами и прототипами.

Да, я конечно же имел ввиду объект

как это ни печально.
И снова здравствуйте :)
Накуяяя вам классы?!

Переиспользование кода, так же облегчается разбор кучи г**** когда скриптов много становиться.

И при чем тут классы? Модули прекрасно справляютсо на обемах более 2К строк. Миксины куда более гибкий вариант. Функции создающие объекты (или клонироание).

ну код не гениальный (хотя и аккуратный, это плюс), но не в этом суть
польза в том, что в подобные говвноконторки нельзя поступать на работу, ни в коем случае
от по заданию —

«чистым» жаваскрипт, без фреймворков.

— это шо — гугль, или йахуу ? ну можид рамблер на крайний случай ?
в мире есть очень мало контор, которые могут себе позволить кодить на чистом js (асме, коболе, фортране) ибо реальный код будет выглядеть очень «неровно» с кейзами для хрома, оперы и шестого ие :)

так что предлагаю забить :)

а я понимаю принимающих, хотели проверить понимание основ и отношение к задачам ... и проверили
и нефиг забивать, нужно учиться и совершенствоваться, и не только JS но и отношению к задаче.

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

да вы продолжайте, может какой-то толковый конструктив проскочит в потоке ваших возвышенных гордых эмоций.. :)

нет никакой пользы давать задание, которое даже сам задающий не будет (и скорее всего не сможет сделать, разве что за много времени и очень длинно) — это просто некрасиво

нет никакой пользы давать задание, которое даже сам задающий не будет

Ну как сказать. Фишка таких «низкоуровневых» задачек в том что они показывают глубину понимания. То есть отказать тому кто не сделал нельзя, а вот тот кто осилил точно(!) подходит.

в данном конкретном случае занадто уж низкоуровневое задание, могли бы сразу на асме попросить :)

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

1. Заданный функционал толком не работает.
2. Коментарии?
3. Желательно оформить-прислать в нормальной файловой иерархии хтмл-цсс-жс. (может это и сделал).

4. Код слабенький (может дали мало времени)

з.ы. Согласен с Богданом что по такому куску ничего не понятно и это однозначно отговорка

1. Заданный функционал толком не работает.

уточните, пожалуйста — «толком»

2. Коментарии?

изначально, конечно же, были, но для данной темы они не нужны, меня интересует качество функциональной части

4. Код слабенький (может дали мало времени)

уточните, в чем конкретно слабость?..

Уточнять ничего не буду потому что мне тоже

лениво

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

Вам уже одни промолчали, вы довольны?

Код рассмотрели и от дальнейшего общения со мной отказались, с рецензией «слабый уровень».

Ну это скорее всего отговорка, ибо по такому куску кода мало понятно.
Но если «по всей строгости», то код слабый:
— все в одной функции, слабая утилизация кода.
— магические числа 300 и 2.

— не обрабатывается клик дважды (2 раза открывается окно).

В коде баги. updateButton.onClick(). Ставим точку, запускаем её редактирование, пишем в поле «имя» единицу, не закрываем окошко редактирования. Ставим вторую точку, пишем в поле «имя» двойку, закрываем менюшечку. Открываем окошко редактирования второй точечки — видим что она называется не «2», а «1»
Как уже сказали — одна функция для всего.

Форма редактирования не привязана к меткам, при прокрутке видно

— все в одной функции, слабая утилизация кода.

хмм.. как бы меня в свое время учили что так правильно.

— магические числа 300 и 2.

таковы условия вводной задачи

— не обрабатывается клик дважды (2 раза открывается окно).

да, действительно, недосмотрел.

— магические числа 300 и 2.
таковы условия вводной задачи
Я совсем про другое. Про константы слышали когда-то? 2 — это какой-то markerSize, а не 2.
хмм.. как бы меня в свое время учили что так правильно.
Вот теперь ясно, шо таки «слабый уровень». Ибо кто бы вам это не сказал — вас обманул, и при этом самое гланое, вы почему-то ему поверили, а не критически оценили его слова.
Если таки одумаетесь учитсо, то ищете по именам Крокфорд, Резиг, Стефанов, Османи.

забыл «и прочие и прочее»...))

Когда титул зачитывают и их очень-очень много говорят «царь вся Руси и прочая, и прочая, и прочая.»"

Бррр... У нас тут +30 так шо я сильно туплю: все равно не понял, да наверное и не важно :)

аа забей, в следующий раз попробую поискрометнее =)

Мне не понравилось, что форма редактирования отрывается от метки при прокрутке контейнера.

да, есть такой момент, спасибо за вказивку.

Название компании — в студию! Пусть страна знает своих «героев».

да енг с ней, с этой достаточно известной компанией, меня зацепило только то, что возможно я не знаю чего-то важного в плане кодинга.

(хотя не исключаю вариант, что зарубили меня формально, — не подошел цвет глаз, возраст и т.д.)

Всё ок. Посылай их в жо и напиши в блоге отзыв о компании.

я комсомолец, не могу без трудностей :) а вдруг я чего-то не знаю?.. :)

тем более, отзываться о компании в целом из-за странных критериев оценки одного какого-то сотрудника, — не конструктивно.

Если компания держит таких некомпететных сотрудников значит вся компания такая.
Посуди сам:
* Один кретин некоректно оценил твой уровень.
* Тестовое задание на которое ты потратил своё время
* Слабый или сильный уровень по сути ничего не значит. Даже самые сложные знания навёрстать можно за пол года.
* Чисто джаваскрипт никому не нужен, глубоко собеседовать по нему этот как минимум унизить веб разработчика, ведь главные работы всегда проходят на сервере.
* Отзывы о твоём уровне это информация для служебного пользования. Тебе не должны были её говорить чтобы случайно не обидеть (как и случилось) или не переоценить.
* Тебя ейчар не спросила фидбек как тебе собеседование.

Вообщем, если в компании есть адекватное руководство, то ты можешь смело оставлять ЛЮБЫЕ свои отзывы дописав в к конце «у меня сложилось такое впечатление».
Фидбек, даже неверный и отрицательный это дар. Так что ты ещё поможешь стать компании лучше.

Теперь понятно, почему на ДОУ отзывы о компаниях закрыли. :-)

Підписатись на коментарі