Board.KolibriOS.org

Official KolibriOS board
It is currently Thu Oct 22, 2020 3:50 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Wed May 20, 2020 10:03 am 
Offline

Joined: Thu May 23, 2019 10:50 pm
Posts: 90
https://dev.by/news/20-veschei-kotorye- ... yandex.com

Я программирую с 1999 года, то есть уже больше 20 лет. Начинал с Basic, но вскоре перешёл на Pascal и C, а потом изучал объектно-ориентированное программирование на Delphi и C++. В 2006 взялся за Java, а в 2011-м — за JavaScript. Работал в самых разных сферах от робототехники, финтеха и медтеха до СМИ и телекоммуникаций. Был исследователем, СТО, ТРМ (технический продакт-менеджер), преподавателем, системным архитектором, техлидом, но никогда не переставал кодить.

Некоторыми из продуктов, в разработке которых я поучаствовал, пользовались миллионы людей, а некоторые были похоронены ещё до релиза. Я работал консультантом и даже пробовал вырастить стартап. Кучу времени посвятил проектам с открытым исходным кодом, с закрытым кодом, inner source-проектам (когда методологии open source-разработки используются в создании проприетарного софта сообществом внутри компании). Доводилось работать с крошечными микроконтроллерами, с мобильными и десктопными приложениями, облачными серверами и бессерверными архитектурами.

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

Не боритесь с инструментами — библиотеками, языками, платформами — чем бы то ни было. Старайтесь использовать присущие им конструкции. Не пытайтесь прогнуть технологии, но и задачу под них тоже подстраивать не нужно. Выбирайте правильный инструмент для решения конкретной проблемы, или придётся искать «правильную» проблему под те инструменты, которые оказались у вас в руках.
Вы пишете код не для машин. Вы пишете его для своих коллег и для будущего себя (если это какой-нибудь пробный или «расходный» проект). Пишите код для неопытных разработчиков как эталон.
Любой серьёзный и успешный программный продукт — результат совместного труда. Коммуникация должна быть эффективной и открытой. Доверяйте другим и сами заслуживайте доверие. Цените людей больше, чем код. Подавайте пример. Помогайте другим становиться лучше.
«Разделяй и властвуй». Пишите обособленные модули с определённым назначением, которые можно запросто объединить. Тестируйте каждую часть отдельно и вместе с другими. Тесты должны быть приближены к реальности, но и предельные случаи тоже нужно тестировать.
Код не должен зависеть от вас. Не замыкайте код на себе. Оптимизируйте его таким образом, чтобы другие люди могли фиксить баги и добавлять новые фичи. Оставляйте себе возможность свободно перейти к новому проекту или в другую компанию. Не относитесь к коду как к своей собственности, а то никогда не перерастёте его.
Есть разные уровни безопасности. Каждый нужно рассматривать индивидуально, но в контексте целого. Приемлемый уровень риска — это бизнес-решение, которое прямо соотносится с уязвимостью и вероятностью. У каждого продукта/организации этот уровень — готовность идти на тот или иной риск для получения большей выгоды — различный. Часто возникает конфликт между тремя вещами: UX, безопасностью и производительностью.
Поймите, что у любого кода есть жизненный цикл, который когда-нибудь закончится. Иногда код «умирает» в зачаточном состоянии, так и не дотянув до выхода в продакшн. Учитесь отпускать. Помните, что функционал делится на 3 неравнозначные группы:
— ключевой — например, двигатель в автомобиле. Без таких фич продукт бесполезен;
— необходимый — например, запасное колесо. Использовать его выпадает редко, но если час придёт, от него будет зависеть работоспособность всей системы;
— дополнительный — например, подстаканник. Приятно, когда он есть, но можно и обойтись.
Нельзя по коду судить о человеке. Не приравнивайте людей к артефактам, которые они генерируют. Не принимайте на свой счёт, когда кто-то ругает ваш код, но сами будьте крайне деликатны, критикуя код других.
Технический долг как фастфуд: допустим в умеренных количествах, но если войдёт в привычку, не успеете оглянуться, как он убьёт продукт, и это будет больно.
Если когда вы принимаете решение, все следующие факторы имеют одинаковый приоритет, расставьте их в таком порядке:
безопасность > юзабилити (доступность + UX) > сопровождаемость > простота («опыт разработки», developer experience) > краткость (длина кода) > производительность.
Только не нужно строго придерживаться такой последовательности, поскольку всё зависит от сущности продукта. Как и в любой другой профессии, с опытом у вас будет всё лучше получаться найти правильный баланс в каждом конкретном случае. Например, при разработке игрового движка первостепенную важность имеет производительность, а для банковского приложения главным фактором будет безопасность.
Верный способ плодить баги — использовать копипаст. Всегда смотрите, что копируете; всегда проверяйте, что вставляете. Баги кроются в сложностях. Не мудрите с кодом.
Пишите код не только для благоприятных сценариев. Предусмотрите ещё и сообщения об ошибках, из которых понятно, почему они произошли, как были обнаружены и что сделать, чтобы их исправить. Верифицируйте все данные, поступающие в систему извне (в том числе вводимые пользователем): лучше, чтобы ошибки срабатывали как можно раньше и по возможности устранялись. Представьте, что у пользователя в руке пистолет: вложите в сообщение максимум усилий, чтобы стрелять куда угодно, но не вам в голову.
Используйте зависимости только тогда, когда затраты на импорт, сопровождение, устранение крайних случаев/багов и рефакторинг в случае, когда они не отвечают нуждам, оправдывают себя.
Не идите на поводу у хайпа (это называется hype-driven development). Но старайтесь постоянно расширять кругозор. Пилите домашние хобби-проекты.
Выходите из зоны комфорта. Каждый день учитесь чему-то новому. Учите других тому, чему научились сами. Когда человек упирается в потолок, то перестаёт развиваться. Изучайте новые языки, технологии, культуры, будьте любознательны.
Хороший код не требует документации, но отличный код задокументирован по определению. Любой человек со стороны, который не участвовал в его разработке и доведении до текущего состояния, может с ним работать. Если фича не задокументированне, её не существует. Для фичи, которой не существует, не должно быть и кода.
Старайтесь по возможности избегать переопределения, наследования и других усложнений. Пишите чистые функции. Их легче тестировать и анализировать. «Нечистая» функция должна быть классом. У каждой конструкции кода со своей функцией должно быть своё имя.
Никогда не начинайте кодить (разрабатывать какое-то решение), полностью не вникнув в суть задачи. Ничего страшного, если уйдёт больше времени на прослушивание и чтение материалов для подготовки, чем на стучание по клавишам. Прежде чем писать код, ознакомьтесь с предметной областью.
Не сражайтесь с ветряными мельницами. Не занимайтесь «спекулятивным программированием». Делайте код расширяемым только в том случае, если уверены, что его точно будут расширять. Может случиться, что к тому времени проблема будет стоять уже не так, как тогда, когда вы начинали писать код.
Софт веселее создавать вместе. Соберите сплочённое сообщество. Слушайте. Вдохновляйте. Учитесь. Делитесь.
Я не претендую на звание эксперта по разработке программного обеспечения. Это просто соображения, которые накопились за годы практики. Уверен, что ещё через 20 лет этот список будет более глубоким.

