Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Ви для нас занадто розумні

Нещодавно проходив процес найму в одну іноземну компанію. Процес складався з технічної співбесіди і тестового завдання. Співбесіда пройшла успішно і мене запевнили, що, судячи з рівню моїх знань, я легко пройду інші етапи працевлаштування. Однак, коли я зробив тестове, мені скзали, що я їм не підхожу. Мотивували це тим, що в мене дуже зарозумілий код, а саме «hard to follow up the main logic and data flow, application cannot be easy maintained by other developers».

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

Є ще одне питання. Наскільки великиі ризики для компанії з такими «зарозумілими» програмістами? Логіно припустити, що людина зі знаннями і досвідом, яка пише складний код, може так само писати простий код. В будь якому випадку, треба витрачати час на інтеграцію нової людини у виробничий процес.

АПД. Оскільки всі повелися на гучну назву топіку і коментують спершу її, то пояню, що це іронія. Ніхто такого, звісно, не казав.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

hard to follow up the main logic and data flow, application cannot be easy maintained by other developers
в мене дуже зарозумілий код
Ты никогда не задумывался, что тебе еще есть куда рости? А не ты слишком умный?
Логіно припустити, що людина зі знаннями і досвідом, яка пише складний код, може так само писати простий код.
Нет.

«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте»

А з чого ви взяли, що ви занадто розумні (судячи з назви топіку)?

«hard to follow up the main logic and data flow, application cannot be easy maintained by other developers»

Хотілося б побачити ваш код, адже судячи по сказаному можна трактувати, що ви написали спагетті код, котрий нікому не зрозумілий, тому відповідно й відмовили. Без прикладу вашого коду це черговий «ВБРОС»

«hard to follow up the main logic and data flow, application cannot be easy maintained by other developers»
це зовсім не одне й то саме що
Ви для нас занадто розумні
Це швидше: Ти тут наговнокодив тільки не в класичному індус стайл, а з викорисанням всьго взагалі що ти знав, одночасно для маленької задачі, яка того і близько не вимагала.

Звістно це може бути тільки одна з причин, чому тобі відмовили.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Посмотрел код тестового задания на github.com/mihato/500px-API-Test .Несмотря на недосып, не испытал никаких проблем в понимании

main logic and data flow

Более чем понятная и читаемая реализация MVVM в упрощенном виде штатными средствами CocoaTouch. К реализации отдельных классов тоже затрудняюсь предъявить какие-то серьезные претензии. Код-стайл и подходы к реализации бойлерплейта типа
 override func layoutIfNeeded() {         super.layoutIfNeeded()         let y = self.titleLabel?.frame.origin.y ?? self.bounds.height         self.shadowLayer.frame = CGRect(x: 0, y: y, width: self.bounds.width, height: self.bounds.height - y)     }
легко оговариваются конвенциями на проекте и при прочих равных не должны влиять на решение hire/not hire. Видно, что у кандидата есть своя коллекция заготовок: сомневаюсь, например, что кандидат стал бы для такого простого ТЗ писать полноценный кэш — явно взята заготовка, что очень хорошо. Стоит ли для такой простой программы тулить MVVM, абстракции над нетворкингом и т.п., IMHO — стоит . Тестовое задание — это showcase твоих знаний синтаксиса и парадигм языка, паттернов, глобальных архитектур, заготовок. Претензия к тому, что в простой демо-программе использованы сложные подходы предельно неадекватна. Адекватной она может быть только в случае, если одним из требований к ТЗ четко написано «при реализации демо-предложения необходимо использовать Ad Hoc решения и рассматривать демо-предложение, как завершенный продукт». Что лично в моих глазах добавило бы очков конкретно этому демо-приложению? Можно было бы вместо разведения сабклассов Request показать элегантное решение на дженериках. То же самое для класса Loader. Тоже самое для FileCache — приятнее работать с T на выходе, чем с Data. Для Photo и User просится DataConvertible протокол. Можно было бы показать документацию для пары классов, чисто для showcase — понятно, что там все и так самодокументировано в глазах любого иосника. Ну и так далее, есть, что улучшать, но в целом, более чем адекватное демо. Солидарен с мнением, что автору просто прилетел вежливый отказ. Хотя, опять таки, тон подачи топика вызывает подозрения в адекватности автора как личности и возможно отказ прилетел именно оттуда — сказать, что у вас нечитаемый код всега проще, чем сказать, что у вас явный флёр ебанутости. Хотя психически уравновешенный инженер вообще вызывает сомнения в проф. пригодности.

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

Люди від мене постійно чекають підстави на FizzBuzz завданні. Тому я завчасно кажу «тут задача без підвоху, вирішується в десяток рядків, робіть найпростіше рішення».

одна компания дала мне тестовое задание — нужно было устроить свистопляску вокруг графов и было очень большое желание накрутить всякого разного. В задании было указано «production-style code». Переспросила, что насчет перфоманса и мне ответили так: 1) completeness, 2) readability, 3) perfomance. Вобщем, сосредоточилась на паттернах, рефакторинге и названиях переменных. Прокатило.


override func layoutIfNeeded() {
super.layoutIfNeeded()
let y = self.titleLabel?.frame.origin.y ?? self.bounds.height
self.shadowLayer.frame = CGRect(x: 0, y: y, width: self.bounds.width, height: self.bounds.height — y)
}

Я бы джуном даже не взял тебя, если бы увидел такой говнокод. Что это за функция без док блоков? Со стремным названием? У функции и у класса явно нет Сингл Респонсибилити. Почему то это все делается в коллекции (тут вообще волосы дыбом становятся). Это должен быть как минимум presentation layer. И это должно быть ответственностью View (если мы уже говорим про стандартный MVC)

А вот это вообще костыляка ппц
let y = self.titleLabel?.frame.origin.y ?? self.bounds.height

Чувак лучше не выкладывай такое!!!!
Это даже хуже чем спагетти код — это полный месс

ЗЫ, Я просто открыл один класс и просто посмотрел одну функцию

«Стрьомну назву» функції видали інженери Apple: developer.apple.com/…​ew/1622507-layoutifneeded

Це все що треба знати про вашу компетенцію.

Чувак, если не знаешь свифта или iOS — лучше не обсуждай код.

Но вообще этот кусок кода странный, получается что высота shadowLayer (т. е. тени) может быть нулевой, если titleLabel будет равно nil, я правильно понял? ТС, зачем тогда тень с нулевой высотой?

Тінь має санс при наявності title. Нема title — нема тіні. В теорії такого не має бути, бо вьюха створюється з xib’a, але я працюю з оутлетами через optionals.

если в теории нет такого — то объявляй titleLabel как ! и не засоряй код ненужными ? и ??.

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

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

Відомий вислів говорить: «Все слід спрощувати до тих пір, поки це можливо, але не більше того». Повністю з ним погоджуюсь.

Іншими словами можна сказати, що якщо ви щось пояснюєте заплутано, значить ви не досить добре володієте предметом, про який розповідаєте.

наверное очередной нарцисс даже во фразе «hard to follow up...» увидел: «я умный, я классный».

P.S. Это напомнило ситуацию когда одна газета перевела фразу Обамы «Putin is not completely stupid» как «Путин умен»

Ви неймовірно проникливі. Такий точний діагноз, і всього по одній фотографії.

Михайле, пан Микола хотів сказати що влаштуватись на роботу в амплуа д’Артаньяна дуже важко. якщо тімлід задетектає д’Артаньяна коли кандидат пояснює свій код, зразу буде відмова.
Attitude один з ключових і можливо вирішальних факторів влаштування на роботу.Треба не тільки написати код а й допомогти іншим його зрозуміти і донести (а як фірма іноземна то супер культурно i хфрендлі :) ) чому саме так.

Та я не жаліюся. Мене тут одразу розкусили і вивели на чисту воду. Але ніц не можу з собою зробити. З рештою, сам не похвалиш — ніхто не похвалить.

Оцінювати якість «main logic and data flow» неможливо під час співбесіди взагалі за кодом на папірці (чи навіть на компі). Для цього є пробний період. Якщо ці дебілоіди навіть таких простих речей не розуміють — тобі ж краще що тебе не взяли, бо всі косяки бездарного керівництва завжди означають овертайми та погану карму для наступної роботи. Навіть за гарні гроші не треба на таке йти.

був схожий випадок.
після коміта з викрутасом тімлід сказав що викрутас красивий і корисний але гер Вольфганґ (найстарший програміст в тімі) його не розуміє, тому напиши простіше. прийшлося переписувати :)
розуміти KISS супер необхідно як і SNAFU :)

Якщо це в бойовому коді, нічого страшного, іноді буває. Але погодься, на співбесіді таке оцінити неможливо. Звідки вони знають, що б там було в нормальних умовах, якщо є півтони коду для копіпасти.

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

Особисто я вважаю, що він це на сам писав. Принаймні, так подумав тімлід, і почав ставити конкретні питання по коду. Після чого намагалися максимально ввічливо відповісти, пам′ятаючи про те що гарними програмістами не народжуються.

В мене в самого десять років тому було хибне враження, що раз немає бажаючих зв’язуватися з нашим тодішнім проектом на Delphi, то це свідчить саме про нашу нереальну крутість, а не про те, що там просто вкрай погана структура коду (Smart UI в повний зріст, переваги ООП заюзані мінімально) і тому подібне.

Поступово я зрозумів, що писати код, який

CAN be easy maintained by other developers
це чи не важливіше за технічну грамотність. Бо знань набути легше, ніж корисних звичок.

Robert C Martin «Clean code» (Чиcтый код) вам у поміч. Книга, яка розставляє по місцях розуміння того, яким має бути ваш код.

Я з вами повністю згоден. От тільки maitainancy поняття доволі широке. Наприклат, проект може мати просту, але не гнучку архітектуру. Зрозуміти його буде легко, а додавати нові фічі — важко. І навпаки: DI додає магії, важко зрозумілої новачкам, а разом з тим, додає можливостей.

Зрозуміти його буде легко, а додавати нові фічі — важко.
Ну то взагалі болюча тема :-)

Вот по этому и ищут людей, которые могут делать простые и гибкие системы.

А з чого ви взяли, що ви занадто розумні (судячи з назви топіку)?

«hard to follow up the main logic and data flow, application cannot be easy maintained by other developers»

Хотілося б побачити ваш код, адже судячи по сказаному можна трактувати, що ви написали спагетті код, котрий нікому не зрозумілий, тому відповідно й відмовили. Без прикладу вашого коду це черговий «ВБРОС»

назва топіку свідомо іронічна. посилання на код є в коментах.

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

Мене не дуже цікавить конкретно цей випадок. Скоріше, загальне питання в теорії. Після публікації лінки я отримав дві відповіді «Swift не знаю, але...». От і яка мені користь з цього?

І повірте, якщо читати 100500 коментарів, то ряд питань відпадає, бо на них вже відповіли.

так а може в конторі, куди ви влаштовувалися, також swift не знають ? :)
ща ми HR-ів покличемо, вони вам пояснять, що не так з кодом :)))

Ва-первых: ИМХО вакансию уже заняли, а Тебе — нашли к чему придрацца.
Во-вторых, очень советую помнить KISS принцип:
— Correct is better than fast.
— Simple is better than complex.
— Clear is better than cute.
— Safe is better than insecure.
Как известно, «программы пишутся для того, чтобы люди их читали, и только иногда случайно компутеры способны их выполнять» :8) Поэтому понятно написанная программа априори более приятна глазу проверяющего, чем «слишком умная»: этим Вы можете занятся, когда встанет вопрос об оптимизации прграммы.

Safe is better than insecure.

Хм, а в оригинале точно так звучало? А то safe и secure это разные, хоть и родственные понятия.

Так звучало у Саттера и Александреску применительно к С++ ... льохко проверить поиском :8) но оригинал KISS-а восходит ИМХО еще к древнеримской армии :8)

KISS вообще-то Keep It Simple Stupid.

вообще-то если посмотреть линку на википедию, то вариантов много. Этот отражает армейский подход. Те же Саттер и Александреску в применении к программированию раскрывают KISS как Keep It Simple Software.

Это не армейский подход. Это то что я видел много раз: сложно сделать простую систему, легко сделать сложную.
Только недавно видел — хрень глючит, а где — ХЕЗ. Потому что народ сделал систему сложную.

Все правильно. Можете не верить, но это таки армейский подход :) - посмотрите по линку википедию, там ссылка на ВМС США :8) Другое дело, что Вы очевидно сравнили с тем, что более на слуху: «круглое неси, квадратное кати» :) ... нет, речь была не об этом :)))

Да. Я с нашей армией (до АТО) сравнил. Тоесть чем проще — тем лучше. Сложной система станет сама по себе. Упрощай и используй стандартные протоколы/интерфейсы везде где только можно.

— Тестове завдання зробiть // if (position.Rank > Ranks.Junior)
— А ви Google, Microsoft aбо Amazon (Facebook, AirBnB etc.)?
— Нi (ми лiдер ринку/динамiчно розвиваємося/сотнi клiєнтiв/досвiдчена команда та iнша нiсенiтнеця)
— До побачення (горiть в пеклi, хай вам грець etc.)

забей на это — это вежливый отказ. Это вариация на тему " Вам у нас будет работать неинтересно", когда ты им просто не понравился. Первый раз такое мне прислали от Касперского, когда все прошел. А вот второй — довольно интересный случай — есть в Запорожье шарага (не помню, как называется ), которая занимается безопасностью. Отослал им тестовое задание, хрюша отвечает, что тест я прошел, но взять меня не могут, что для них мои скилы очень высокие. Самое интересное было через неделю, та же самая хрюша присылает мне предложение рассмотреть ту же вакансию, на которую они меня тестировали. Я им копию их того ответа и отослал. Больше никаких предложений я от них не получал

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

интересно что человек не делает выводов сразу)))

В современном программировании часто навыки командной работы и бизнес-ориентированность ценятся выше, чем «навороченность» и «крутость» кода, особенно в зарубежных стартапах. Нужно писать быстро, просто и понятно, чтобы оно также быстро и понималось. Все равно завтра выбросят или перепишут :)
В аутсорс компаниях сдвиг больше идет в инжениринг, потому что разработчики там далеки от бизнеса и варятся в своем ООП соку

