Я более пяти лет работал кодером и за все эти годы мне приходилось решать разные задачи, но тем не менее все они являются типовыми и поддаются классификации и обобщению. В этом посте я расскажу какие задачи приходится решать обычным кодерам. Я буду их приводить в порядке воспоминаний, так что порядок не важен.
Немного ликбеза:
Аутентификация - процедура проверки легальности пользователя или данных. Авторизация - процедура предоставления субъекту определённых прав. Процедуры аутентификации и авторизации совмещаются. Авторизация производит контроль доступа легальных пользователей к ресурсам системы после успешного прохождения ими аутентификации.
Лично я до сих пор так и не смог запомнить, чем на деле одно отличается от другого. Если данное выше определение кажется вам слишком абстрактным, то почитайте довольной простой пост чем авторизация отличается от аутентификации на примере старой доброй ОС Windows 2000/XP. Это даст некоторое представление.
В последние годы популярность набрала технология OAuth-авторизации. Это когда пользователь может логиниться через третьи сервисы типа ВКонтакте или Facebook. Так что по сегодняшним меркам держать свою БД с логинами и паролями юзеров уже не комильфо.
2. Надо уметь работать с транзакциями в базах данных.
В промышленных базах данных недопустимо выполнять какие-то операции манипулирования данными частично или со сбоями. Ваша программа должна либо 100% успешно выполнить операцию и доложить об этом пользователю, либо выдать ошибку не произведя при этом никаких необратимых изменений. Т.е. если вы перепрыгиваете пропасть на 99.9% вы всё равно с воплем летите вниз. В изменении данных не бывает мелочей. Поэтому транзакции надо знать как свои 5 пальцев. Два и более пользователей не должны одновременно изменить одни и те же данные, иначе произойдет коллизия.
Если ваша информационная система интегрируется с другой системой, то возможно они обмениваются данными. То бишь вам приходится грузить свою базу данных экспорт из другой БД. Будет плохо, если ваш ETL-механизм работает со сбоями. Например, если вы загружаете .CSV или .XLS(X) файлы, а какой-то из них пришел битым или поменялся немножко формат, то ваш загрузчик должен отменить транзакцию по загрузке этого файла и создать соответствующее уведомление. Вообще бы хорошо вести журналирование изменений и иметь возможность откатить любым изменения, например, загрузку какого-нибудь файла в БД.
3. Надо уметь работать с офисными файлами.
Речь идет о форматах .DOC(X) и .XLS(X). Они очень широко распространены в среде офисных служащих. Надо уметь читать и генерировать такие файлы.
4. Надо уметь работать с форматами XML и JSON.
Эти форматы стали де-факто стандартом в сетевом обмене данными. Поэтому будет отлично, если вы умеете виртуозно оперировать с данными в таком формате. Нужно опять таки уметь читать и писать данные.
Кроме того данные могут представлять собой какие-нибудь объекты. Поэтому нужно знать сериализацию и десериализацию.
5. Надо уметь генерировать отчеты, графики и диаграммы.
Особенно это нужно в информационно-аналитических системах. Всё это должно быть доступно в разных представлениях: .PDF, .DOC(X), .XLS(X), .CSV, .HTML (еще может быть <iframe> какой-нибудь для вставки на другие сайты).
Таким образом система еще решает задачу экспорта данных.
Могут быть какие-нибудь экзотические требования типа вставить диаграмму данных в PowerPoint-презентацию способом <iframe>, чтобы эта диаграмма постоянно отображала актуальные данные.
6. Надо уметь делать модель данных.
Для начала нужно уметь составлять схемы данных. Какие сущности будут в БД и как они будут друг с другом связаны. Но схема - это просто идея на уровне логики. Вам нужно еще сделать физическую реализацию этой схеме на конкретной СУБД. Но и этого еще недостаточно, когда фундамент готов надо на нём построить DAO-слой, который будет взаимодействовать с остальным кодом являясь как бы прослойкой между базой данных и остальным механизмом.
7. Надо уметь делать веб-сервисы.
Веб-сервисы как правило плотно связаны с моделью данных. Поэтому тут бы вам хорошо подумать и не допустить дублирования моделей данных. Иногда такое случается, что веб-сервиса своя модель данных, а у программы своя, что приводит к написанию конвертеров, которые надо впоследствии поддерживать вслед за изменениями модели данных. Я уже писал о проблеме дублирования моделей данных.
Хорошо бы уметь делать не только back-end часть, но и front-end, потому что в противном случае вас запарят вопросами "а как оно у вас там работает?". Если вы делаете веб-сервис, то вы должны его делать полностью от начала и до конца. Другие только пользуются вашим интерфейсом. Получается как бы такой веб-сервисный DAO.
Есть две основные технологии для реализации веб-сервисов: REST и SOAP. В последние годы широкое распространение получили мобильные технологии, которые склоны использовать REST и вообще кладут большой и толстый на SOAP. Надо иметь это ввиду, когда вы выбираете стек технология для своего проекта. Трудно будет найти хорошую библиотеку для работы с SOAP на Objective-C или не дай бог Swift. Но у SOAP есть преимущество - WSDL, который позволяет таки дать какое-то описание модели данных и всё это чётко стандартизировано. Но стандарт - это не истина в последней инстанции. Стандарт - это НЕ самое лучшее решение, которое может быть. Стандарты тоже живут, размножаются и умирают.
8. Надо учитывать большие нагрузки.
Надо уметь:
- грамотно составлять индексы для баз данных;
- реализовывать кэширование всякое разное;
- настраивать балансировщики нагрузки;
- писать масштабируемые приложения;
- делать параллельные вычисления;
- и т.д.
Я смотрел какое-то видео из Академии Яндекса (то ли с Яндекс.Музыкой что-то связанное было или нет...), ну там они рассказывали как они сделали кэширование - просто тупо генерировать статические HTML-файлы и отдавали их. Мне показался этот способ интересным. Я принимал участие в разработке парочки информационно-аналитических систем и мне кажется там можно было бы подобным способ закэшировать результаты SQL-запросов и потом тупо отдавать их.
Лично я до сих пор не понимаю как оценить грузоподъёмность ASP.NET- или Java-приложения. А надо бы. Вы должны четко понимать какую нагрузку может выдержать ваше приложение. Как мне кажется тут надо смотреть в сторону облачных вычислений, юзать какой-нибудь Heroku и не париться со своим железом.
Заодно следует подумать о high availability и fault tolerance.
9. Надо уметь генерировать формы для заполнения данными.
Всякие корпоративные дела могут быть связаны с довольно таки иногда сложными формами интерфейса редактирования данных. Например, этого могут формы для заявок. Как правило пишутся на HTML, но могут быть и desktop-приложения. Формы могут быть очень сложными. Ну знаете типа эти налоговые или банковские бланки с кучей полей для заполнения. Вот всё то же самое, но только в электронном виде. Делать это судя по всему придется именно вам. Легко написать PHP-скрипт выдающий страничку с парочкой полей, а вы попробуйте поддерживать скриптище обрабатывающий парочку сотен полей. Поля могут добавляться, могут удалятся. Короче динамическая такая структура.
Естественно всё это как-то связано с базой данных, а значит и DAO.
Валидация тоже важный момент.
10. Надо уметь синхронизировать.
Может стать задача синхронизировать что-нибудь с чем-нибудь. Я считаю это одна из самых сложнейших задач. Например, может понадобится синхронизировать две базы данных MS SQL Server и MySQL. А может будет поставлена задача синхронизировать какую-нибудь сложную структуру данных (например папка с файлами JSON и другими вложенными папками... и всё это может сливаться и т.д.).
Рассинхронизация очень огорчает пользователей.
11. Надо уметь работать с иерархическими структурами данных.
То тут, то там возникают и исчезают иерархии. Это может быть файловая структура. Это может быть XML или JSON. Это может быть таблица с PARENT_ID в реляционной СУБД к которой надо делать SQL-запрос. В общем данные могут быть представлены в совершенно разном виде и вы должны уметь легко работать с ними.
Тут могут возникать адские трудности. Например, если иерархия живая, то некоторые узлы могут распадаться во времени, а потом снова собираться или исчезать. Вчера это был один узел, а сегодня два. После завтра этого узла не будет. А через пол года он воскреснет как птица Феникс из пепла.
12. Надо уметь делать красиво.
Иногда от вас требуют добавить свистелок каких-нибудь в ваше приложение. Анимацию там запилить какую-нибудь или CSS-эффект сделать. Есть стандартный набор эффектов, которые реализуются стандартными средствами технологии, его-то и можно использовать. Просто надо разбираться во всём этом.
В принципе можно положить на это всё либо идти в дизайнеры тогда уж.
13. Надо уметь связывать одну технологию с другой.
Это может быть простая задача типа ASP.NET + Oracle, хотя логичнее было бы ASP.NET + SQL Server. Может быть что-то десктопное типа Objective-C + JavaScript. Может быть что к веб-приложению на Java нужно подключить C++ библиотеку.
В общем, если вам на досуге нечем заняться, то можете поиграть в комбинирование различных технологий. Я этим больше заниматься не хочу и бегу от таких задач как черт от ладана.
Я не рассматриваю случаи, когда нужно установить новый ASP.NET на допотопный Windows Server выпущенный десять лет назад. Это клиника и надо сразу записываться к психиатру.
14. Надо уметь крутить фоновые задачи на back-end стороне.
Не все запросы пользователя можно выполнить быстро и сразу вернуть ответ. Некоторые задачи требуют длительного времени. Вам нужно разработать какой-то механизм как вы будете их запускать и оповещать пользователя о текущем прогрессе. Лучше конечно чтобы пользователь сам запрашивал текущее состояние задачи.
15. Надо уметь делать таблицы.
Эти таблицы не всегда похожи на ровную сетку. Тут может быть несколько рядов заголовков, фиксированные столбцы, объединенные и разбитые ячейки, фиксированные строки, раскрывающиеся строки и т.д. В ячейках может быть всё что угодно. И самое ужасное всё это должно редактироваться и валидироваться. Для реализации всего этого стандартных возможностей как правило не хватает и надо изощряться. Из JavaScript-библиотек могу порекомендовать DataTables в котором очень многое есть, но этот плагин страдает нарушением ширины столбцов.
16. Надо уметь использовать типовые решения.
Многие программисты считаю, что у всех технологий есть один серьезный минус. Эти технологии были написаны не ими. Конечно всегда хочется сорваться и сделать "по красоте" свою реализацию. Но тут есть большой риск завалиться. Можно здорово упростить себе жизнь, если научиться использовать в своей работе уже придуманные вещи. Не надо делать собственную CMS, есть есть Drupal и куча модулей на все случаи жизни. Вы никогда в одиночку не напишите ничего даже близко похожее по мощности и расширяемости. В основном молодежь кидается с песочной лопаточкой сносить горы.
Был такой русский физик Кикоин и как-то его спросили почему он не занимается там какой-то захватывающей штукой, на что он сказал, что это очень интересно, но ему не хватит времени чтобы достичь результата. Т.е. человек понимал свои возможности и не питал иллюзий.
Поверьте мне на слово, чем меньше напридумываете, тем легче будет это всё поддерживать.
17. Надо уметь писать SQL-запросы.
Особенно во всяких enterprise-ориентированных компаниях. Я уважаю людей, которые могут за один SQL-запрос вытащить любой отчет, в это есть какой-то истинный дзэн.
Бывает, что приходится строить большие запросы. Поддерживать их просто невозможно. Поэтому лучше это всё дело завернуть в какой-нибудь паттерн типа Builder и генерировать на лету.
Тут стоит уделить внимание умению составлять аналитические запросы. Т.е. чтобы что-нибудь там хитро считалось. Например, знаете ли вы про операторы операторы PIVOT и UNPIVOT?Полезно уметь делать запросы к иерархическим данным.
18. Надо уметь вести техническую документацию.
Составлять ТЗ по ГОСТу или по-американски. Вырабатывать требования. Рисовать UML-диаграммы, для UML я так и не увидел ни одного нормального инструмента. Рисовать ER-диаграммы, могу порекомендовать Sybase PowerDesigner - сделает всю работу за вас. Есть еще куча всякой лабуды типа IDEF разных мастей, DFD, BPMN, ... На мой взгляд всё это нужно только для описания и противоречит гибкой методологии разработки ПО (agile). Потому что невозможно на каждое изменение требований и условий изменять UML-диаграмму. А учитывая что сегодня постоянные изменения это закон жизни, получается, что работаешь только на то чтобы поддерживать UML-диаграммы в актуальном состоянии. Такая жизнь угнетает человека.
19. Нужно уметь парсить всё на свете.
Что значит парсить? Это значит уметь извлекать нужные данные. Тут активно надо использовать регулярные выражения. Или строить какие-то иерархические модели и делать их обход. В общем зависит от формата.
Нужно уметь парсить: HTML, XLS(X), CSV, XML, JSON. В некоторых случаях может понадобится парсить CSS.
Мне нравится использовать bash и командные утилиты. Например, для JSON есть отличная утилита jq.
20. Нужно уметь делать графические интерфейсы.
У вас не должна вызывать сложностей работа с любым стандартным компонентом. Компоненты для работы с данными надо знать наизусть.
Заключение
Чем на больших языках программирования, платформах и технологиях вы всё это будете уметь делать, тем для вас будет лучше, в смысле легче работать будет.
