Быть строгим или прагматичным?

Я начинаю понимать, что разработка программного обеспечения - это (помимо прочего) процесс постоянного задавания себе вопросов. Вопросы относительно качества кода, разделения проблем, минимизации зависимостей, ...

Но главный вопрос: как далеко вы можете пройти, не попав в психиатрическую больницу?

Я подаю заявку на новую работу. Вчера я был с возможным будущим работодателем, который хотел проверить мои возможности программирования. Одним из упражнений было: объяснить, что делает этот код. Я просмотрел некоторый код приложения (winforms in vb.net), который они разрабатывают (это административное приложение для больницы). Это дало мне возможность реально увидеть, как они подходят к вещам, и это было довольно обидно.

Несколько примеров:

• Я где-то видел: Позвоните [введите название подпрограммы здесь] -> Я был поражен: разве это не что-то из VB6?
• У них есть отдельный слой данных, использующий ado.net, но один метод, который мне пришлось изучить, возвращает набор данных на вызывающий слой. Таким образом, отдельный слой данных или нет, приложение привязано к ado.net (что также никогда не будет проблемой, если они никогда не переключатся на другой подход к доступу к данным).
• Этот набор данных читается как есть, поэтому он по-прежнему ориентирован на данные (конечно, можно поспорить, сколько логики / поведения вы можете поместить в такие классы, как «Patient» или «LabAnalysisRequest»).
• Я также считаю, что видел конструирование SQL-запроса путем конкатенации строк.
• Они используют хранимые процедуры (что для меня означает: рассеяние логики)
• нет упоминаний о представлениях / контроллерах: все это зависит от формы
• Самое ужасное, что я видел, было:

      Если TestEnvironment.IsTesting то
         someVar = [жестко закодированное значение]
      еще
         someVar = [некоторое динамически полученное значение]
      конец, если
      [Остальная часть функции здесь]
  

Все это так сильно отличается от того, что я изучал в школе: (постоянный уровень) уровень домена, постоянный уровень, уровень представления, модульное тестирование, ...

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

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

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

Да, в отрасли, с десятилетней устаревшей базой кода, которую со временем взламывали три десятка разработчиков с разным опытом, навыками и увлечением, обусловленными жесткими сроками, нехваткой ресурсов и финансовыми ограничениями, код никогда не будет посмотри, как ты (должен) узнал, это должно выглядеть. Вам придется пойти на некоторые уступки. Но сколько и где вы проводите черту, зависит только от вас.
Конечно, труднее найти меньше уступок, на которые вы идете. Но они могут быть более приятными.

FWIW, я до сих пор (> 10 лет в отрасли) никогда не работал в большой компании со многими разработчиками (~ 30 разработчиков было больше всего, дюжина норм), потому что гораздо более вероятно, что вы что-то измените в маленьком Компания. Пока я зарабатываю достаточно денег, чтобы не голодать детей, я не хотел бы быть маленькой шестеренкой в ​​большой компании, где все, что мне нужно сделать, - это синхронизироваться с остальными механизмами.
Я отклонил предложения о работе после просмотра тестов, которые они хотели, чтобы я прошел. Я - разработчик C ++, и есть много тестов C ++, которые настолько плохи, что заставляют ногти на ногах отвращаться, и я не хочу тратить свое время на борьбу с ветряными мельницами, потому что они наняли дебилов, которые не могут писать чистый код.
Я также оставил работу через несколько месяцев, потому что их философия программирования (краткосрочные цели, не говоря уже о следующем году) не соответствовала моим способностям (долгосрочная стабильность кода), несмотря на то, что в интервью они говорили по-другому.

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

Вот список вопросов, которые я составил, которые определят, насколько хорошо вы вписываетесь в стиль программирования компании.

1. Насколько они ценят время установки для рефакторинга и обновления своей базы кода. То, как они видят обновление кодовой базы, будет основным определяющим фактором того, насколько хорошо вы подходите.
2. Как часто они покупают третье лицо вместо того, чтобы кодировать на месте.
3. Что они думают о программном обеспечении с открытым исходным кодом. Они понимают, что они имеют гибкость в изменении кода. Они смотрят на это так же, как на покупку третьей стороны.
4. Вы будете работать над определенным уровнем абстракции. Команда, с которой вы взаимодействуете, определяет ваш интерфейс для вас? Какой уровень / команда / сторона интерфейса имеет больше возможностей при принятии решений.
5. Сколько надзорных слушают программисты при принятии решений. Когда программист бросает красный флаг, надзор останавливается и пересматривает свое решение.
6. Считаете ли вы менеджмент опытных программистов? Как они видят свой опыт? Является ли их опыт действительным? Позволяют ли они устаревшему опыту влиять на принятие решений?
7. Насколько липкой является база кода?
8. Как часто они обновляют свои инструменты программирования (IDE и т. Д.)

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

