-
Пособеседуем...
-
Пособеседуем...
поверьте это возможно, писать всегда хорошо и выдавать всегда хороший код .
Это что, тонкая шутка? Если нет, то вы наверное сразу бросаете работу если там нет ТЗ, бизнес аналитика и установлены жесткие сроки, в которые вы гарантированно не уложитесь?
Сроки не могут идти впереди Качества :).По поводу джавадоков — это может быть не нужно вам, но очень выручит того кто без знания всего ТЗ и всего кода, сможет быстро разобраться именно с этим функционалом.
Да 90% жаводоков не помогают, в том то и дело. Текущая проект — реальный пример того, как компания требовавшая доки ранее, сделала их опциональными. Просто было принято решение что этот тип документирования себяне оправдывает -
Пособеседуем...
Сорри за отсутствующие местами пробелы — клавиатура дрянь
-
Пособеседуем...
«Покажите, пожалуйста, программный код, который максимально отражает Ваш текущий профессиональный уровень».
Смешно. Я, например, могу писать дома код абсолютно разного качества и одинаково гордиться им. Все зависит от целеи, с которой этот код пишется. Месяц назад, например, я писал жесткую функциональщину с целью вложить максимум функционала в минимум строк кода. Мне нравится этот код. Сейчас я пишу с подходом «Парни, а давайте быстро сделаем штуку, пофиг на качество, вдруг денег дадут». Ни одного комментария, теста, валидации ошибки, все что пишется ни разу не рефакторилось. Умных алгоритмов вы там тоже ненайдете — не нужны они для старта.
Уровень владения UML, количество типов диаграмм в арсенале С.
В 20 лет прекрасно знал. В 23 уже забыл немного, сейчас — тем более.
Владение паттернами проектирования.
Применял еще до прочтения разных GoFов. Названий не знал. В
22-21 уже знал названия, к 23 начал забывать.Комментарии кода.
Не пишу в 99% кода(Если явно не оговорено), просто нет необходимости. Почти весь код со сложной и непонятной логикой предназначен для себя любимого и интересен только в процессе написания. Если надо будет писать в команде что-то из rocket science, то комментировать буду. Код, который идет жить в продакшен просто обязан быть настолько прост для понимания, что комментарии излишни. На текущем проекте, например, джавадоки явно указанны как излишество. Если поведение вашего кода непонятно — переписывайте код.
Итог — методика претендует на роль быть silver bullet, при этом не вписываясь в реальную жизнь
Підтримали: Олег Кострубин, Варю Борщ, Volodymyr Kholoshenko, Vladyslav Khaletskyi, anonymous, Vitalii Nazarov, Александр Штыхер, Roman Pavlyuk, Andy, Серёга Самбор, Mike Gorchak, Igor Kononuchenko, Kostiantyn Kudriavtsev, eGlyph eGlyph, gorik gorik, Sergey Svechnikov, Dmytro Kolesnykov, yesnomaybeidontknow, Віталій Іванов, Леголас Трандуилович, Антон Батареечкин -
Сеньоры, Мидлы, Джуны.....может лучше сертификация?!
Не встречал ни одного случая, чтобы сановская/оракловская сертификация была заметным плюсом на техническом интервью. Все относятся к сертификатам достаточно ровно, некоторые даже с легким презрением/недоверием.Наверное для джавистов — от оракла
Правка — все, кого я знаю
-
ДОУ Хакатон 11-12 июня
Да, дата действительно неудачно выбрана. Хотел бы посетить, но из-за праздников не смогу. Голосую за перенос, если возможно.
Да, верно. То что чей-то коде непонятен вовсе не значит что это правильно. Комментарий не особо поможет, в программировании сходу могут быть непонятными либо редкоприменяемые алгоритмы, либо что-то из бизнес-рилэйтед. Второе должно быть описанно не в комментариях, первое можно и прокомментировать. Только вот я почем-то не вижу часто в продакшене методов подбора градиентным спуском, всё какое-то приземленное.