Как Вы заставляете людей оценивать абстракцию и гибкость по “просто получению сделанного”?
Изменение моей выборки на полный URL-адрес и удаление учетных данных: «include» работал
импорт выборки из «isomorphic-fetch»;
export function saveData(rec) {
debugger
return function(dispatch){
var url = 'http://localhost:3001/api/v1/charts';
return fetch(url, {
method: "POST",
headers: {
'Accept': "application/json",
'Content-Type': "application/json",
},
body: JSON.stringify(rec)
})
.then(res => {
return res.json()
}).then(data => {
debugger
dispatch({type: 'ADD_CHART', payload: data})
})
}
}
11 ответов
Убедите их, что поиск легких путей является ложной экономикой.
Объясните, что начальное усилие по кодированию составляет меньше чем 30% усилия по начальному развитию и меньше чем 10% (по моему опыту), полного усилия проекта (включая обслуживание).
Если они остаются при своем мнении, и у Вас есть полномочия, чтобы сделать так, затем сказать им делать это Ваш путь. Если у Вас нет полномочий, то не сделайте ничего иного. В конечном счете Ваш супервизор, если она стоит чего-нибудь, распознает это, и Вы затем будете в положении полномочий.
Сделайте, чтобы они работали над некоторым унаследованным кодом, исправляющим ошибки в нем. Это в значительной степени, как большинство людей, которых я знаю, извлекло эти действительно ценные уроки... твердый путь.
"Легче", когда? Теперь, когда все не в состоянии потока? Или три месяца с этого времени, когда требования клиента изменились и у них есть 'решение', которое не является решением еще?
Я не очень для структуры и правил ради структуры и правил, но хорошо знать A), кто управляет лодкой B), что правила и C), почему мы приняли решение сделать это этот путь.
В моем магазине нам не нравится должными быть переписывать код, потому что мы завинтили и hardcoded набор материала или создали некоторое хрупкое 'решение' проблемы. Это имеет тенденцию не быть немного тяжелее для следования за более гибким подходом, после того как люди понимают, что это уменьшит разочарования позже, когда вещи будут перевернуты вверх дном набором изменений требования. Мы кодируем для 'долгого пути' не для 'потребности его сегодня', обычно, таким образом, дизайн сделан по причине и дизайну, сопровождается по той же причине.
Я провел неделю своей жизни (7 дней прямо) перезапись модуля, потому что я был в, 'получают сделанный быстрый' режим. Семь дней изнурительного времени, дни 10-12 часов, делая его правильный путь, поздно в игре, когда я, возможно, смотрел Супер Боул. Вонявший. Я извлек урок там. Может случиться так, что Ваши 'друзья' должны будут испытать такое сенсационное сообщение сами также.
Всего наилучшего
Я на самом деле очень не хочу взять особое мнение об этом, но...
Заключить Van Halen в кавычки (заключающий клише в кавычки), "существует время и место для всего". В то время как я, конечно, не рекомендую писать плохо, когда-либо, иногда действительно необходимо было просто сделать его и найти, что золотая середина между устойчивым/устойчивым и взламывала/документировала. (Зарегистрированная часть, являющаяся особенно важным, на двух передних сторонах: один, что Вы ясно указываете, что независимо от того, что это, Вы делаете, делается просто в интересах получения сделанного и берет определенные ярлыки; и, два, общее представление, относительно какой более корректный способ приблизиться к проблеме мог бы быть.
Как программисты, мы часто стремимся написать идеальный код (хорошо, некоторые из нас делают), и иногда теряйте из виду большое изображение - существуют всевозможные причины, почему могло бы быть нормально (на уровне) играть быстро и освобождать с кодом при уменьшении влияния, которое будет иметь в будущем.
Не используйте это в качестве выравнивания - правило 80/20 применяется здесь, конечно. Большую часть времени Вы абсолютно хотите сокрушить любые ярлыки вдоль этих строк; но иногда...
Лучшая вещь состоит в том, чтобы, вероятно, продвинуть их управление, таким образом, они не могут нанести вполне такой ущерб.
Покажите им! Позвольте им выполнить в маленьком модуле, "Но это было бы легче". разработайте, в то время как Вы делаете это правильный путь. Затем попросите, чтобы они внесли 2 - 5 изменений в требования (это должны быть они вносящий изменения), и имейте синхронизированный конкурс при реализации изменений. Может потребоваться день или два, но они получат его. Если Вы не сделаете, то у Вас будет то же обсуждение каждого нового проекта или задачи.
Проблемой является большинство людей, даже не знают о разработке программного обеспечения кроме наиболее фундаментальных понятий и перетаскивают разработку стиля. Для каждого разработчика, который исследует и узнает обо всех лучших новых понятиях и технологиях, существует десять, кто идет домой и не смотрит на ПК. Необходимо преподавать их.
Вы могли попробовать аналогию на них....
Правила шахмат довольно просты. Можно преподавать их ребенку: "лошадиные перемещения как это", "замок перемещается как это", и т.д.
Если это - все, что Вы знаете, можно играть в некоторые шахматы и вероятно хорошо провести время, но кто-то с более глубоким знанием игры собирается вытереть плату Вами каждый раз. Вы будете избиты настолько плохо, это даже больше не будет забава, потому что Вы будете понятия не иметь, как они делают его.
Тот же принцип относится к программированию. Знания синтаксиса языка и нескольких простых структур данных достаточно для получения Вас рабочая программа, но Вы не собираетесь иметь много удачи с крупномасштабным приложением, которое должно пережить несколько циклов выпуска.
Шахматы установили открытия, стратегии нападения, и т.д. У нас есть Шаблоны разработки.
Я разработал большую и сложную систему приблизительно пять лет назад. Я провел следующие пять лет, вводясь в каждый проект, который влиял на "мою" систему, чтобы помешать варварам пятнать мою архитектуру. Пока я оказал постоянное, неумолимое давление, я смог сохранить архитектуру довольно чистой, но я терпел поражение. Вот то, почему:
1) Большинство людей оценено на том, сделали ли они задание сегодня. Никому никогда не делали выговор, потому что они сократили угол (или два) три года назад для получения проекта снаружи вовремя. С другой стороны, многим людям сделали выговор за то, что они не получили проекты снаружи вовремя.
2) Можно хотеть сохранить систему опрятной, потому что у Вас есть смысл владения по коду, или приложению или пользователям, и т.д. Многие люди не будут иметь смысла владения и поэтому слишком рады изрубить что-то так, что они могут быть сделаны с ним. Можно привести лошадь орошать, но Вы не можете заставить его заботиться.
3) Если Вы действительно убедите всех поддерживать код правильно, то новые люди попадут на борт и должны преподаваться, как сделать вещи правильно. Таким образом, даже если Вы успешны, можно чувствовать, что перестали работать, потому что Вы всегда ведете тот же бой против новых противников.
4) Вы могли бы на самом деле быть неправыми. Имело бы финансовый смысл для Microsoft проводить вдвое больше часов программиста, делая Краску MS устойчивой и удобной в сопровождении? Иногда ужасная вместе взломанная система Достаточно хороша. Самые хорошие программисты испытывают затруднения при понимании этого, но это обычно, потому что они - хорошие программисты.
5) Я клянусь, что существуют некоторые люди, которые получают извращенное удовольствие от взламывания вещей вместе или потому что они могут сделать это быстрее, или они будут единственными, кто понимает это, или у них есть ребяческая потребность нарушить правила. Вы не можете рассуждать с этими людьми, и чем больше времени Вы проводите утверждение с ними, тем ближе крайний срок проекта добирается, который вынудит Вас взломать что-то вместе так или иначе.
6) Существует хороший шанс, Вы понимаете систему лучше, чем они. То, что похоже на ужасный взлом Вам, могло бы быть похожим "на поступь слегка" человеку, который не так знаком с системой. Или дополнительное усилие сделать код устойчивым защитит программиста от проблемы, которую он никогда не имел прежде, и поэтому не может grok. Вы не учитесь проверять коды возврата, пока что-то не идет не так, как надо, потому что Вы не проверяли код возврата. В той точке это прекращает быть "дополнительной работой" и начинает " требоваться работа".
Если у Вас есть малочисленная, трудная группа разработчиков, это возможно. Но чем больше организация, тем менее вероятно необходимо успешно выполниться. Если Вам удается заставить отдел ИТ с 250 людьми оценивать делающие правильно вещи по выполнению вещей быстро затем, Ваши полномочия убеждения легендарны.
http://catb.org/jargon/html/L/LART.html SCNR, и т.д. стр ;)
Скажите им читать (не, что они когда-либо будут), теория Инкапсуляции: http://www.edmundkirwan.com/