Догма неизбежно будет сломана (у нас просто нет времени обновить X). Тем не менее, приоритеты будут определять, насколько вы сталкиваетесь с их стилем и принятием решений.

Я думаю, что вы должны взвесить это как часть целого. Я помню, что одна из моих первых работ была должность в группе, которая говорила мне, что они занимаются объектно-ориентированным C ++ - это то, что я только что сделал в школе несколько лет.

Их самооценка была неправильной - они делали несколько коренастый Си. Он все еще был очень функционально спроектирован по своей природе, и мне пришлось взять себе книгу по Си, чтобы научить себя printf, getf и другим механизмам Си, которые я никогда не изучал. Тот факт, что никто в команде даже не осознавал, как C нравится их код, указывает на то, что этот «дизайн C ++» потерпел неудачу. Моя цель в то время состояла в том, чтобы заняться разработкой ОО, так что это было немного неприятно.

Но я в конце концов рад, что застрял в команде. Они были динамичной группой очень умных людей, и я промок от множества трудных проблем, мне пришлось работать весь жизненный цикл, и то, что я узнал о проблемной области (PKI), подпитывало мою карьеру с тех пор. Работа, которую команда выполняла в функциональном пространстве, была удивительной, и я до сих пор очень люблю этот продукт и этот опыт работы. Еще лучше - я все еще работаю с некоторыми из этих людей сегодня (несколько компаний позже), они все еще вдохновляют, и мы все еще делаем хорошую работу.

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

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

Самое важное, что нужно помнить здесь, это какова ваша цель ?

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

Хороший код - это инструмент, который вы должны применять там, где он дает вам хороший ROI.

Несколько примеров:

1. Я потратил бы много времени на разработку и кодирование моих API, особенно API моего бизнес-уровня. Многие другие программисты собираются использовать их, и это сэкономит много времени и проблем, если они правильно спроектированы
2. Я немного ослаблю правила на своем уровне презентации. Там я буду более склонен жертвовать «совершенством» кода в пользу добавления новых функций

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

Я работал в розничной сети электронной коммерции в течение нескольких лет. Когда я начал там, код для их внутренних приложений был написан на VB для MS Access, и это было, по меньшей мере, ужасно. У меня была команда из 3 разработчиков, и в течение следующих нескольких лет мы заменили это соответствующими приложениями VB.Net.

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

А потом я начал работать с моими парнями. Немного обучения OOD, дизайну баз данных, MVC и C #. И с годами все улучшилось. Когда я ушел через 4 года, кодовая база была все еще не очень хороша, но в 100 раз лучше, чем когда я начинал.

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

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

Я думаю, что придерживаться ваших принципов очень важно. Вы всегда должны стремиться создавать лучший код из возможных ограничений. Однако, если вы добавите в список принципов «никогда не придется читать или изменять плохой код», вам будет очень трудно найти работу. Помните, что 50% программистов получили высшее образование в нижней половине своего класса. Даже в команде из одного человека «сегодня ты» лучше подготовлен для решения проблемы, чем «ты в прошлом месяце». Возможность работать с неидеальным кодом - это только часть работы.

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

В 99% случаев вы должны придерживаться «догмы», как вы ее называете. Догма сделана опытными людьми за годы практики, и то, что кажется прагматичным в какой-то момент, действительно часто не так. Это обычно более актуально, чем тот факт, что вы недостаточно хороши, чтобы правильно решить эту проблему.

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

Будьте строги, когда это важно. Стиль скобок (или другие правила кодирования)? Это не важно Используйте тот, который использует магазин. Нарушение инкапсуляции (или других фундаментальных принципов программирования) без уважительной причины? Не так тривиально.

Stack Exchange использует таблицы для разметки (как и многие другие крупные сайты, которые зарабатывают деньги ). Это заставляет дым выходить из ушей пуристов? Конечно, это так. Но прагматизм побеждает чистоту, каждый раз. Доставка продукта выигрывает, получая его идеально, каждый раз.

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