Или, может быть, вы не пишете Python, JavaScript или что-то еще, как я вырезал это в своем письме. Вот пояснение.
В процессе написания я занимаюсь изучением различных технологий и языков программирования. Я пишу о многих вещах, в которых не разбираюсь. Я пишу о колонизации Венеры.
Подробнее: Зачем колонизировать Венеру вместо Марса
Кто-нибудь всерьез думает, что я обученный космический инженер? Я пишу об архитектуре микропроцессоров, таких как конвейерная обработка, предсказание ветвлений, декодирование инструкций и т. Д. Тем не менее, я не обученный разработчик микросхем.
Подробнее: Зачем нужны конвейеры для микропроцессоров?
Я не ваш эксперт по техническим вопросам. Я популяризатор. Я турист в стране технологий. Я хожу в гости и пишу о том, что вижу. Я даю вам нестандартный опыт. Как выглядит технология или язык программирования для того, кто распаковывает их в первый раз и пробует их испытать?
Поэтому, когда люди говорят: «Вам не следует писать о Python», пока вы не узнаете его лучше, или «вы явно недостаточно знаете о C #, чтобы писать об этом», эти читатели полностью упускают из виду суть. Я даю перспективу для новичков, и это очень важно. Позвольте мне сделать шаг назад, чтобы объяснить почему.
Подробнее: Java и C # устарели в эпоху Docker.
Раньше я работал в компании, где мы создавали сложное программное обеспечение для 3D-моделирования для отраслевых экспертов, таких как геологи, петрофизики, моделирующие пласты, бурильщики и многие другие профессии и должности, о которых я даже не знаю. Это программное обеспечение имело сотни диалогов, в каждом из которых могло быть 10 или более вкладок с несколькими десятками опций для переключения на каждой вкладке. Вдобавок у нас были десятки различных способов отображения одних и тех же данных. Мы могли бы предоставить вам 2D-вид, 3D-вид, вид пересечения или многое другое для целого ряда различных специализированных объектов.
Подробнее: Объекты данных в геологическом моделировании.
Короче говоря, это был сложный процесс, и одна из основных проблем, с которыми мы столкнулись, заключалась в том, что клиенты начинали переходить на конкурирующее программное обеспечение. Но как такое могло быть? Каждый раз, когда мы добавляли новые функции, мы обращались за отзывами к ведущим специалистам по нашему программному обеспечению во всех крупных компаниях. Мы дали им то, что они хотели. Одна расширенная функция за другой.
Вот в чем проблема. Мы только слушали экспертов. Мы забыли послушать обычных пользователей. Новичкам. Хотя меня всегда заботил пользовательский опыт, для меня это было действительно большим началом. Я начал пользовательское тестирование и изучение дизайна графического интерфейса. Я начал тестировать менее опытных пользователей. Быстро стало ясно, что удобство использования не воспринималось достаточно серьезно. Я начал приставать к руководству по этому поводу. Совершенно неожиданно они сделали меня руководителем UX в компании. Полагаю, это то, что вы получаете за то, что у вас болит шея.
Подробнее: Понимание визуального макета в дизайне графического интерфейса.
Так что, если мой код Java, Python, JavaScript, C # или любой другой отстой, то это часть сути дела. То, что я пишу, обычно является результатом рассмотрения общих советов, которые вы найдете в Интернете, в сочетании с чтением официальной документации. Если из-за этого получается дерьмовый код, значит, это что-то говорит о том, как эти языки представляют себя, или о данных советах.
Когда я проходил обучение UX, ответом пользователю, который не мог понять наше программное обеспечение, никогда не было: «Ты глуп и тебе нужно больше практиковаться в использовании нашего программного обеспечения!» Обвинять пользователя не очень продуктивно. Если новички не могут правильно использовать ваше программное обеспечение, вам необходимо подумать о его переработке. Это не всегда вариант, но тогда вы должны быть скромными и признать, что у вас есть проблема, вместо того, чтобы перекладывать вину на пользователя.
Язык программирования не может быть определен с точки зрения того, что может выполнить звездный исполнитель со всеми экспертными знаниями. На это следует смотреть через призму того, чего может достичь средний разработчик. И в этом отношении язык - это не просто синтаксис и семантика в документе спецификации. Скорее, язык - это целая экосистема, которая с ним связана. Сообщество, практики, инструменты и библиотеки. Скажем, есть отличный способ написания кода Java, но если это не доминирующий стиль, практикуемый сообществом, то это откровенно не имеет значения. Средний новый разработчик будет выбирать стиль программирования, который доминирует в языковом сообществе.
Подробнее: Объектно-ориентированное кодирование: Java vs Go.
Это сообщество - продукт всех ваших прошлых ошибок. Если язык вначале пошел по неверному пути, это, скорее всего, будет преследовать вас в течение долгого времени. Таким образом, важно сразу понять основы. Это, ИМХО, часть «особенностей» языка, даже если это не упоминается ни в одном документе спецификации.
Таким образом, если вы жалуетесь на мой стиль кодирования, я призываю вас продемонстрировать, что он идет вразрез с советами сообщества. То, что у вас есть собственный уникальный и превосходный стиль программирования, не имеет отношения к обсуждению.
Хорошо ... Полагаю, я просто поставил себя на линию огня.
