Соответственно, в какой-то критической ситуации (например, на проекте 100 багов на проде) - человек будет абсолютно спокоен - "мне задачи на исправление этих ошибок никто не ставил - какие вопросы?"
Опять же, человек по своему прав, но вот мне, человеку который не равнодушен к своей работе (и я хочу, чтобы проекты, над которыми работаю были качественными), работать с такими очень неприятно
Спасибо за приятные слова. Зрите прямо в корень! Если бы мог поставить плюс и комментарию, и в карму то уже бы это сделал.
Написанная за два часа маленькая программка в данном случае разработчика "раскроет" лишь частично - вам все равно нужно будет выяснить, писал ли он ее сам, а не подсунул ли чужую, насколько глубоко его знание используемого стека, а не сделал ли он херак-херак копипастой со стековерфлоу, владеет ли он технологиями, которые нужны для проекта, но не были затронуты в его "маленькой программке", способен ли он к дизайну архитектуры, что в маленькой простенькой программке не продемонстрировать почти никак.
Маленькая программа как раз показывает всё что именно нужно, если вы её не просто читаете, а ещё слушаете прекрасную басню о том, как кандидат её создавал.
Маленькая часть неформальной работы, которую приходится делать каждый день. А мне оно и нужно - всё что вы подразумеваете под профессиональными качествами, не более чем привычки, которые видно даже невооруженным глазом. Талант, как говорится, не пропьёшь.
Вопросы честности, манер, стиля работы и всего остального, что выделенно курсивом как раз прекрасно покажет кандидат за время испытательного срока.
О, и не волнуйтесь, я не увольняю человека только за то, что он приукрасил своё резюме. Мне не важно как человек сделал программу, написал с нуля или адаптировал свои или чужие предыдущие наработки, куда важнее, чтобы работа производилась в приемлимые сроки и проходила ряд требований во время тестирования, то есть программа работала без нареканий.
И для справки: Испытательный срок длится всего 21 день. Эмпиречески уже давно определенный период времени, за который человек сможет как минимум влится в коллектив, а заодно понять всё что ему необходимо. Увы, идеальных компаний здесь не бывает.
Для упращения работы бухгалтерии его обычно назначают кратным 1 месяцу, 3 месяца - это максимальный срок установленный ТК РФ. Вопрос "Кто кого тут обхитрил?" уже риторический, бывает люди назначают бесплатные стажировки, с чем я в корне не согласен. Если человек только набирается своего первого опыта работы в коллективе, то его труд всегда должен оплачиваться.
"Интересно, и как это вы себе представляете конкретно для C/C++?"
Вы серьёзно меня спрашиваете, как я представляю себе вещи, которые по моему же утверждению не существуют? Никак не представляю.
К чему тогда все ваши притензии? Может тогда это только вы плохо знаете основы программирования и просто невнимательны?
Если вам так нравится Rust, то пишите только на нём. Он же компилируемый, а следовательно на нём можно всё что угодно писать. На черта вы всем вокруг пытаетесь навязывать свои предрассудки как религиозную догму?!
Справедливости ради, такому человеку и предложить выпить не жалко. По опыту знаю, что в менеджменте нормальные доверительные отношения можно сложить только с людьми, которые как минимум неравнодушны к себе, и как следствие к своей работе.
Один из признаков профессионального роста - это умеренная самооценка.
В общем рекомендую вам попробовать походить по собеседованиям, чтобы убедиться в том, что там где на «техническом фильтре» стоят не hr'ы, а нормальные тех. специалисты, проблем с определением уровня кандидата не возникает.
А я изначально думал, что хотя бы за уважительный тон смогу поблагодарить. Знаете в чем ирония? С вами сейчас и беседовал технический специалист, прошедший только за прошлый год 15 собеседований за 2 месяца при смене места работы.
Но увы, вы слишком часто делаете выводы из глупых предположений. А спросить явно вам либо ума, либо совести не хватило. Жалкое зрелище все ваши отговорки, которыми вы оправдываетесь на том, о чем не додумался всего лишь спросить.
Вы слишком грубы, когда предписываете собеседнику что он никаким образом не имел ввиду. Я ни слова не говорил ни про open source, ни про большие программы. Хватило бы короткого полезного вам кейса, может исходник рабочей программы созданной вами, который скорее всего я потребовал только прокомментировать и рассказать о том через что вы прошли, чтобы его создать. Даже более скажу, вы бы сами охотно так и поступили.
Также никто не мешает спокойно использовать наработки из ранее написанных проектов. За NDA никто вам слова не скажет - попробуйте ещё доказать факт его нарушения. А стучать сам на себя - сами знаете как это выглядит.
Настоящие технические специалисты с хорошим образованием никогда не строят выводы только из предположений, как минимум об этом делают замечание, но, повторю, никогда не аргументируют свои слова таким грубым способом. Как минимум, это проявление неуважения к собеседнику.
И для справки: На более высоких должностях интересуют далеко не базовые вещи, а то что всегда остаётся в глубине. Нельзя построить нормальных отношений с сотрудником, который неуважительно относится к своей профессии, и тем более, если он не уважает даже себя.
Тем более учитывайте, что умение писать небольшие, но полезные программы, куда больше говорит о программисте, чем писать только большие проекты, где далеко не ясно насколько он был в авангарде, а насколько перекладывал свою работу на других.
Например, я использую короткие кейсы для того, чтобы разобраться в новых для себя инструментах. Сейчас, по иронии судьбы, мне нужно перебрать 170 ГБ информации из 60 с лишним тысяч медиа-файлов, из которых полезных фотографий только 24 ГБ. Вручную уйдёт на это годы, а нужную программу написать на понравившемся компиляторе займёт не более чем 2 часа, даже с нормальным оконным UI.
Вот только за 2 часа вы в лучшем случае напишите крохотную утилитку
А я где-то говорил об обязательно больших программах? Или где-то, как тут некоторые прикручивали, про open source? Нет, ни единого слова.
Цитата:
Если бы я нанимал крепкого миддла и тем более сеньора на постоянную работу, то сразу бы спросил исходник его программы, которой он сам пользуется или сделал так, что хочется ей пользоватся, и ограничился только общими вопросами по условиям работы, остальное - покажет только испытательный срок.
Вы поступаете очень невежливо в отношение собеседника, когда пытаетесь приплетать к нему того, что он никаким образом не имел ввиду. Подумайте над этим ещё раз перед тем, как писать свои отговорки.
Такие вещи нельзя адекватно прикрутить к языку пост-фактум, язык надо изначально создавать с ними в уме.
Интересно, и как это вы себе представляете конкретно для C/C++? Может изначально нужно в стандарте для разработчиков компиляторов ещё прописывать, чтобы интегрировали статические анализаторы, а то программисты совсем не внимательные стали? Вот очень интересно узнать, ответьте, пожалуйста.
Вот пусть и ответит человек выше на этот вопрос. Кому-то функционал подавай, кому-то эргономику.
Из Java-подобных компиляторов мне больше понравился Eclipse, но там даже 0,7 коньяка едва ли хватит, чтобы разобраться.
Из С/С++/С# поработал с плагинами для Visual Studio, но предпочитаю больше CodeGear 2009 и ему подобные компиляторы с 5-оконным интерфейсом. Засовывать всё в одно окно, как делают это современники - крайне ущербная тактика.
Что примечательно - с каждым из кандидатов общались строго по техническим вопросам, никаких личных или "о жизни". Оба были хорошими техническими спецами (не идеальными, но все люди чего-то могут не знать) которых точно бы наняли если бы не личностные черты.
И это ещё хорошие специалисты? Боюсь представить, как выглядили плохие?! Сочуствую, коллега. Многих повидал на своём опыте, даже близко не походили на изложенное. У нас таких равнодушних неадекватов ни то что на порог не впустили, впринципе ещё постаратся найти надо.
Если бы. Практика показывает, что далеко не из-за давления они это делают. Социальные сети сейчас давят на человека куда больше, чем любой самый что ни на есть эффективный менеджер.
Нормальный руководитель будет собирать команду по уникальным компетенциям и не будет нанимать 100 разработчика, который умеет вращать красночерное дерево, т. к. достаточно одного, максимум двух.
Я приводил практику, руководствуясь элементарным здравомыслием, и тем что прекрасно представляю, в чем состоит работа менеджера среднего звена. Сам же работаю на подобном должностном уровне.
"Если бы я нанимал крепкого миддла и тем более сеньора на постоянную работу, то сразу бы спросил исходник его программы, которой он сам пользуется или сделал так, что хочется ей пользоватся"
Это вообще как? Давайте подумаем.
<...>
Вот и получаем простую ситуацию: я уже полтора десятка лет профессионально программирую, у меня большой послужной список проектов, во всех компаниях, где я работал, моей работой были довольны и коллеги, и руководство, и заказчики - а показать код я не могу. И таких как я тысячи. Что будем делать?
Сделайте любительский проект, чисто для души, который не стыдно показать другим - это более чем достаточно. Одно только его наличие в резюме уже сильно вас выделит. Оправдывать себя мифами о неком "большинстве" больше походит на откровенное инфоцыгантство, чем слова компетентного человека.
Возможно, но это в любом случае намного лучше, чем терпеть этот цирк Шаппито. По крайней мере, если у человека есть уважение к себе и своей профессии, то найти 2 часа и написать одну программу он точно сможет.
у большинства нет на это ни дополнительных сил, ни времени. Семья и отдых дороже.
Если человек ищет работу, то у него точно найдётся и время, и вдохновение.
Мой личный рекорд — 8 этапов-собеседований в течение 1.5 месяцев в яндекс (после такой хрени, я к ним больше ни ногой), прошел из интереса, но пока это все проходило, у меня 4 менее интересных офферов сгорело, одно из которых мне очень понравилось по команде
Мне очень интересно кто тут больше дурак: вы или они? 1,5 месяца на собеседование - это же ещё деградировать до такого уровня надо. Не топ-менеджера же они выбирали, ни директора филиала.
А чем вам C++ не устроил? Ищите лучше хороший компилятор, а не языки. Для C++ по крайней мере есть большой выбор редакторов кода, для всяких ржавчин и змей нет даже и этого.
Мне менеджерам всех компаний хочется воззразить лишь одним словом: "Вы либо крестик снимите, либо трусы наденьте". Что это за цирк Шаппито?! Они что там все совсем джуна нанимают?!
Если бы я нанимал крепкого миддла и тем более сеньора на постоянную работу, то сразу бы спросил исходник его программы, которой он сам пользуется или сделал так, что хочется ей пользоватся, и ограничился только общими вопросами по условиям работы, остальное - покажет только испытательный срок.
Тоже касается и опыта. Тут нужно просто задавать вопросы, а не слепо надеятся, что в резюме всё опишут в подробностях. Был у человека опыт в коллективе, не был - не столь важно, однако если подразумевается что кандидат будет работать в уже существуюшем (!) коллективе, то достаточно спросить об предыдущем коллективе в общих чертах, отношение в целом к коллективу и даже если у человека это первыф коллектив за много лет, то тут нет никаких поводов для отказа. Скорее это подсказка о том, кто с вами (менеджером) будет чаще общаться, а кто предпочитает работать без лишнего внимания.
Если же коллектив молодой или еще формируется, то когда оцениваете возраст кандидата, оценивать стоит его на должность выше или как самого опытного сотрудника среди них и организовывать работу соответствующим образом.
"Сколько времени уйдет на внесение изменений в будущем не понятно. Ведь мы не знаем какого рода это будут изменения и кто их будет вносить." - детально, мы конечно не знаем, но предположить в каких направлениях могут меняться требования - можем (правда для этого требуется опыт решения схожих задач).
Для того, чтобы понять что и куда двигается, достаточно понять непосредственно что вы делаете и для кого, а точнее для какого пользователя вы это делаете.
Бывает, что софт проваливается только из-за того, что держал пользователя за идиота. Аналогично, когда функционал перенасыщен настолько, что основные функции софт уже выполнять не может.
И какого-то особого опыта там не требуется. Его вообщем и не определишь. Погружение в проект давно известная дилемма в управление.
Просто представьте себе картину: Вы привлекаете человека с опытом разработки средних проектов, например, разработчика драйвера под ваше многофункциональное устройство к разработке прошивки для этого устройства. Так вы ещё хотите, чтобы он возглавил всю команду программистов, занимающихся именно прошивкой. Мало того, что это совершенно разные уровни взаимодействия между конструкторами и программистами, так вы ещё ожидаете от него заранее определенных конкретных результатов, едва ли дав ознакомится с содержанием своей работы.
И нет, я не говорю, что это невозможно. Однако, всегда нужно понимать, где что и за чем следует, а не бросаться с голой грудью на амбразуру.
Всё это на заметку автору статьи выше, о том что его старая советская методичка по нормированию в корне неприменима для менеджмента в IT. Об этом тысячи статей и десятки книг уже изданы.
Очевидно, что понятие "качественный" у каждого из них свое. Но как понять, из чего оно складывается?
Парень, это так не работает. Нет там никакой прямой взаимосвязи между понятиями "качественный красивый элегантный код" и "эффективно работающая программа". Такой вопрос не решается вот так в лоб.
В технике вообще часто приходится идти на компромиссы, чтобы добится лучшего результата. В вашем случае, если хотите добится именно "эффективности", то оно решается средствами отладки, а не правилами кодонаписания.
Есть задача и есть 5 вариантов решения (ситуация в статье)
А что если скажу, что все ваши 5 вариантов - это полное гавное, понятное только вам и адептам Java, но совершенно не понятное никому-либо прочитавшему это?
Вы хотя бы знаете что такое комментарии в исходнике?!
Нужно взять самый качественный/лучший/хороший вариант.
И, внезапно, выясняется, что 3 человека выбирая самый качественный/лучший/хороший вариант взяли разные варианты.
Значит более опытные, чем их коллеги оказались. Или менее закомплексованные, что более вероятно.
На месте ваших коллег я бы сразу спросил: А нахрена там эта проверка? Лучше тогда сделать обработку ошибки. И засунул функцию в класс-предок, так как у меня одна функциональность уходит в три разных класса.
Не важно, как написан код, главное чтоб задача решалась?
А в чем тогда цель code review? Внушать программистам волю team lead-а, которому не хватает ума, чтобы набраться авторитета, а назначить из команды мозгов уже менеджерам не хватило? Заражать предрассудками о неком "идеальном чистом коде", попутно вырабатавыя лишь комплекс неполноценности?
Именно такие вопросы приходят на ум, после всего что я тут прочитал.
А если вы хотите узнать о настоящей деловой коммуникации, то советую почитать.
Вообще не надо писать код, надо находить какие-то другие пути?
Нет, я ответ дал в последнем абзаце. Не вежливо, знаете, отвечать человеку не дочитав его сообщения.
Я так скажу. Вообще в программирование нет понятия "эстетики кода". Классики ещё до вашего рождения здесь всё расписали. Мы все когда-то проходили через этап комплекса перфекционизма, когда только начинали программировать, но с опытом приходит понимание и творческое осознание. Именно оно, к слову, отличает начинающего от специалиста, а не какие-то там железные принципы и тем более предрассудки. Михаил Флёнов в своих книгах "Программирование глазами хакера" отмечал это разницей между "хакером" и "крекером" (от англ. crack - "взломать") в самой первой главе.
Спасибо за приятные слова. Зрите прямо в корень! Если бы мог поставить плюс и комментарию, и в карму то уже бы это сделал.
Маленькая программа как раз показывает всё что именно нужно, если вы её не просто читаете, а ещё слушаете прекрасную басню о том, как кандидат её создавал.
Маленькая часть неформальной работы, которую приходится делать каждый день. А мне оно и нужно - всё что вы подразумеваете под профессиональными качествами, не более чем привычки, которые видно даже невооруженным глазом. Талант, как говорится, не пропьёшь.
Вопросы честности, манер, стиля работы и всего остального, что выделенно курсивом как раз прекрасно покажет кандидат за время испытательного срока.
О, и не волнуйтесь, я не увольняю человека только за то, что он приукрасил своё резюме. Мне не важно как человек сделал программу, написал с нуля или адаптировал свои или чужие предыдущие наработки, куда важнее, чтобы работа производилась в приемлимые сроки и проходила ряд требований во время тестирования, то есть программа работала без нареканий.
И для справки: Испытательный срок длится всего 21 день. Эмпиречески уже давно определенный период времени, за который человек сможет как минимум влится в коллектив, а заодно понять всё что ему необходимо. Увы, идеальных компаний здесь не бывает.
Для упращения работы бухгалтерии его обычно назначают кратным 1 месяцу, 3 месяца - это максимальный срок установленный ТК РФ. Вопрос "Кто кого тут обхитрил?" уже риторический, бывает люди назначают бесплатные стажировки, с чем я в корне не согласен. Если человек только набирается своего первого опыта работы в коллективе, то его труд всегда должен оплачиваться.
К чему тогда все ваши притензии? Может тогда это только вы плохо знаете основы программирования и просто невнимательны?
Если вам так нравится Rust, то пишите только на нём. Он же компилируемый, а следовательно на нём можно всё что угодно писать. На черта вы всем вокруг пытаетесь навязывать свои предрассудки как религиозную догму?!
По привычке называю среды разработки компиляторами. Они собственно этим и являются, только отличаются функциональностью.
Справедливости ради, такому человеку и предложить выпить не жалко. По опыту знаю, что в менеджменте нормальные доверительные отношения можно сложить только с людьми, которые как минимум неравнодушны к себе, и как следствие к своей работе.
Один из признаков профессионального роста - это умеренная самооценка.
А я изначально думал, что хотя бы за уважительный тон смогу поблагодарить. Знаете в чем ирония? С вами сейчас и беседовал технический специалист, прошедший только за прошлый год 15 собеседований за 2 месяца при смене места работы.
Но увы, вы слишком часто делаете выводы из глупых предположений. А спросить явно вам либо ума, либо совести не хватило. Жалкое зрелище все ваши отговорки, которыми вы оправдываетесь на том, о чем не додумался всего лишь спросить.
Вы слишком грубы, когда предписываете собеседнику что он никаким образом не имел ввиду. Я ни слова не говорил ни про open source, ни про большие программы. Хватило бы короткого полезного вам кейса, может исходник рабочей программы созданной вами, который скорее всего я потребовал только прокомментировать и рассказать о том через что вы прошли, чтобы его создать. Даже более скажу, вы бы сами охотно так и поступили.
Также никто не мешает спокойно использовать наработки из ранее написанных проектов. За NDA никто вам слова не скажет - попробуйте ещё доказать факт его нарушения. А стучать сам на себя - сами знаете как это выглядит.
Настоящие технические специалисты с хорошим образованием никогда не строят выводы только из предположений, как минимум об этом делают замечание, но, повторю, никогда не аргументируют свои слова таким грубым способом. Как минимум, это проявление неуважения к собеседнику.
И для справки: На более высоких должностях интересуют далеко не базовые вещи, а то что всегда остаётся в глубине. Нельзя построить нормальных отношений с сотрудником, который неуважительно относится к своей профессии, и тем более, если он не уважает даже себя.
Тем более учитывайте, что умение писать небольшие, но полезные программы, куда больше говорит о программисте, чем писать только большие проекты, где далеко не ясно насколько он был в авангарде, а насколько перекладывал свою работу на других.
Например, я использую короткие кейсы для того, чтобы разобраться в новых для себя инструментах. Сейчас, по иронии судьбы, мне нужно перебрать 170 ГБ информации из 60 с лишним тысяч медиа-файлов, из которых полезных фотографий только 24 ГБ. Вручную уйдёт на это годы, а нужную программу написать на понравившемся компиляторе займёт не более чем 2 часа, даже с нормальным оконным UI.
А я где-то говорил об обязательно больших программах? Или где-то, как тут некоторые прикручивали, про open source? Нет, ни единого слова.
Цитата:
Вы поступаете очень невежливо в отношение собеседника, когда пытаетесь приплетать к нему того, что он никаким образом не имел ввиду. Подумайте над этим ещё раз перед тем, как писать свои отговорки.
Интересно, и как это вы себе представляете конкретно для C/C++? Может изначально нужно в стандарте для разработчиков компиляторов ещё прописывать, чтобы интегрировали статические анализаторы, а то программисты совсем не внимательные стали? Вот очень интересно узнать, ответьте, пожалуйста.
Вот пусть и ответит человек выше на этот вопрос. Кому-то функционал подавай, кому-то эргономику.
Из Java-подобных компиляторов мне больше понравился Eclipse, но там даже 0,7 коньяка едва ли хватит, чтобы разобраться.
Из С/С++/С# поработал с плагинами для Visual Studio, но предпочитаю больше CodeGear 2009 и ему подобные компиляторы с 5-оконным интерфейсом. Засовывать всё в одно окно, как делают это современники - крайне ущербная тактика.
И это ещё хорошие специалисты? Боюсь представить, как выглядили плохие?!
Сочуствую, коллега. Многих повидал на своём опыте, даже близко не походили на изложенное. У нас таких равнодушних неадекватов ни то что на порог не впустили, впринципе ещё постаратся найти надо.
Если бы. Практика показывает, что далеко не из-за давления они это делают. Социальные сети сейчас давят на человека куда больше, чем любой самый что ни на есть эффективный менеджер.
Я приводил практику, руководствуясь элементарным здравомыслием, и тем что прекрасно представляю, в чем состоит работа менеджера среднего звена. Сам же работаю на подобном должностном уровне.
Сделайте любительский проект, чисто для души, который не стыдно показать другим - это более чем достаточно. Одно только его наличие в резюме уже сильно вас выделит. Оправдывать себя мифами о неком "большинстве" больше походит на откровенное инфоцыгантство, чем слова компетентного человека.
Возможно, но это в любом случае намного лучше, чем терпеть этот цирк Шаппито. По крайней мере, если у человека есть уважение к себе и своей профессии, то найти 2 часа и написать одну программу он точно сможет.
Если человек ищет работу, то у него точно найдётся и время, и вдохновение.
Мне очень интересно кто тут больше дурак: вы или они? 1,5 месяца на собеседование - это же ещё деградировать до такого уровня надо. Не топ-менеджера же они выбирали, ни директора филиала.
А чем вам C++ не устроил? Ищите лучше хороший компилятор, а не языки. Для C++ по крайней мере есть большой выбор редакторов кода, для всяких ржавчин и змей нет даже и этого.
Мне менеджерам всех компаний хочется воззразить лишь одним словом: "Вы либо крестик снимите, либо трусы наденьте". Что это за цирк Шаппито?! Они что там все совсем джуна нанимают?!
Если бы я нанимал крепкого миддла и тем более сеньора на постоянную работу, то сразу бы спросил исходник его программы, которой он сам пользуется или сделал так, что хочется ей пользоватся, и ограничился только общими вопросами по условиям работы, остальное - покажет только испытательный срок.
Тоже касается и опыта. Тут нужно просто задавать вопросы, а не слепо надеятся, что в резюме всё опишут в подробностях. Был у человека опыт в коллективе, не был - не столь важно, однако если подразумевается что кандидат будет работать в уже существуюшем (!) коллективе, то достаточно спросить об предыдущем коллективе в общих чертах, отношение в целом к коллективу и даже если у человека это первыф коллектив за много лет, то тут нет никаких поводов для отказа. Скорее это подсказка о том, кто с вами (менеджером) будет чаще общаться, а кто предпочитает работать без лишнего внимания.
Если же коллектив молодой или еще формируется, то когда оцениваете возраст кандидата, оценивать стоит его на должность выше или как самого опытного сотрудника среди них и организовывать работу соответствующим образом.
Для того, чтобы понять что и куда двигается, достаточно понять непосредственно что вы делаете и для кого, а точнее для какого пользователя вы это делаете.
Бывает, что софт проваливается только из-за того, что держал пользователя за идиота. Аналогично, когда функционал перенасыщен настолько, что основные функции софт уже выполнять не может.
И какого-то особого опыта там не требуется. Его вообщем и не определишь. Погружение в проект давно известная дилемма в управление.
Просто представьте себе картину: Вы привлекаете человека с опытом разработки средних проектов, например, разработчика драйвера под ваше многофункциональное устройство к разработке прошивки для этого устройства. Так вы ещё хотите, чтобы он возглавил всю команду программистов, занимающихся именно прошивкой. Мало того, что это совершенно разные уровни взаимодействия между конструкторами и программистами, так вы ещё ожидаете от него заранее определенных конкретных результатов, едва ли дав ознакомится с содержанием своей работы.
И нет, я не говорю, что это невозможно. Однако, всегда нужно понимать, где что и за чем следует, а не бросаться с голой грудью на амбразуру.
Всё это на заметку автору статьи выше, о том что его старая советская методичка по нормированию в корне неприменима для менеджмента в IT. Об этом тысячи статей и десятки книг уже изданы.
Парень, это так не работает. Нет там никакой прямой взаимосвязи между понятиями "качественный красивый элегантный код" и "эффективно работающая программа". Такой вопрос не решается вот так в лоб.
В технике вообще часто приходится идти на компромиссы, чтобы добится лучшего результата. В вашем случае, если хотите добится именно "эффективности", то оно решается средствами отладки, а не правилами кодонаписания.
А что если скажу, что все ваши 5 вариантов - это полное гавное, понятное только вам и адептам Java, но совершенно не понятное никому-либо прочитавшему это?
Вы хотя бы знаете что такое комментарии в исходнике?!
Значит более опытные, чем их коллеги оказались. Или менее закомплексованные, что более вероятно.
На месте ваших коллег я бы сразу спросил: А нахрена там эта проверка? Лучше тогда сделать обработку ошибки. И засунул функцию в класс-предок, так как у меня одна функциональность уходит в три разных класса.
А в чем тогда цель code review? Внушать программистам волю team lead-а, которому не хватает ума, чтобы набраться авторитета, а назначить из команды мозгов уже менеджерам не хватило? Заражать предрассудками о неком "идеальном чистом коде", попутно вырабатавыя лишь комплекс неполноценности?
Именно такие вопросы приходят на ум, после всего что я тут прочитал.
А если вы хотите узнать о настоящей деловой коммуникации, то советую почитать.
Нет, я ответ дал в последнем абзаце. Не вежливо, знаете, отвечать человеку не дочитав его сообщения.
Я так скажу. Вообще в программирование нет понятия "эстетики кода". Классики ещё до вашего рождения здесь всё расписали. Мы все когда-то проходили через этап комплекса перфекционизма, когда только начинали программировать, но с опытом приходит понимание и творческое осознание. Именно оно, к слову, отличает начинающего от специалиста, а не какие-то там железные принципы и тем более предрассудки. Михаил Флёнов в своих книгах "Программирование глазами хакера" отмечал это разницей между "хакером" и "крекером" (от англ. crack - "взломать") в самой первой главе.