تعلم أساسيات عقلية المطور الجيدة في 15 دقيقة

"من الصعب إجراء تغييرات صغيرة"

"كسر وظائف البرنامج بإجراء تغييرات"

"تقديم خطأ جديد من خلال إصلاح خطأ آخر"

"تنفيذ رمز غير ضروري"

"يكاد يكون من المستحيل إضافة ميزة جديدة بسبب الشفرة المعقدة"

"المنتج الذي لا يتم شحنه أبدًا"

"التخلص من الشفرة وإعادة كتابتها من الصفر"

هل كل البيانات المذكورة أعلاه مألوفة؟

في كل دقيقة يقول مطور من أي جزء من العالم (أو يفكر) أيًا من العبارات المذكورة أعلاه ويرغب في البكاء. لماذا ا؟

هذه قضايا شائعة تحدث عنها المطورون كثيرًا. يتم اختبار هذه القصص في كل فريق تطوير.

هناك العديد من العوامل الصغيرة التي تضر ببطء وتدريجي بمشاريع المطور. فهي ليست مدمرة على الفور. معظمهم يتسببون في أضرار طويلة المدى فقط. شيء لن ترى الضرر لمدة عام أو أكثر. لذلك عندما يقترحهم شخص ما ، غالبًا ما يبدون غير ضار.

حتى عندما تبدأ في تنفيذها ، قد تبدو جيدة. ولكن مع مرور الوقت - وخاصة مع تراكم المزيد والمزيد من هذه الأشياء - يصبح التعقيد أكثر وضوحًا وينمو حتى تصبح ضحية أخرى لقصة الرعب الشائعة جدًا.

لتجنب الوقوع ضمن الضحايا ، يجب أن تتبنى القوانين الأساسية للبرامج. يجب عليك تطوير عقلية يجب أن يمتلكها كل مطور. ستساعدك هذه العقلية على اتخاذ قرارات أفضل في رحلة البرمجة اليومية. يمكنك أن تبقي برنامجك بسيطًا قدر الإمكان. يمكنك حمايته من كونه نظامًا معقدًا يصعب إدارته.

فيما يلي النقاط الأساسية التي يجب على كل مطور إتقانها.

1. تصور الغرض من البرنامج

بادئ ذي بدء ، يجب أن تفهم الغرض من البرنامج. هناك ، في الواقع ، هدف واحد لكل البرامج: مساعدة الناس .

تذكر: الغرض من البرنامج ليس إظهار مدى ذكاءك. - ماكس كانات الكسندر ، بساطة الكود

المطورون الذين لا يستطيعون تصور الغرض من البرنامج سوف يكتبون برامج سيئة. ما هي البرامج السيئة؟ نظام معقد لا يساعد الناس كثيرًا.

عندما تتخذ قرارات بشأن البرنامج ، يجب أن ترشد نفسك من خلال وضع هذا في الاعتبار دائمًا: كيف يمكننا المساعدة؟ يمكنك حتى تحديد أولويات طلبات الميزات بهذه الطريقة.

2. أهداف تصميم البرمجيات

كل مبرمج هو مصمم.

عندما يصعب إنشاء البرامج أو تعديلها ، يقضي المطورون معظم وقتهم في التركيز على جعل الأشياء "تعمل فقط" ، ووقتًا أقل في التركيز على مساعدة المستخدمين. يهدف تصميم البرنامج إلى جعل عمل المطورين أسهل ما يمكن حتى يتمكنوا من التركيز على الأمور المهمة. ستنشئ برنامجًا يساعد المستخدمين وسيستمر برنامجك في مساعدتهم لفترة طويلة.

ومع ذلك ، إذا صممت نظامًا سيئًا ، فسيكون عمر البرنامج قصيرًا.

يقودنا هذا إلى أهم هدف لتصميم البرنامج:

لتصميم الأنظمة التي يمكن إنشاؤها وصيانتها بسهولة قدر الإمكان بواسطة مطوريها ، بحيث تكون - وتستمر - مفيدة قدر الإمكان. - ماكس كانات الكسندر ، بساطة الكود

