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

1) Масштабирование

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

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

2) Безопасность

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

Итак, давайте рассмотрим пример: вы написали API для вставки некоторых данных в вашу базу данных MySQL, которые были запрошены клиентом. Вы обрабатываете запрос, бум! теперь вся ваша база данных повреждена.

Как это вообще произошло? ваш код почти такой же, в нем ничего не изменилось, это была очень специфическая операция, но затем она привела к повреждению всей базы данных. Ответ здесь - атака с использованием SQL-инъекции. В ваш API был отправлен вредоносный скрипт SQL в форме, он не был проверен или дезинфицирован, и этот скрипт был выполнен вашим API.

Это один из примеров, которые я привел. Если вы прочитаете 10 самых популярных уязвимостей OWASP, вы узнаете больше о таких атаках, которые происходят ежедневно.

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

3) Чистый код

Позвольте мне быть честным, у меня есть личные чувства по этому поводу.

Мне есть чем поделиться ...

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

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

В одном из выступлений Google поделился статистикой, согласно которой мы читаем код в 80% случаев и пишем только в 20% случаев. Это огромная доля. Теперь вы должны понять его серьезность, написав чистый, четко определенный код, который легче читать и может передать то, для чего он предназначен.

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

4) Тестирование

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

Выслушайте мою часть, а затем решите, имеет ли это смысл или нет.

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

Как этого избежать? начать писать модульные тестовые примеры, интеграционные тестовые примеры. Да, вы можете писать эти вещи. Хорошая часть состоит в том, что вы пишете это один раз (хорошо, еще несколько раз), но это облегчает вашу тестовую часть. Теперь, как и в приведенном выше случае, допустим, вы ранее написали модульный тест для проверки функциональности этой формы. Теперь, когда вы вносите изменения, все, что вам нужно сделать, это запустить пример модульного теста, если он пройдет успешно, тогда вы можете быть уверены, что базовая функциональность по-прежнему функционирует. Если он сломается, вы узнаете об этом еще до того, как попадете на производственные серверы. разве не здорово знать такие вопросы заранее. Автоматизация повышает вашу эффективность за счет исключения ручного тестирования, которое подвержено человеческим ошибкам. Подобные тесты автоматизации выполняются довольно быстро, а их интеграция с инструментом CI / CD снижает трудозатраты.

5) Принимая во внимание сложность пространства и времени.

Большинство из нас узнали, что Big O - лучшая временная сложность, но думали ли мы когда-нибудь о ее применении в сценариях реальной жизни? Это то, что вы можете связать с первым пунктом этой статьи. Поскольку эти обозначения зависят от размера ввода, это определенно влияет на масштабируемость.

Допустим, у нас есть единственный цикл for, если мы выполняем на N входах, его временная сложность составляет O (n), что является наилучшим сценарием. Но если у нас есть вложенный цикл for, его временная сложность будет O (n ^ 2).

Если для обработки одного ввода в цикле for требуется 2 секунды, а у нас есть 10000 входов, то общее время выполнения будет 20000 секунд. тогда как во вложенном цикле for для того же сценария это будет 10000 * 10000 * 2 = 200000000 секунд.

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

6) Подумайте, прежде чем писать.

Я узнал об этом от одного из своих наставников из-за постоянных нападок, но это определенно сослужило мне хорошую службу. Многие из нас делают то, что, как только формулировка проблемы приходит к нам, мы начинаем думать о том, как ее реализовать. И какое бы первое решение ни пришло нам в голову, мы его записываем. Код идет на тестирование и бум! Тестировщик создал для нас много билетов, и в следующий момент ваш менеджер узнает об этих билетах и ​​начнет бить вас. Почему? потому что вы не продумали все возможные случаи / сценарии. Разработка программного обеспечения - это все о сценариях, которые могут возникнуть во время его выполнения.

Давайте возьмем очень простой пример калькулятора. попробуйте погрузить любое число на ноль, и калькулятор скажет вам, что он не может разделить его на ноль. Теперь, если бы калькулятор не справился с этим достаточно хорошо, вы бы по-прежнему доверяли и использовали тот же калькулятор? Ответ должен быть «Нет». То же самое и с любым навыком решения проблем. Всякий раз, когда вам предлагают формулировку проблемы, потратьте не менее 60% времени на размышления о возможных путях решения этой проблемы. Если вы потратите достаточно времени, вы всегда обнаружите, что есть несколько способов решить эту проблему. И как только вы исключите все возможные сценарии, это решение будет наименее подвержено ошибкам и ошибкам. Вероятно, он будет использовать меньшее количество LOC, его будет легко поддерживать и легко читать.

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

Немного обо мне…

Я работаю в индустрии программного обеспечения с 2015 года и с первых дней занимаюсь разработкой полного стека. Сделав много ошибок (я много имею в виду), теперь я хорошо разбираюсь в Angular, .Net Core, RDBMS и NoSQL, NodeJS. В настоящее время переходит к методам DevOps. У меня есть практический опыт работы с Azure, AWS и Alibaba Cloud.

Если вам есть что обсудить, прокомментируйте ниже, или мы можем обсудить это через мой дескриптор Instagram: i_m_vibh или мой дескриптор Twitter: VibhanshuBiswas