[!] Выделил в отдельную тему отсюда, dunkaist.

_________________
Монтировка решит всё 8)


Top
   
PostPosted: Wed May 20, 2020 10:45 am 
Offline

Joined: Wed Mar 26, 2008 12:44 pm
Posts: 248
Как же задолбали эти "эффективные менеджеры" :evil: Хочешь помочь проекту - делай что-либо сам. Конечный результат лучше любых слов.


Top
   
PostPosted: Wed May 20, 2020 10:48 am 
Offline

Joined: Wed Mar 26, 2008 12:44 pm
Posts: 248
Гордон Фримен wrote:
Работал в самых разных сферах от робототехники, финтеха и медтеха до СМИ и телекоммуникаций. Был исследователем, СТО, ТРМ (технический продакт-менеджер), преподавателем, системным архитектором, техлидом

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


Top
   
PostPosted: Wed May 20, 2020 10:54 am 
Offline

Joined: Wed Mar 26, 2008 12:44 pm
Posts: 248
А уж самомнения у него, хоть отбавляй - СТО он был :) А потом простым преподом :)


Top
   
PostPosted: Wed May 20, 2020 1:53 pm 
Offline
User avatar

Joined: Mon Nov 19, 2012 5:22 pm
Posts: 459
Эмм.. в этой теме разрешен пиар? Вроде, тема не об этом.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 5 posts ] 

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited