Работа в качестве единственного разработчика: просмотр кода

39

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

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

Я знаю такие сайты, как Stack Exchange, и Code Review - очевидный потенциальный ответ, но, как многие оценят, это далеко от идеала:

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

Есть ли какие-либо ответы, кроме оплаты консультанта за просмотр моего кода?

code-reviews solo-development

— CL22
источник

3

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

— Остин Хайд

23

Вы всегда можете поговорить с самим собой - это особенно хорошо для проверок на безумие :-)

— Дэнни Варод

4

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

— JW01

6

Работать самому может быть лучше, чем работать с идиотами.

— Работа

2

Не совсем решение, но вы можете общаться в чате SO или на соответствующем IRC-канале; это может облегчить бремя работы на себя.

— Тихон Джелвис

36

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

— davidk01
источник

Хороший! ... 15

— Марьян Венема

2

Теоретически это может сработать, на практике НЕТ ПУТИ В АД, он собирается вернуться и посмотреть на код, который он написал 2 недели назад, если он работает. И при этом он, вероятно, не должен .. Если это работает, возвращаясь, чтобы тратить время на это по единственной причине того, чтобы сделать его «красивее» - пустая трата времени, это должно быть сделано, когда и если это затронуто снова.

— Томас Бонини

3

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

— davidk01

@david: вы упомянули, что оглядывались назад на код после определенного промежутка времени, даже если в этом нет необходимости. Изначально вы не говорили, что нужно оглядываться на код только тогда, когда вам нужно сделать это, чтобы добавить новые функции. Так что, если - в соответствии с тем, что вы сказали - вам придется в конечном итоге оглянуться назад на весь старый код, почему бы не сделать так что в данный момент это актуально, а не после определенного периода времени?

— Томас Бонини

3

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

— davidk01

17

Есть ли какие-либо ответы, кроме оплаты консультанта за просмотр моего кода?

Нет.

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

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

— Идиоты
источник

4

Многие профессиональные писатели делают это.

— JeffO

10

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

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

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

Вы должны отказаться от идеи, что вы можете поддерживать тот же уровень качества, работая в одиночку, в то же время, что и человек, работающий в команде. Есть причина, по которой люди работают в командах. Хорошей новостью является то, что у вас нет конфликтов по поводу дизайнерских решений. Плохая новость - у вас нет конфликтов по поводу дизайнерских решений. Надеемся, что дополнительное время, потраченное на поддержание качества, несколько компенсируется преимуществами работы в одиночку.

— Карл Билефельдт
источник

Я не вижу, как TDD является ответом здесь.

— Аарона

1

@ Aaronaught Я нахожусь в той же лодке, что и TS, и я могу заверить вас, что написание тестов (либо до кода, как в TDD, либо после него) - это способ проверить, является ли ваш код вменяемым. Если вы не можете это проверить, это плохо.

— Стийн

1

@stijn: Может быть (несколько) правда, что плохой код труднее писать тесты, но это никогда не невозможно - это то, как устаревшие системы обновляются. Даже если мы принимаем за чистую монету сомнительное утверждение о том, что хороший код приводит к хорошим тестам, обратное утверждение все еще не доказано; прохождение теста не означает, что код имеет приемлемое качество. Фактически, предпосылка TDD - «красный, зеленый, рефакторинг» - по сути означает написание небрежного кода, который проходит тест, а затем рефакторинг его для улучшения качества, поэтому в конце дня вы вернетесь к тому, с чего начали, просто с тестами.

— Ааронаут

2

@Aaronaught: вы действительно делаете правильные замечания, но все же я придерживаюсь своей точки зрения, что тесты - очень очень хороший способ проверить правильность кода (хотя на самом деле это не единственный способ); Опыт доказал мне это, особенно полезно видеть, где SRP сильно нарушается.

— Стийн

@Mark: Это хорошо, но все эти анекдоты стоят даже меньше, чем рекламная заявка «Я потерял 50 фунтов за 2 недели», потому что обсуждаемая вещь даже не была измерена , не говоря уже о наблюдении в контролируемых условиях. Да, есть доказательства того, что TDD уменьшает дефекты перед выпуском, и это здорово; Обзоры кода решают совершенно другую проблему, и нет оснований предполагать, что TDD решает ту же проблему. Модульные тесты «старой школы», вероятно, на самом деле лучше для этого, потому что они накладывают ограничения на тестируемость на отдельные классы, а не на их группы.

— Ааронаут

6

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

— Морган Херлокер
источник

4

Я нахожусь в подобной ситуации, и я в значительной степени полагаюсь на Stack Overflow для получения отзывов по грубым вопросам. Я также обнаружил, что в силу необходимости записать описание проблемы, ответ часто становится очевидным. Что касается передового опыта, я являюсь разработчиком .Net и использую ReSharper, который будет предлагать варианты хороших практик для кода, который я пишу (который я иногда просто игнорирую - он может быть немного педантичным). Еще одним полезным инструментом является FxCop, который выполняет статический анализ кода и выделяет любые проблемы, которые не соответствуют его набору правил.

В противном случае вы должны прочитать и оставаться в курсе текущих практик. Мне нравится «Утренняя роса» Элвина Эшкрафта за ссылки на то, что нового и улучшенного в мире .Net.

— Дэвид Кларк
источник

4

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

— jmoreno
источник

3

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

— Картик Сринивасан
источник

2

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

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

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

— azerafati
источник

2

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

Я испытываю то же самое для> 75% вопросов, которые я публикую.

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

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

Дело в точке:

Когда я был начинающим разработчиком, я много раз имел дело со страницей ошибок ASP.Net . Мне нужно было Google сообщение, чтобы выяснить, что не так. может пройти несколько часов, прежде чем я найду правильное решение. Я в основном делал все ошибки в книге, и впоследствии мне пришлось столкнуться с последствиями необходимости отладки проблем.

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

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

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

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

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

Четыре случая:

Когда я делаю свой личный анализ / список задач как разработчик, я все еще использую ручку и бумагу. Я заметил, что при печати своих заметок я замаскирую предположения и ложь, потому что мой разум думает, что «я могу легко это исправить позже». Однако необходимость исправлять то, что вы написали на бумаге, раздражает, вам нужно вычеркивать и писать между строк, и документ выглядит намного хуже, когда на нем есть надписи. Письмо на бумаге заставляет меня проверять факты, прежде чем я начну писать. Это рано улавливает множество недоразумений, еще до того, как я напишу код, который будет вызывать ошибки.
Моя бабушка была секретарем (возраст пишущей машинки). Создание опечатки в официальном документе означало необходимость повторного ввода всей страницы. Моя тетя - секретарь (возраст текстового редактора). Она может положиться на автоматическую проверку орфографии, и ошибки могут быть исправлены легко и с минимальными усилиями. Неудивительно, что моя бабушка делает гораздо меньше ошибок при наборе текста и орфографических ошибок по сравнению с моей тетей.
Видеоигры раньше печатались на картриджах. Исправление ошибки после выпуска было почти невозможно. Вам нужно будет перепечатать все картриджи, распространить их среди всех продавцов и надеяться, что продавцы смогут как-то связаться с покупателями, которые уже купили игру. Это будет стоить кучу денег (удвоить физическую стоимость производства) и все равно не достигнет некоторых клиентов. Сейчас, в эпоху интернет-патчей, разработчики игр значительно меньше инвестировали в тестирование своих игр, чтобы избежать ошибок, связанных с выходом, потому что гораздо проще просто отправить исправление каждому клиенту напрямую. Последствия ошибки сводятся к минимуму до такой степени, что после факта лучше исправить несколько проблем, по сравнению с необходимостью проверки на все возможные ошибки, которые могут возникнуть.
Раньше я жил в трехэтажной квартире без лифта, и мне приходилось парковать одну или две улицы из моего здания. Я почти никогда не забывал взять что-то из моей машины. Теперь я живу в доме с моей машиной рядом со мной на дороге. Я забываю брать вещи из машины все время .

Основная идея здесь заключается в том, что сложная система обмена побуждает людей к правильным и проверенным фактам обменам . Строгость наказания (= трудный процесс исправления) учит вас не совершать ошибок.

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

Когда вы делаете MCVE , вы не должны просто создавать его и публиковать в вопросе. Вы должны сначала сделать это для себя , чтобы вы могли изолировать проблему. И затем, когда вы думаете, что проблема больше не может быть уменьшена, и вы все еще не видите причину; тогда у вас есть правильный вопрос для StackOverflow.

Дело в точке:

У меня всегда есть вторая Visual Studio, работающая с простым консольным приложением под названием Sandbox. Всякий раз, когда я сталкиваюсь с технической проблемой, я копирую нарушающий код в песочницу и начинаю играть с ней.

Что происходит, когда я меняю этот параметр?
Могу ли я воспроизвести проблему, если укоротю код?
Какие настройки позволяют / невозможно воспроизвести проблему?

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

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

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

Когда у вас уже есть MCVE, вам не нужно много личной информации (или компании). Если вы делаете, так как код минимален, легко переименовать вещи в более простой пример foo / bar / baz.

— Flater
источник