Код будет? Если нет, то и разговаривать не о чем

В мене на гітхабі, якщо так цікаво.

... а ссылку угадывайте сами

Думав в профілі є... Дивно що ДОУ нема прив’язки Гітхаб акка.
github.com/mihato/500px-API-Test

Тоже свифта не знаю но код не очень читабельный

у-у, swift, сцуко... цікаво...
а що ця штука робить (я так розумію, вставляє картинки у вьюху за певним розташуванням?):

    func viewModel(_ viewModel: PhotosViewModel, didLoadItems count: Int) {
        DispatchQueue.main.async {
            self.hideActivityIndicator()
            guard let viewModel = self.viewModel else {
                self.collectionView?.reloadData()
                return
            }
            let paths = (viewModel.numberOfItems - count ..< viewModel.numberOfItems).map({ IndexPath(item: $0, section: 0) })
            self.collectionView?.performBatchUpdates({ 
                self.collectionView?.insertItems(at: paths)
                }, completion: nil)
        }
    }

paths — це массив int?

коротше func viewModel(_ viewModel: PhotosViewModel, didLoadItems count: Int)
в PhotosCollectionViewController.swift

Тут вроде был тег code, может он спасёт? :)

це якраз з тегом code — без нього ок, але відступів в коді немає.

Какой отличный тег :DD

на виході paths це мавив з IndexPath. тобто: (N ..< M).map({ IndexPath(...) }).

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

@IBOutlet var titleLabel: UILabel?

Вам же надо решать задачу, а не задавать вопросы.

лол, що тут незрозумілого, значення може бути нуль

Частенько встречаются сложночитаемые вещи, вам не соврали. Примерчик:

func showError() {
	let alert = UIAlertController(title: NSLocalizedString("Error", comment:""),
                                  message: NSLocalizedString("Unfortunately an error occurred during image loading. Please try again later.", comment:""),
                                  preferredStyle: .alert)
	alert.addAction(UIAlertAction(title: NSLocalizedString("OK", comment:""), style: .default, handler: { (_) in
        let _ = self.navigationController?.popViewController(animated: true)
    }))
	self.present(alert, animated: true, completion: nil)
}

Надо в этом плане сдержанней себя вести. Не пытаться все впилить в 1 строку. Времена прошли, есть минификаторы кода, в парсерах и интерпетаторах все оптимизируется... Для дисциплинки можете настроить свой IDE так, чтобы все переносил после 80 символов в строке для начала. Ну и в целом мозги перестроить на то, что я пишу код 5% времени, а читаю / пытаюсь в него врубиться — остальные 95%.

ps: для кода тут есть тег pre =) но он не спас

То хєрня, цілком зрозумілий код. Перш за все має бути зрозуміло що ПРИЗНАЧЕНИЙ робити той код, а не ко кожна крапка. Якщо це addAction, то ніхто далі не читатиме, якщо проблема не в екшені. А якщо в ньому — то в парі строчок досить легко знайти логіку.

Значно складніше, коли ця логіка розкидана абстракціями по багатьом різним місцям. Компактність — навпаки, плюс.

Значно складніше, коли ця логіка розкидана абстракціями по багатьом різним місцям. Компактність — навпаки, плюс.
не плюс это, я в институте чтобы было «удобно» код весь форматировал чтобы он полностью от начала до конца а4 листок занял, чтобы вот все — на ладоне, любой вопрос и я тыкнул пальцем в место на листике, а не искать по страницам, код нормально читать было нереально, вот тут тоже самое только в меньших масштабах, отучился мгновено, когда препод вернул со словами: «я не понимаю что тут написано, отформатируй правильно и приходи»

Логика простой задачи должна быть компактной. А вот большие блоки — уже разделены. Грубо говоря, если идёт инициализация Action — то всё что её касается желательно сложить в одном месте, а если нужно куда-то сослаться — желательно написать зачем туда ссылаешься.

Правильно должны быть отформатированы БЛОКИ кода. А не размазывать одну строчку по странице.

Правильный код выглядит так:
if (условие) действие;
if (условие){
действие;
действие;
}
if (условие){
....
150-е действие;
} // end of описание-условия
понятноеДействие(параметр 1,параметр2,шаблонноеПреобразование(параметр3));

Правильный код выглядит так:
нет, правильный выглядит так:

class : interface
{
InjectedDependency{get;set;}
Method()
{
//single responsibility action
}
}

а то что ты написал спагетти называется

Запахло майкрософтом.
Где-то случайно наступил.

так примерно нормальный код и выглядит)

Спагетти есть ХОРОШО до определённой длины. А выбрасывание сущностей во внешние области определения — есть ПЛОХО, если транзакционные затраты на поддержание внешней абстракции не обоснованы выгодой от снижения затрат на поддержание этой же абстракции внутри.

Ключевой принцип ООП — это держать все ингредиенты супа как можно ближе, а не бежать в супермаркет за каждой луковицей или щепоткой соли. Зная кроме программирования ещё и поведенческую психологию, смею утверждать, что именно этот принцип позволяет СНИЗИТЬ ИЗДЕРЖКИ на управление низкоуровневым кодом.

Спагетти есть хорошо и после этой длины, если код хорошо структурирован. Например, книга — это огромный массив информации, организованный по принципу спагетти. И почему-то профессионалы предпочитают иметь книги, чем помощь как в продуктах Майкрософт или Гугл, где есть короткий ответ на каждый вопрос, но его чтобы им воспользоваться — нужно к моменту прочтения знать всё остальное.

Даже в твоём маленьком примере то что ты написал — 100% издержки. Как считаешь, когда у тебя ≈300 внешних инъекций, в них легко разобраться? А если 3000? Так вот, в моём коде их от силы десяток, и по каждой — детальное пояснение: что оно такое, где и чем управляется, от чего зависит, какие значения может принимать, и что там было до того как кто-то влез кривыми руками. Если бы то же самое использовалось локально, это был бы короткий коммент в коде, и тому кто не хочет именно этот участок править — не нужно знать КАК он работает, лишь ЧТО от него ждать.

пост про суп и спагетти :)

Спагетти есть ХОРОШО до определённой длины. А выбрасывание сущностей во внешние области определения — есть ПЛОХО, если транзакционные затраты на поддержание внешней абстракции не обоснованы выгодой от снижения затрат на поддержание этой же абстракции внутри.
тут написано «хорошо — это хорошо пока не плохо, а плохо — плохо, если не хорошо», так что логично предположить что следует брать вариант, когда максимально долго код будет переходит из хорошо в плохо, это то что я написал
Ключевой принцип ООП — это держать все ингредиенты супа как можно ближе, а не бежать в супермаркет за каждой луковицей или щепоткой соли.
oop или ood, или где? а то я про супы не слышал принципа, ни один из принципов не может рекомендовать делать god-классы
Спагетти есть хорошо и после этой длины, если код хорошо структурирован. Например, книга — это огромный массив информации, организованный по принципу спагетти. И почему-то профессионалы предпочитают иметь книги, чем помощь как в продуктах Майкрософт или Гугл, где есть короткий ответ на каждый вопрос, но его чтобы им воспользоваться — нужно к моменту прочтения знать всё остальное. 
ну классно что профессионалы любят книги, говнокод-то тут при чем?
Даже в твоём маленьком примере то что ты написал — 100% издержки. Как считаешь, когда у тебя ≈300 внешних инъекций, в них легко разобраться?
если они логичны, то да, да и вообще зачем? у тебя проблема или расширение будет в одном месте, найди его и делай, найти его в куче файлов будет не сложнее чем в одном файле на 100к строк, зато меняя его не надо будет пересматривать все остальные файлы, а в лапшовом методе придется
А если 3000? Так вот, в моём коде их от силы десяток, и по каждой — детальное пояснение: что оно такое, где и чем управляется, от чего зависит, какие значения может принимать, и что там было до того как кто-то влез кривыми руками.
у тебя явно какие-то личные проблемы в отношениях с внедрением зависимостей, я примерно такое же говорил как и ты, когда не пользовался им и писал нетестируемый хрупкий код, нет проблем сколько ты инжектов не произошло в программе, в реальной жизни нет же проблем с нахождением зависимостей, заболел, пришел в больницу, показали врача, поговорил с ним, получил список лекарств, пришел в аптеку, купил их, прочел инструкцию, выпил, выздоровел, зависимости посчитаем? я 9 насчитал, вроде не сложно вышло; ты же предлагаешь: заболел -> вылечился, остальное прочтешь в мед. карте, там неразборчивым почерком все есть
Если бы то же самое использовалось локально, это был бы короткий коммент в коде, и тому кто не хочет именно этот участок править — не нужно знать КАК он работает, лишь ЧТО от него ждать.
вот это не понял, похоже какое-то административное решение проблем

В реальном мире: заболел, посетил врача, получил рецепт, купил, вылечился.
Если бы писал «правильный» программист, там была бы инжекция типа «парацетамол 500мг в капсулах», и код бы падал потому что в аптеке это прописано как «парацетамол-здоровье 500мг в/к».

На чём акцентирую внимание: человеческий фактор. Люди — самое слабое звено, и самое дорогое. Можно сколько угодно разводить бюрократию под идеального человека, который всё знает и всё помнит. Но в результате вылезут реальные издержки реальных людей. СОКРАЩЕНИЕ количества памяти и логики человека, требуемой для понимания кода — это цель хорошего кода. Всё остальное — бюрократическое говно.

В твоём случае, зависимости типа «болезнь», «врач», «покупка», «лечение» — завязаны на образование, несовешеннолетних к ним даже не допускают [а это 18 лет опыта, на минуточку задумайся], а к некоторым частям — без спец.образования. В развитых странах ещё сложнее. И все эти зависимости ПРОПИСАНЫ в нормативных актах, и нельзя плодить собственных.

В случае программирования — требования такие же. Минимизировать точки разрыва. Потому что они требуют много магии. Являются источниками ошибок. И разумеется требуют тестирования. А для тестирования ты напишиешь что? Спагетти-код, который в свою очередь уже куда менее логичен, и надо удерживать в памяти места сшива, чтобы понимать что откуда.

То есть как правильно? Наследовать логику такой, какая она есть в задаче. И сущности те же. Если есть нужда в дополнительных сущностях — ПРЯТАТЬ в другое место, не смешивая с остальными. Если же есть нужда в инъекциях этих доп.сущностей — лучше избегать инъекции, а инициализировать в коде, явно писать откуда они берутся. Просто потому что в исходной логике их нет, а значит стороннему человеку будет сложно понять что это и откуда. И можно либо хорошо документировать (и получить издержки на чтение документации), либо написать как можно более линейный и понятный пошаговый код.

Цель только одна — выиграть время-деньги.

Локальная сложность намного легче по пониманию (я бы сказал в десятки раз), чем она же выброшенная глобально. Потому не вижу ничего страшного, если сотня-другая строк кода окажется вложенными ЕСЛИ.
Но если локальные шаблоны будут вынесены дальше своего кода — придётся ОБЪЯСНЯТЬ их сущность, структуру, отношение к другим сущностям, и личное мнение автора. Знал бы ты, как потом тяжело этим всем пользоваться даже при качественном разъяснении. Но львиная доля авторов считает что всё это не нужно, в результате — работает по принципу «не дышать», и баги правятся годами.

Особо отличился в этом Drupal — они не только вывели 100500 сущностей наружу, но ещё и вывернули этого дикобраза иголками вовнутрь, так чтобы любая попытка менять код внутри доставляла адскую боль не только при изменениях, но и в процесе работы кода, и при том как другие части дикобраза двигаются.

То хєрня, цілком зрозумілий код.
Не говорил, что он непонятный. С ним можно работать.
Значно складніше, коли ця логіка розкидана абстракціями
Согласен, плодить leaky-abstractions не комильфо. Хотя тоже вопрос философский. Но тут дело в другом. Мне по первому впечатлению захотелось его порефакторить чисто для читаемости. Минимального, но хоть какого-то style guide надо придерживаться. Тем более если это может стать причиной отказа со стороны работодателя.

Мінімальний style guide диктує мова/IDE/системні фрейморки. В цьому він теж є, але не такий очевидний. А відмовляти через відсутність style guide це тупість. Принаймі, це треба обумовлювати на етапі постановки задачі.

Мінімальний style guide диктує мова/IDE/системні фрейморки
это неправда, синтаксис они диктуют и все, а в стайл гайде как раз то что синтаксис не может никак провалидировать

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

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

ну, код и действительно почти не форматирован и слабочитаем,
в серьезных компаниях он не прошел бы автоматическую пре-пуш проверку различными *линтами, ну а потом, после правок, был бы возвращен ревьюером на доработку

удали ссылку лучше ;) пока архитекторы не набежали

Нехай. Як то кажуть: «ваша думка дуже важлива для нас». Та чи можуть архітектори вплинути на самооцінку «нарциса-говнокодера»?

Отказали не из-за кода. К нему могут быть разные претензии (у каждого свои предпочтения), но нельзя сказать что он прямо плох, сложен или нечитаем — даже если человек пишет в абсолютно другом ключе (я например пишу вообще не так) — такими словами он не выразится.
Может быть как человек вы не вписываетесь в команду, может позиция внезапно закрылась чьим-то старым другом, а может вы решили совсем не ту задачу которую было нужно из-за проблем с коммуникацией — но сам код явно не был причиной отказа

We couldn’t find any repositories matching ’grebionkin’

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

Логіно припустити, що людина зі знаннями і досвідом, яка пише складний код, може так само писати простий код.
Нет.
hard to follow up the main logic and data flow, application cannot be easy maintained by other developers
в мене дуже зарозумілий код
Ты никогда не задумывался, что тебе еще есть куда рости? А не ты слишком умный?

та мені вже пояснили, що я

говнокодер и/или овер-инженер
Логіно припустити, що людина зі знаннями і досвідом, яка пише складний код, може так само писати простий код.
Можливо, і може. Але не факт, що буде.
Вони припустили, що ваш код на проекті буде в стилі вашого коду в тестовому завданні.
І зробили висновки, що інші девелопери цей код не зрозуміють.
Підозрюю, що «хотіли побачити» саме стиль, в якому ви пишете постійно, а не «як втиснути в кусок коду всі навороти, які я знаю».