إذن هناك نقطتان أساسيتان هنا: يجب أن يكون تصميمك سهلًا بالنسبة لك ومفيدًا للآخرين.

3. (سوء) الفهم

يميل المطورون الذين لا يفهمون عملهم بشكل كامل إلى تطوير أنظمة معقدة. يمكن أن يصبح حلقة مفرغة: يؤدي سوء الفهم إلى التعقيد ، مما يؤدي إلى مزيد من سوء الفهم ، وما إلى ذلك.

في الواقع ، تتمثل إحدى أفضل الطرق لتحسين مهارات التصميم لديك في التأكد من فهمك الكامل للأنظمة والأدوات التي تعمل بها.

الفهم هو الفرق الرئيسي بين المطور السيئ والمطور الجيد. - ماكس كانات الكسندر ، بساطة الكود

لا يفهم المطورون السيئون ما يفعلونه ، والمطورون الجيدون يفعلون ذلك. هو حقا بهذه البساطة.

4. البساطة

البساطة هي التطور في نهاية المطاف. - ليوناردو دافنشي

البرمجة هي عملية تقليل التعقيد إلى البساطة. "المطور السيئ" هو مجرد شخص يفشل في تقليل التعقيد. يبذل "المطور الجيد" كل ما في وسعه لجعل الشفرة بسيطة قدر الإمكان للمبرمجين الآخرين.

ينشئ المطور الجيد أشياء يسهل فهمها بحيث يسهل حقًا التخلص من كل الأخطاء.

الآن ، المطورون هم أشخاص أذكياء بشكل عام ولا يحب أي منهم أن يعامل كما لو كانوا أغبياء. ومن المفارقات أن هذا يقودهم أحيانًا إلى إنشاء أشياء معقدة بعض الشيء. يفكرون بشكل أساسي مثل هذا:

" أوه ، سوف يفهم المطورون الآخرون كل شيء قمت به هنا. يجب أن أكتب بعض التعليمات البرمجية الذكية التي يصعب فهمها حتى يظنوا أنني ذكي جدًا. "

خطأ ناجم عن عقلية خاطئة - ليس بالضرورة بسبب نقص مهارات البرمجة. تحدث معظم حالات فشل البرمجة بسبب تلك العقلية.

إظهار أنك ذكي لا يساعدهم.

المطورون الجدد في التعليمات البرمجية الخاصة بك لا يعرفون أي شيء عنها ؛ عليهم أن يتعلموا.

لذا ، يجب أن تسأل هذا السؤال: " هل أريد أن يفهم الناس هذا وأن يكونوا سعداء ، أم أريدهم أن يكونوا مرتبكين ومحبطين؟ "

الحقيقة هي أنه إذا كان بإمكان المطورين الآخرين الذين قرأوا التعليمات البرمجية فهمها بسهولة ، فهذا يعني أنك تقوم بعمل جيد.

التعقيد ليس له علاقة بالذكاء ، البساطة تفعل ذلك. - لاري بوسيدي

السؤال هو: "ما مدى البساطة التي يجب أن تكون عليها؟"

ها هي إجابتك: غبي ، بسيط غبي.

5. التعقيد

السيطرة على تعقيد هو جوهر برمجة الكمبيوتر. - بريان كيرنيغان

مصدر العديد من فشل البرامج هو التعقيد. تبدأ بمشروع بسيط يمكن إكماله في شهر واحد. ثم تضيف التعقيد ، وستستغرق المهمة ما يصل إلى ثلاثة أشهر. ثم تبدأ في إضافة ميزات تفي ببعض الأغراض الأخرى. تصبح الأمور معقدة للغاية لأنك تقوم بتوسيع الغرض من برنامجك دون سبب. ستستغرق المهام ستة أشهر.

ولكن هذه ليست النهاية.

Then you take each piece of the feature and make it even more complex, and the task will take nine months. Then you start to introduce many new bugs because of the complexity in your code. Naturally, you start fixing them all without thinking how these fixes will affect other parts. At the end, when even small changes become hard. When bug fixes start to introduce new bugs, you will come to one of the most popular programming horror stories: Rewriting code from scratch.

So, how did you become a victim of this horror story? Nah, who cares. It’s better to ask: How could you avoid being a victim?

