У меня нет иного выбора, кроме как работать самостоятельно, и я не могу найти адекватного решения для того, чтобы осмотреть мою работу, проверить работоспособность, найти кого-то для мозгового штурма идей, обсуждения лучших практик и так далее.
Я думал, что получу ответ через статью Джеффа Этвуда: «В программировании - один из самых одиноких чисел» - лучшее, что я смог найти по этому вопросу, но оказалось, что он просто повторил мой вопрос.
Я знаю такие сайты, как Stack Exchange, и Code Review - очевидный потенциальный ответ, но, как многие оценят, это далеко от идеала:
Несмотря на то, что я не могу перечислить все подводные камни, часто формулирование вопроса и включение его в самостоятельную проблему часто требует столько работы, что к тому времени, когда вы достаточно подготовитесь, вы ответили на свой вопрос более время, чем это заняло бы иначе. Кроме того, сокрытие деталей, чтобы задать четко определенный вопрос, исключает возможность того, что кто-то обнаружит проблемы, о которых вы даже не думали. Кроме того, хотя я не могу понять, насколько быстро реагирует свободная беседа, я не могу придумать какую-либо текстовую интернет-дискуссию. И последнее, но не менее важное: я не хочу публиковать весь свой проект на весь мир, чтобы посмотреть на него до конца вечности по понятным причинам.
Есть ли какие-либо ответы, кроме оплаты консультанта за просмотр моего кода?
Ответы:
Я был на твоем месте, и я не думаю, что есть какое-то простое решение. Оплата консультанта за просмотр вашего кода не является хорошим способом потратить деньги. Если ваша проблема в том, что вы чувствуете себя одиноко и вам не с кем поговорить о программировании, тогда я не могу вам помочь, но если вы действительно заинтересованы в улучшении качества вашего кода, тогда лучше всего его настроить. в сторону и вернуться к нему через неделю или около того. Если код действительно плохой, это будет очевидно, потому что вы не сможете понять его, и вы можете начать рефакторинг, чтобы иметь смысл. После нескольких итераций этого процесса вы начнете замечать шаблоны кода, которые упрощают понимание кода и улучшают качество кода.
источник
Нет.
Мой совет: присоединяйтесь к локальной группе разработчиков и пользователей и обсуждайте свои идеи с другими. Поговорим о вашем дизайне. Спросите других, как они подошли к определенным проблемам.
Если они проверяют ваш дизайн, даже не глядя на ваш код, этого должно быть достаточно.
источник
Существуют методы самопроверки, такие как разработка через тестирование, которая может помочь обеспечить обратную связь. Когда это становится трудно, вы знаете, что ваша архитектура, вероятно, не в порядке.
Проблема решена. Вам не нужна внешняя обратная связь для каждой отдельной строки кода для улучшения, просто хорошая выборка на ключевых дорожках и тщательные самопроверки в промежуточных точках.
Вы должны отказаться от идеи, что вы можете поддерживать тот же уровень качества, работая в одиночку, в то же время, что и человек, работающий в команде. Есть причина, по которой люди работают в командах. Хорошей новостью является то, что у вас нет конфликтов по поводу дизайнерских решений. Плохая новость - у вас нет конфликтов по поводу дизайнерских решений. Надеемся, что дополнительное время, потраченное на поддержание качества, несколько компенсируется преимуществами работы в одиночку.
источник
Я бы рекомендовал создавать как можно больше сетей на конференциях и в местных группах пользователей. Я знаю многих разработчиков, которые все время снимают продезинфицированный код по электронной почте или им только для того, чтобы быть в курсе всех алгоритмов. Нет, это не разговор лицом к лицу, и да, иногда это сложно дезинфицировать код, но время от времени проверка кода мгновенного обмена сообщениями может быть довольно полезной, особенно когда вы отчаянно нуждаетесь во второй паре глаз.
источник
Я нахожусь в подобной ситуации, и я в значительной степени полагаюсь на Stack Overflow для получения отзывов по грубым вопросам. Я также обнаружил, что в силу необходимости записать описание проблемы, ответ часто становится очевидным. Что касается передового опыта, я являюсь разработчиком .Net и использую ReSharper, который будет предлагать варианты хороших практик для кода, который я пишу (который я иногда просто игнорирую - он может быть немного педантичным). Еще одним полезным инструментом является FxCop, который выполняет статический анализ кода и выделяет любые проблемы, которые не соответствуют его набору правил.
В противном случае вы должны прочитать и оставаться в курсе текущих практик. Мне нравится «Утренняя роса» Элвина Эшкрафта за ссылки на то, что нового и улучшенного в мире .Net.
источник
Я бы предложил создать (или найти) небольшую группу пользователей. Сделайте свой код доступным, и заставьте всех совершить его работу - полчаса или больше ежедневно.
источник
Конструктивная обратная связь с моим опытом заключается в том, что в первые годы вашей разработки было бы очень важно, хотя и не обязательно, чтобы опытный разработчик проверял ваш код, чтобы заложить основу. Если у вас есть опыт, вы можете следовать подходу, предложенному @ davidk01, т. Е. Периодически проверять свой собственный код для улучшения качества кода.
источник
Я не знаю деталей вашей ситуации, но там, где я сейчас нахожусь, есть много голодных для опытных студентов, которые более чем счастливы работать стажером и чему-то научиться.
Для вас может показаться дополнительной работой справиться с ними и научить их тому и этому, но мы все были там, когда мы только начали, и я думаю, что теперь наша очередь расплачиваться.
Они не являются экспертами, и они могут даже иногда вводить вас в заблуждение, но обычно они бросают вызов всему и полны идей и отлично подходят для обсуждения, где вы должны защищать каждую деталь вашего кода.
источник
Я испытываю то же самое для> 75% вопросов, которые я публикую.
Тем не менее, это не аргумент, чтобы не беспокоиться об этом. Это эффективно отладка резиновой утки. Вы находите ответы на вопросы, которые, по вашему мнению, могут возникнуть в ответ на ваш вопрос; Это означает, что вы думаете о проблеме с точки зрения разных людей; Это означает, что вы думаете о проблеме со всех возможных направлений; это лучший способ найти недостаток.
В лучшем случае вы убедительно доказали, что явно не можете придумать ответ здесь. В худшем случае вы отвечаете на свой вопрос. Следите за цитатами, потому что это совсем не плохо. Возможно, это было немного неэффективно, но решение проблемы медленнее, чем быстрое решение не решать проблему . В конечном итоге вы быстрее решите проблему.
Дело в точке:
Когда я был начинающим разработчиком, я много раз имел дело со страницей ошибок ASP.Net . Мне нужно было Google сообщение, чтобы выяснить, что не так. может пройти несколько часов, прежде чем я найду правильное решение. Я в основном делал все ошибки в книге, и впоследствии мне пришлось столкнуться с последствиями необходимости отладки проблем.
Теперь, когда появляется ошибка, я уже знаю «обычных подозреваемых» о том, что может быть причиной проблемы. Мой мысленный список «обычных подозреваемых» фактически основан на тех проблемах, с которыми у меня были проблемы больше всего в моей карьере. Если бы я сначала не потратил много времени на поиски в Google, я бы никогда не составил этот список мыслей . Но теперь, когда у меня есть этот список мыслей, я значительно быстрее устраняю неполадки.
Я несколько не согласен здесь. Вы правы, что интернет-коммуникация менее отзывчива, но вы (на мой взгляд) ошибаетесь, что это плохо для вас.
Как одинокий разработчик, вы будете полагаться на отладку резиновой утки. Ключевым компонентом работы RDD является то, что вы ожидаете вопросов, которые может возникнуть у вас у резиновой утки. Вы, очевидно, не можете полагаться на то, что на самом деле говорит резиновая утка.
Когда вы работаете с системами медленного обмена сообщениями (отправка сообщений в StackOverflow или общение посредством написания писем), вы по своей сути заинтересованы в том, чтобы убедиться, что вы правильно поняли это с первого раза. Потому что необходимость исправления ошибки будет медленным и трудным процессом.
Для сравнения, учтите, что в системах быстрого обмена сообщениями (разговор, обмен мгновенными сообщениями) вы можете сразу что-то исправить. Возможность быстро что-то исправить делает людей менее заинтересованными в том, чтобы это было правильно.
Четыре случая:
Основная идея здесь заключается в том, что сложная система обмена побуждает людей к правильным и проверенным фактам обменам . Строгость наказания (= трудный процесс исправления) учит вас не совершать ошибок.
Когда вы делаете MCVE , вы не должны просто создавать его и публиковать в вопросе. Вы должны сначала сделать это для себя , чтобы вы могли изолировать проблему. И затем, когда вы думаете, что проблема больше не может быть уменьшена, и вы все еще не видите причину; тогда у вас есть правильный вопрос для StackOverflow.
Дело в точке:
У меня всегда есть вторая Visual Studio, работающая с простым консольным приложением под названием Sandbox. Всякий раз, когда я сталкиваюсь с технической проблемой, я копирую нарушающий код в песочницу и начинаю играть с ней.
В 90% случаев я нахожу причину проблемы, потому что песочница помогла мне взглянуть на код, вызывающий сбой, не отвлекаясь на окружающий контекст (или, например, на любые неопределенности в отношении значений, которые приходят для разных частей кода.
В остальных 10% случаев у меня остается минимальный код для воспроизведения проблемы, который служит прекрасным примером фрагмента для публикации в StackOverflow.
Когда у вас уже есть MCVE, вам не нужно много личной информации (или компании). Если вы делаете, так как код минимален, легко переименовать вещи в более простой пример foo / bar / baz.
источник