Може бояться що ви швидко переросте ту компанію і підете кудись де зможете себе краще самореалізувати.

Не знаю де ви там слово «зарозумілий» побачили, скоріше вони натякають на спагеті код.

Як відомо, є 4 стадії розвиту дева в плані напсинная программ:
1. Просто і невірно
2. Складно і невірно
3. Складно і вірно
4. Просто і вірно

Варіант 3 поправимий, сумніваюсь що хтось би в такому випадку відмовляв. Так що скоріше всього варіант 2.

Ну тестове наче працювало, я перевіряв...

Забрали сисадмина в армию.
Идут стрельбы, админ отстрелялся и слышит результат:
— Ни одного попадания!
Удивился, почесал затылок осмотрел автомат (проверил магазин, заглянул в ствол...) и грит:
— Ну не знаю... от меня пули ушли. Проблемы на принимающей стороне...

Якщо в вашому коді нема помилок, зверніться до системних програмістів. Хай виправлять помилки у компіляторі.

Не автор занадто вумный, а говнокодер и/или овер-инженер.

«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте»

Логіно припустити, що людина зі знаннями і досвідом, яка пише складний код, може так само писати простий код
Простое лучше чем сложное ))) Наваял бы так, как будто ты на проэкте, коментов побольше, кода поменьше и не через то, что токо узнал и нихера никто не знает. Ну например ты взял и начал фигачить в функциональном стиле или не закаманентил хитровыеаный кусок кода, вот все и дали заднюю...
«hard to follow up the main logic and data flow, application cannot be easy maintained by other developers»
це зовсім не одне й то саме що
Ви для нас занадто розумні
Це швидше: Ти тут наговнокодив тільки не в класичному індус стайл, а з викорисанням всьго взагалі що ти знав, одночасно для маленької задачі, яка того і близько не вимагала.

Звістно це може бути тільки одна з причин, чому тобі відмовили.

«Ви для нас занадто розумні» — це я іронізую. Такого, звісно, ніхто не казав.

если ты иронизировал — то это перечеркивает всё остальное содержание топика. Так о чем топик вообще?

в топіку два питання:
1. чи варто використовувати усіляки патерни і хитрі прийоми для простого тестового, щоб показати, що ти все це знаєш?
2. які ризики для компанії від достатньо розумного/скілового, але який пише складний код?

1. Варто вирішувати задачу, яка стоїть перед розробником. У цьому випадку написати рішення до тествого завдання. Якщо рішення потребує

усіляки патерни і хитрі прийоми
тоді можна і їх використати.

2. Людина буде вартувати більше, ніж компанія може собі дозволити.

2. Людина буде вартувати більше, ніж компанія може собі дозволити.
Грошові компенсації обговорюються при оффері.

мова не про зарплатню. Мова про те, що якщо вони не можуть зрозуміти, що відбувається в твоєму коді, то є ризик, що коли ти звільнися все тобою написане доведеться переписувати наново. Може не доведеться. Але нащо їм ризики? Множ свою зарплатню на весь час що ти пропрацював і десь так на 5... ти один раз її отримав... тепер треба приблизно прикинути що воно робить... переписати... відловити баги... поправити... дописати... заново перевірити... перемога. Ну і варто чекати, кожної твоєї відпустки хтось вішатиметься :-)
З відповіді зрозуміло 1 просту річ. їм не потрібні таланти, їм потрібні люди які просто виконують задачу і яких легко замінити. Корпоративний підхід.

Талант — написать простое и понятное решение для сложной задачи, но обычно нагородят американские горки на простую задачу

не знаю. У нас как-то был боец о котором говорили что он талантище, придумывает отличные простые решения и т.д. и т.п. Только код у него был несопровождаемым. Ну и работало оно где-то так же. В остальном талант — вопросов нет.

Если нельзя поддерживать то это не простые решения

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

очень быстро (в течении пары месяцев) назначили на архитектурно-тимлидскую должность

вау эфект пацан перестал создавать только после того как больше чем полконторы начало только тем и заниматься что сопровождать его код. В итоге выгнали через 2 года. Но два года нам тыкали в него пальцем и заявляли что гений... гений..! в основном разработчики с которыми он лично общался...

очень странно если просто объясняется то так же должно реализовыватся

оно может и должно... но не реализовывалось и не работало вменяемо.

срач с тестировщиками доходил до того, люди просто открывали макет, рядом ставили страницу которая есть. Делали скриншот и подписывали: «ничего общего». Переоткрывали полностью всю фичу которая 3 недели писалась. Это фронт. Бэкэнд начал работать хоть как-то правдиво где-то через полтора года правок другими людьми. Которые получают меньше и не столь гениальны.

То что вы описываете очень странно. Вообще больше похоже на проблемы коммуникации, ибо если есть спецификации то ее и надо делать, за исключением если не был переубежден ПО. но не могу сказать был ли ваш гений прав или нет