Well, it is simple. First, you will exactly know your software purpose and its definition. Second, you will be as simple as possible in every piece of code you write. Third, when a new feature or change request comes to the discussion table, you will evaluate them based on your software purpose and question them.

As a developer, your first behavior should be resistance to (unnecessary) change. This will prevent you from adding unnecessary codes into your software. When you are convinced that this change is a need, then you can implement it.

There are many factors that will increase complexity but those are the most popular ones. Aside from everything, there is only one rule that you should follow:

Your main purpose is to control complexity, not to create it.

6. Maintenance

Maintenance is one of the most important things in software development. Unfortunately, developers usually ignore how important it is. Quick coding and fast shipping look more important than code maintenance. This is the point where they make a mistake — ignorance of future code maintenance.

There will always be some implementation of changes. Not only you have to implement them, but you also have to maintain them over time. As a developer, thinking about future maintenance of changes is one of your main responsibilities.

كل التغييرات تتطلب صيانة. البساطة والتعقيد هما العاملان الرئيسيان اللذان يؤثران على صيانة الكود. تتناسب سهولة صيانة أي جزء من البرنامج مع بساطة قطعه الفردية. يتناسب جهد الصيانة مع مدى تعقيد البرنامج ، والقاعدة الوحيدة التي يجب عليك اتباعها بشأن الصيانة هي: تقليل جهد الصيانة أهم من تقليل جهد التنفيذ. - ماكس كانات الكسندر ، بساطة الكود

7. الاتساق

الاتساق جزء كبير من البساطة. إذا كنت تفعل شيئًا بطريقة واحدة في مكان واحد ، فافعل ذلك بهذه الطريقة في كل مكان. على سبيل المثال ، إذا قمت بتسمية متغير thisIsVariable ، فيجب تسمية جميع المتغيرات الخاصة بك بهذه الطريقة (متغير آخر ، متغير آخر ، وما إلى ذلك ، وليس متغيرًا آخر). - ماكس كانات الكسندر ، بساطة الكود

يصعب فهم الكود غير المتسق. لا تستمر في إجبار المطورين على إعادة تعلم الطريقة التي يعمل بها نظامك في كل مرة ينظرون فيها إلى جزء جديد منه.

في أي رياضة جماعية ، تتمتع أفضل الفرق بالاتساق والتناغم. - روجر ستوباخ

8. تحديد الأولويات

كيف تتخذ قرارات بشأن برنامجك؟

عندما تواجه العديد من الاتجاهات الممكنة ، كيف تقرر الخيار الأفضل؟ ما الذي يجب التركيز عليه وما الميزات التي يجب عليك تنفيذها؟

للإجابة على هذه الأسئلة ، هناك ثلاثة عوامل مهمة ستساعدك على اتخاذ قرار أفضل. تم شرح هذه المعادلة جيدًا في كتاب Code Simplicity:

  • الرغبة في التغيير (د): إلى أي مدى تريد أن يحدث هذا التغيير؟
  • قيمة التغيير (الخامس): ما هي القيمة التي يقدمها التغيير؟ إلى أي مدى تساعد المستخدمين لديك؟
  • الجهد المطلوب لإجراء التغيير (هـ): ما مقدار العمل الذي ستحتاج إلى القيام به لتحقيق هذا التغيير؟

المعادلة بسيطة: D = V / E

الرغبة في أي تغيير تتناسب طرديا مع قيمة التغيير وتتناسب عكسيا مع الجهد المبذول في إجراء التغيير. - بساطة الكود

عندما تحدد أولويات عملك ، يجب عليك اتباع هذه القاعدة:

The changes that will bring you a lot of value and require little effort are better than those that will bring little value and require a lot of effort.

9. Solving Problems

The first step is understanding. Know exactly what is being asked. Most hard problems are hard because you don’t understand them. Write down your problem and try to explain it to someone else.

If you can’t explain something in simple terms, you don’t understand it. — Richard Feynman

The second step is planning. Don’t take action. Sleep on it. Give your brain some time to analyze the problem and process the information but don’t spend too much time on planning.

Think before acting.

The third step is dividing. Don’t try to solve one big problem. When you look at the problem as a whole, it can scare you. Divide it into smaller tasks and solve each sub-problem one by one. Once you solve each sub-problem, you connect the dots.

10. Good enough is fine

“Perfect is the enemy of good.” — Voltaire

Whether creating a new project or adding a feature to existing system developers tend to plan everything out in detail from the beginning.

They want the first version to be perfect. They don’t focus on the problem they will solve and how their software will help people.

They start by thinking of every small detail they could think about. Then assumptions and predictions come along followed by “What if” sentences. They have to predict the future because they were now so captivated by the imagination of the project in their mind and their project has to be as perfect as they imagined it.

Actually, they are not aware of what’s waiting for them and how much it will cost them by chasing perfection.

Let me tell you what will happen:

  • You will be writing code that isn’t needed
  • You will increase complexity by adding unnecessary codes
  • You will be too generic
  • You will be missing deadlines
  • You will be dealing with many bugs caused by the complexity

Do you want this to happen? I guess no.

What you should instead?

Start small, improve it, then extend.

يجب أن يكون التصميم الإضافي هو دليلك. إليك كيفية استخدامها لتصميم آلة حاسبة:

  1. خطط لنظام يقوم بالإضافة فقط ولا شيء آخر.
  2. تنفيذه.
  3. قم بتحسين تصميم النظام الحالي حتى تتمكن من إضافة عمليات أخرى أيضًا.
  4. خطط للطرح وكرر الخطوتين 2 و 3.
  5. خطط لعملية الضرب وكرر الخطوتين 2 و 3.
  6. خطط للقسمة وكرر الخطوتين 2 و 3.

11. التنبؤات

"التنبؤ هو ببساطة توقع بحدوث شيء ما في المستقبل. يمكن أن تكون واقعية وتستند إلى نوع من البيانات الموضوعية أو يمكن أن تستند إلى افتراض ". عند مواجهة حقيقة أن الكود الخاص بهم سيتغير في المستقبل ، يحاول بعض المطورين حل المشكلة من خلال تصميم حل عام بحيث (يعتقدون) أنه سيتناسب مع كل موقف مستقبلي محتمل. - بساطة الكود

Being too generic involves a lot of code that isn’t needed.

You can’t predict the future, so no matter how generic your solution is, it will not be generic enough to satisfy the actual future requirements you will have. Most probably, this time will never come and the code you wrote to solve future problems will increase complexity, make it hard to change the pieces of code and eventually it will become a burden that may destroy your software.

Don’t predict to future. Be only as generic as you know you need to be right now.

12. Assumptions

What is the assumption?

“An assumption is something that you accept as true or suppose to be true, although you have no conclusive proof.”

One of the great killers of a software project is assumptions. Let’s see how an assumption can kill a software project.

يعرف المطور أنه يتعين عليهم تطوير نظام للقيام بـ X. ثم يعتقدون أن النظام سيطلب منهم تنفيذ Y في المستقبل ، ويقومون بتنفيذ Y أيضًا. يكتبون آلاف الأسطر من التعليمات البرمجية لتصميم Y.

في المستقبل ، يدرك المطور أن المتطلبات الحالية مختلفة تمامًا عما كان يعتقد. ولكن الآن ، يحتوي البرنامج على أكواد غير ضرورية تجعل من الصعب التخلص منه لأن كل شيء متشابك. يستغرق الأمر شهورًا لإعادة تشكيل الكود ، والآن يفكرون في إعادة كتابة البرنامج بالكامل من نقطة الصفر مما سيؤدي إلى خسارة شهور.

لتجنب الوقوع ضحية مثل هذا المطور ، اتبع هذه القاعدة البسيطة:

يجب تصميم الكود بناءً على ما تعرفه الآن ، وليس بناءً على ما تعتقد أنه سيحدث في المستقبل. - بساطة الكود

13. وقف إعادة اختراع

If, for example, you invent your own garbage collector when a perfectly good one exists, you’re going to be spending a lot of time working on the garbage collector, when you could just be working on your software.

The only times it’s okay to reinvent the wheel is when any of the following are true:

  • You need something that doesn’t exist yet
  • All of the existing “wheels” are bad technologies or incapable of handling your needs
  • The existing “wheels” aren’t being properly maintained

Simple rule:

Don’t reinvent the wheel.

14. Resistance

As a developer, your first reaction to changing requests should be “NO’’.

Always resist adding more code, more features until you are convinced that they are required and there is a need to implement them. Because unnecessary changes will increase defects in your software.

How can you know that there is a need for them?

Go back and remember your software purpose. Then remember the simple equation in prioritizing section.

From: [email protected] (Russ Cox)Subject: Re: [9fans] design clairvoyance & the 9 way Date: Thu, 8 May 2003 04:05:31 GMT > What does tomorrow's unix look like? I'm confident that tomorrow's Unix will look like today's Unix, only cruftier. Russ

15. Automation

Don’t spend your time on repetitive tasks. Set them up and forget about them. They can work while you are sleeping. When you realize that you are doing something again and again, just remember this rule:

If you can automate it, automate it.

16. Code measurement

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

— Bill Gates

I see developers who measure their software quality based on code lines. They think that more code lines mean that they are doing a great job. The software contains hundreds of thousands of lines of code, which means the software they work on is so big.

The question that pops up here is: Is it really that big, or there is something wrong there?

The answer is that most probably there is something wrong with their design. Most of the simple solutions don’t require a lot of code. You can achieve simplicity with a little bunch of code and solve the problem.

I’m not saying that fewer lines of code is always better. While you want to avoid having less code, you can easily fall in a trap that will cause you to write clever code that is hard to understand for others. You should find a balance.

The optimum code is a small bunch of code that is easy to understand, easy to read.

17. Productivity

How do you measure your productivity?

By writing more lines of code or by throwing hundreds of lines of code away?!

Your main goal should be keeping your code base as small as possible. The question is not “How can I write more code?” rather it should be “How can I remove more code?”

“One of my most productive days was throwing away 1000 lines of code.” — Ken Thompson

18. Testing

When should you add logging and error handling to your project?

You should add logging in a very early stage. This will help you to find the problem easily and save your time.

I see many mistakes when it comes to testing code. Let me give you an example. There were two conditions, a simple if-else block. The developer gave input to the software which will enter inside the if block. They tested it and committed code to source control. Done!

But what about the else block? When the software was shipped to production, that caused a lot of errors. When you test your code, you must execute all new lines at least once and you should start to test parts before the whole.

When you have a bug, first you should reproduce it. You shouldn’t guess the source of the bug and apply fixes based on your assumption. Most probably, you will be wrong. You should see it with your own eyes before applying the fix.

You should be reliable. When other developers in your team see that you committed new code to source control, everyone should know that your code is tested, and works.

Untested code is the code that doesn’t work.

19. (Under)Estimation

Developers’ estimation sucks.

Usually, they underestimate things rather than overestimate them. They underestimate the time and effort required to develop a small amount of code or a feature. In the end, this underestimation leads to missing deadlines.

The solution: Break the big thing into smaller things. The smaller it is, the easier it is to estimate. You’re probably still going to get it wrong, but you’ll be a lot less wrong than if you estimated a big project.

Remember:

Everything takes longer than you think.

20. Running Away From Rewriting

I believe that when you embrace the fundamental principles of software development mentioned in that article, you won’t come to this point. However, if, somehow you make these mistakes and find yourself thinking about rewriting your code, here is the main thing that you should know:

Rewriting code is often a developer delusion, not the solution in most cases.

Why is it a delusion?

Well, because it’s harder to read code than to write it. This is why it is so hard to reuse code. This is why our subconscious mind whispers to us “Throw it away and start over” when we read another developer’s code.

There are many cases that you should consider to rewrite your code from scratch and you can read them here. But, here is simple advice for you:

Refactoring should be the first option.

21. Documentation and Commenting

One of the common misconceptions about commenting is that developers add comments that say what code is doing. This is wrong. That should be obvious from reading the code. If it’s not obvious, it means that it is not readable and it should be made simpler.

عندما لا تستطيع جعل الكود أبسط ، يجب عليك إضافة التعليق لشرح هذا التعقيد.

الغرض الحقيقي من تعليقات لشرح "لماذا" كنت فعلت شيئا، وليس "ما" ل كود يفعل. إذا لم تشرح هذا ، فقد يتم الخلط بين المبرمجين الآخرين وعندما يذهبون لتغيير التعليمات البرمجية الخاصة بك قد يقومون بإزالة أجزاء مهمة منها. - بساطة الكود

اكتب تعليقًا لشرح "لماذا" ، وليس لشرح "ماذا".

شيء آخر هو التوثيق. من المهم أن يكون لديك وثائق تشرح بنية البرنامج وكل وحدة ومكونات. هذا مطلوب لمشاهدة الصورة عالية المستوى لبرنامجك.

When a new developer joins your team, it will be easier for them to understand the software as a whole. When developers don’t have any clue about other parts of the software, they could easily make a mistake in their own part which can affect other parts also.

22. Picking Technologies (Tools, Libraries, etc.)

First things first, always remember this rule:

Don’t depend on external technologies.But when you have to do so, try to reduce your dependency on them as much as you can.

Why is that? Because they are another common source of complexity. They can kill your active development and make everything even harder.

When you are dependent so much on external technologies, you are not free. What if there is a major bug in that technology? You have to wait for the developers to fix that bug and if this technology is in the center of your project basically you are stuck, you can’t move forward. So that’s why it is so important to pick the right technologies for your project.

There are a few factors you should consider before you start using some technology:

  • Is there active development behind it?
  • Will it continue to be maintained?
  • How easy is it to switch away from?
  • What does the community say about it?

If you can find the right answer these questions, you can reduce the risk of picking the wrong technology.

23. Self-Development

Keep learning. Try out different programming languages and tools, read books on software development. They will give you another perspective. Every day small improvements will make a real difference in your knowledge and skills.

Be open-minded. Don’t be obsessive about one technology. Use the required technology to solve a specific problem. Don’t be in the unnecessary discussion like Microsoft vs Linux :)

Know that every specific problem has its own specific solution.

24. Don’t be a hero

A lot of times it’s better to be a quitter than a hero. As Jason Fried explains,

على سبيل المثال ، لنفترض أنك تعتقد أنه يمكن إنجاز مهمة ما في غضون ساعتين. لكن بعد أربع ساعات من ذلك ، ما زلت فقط ربع الطريق. الغريزة الطبيعية هي التفكير ، "لكن لا يمكنني الاستسلام الآن ، لقد أمضيت بالفعل أربع ساعات في هذا!" لذلك تذهب إلى وضع البطل. أنت مصمم على إنجاحها (وتشعر بالحرج قليلاً لأنها لا تعمل بالفعل). أنت تمسك رداءك وتنغلق على نفسك من العالم. - جايسون فرايد

لا تكن مهووسًا. اعرف متى تقلع. لا تتردد في طلب المساعدة.

25. لا تسأل أسئلة ... اطلب المساعدة

عندما يكون لديك شيء لتنفيذه ولست متأكدًا من الحلول ، لا تسأل الآخرين عن كيفية القيام بذلك ... على الأقل ليس على الفور. بدلاً من ذلك ، جرب أي شيء وكل شيء يمكنك التفكير فيه هذا أكثر أهمية كلما كنت أقل ارتياحًا لمفهوم أو لغة.

When you can’t think of anything on your own, search! Find answers and try them out. Modify those answers, see if you can understand why they work, adapt them to your code.

…But always seek advice.

When you have tried everything, and preferably after you have a working solution, now is the best time to seek advice. Look to peers and senior developers to review your code.

I tried to explain the fundamentals of a good developer mindset in this article. I used some part from Code Simplicity book which has a big impact on my thinking process as a developer. When I read this book, there was a lot of moment that I reacted “ohh I did this mistake, I did that too.” I mentioned some important parts of the book and combine them with my experience.

I strongly recommend you to read Code Simplicity from Max Kanat-Alexander.

شكرا للقراءة! آمل أن يكون هذا الدليل قد ساعدك!

يمكنك قراءة المزيد من مقالاتي على // huseyinpolatyuruk.com .