Преодоление медленного решения проблем из-за расширения знаний о том, что может пойти не так [закрыто]

Это беспокоило меня какое-то время, и я очень благодарен за вклад других профессионалов.

Короткий фон: я начал программировать, когда мои родители купили мне свой первый компьютер в 1988 году (в возрасте 14 лет мне сейчас 39 лет). Я последовал за несколькими другими карьерными путями, прежде чем, наконец, стать профессиональным программистом в 1997 году. Возможно, поздний цвет, но так оно и было. Я все еще доволен своим выбором, мне нравится программирование, и я считаю себя хорошим в том, что я делаю.

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

Тривиальный пример: это было просто «хорошо, напишите файл здесь». Теперь я беспокоюсь о разрешениях, блокировке, параллелизме, атомных операциях, косвенных /фреймворках, разных файловых системах, количестве файлов в каталоге, предсказуемых именах файлов temp, качестве случайности в моем PRNG, нехватке электроэнергии в середине любого работа, понятный API для того, что я делаю, правильная документация и т. д. и т. д. и т. д.

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

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

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

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

Как вы справляетесь с этим?

436 голосов | спросил 3 revs, 3 users 65%
Zilk
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

21 ответ


264

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

«Эта компания может сделать это быстрее и дешевле, но действительно ли это сделано? Или вы будете искать ошибки в течение многих лет?»

Кроме того, вам нужно знать и принимать старую идиому: «Совершенно враг добра».

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
177

Похоже, вам пора присоединиться к темной стороне: управление.

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

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

Это работает так же хорошо, когда вы разработчик: создайте временный файл, игнорируя разрешения и конфликты имен - 5 мин. Чистая прибыль, остальная часть команды может начать работать над тем, какой код зависит от наличия этого файла. Это идеальное решение? Точно нет. Получит ли он вас 99%, 95%, может быть, 90%? Да, возможно, будет.

Еще один вопрос: как вы относитесь к техническому долгу? Некоторые люди думают, что это должно быть устранено. Я думаю, что эти люди ошибаются. Так же, как и в бизнесе, технический долг позволяет брать взаймы «деньги» или «время», чтобы быстрее что-то доставить. Что лучше: идеальное решение за 2 года или полный взлом, который клиент может использовать и покупать за 4 месяца? Каждая ситуация другая, но в некоторых ситуациях, если вы ждете 2 года, ваш клиент уже зарегистрируется на вашем конкурсе.

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
91

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

Вы также можете посмотреть здесь: Семь этапов экспертизы в Software Engineering . Это показывает, что производительность в значительной степени является побочным эффектом уровня квалификации. Возможно, вы по-прежнему находитесь в какой-то момент между этапом 3 и 4-й технологией, используемой в настоящее время (уровень владения навыками зависит от технологии, вы можете овладеть некоторыми технологиями, еще изучая других).

Теперь я начинаю с биографических показаний.

Немного контекста. Мне 47. Я начал программировать в 12 в 80-х. В то время как в старшей школе я также работал профессиональным программистом. В принципе, у меня не было столько денег, достаточно, чтобы купить оборудование, но мне понравилось и многому научилось. В 18 лет я начал формальное обучение информатике.

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

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

Я никогда не переставал пытаться программировать. И в какой-то момент он вернулся. Ключом для меня было экстремальное программирование, более конкретно принцип Simplicity: «Напишите простейшую вещь, которая может работать».

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

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

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

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

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

Я также участвовал в XP Dojo в практических кодах каталогов с другими программистами, чтобы усвоить практику XP. Это помогло. Это сделало вышеуказанные формальные методы инстинктивными. Также помогло программирование на парах. Работа с молодыми программистами дает определенный импульс, но с опытом вы также видите, чего у них нет. Например, в моем случае я часто вижу, что они участвуют в чрезмерно сложных проектах, и я знаю кошмар, который может привести к этому. Прошел так. Сделал это. Были проблемы.

Первоочередной точкой для меня является поддержание потока. Быть быстрым действительно удается сохранить поток.

Теперь я вернулся в качестве профессионального программиста, и я считаю, что я лучше и быстрее, с более глубоким пониманием того, что я делаю. Практика TDD я все еще могу быть немного медленнее, чем когда я был молодым быком (и ничего не тестировал), но у меня также нет рефакторинга страха и, конечно же, тратить гораздо меньше времени на отладку (почти нет времени, сделайте это менее 10% времени ).

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
39

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

Либо увеличение недостатков, либо уменьшение ETA

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

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

Когда кто-то принимает это мнение, тогда становятся очевидными два важных момента:

  1. ожидания клиентов должны быть ясными (в любой форме);
  2. Ожидания клиентов всегда могут быть изменены, и это делается через искусство переговоров.

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

Построение F16 отличается от построения Cessna, хотя оба они могут летать.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
24

Простой ответ: принять его.

Во всех системах существуют компромиссы между надежностью, надежностью, безопасностью, скоростью, стоимостью оборудования, стоимостью разработки, временем выхода на рынок, вы называете это. Вы не всегда согласитесь с тем, как клиент делает эти компромиссы, но вы не принимаете эти решения. Все, что вы можете сделать, это предоставить мнение. Разработка программного обеспечения охватывает всю гамму, от «моей личной веб-страницы» до «запуска ядерного реактора», и код должен быть написан соответствующим образом. Если авария означает «перезагрузить мою личную веб-страницу», то кто действительно заботится, если это произойдет? Но если авария означает «Чернобыль», то ваше предпочтение твердым кодам - ​​это что-то немного непринужденное по моему вкусу.

Есть несколько клиентов, которые с радостью согласятся с кодом уровня «Proof of Concept» и запускают его в своих живых системах, и часто у них есть системные администраторы, которые к этому хорошо привыкли. IME их системы, как правило, недоступны в течение часа или около того в середине ночи, когда происходит куча запланированных перезагрузок. Но они приняли бизнес-решение, что именно так они хотят бросить. В идеале, потому что их поле настолько быстро движется, что высококачественный код никогда не будет готов, но часто потому, что они не могут видеть значение (если система «просто работает», они никогда ее не замечают, поэтому эта система не представляет значение для Деньги). Если это вас слишком беспокоит, постарайтесь избежать этих клиентов.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
16

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
15

Истина заключается в том, что современные системы становятся все более сложными. Компьютер теперь похож на ту игру «Jenga», где у вас есть все эти части, опираясь на многие другие. Вытащите неправильную деталь, и у вас есть ошибка, вытащите правильную /необходимую деталь, и вы все равно можете произвести ошибку. Чем сложнее система, тем больше времени вы потратите на размышления о том, как сделать код более надежным и, надеюсь, более безопасным. Скорость была бы неплохой, но я думаю, что в эти дни скорость забирает много места, когда вы слышите в новостях, что компания «XYZ» была взломана, и было украдено 6 миллионов номеров кредитных карт клиента.

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
9

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

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

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

Помните:

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
7

Единственное, что я вижу, это: «Вы становитесь все более ценным».

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

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

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

Мое предложение состояло бы в том, чтобы сосредоточиться на этой части.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
7

, когда в сомнении по умолчанию плохо цитирует Кнута ...

«Преждевременная оптимизация - это корень всего зла».

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

Что действительно работает для меня ...

  1. Напишите модульные тесты, как если бы весь код был выполнен.
  2. документируйте интерфейс.
  3. реализовать интерфейс.

что вы действительно сделали:

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
6

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
6

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

Рассмотрим следующие последствия создания плохо написанного фрагмента кода:

  1. Вся база данных сбрасывается каждый месяц. 48 часов простоя при восстановлении резервных копий.
  2. Записи клиентов имеют сшитую связь. Заказы в размере 200 долларов США отправляются неверным клиентам в месяц.
  3. Приказ застрял в неправильном состоянии один раз в неделю. Заказывайте суда, но склад должен вызывать службу поддержки каждый раз, когда это происходит.
  4. Примерно через две недели приложение выйдет из строя, и пользователь должен повторно ввести данные за 2 минуты.
  5. Один раз в месяц приложение зависает при запуске. Пользователь должен убить процесс и начать все заново.

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
5

Решение состоит в создании набора библиотек с обычно используемыми функциями, которые вы можете повторно использовать для разных проектов. Например. У меня есть библиотека .NET StringFunctions.dll, которая делает такие вещи, как кодирование, шифрование, дешифрование, регулярное выражение и т. Д. Таким образом, мне не нужно постоянно переписывать вещи, которые не меняются.

Наличие обертки для задач создания файлов также имеет большой смысл. В вашей библиотеке может быть обнаружен метод GetFile (), который выполняет все проверки для вас и возвращает нуль или файл (или то, что вы считаете полезным).

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
4

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3

@Zilk, я не большой программист, и я программирую с 1998 года. Даже сейчас я столкнулся с этой проблемой. Но то, что я понял, в конечном счете имеет значение для качества. Если я умру сегодня, кто-то должен уметь записывать то, что я делаю сейчас, откуда я ушел. Такими должны быть стандарты программирования (Universal).

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

Изначально как технический архитектор -> Архитектор решений -> Архитектор предприятия -> Главный архитектор и так далее.

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

Как птица выше, она летает больше земли, которую она может видеть, так это ваш опыт.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3

Другой вариант: прекратите писать код, вместо этого продайте свой опыт в определении проблем заранее.

Другими словами, станьте Консультант .

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

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

Сосредоточьтесь на своих сильных сторонах.
(ну, если это то, что вам нравится ...)

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
2

Моя лучшая рекомендация для вас: строительные блоки.

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

Никто не догонит этого, конечно, не новичка, который тратит 80% своего времени на отладку кода, который не подходит для угловых случаев, которые они не понимают.

Больше всего, не исправить проблемы, которые не могут произойти, например, неправильные разрешения.

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
1

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

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

Поэтому большие успехи в настоящее время и в будущем собираются исходить от программистов - передовых алгоритмов и более эффективного кода.

Если вы посмотрите на GTA 4 и GTA 5, различия будут поразительными. Но они оба работают на одном оборудовании. Это результат очень умной и передовой практики программирования, которая просто не требовалась или не была доступна 10 лет назад.

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
1

Как и вы, я начал программировать в возрасте 14 лет, также когда получил свой первый компьютер (хотя я учился в течение нескольких месяцев в этот момент). Однако сейчас я «только» 33. : -)

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

  • Сколько времени потребуется для правильной обработки этой проблемы в вашем коде?
  • Если вы не справитесь с этим должным образом, насколько вероятно, что эта вещь укусит вас позже?
  • Если это вас укусит, каковы последствия?

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
0

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
0

В словах Эдсгера Дийсктры: «Если отладка - это процесс удаления программных ошибок, то программирование должно быть процессом их ввода». Вы просто делаете меньше из последних, поэтому вам нужно делать меньше бывший. Речь идет только о том, чтобы научиться тратить время на правильное кодирование. Я все еще относительно молодой программист (читай 20ish), и я стремлюсь к тому, чтобы иметь возможность кодировать что-то совершенно правильно. Час планирования и 10 минут кодирования лучше, чем 10 минут планирования, час кодирования и три отладки.

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132