тут была история о чуваке, который просидел в опенспейсе год, не написав ни одной стррчки кода, и только через год выяснилось, что он кодить особо и не умеет. Так что «странно» — понятие относительное))

Це вірно, якщо людина працює одна на проекті. Але начебто шукали розробника в команду. І тім лід мав би слідкувати за станом речей на проекті, вести його в потрібному напрямку.

Наразі, серед ризиків я бачу лише витрати на релокейт. Вони чималі, а от чи вільється людина в команду, ще не відомо.

думаю тімлід фізично не здатний за всіма слідкувати і всіх відстежувати як хто що робить

Достатньо слідкувати за людиною перший місяць, пока вона не війде в виробничий процес. А потім наступає момонт, коли тім лід може довіряти кодеру.

І тім лід мав би слідкувати за станом речей на проекті, вести його в потрібному напрямку.
у меня уже левый глаз начинает дергаться, когда я подобное читаю от отечественных программистов. Все им кто-то должен, кто-то что-то обязан, как мама следить и на коленки дуть. А он, весь такой экспириенсед, привык иначе, и пусть тимлид за ним бегает и угадывает-направляет. Если вы устраиваетесь в зарубежную компанию, то забудьте о том, что кто-то нянькой будет. А то блин цены себе не сложат, а потом слезные посты на доу, что не оценили талантище, заковали в бодишопе гринки-зарплаты нет, для нормальных контор слишком умный, поеду домой.

Банальный код ревью никто не отменял. И на нем вполне нужно направлять людей. Сложно, но можно.

Якщо вони не змогли зрозуміти цей код, проблема не в кандидаті, а в ревʼюерах. Дійсно, «занадто розумний».

<div>
1. чи варто використовувати усіляки патерни і хитрі прийоми для простого тестового, щоб показати, що ти все це знаєш?
думаю що ні. Кожну задачу треба вирішувати адекватинми задачам засобами.
Хоча, як на мене, трошки перебор. Навіть якщо в завданні щось не сподобалось то можна як мінімум обговорити. Що якщо пацієнт спеціально старавлся вимахнутись.

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

</div>
<div>

По первому вопросу , требуется оценить задачу и принять решение в выборе технологий, если они не оговорены в ТЗ. Я так понимаю , что ты вместо минимума который необходим, реализовал с помощью всего что знал, чтобы показать себя.
А по второму вопросу, риски самые простые , могут испугался что ты начнёшь пачками использовать проекте новые фреймворки где надо и где не надо и будешь писать код на который трубки много времени для понимания.

А теперь самое главное, забей и ища дальше работу и постарайся не будмать об отказе. Иногда такие вещи нельзя проанализировать и понять.
У меня за карьеру было как минимум раза 3 когда я шёл на интервью , просто потренироваться проходить интервью , так как конторы были явно не айс, отвечал на все, что меня спрашивали , решал все, что просили решить, очень легко и не принуждённо общался с интервьюверами и в итоге меня не брали.
Да бывает когда надо проводить работу над ошибками, после интервью , но иногда это просто отказ:)

</div>
А по второму вопросу, риски самые простые , могут испугался что ты начнёшь пачками использовать проекте новые фреймворки где надо и где не надо и будешь писать код на который трубки много времени для понимания.
не бачу проблеми. якщо йдеш на позицію простого кодера, то тім-лід/тех-лід тобі пояснить, що використовувати, а що ні. якщо йдеш на позицюю того самого ліда, то це твоє рішення і ти зможеш аргументувати плюси/мінуси.
А теперь самое главное, забей и ища дальше работу и постарайся не будмать об отказе.
дякую за підтримку. я не з тих хто дуже париться. мене ці питання цікавлять теоретично.
1. чи варто використовувати усіляки патерни і хитрі прийоми для простого тестового, щоб показати, що ти все це знаєш?
нет
2. які ризики для компанії від достатньо розумного/скілового, але який пише складний код?
умные\скиловые такой код держат у себя на гитхабе, а на работе KISS

Если перевести

«hard to follow up the main logic and data flow, application cannot be easy maintained by other developers»
с дипломатичного английского на русский — то это будет что-то вроде «у нас взорвался мозг и кровоточили глаза от твоего кода».

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

«мироточат» — это если бы Няш-мяш переводила ответ госдепа путлеру

<div>
«че далеко за чертом ходить, у кого черт за плечами»
это из какого его произведения? «Мастер и Маргарита» или «Собачье сердце»?</div>

гоголь «вечера на хуторе...»

«Вечера на хуторе близь поместья Турбиных» конено я знаю это произведение.
конечно я знаю творчество Михаила Афанасьевича Гоголя, это я типа Виктора развлекаю)
вот и сейчас))))

Ну хорошо что не Донцова, не к ночи будет упомянута:)

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